나의 DevOps 여정기 (2)

대기업계열사의 파견직으로 시작한  Zabbix를 통한 서버 관제 고도화  업무

개발 업무를 하지 않으면 좀 더 Devops 업무를 할 수 있겠다 싶었지만, 완전한 착오였다.

일부 Devops 업무가 있었지만 잡무가 훨씬 많았다.

관제 자산 추가, 관제항목 정리, 기본 관제 룰 예외처리, 정기 PM작업...

 

합류하게 된 대기업계열사에서는 정형화된 폼에 관제 룰이나, 대상들을 정리하길 원했고, 나는 Zabbix에서 관제 자산과, Ruleset 등을 추출하여 문서화를 하는데에 시간을 많이 보내게 되었다. 또한 관제 장비 또는 망에 이상이 생겼을 때, 트러블 슈팅 상황을 전제로 어떤 작업을 해야 하는지표준 운영 절차 (Standard Operating Procedure)를 작성해야 했다.

 

투입 당시 운영 유지보수 업무로(SM) 개발 업무가 아예 없었기 때문에 그저 노가다로 웹 UI만 사용하여 업무를 진행하고 있었고,

휴먼에러가 지속적으로 발생하고 있었다. 기존 인원 또한 개발자 출신이 아닌 서버관리자로 OS만 다룰 수 있었다.

효율적인 업무, 휴먼에러를 줄이고 개발을 놓지 않기 위해 API를 활용하여 업무에 활용할 툴을 직접 작성하여 사용하였다.

 

업무를 하다 질려버린 부분이 있었는데,

관제 룰셋을 정의하는 고도화팀이 관제팀 보다 낮은 위치에 있었고, 관제 대상을 추가하거나, 예외처리가 제대로 되지 않아 장애 이벤트가 발생하면 난리가 났다.

 

장애 이벤트 발생은 관제자에게 관제 포인트만 제공하기 때문에 관제자 판단이 우선이다.

관제자가 보기에 오탐이나 예외처리 대상이면 추후에 처리하면 된다.

장애 이벤트 발생보다 실제 장비가 이상이 있는지에 초첨을 맞춰야 한다.

하지만 관제팀에서는 관제시스템을 운영하는 데에 발생하는 사소한 문제들을 쥐 잡듯이 트집 잡고 위에 보고하였다.

 

관제 대상 장비 또는 예외 처리 후에 발생할 모든 상황을 시뮬레이션 하고 장애 이벤트가 발생하지 않도록 완벽한 조치 후에 작업을 진행해야했다. 마치 신성한 의식을 치루는 기분으로 엄숙한 분위기에서 이뤄졌다.

 

주객이 전도된 상황이었다.

"관제는 관제가 되지 않는 것을 경계해야 한다"라고 생각한다.

지속 발생하는 오탐은 실제 탐지에 크게 방해를 주지 않는다면 2순위로 봐야 하는 게 맞았다. 

사소한 이벤트 하나에도 온콜이 열리고  사람들이 모이고 야근을 하는 민감한 상황이 펼쳐지는 것을 보게 되었다.

그리고 그 상황이 발생하면 해당 장비를 등록한 우리의 잘못이 되었다.

 

뭔가 잘못된 것을 느꼈으나 고칠 수 있는 방법은 없었다.

내가 할 수 있는 건 API를 통해 최대한 자동화로 작업을 진행하고 휴먼에러를 방지하는 것뿐이었다.

작업 계획과 스크립트를 만들어 스크린샷과 검증까지 하여 시연하였지만 신뢰성의 이유로 반려당하는 경우도 종종 있었고 온전한 개선으로 이어지지 못한 부분도 아쉬웠다.

 

사내 정치적인 이슈와 협력사라는 이유로 잘못 발생하는 이벤트에 대해서는 책임을 져야 했으며, 이후 보완 조치가 강화되는 것 또한 감내해야 했다. 협력사 구조도 특이하였는데, 내가 합류했을 당시 협력사는 총 3개나 되었다.

협력사간의 불화, 정치까지 이중고를 겪게 되었다.

 

협력사와 현업과의 관계, 한계, 권한, 많은 것을 느낄 수 있었고

결국 다시 회사를 찾게 되었다.

 

3편에 계속....