NMS 개념 - 장애관리 여덟번째

LOG 관리 프로그램 사용에서 LOG 관리 시스템 구축으로의 개념 전환이란 그리 쉽지만은 않다. 이 시스템이라는 것은 H/W, S/W, 그리고 개발이 들어가야 하므로 돈이 어마어마하게(!) 들어가기 때문이다.

 

대부분의 경우 LOG 는 대용량 데이터이다.

대용량 데이터의 대한 처리와 투자 비용은 돈과 연관된 곳에서는 그리 크게 여져지지 않는다. 통신사에서의 콜 횟수나 문자에 대한 데이터 들 또는 카드사의 기록들, 그리고 은행 입출금 기록들이 그러하다. 이런 과금, 결제에 관련된 데이터들은 매우 중요하며 하나라도 유실될 경우 기업의 손실 또는 이익과 직결되므로 대용량일지라도 하나도 빠짐없이 매우 소중히 다루어지게 된다.

그리고 그 결과물도 매우 명확하다.

접속 기록 1회 20초 500원. 하나 놓치면 500원 손실.

투자비용 10억이면 100억 이익.

이 얼마나 명확하며 알기 쉬운가.

 

그러나 이 네트워크 관리에서 발생하는 LOG는 그렇지가 않다.

애시당초 snmp나 syslog 라는 프로토콜 자체가 udp라는 손실을 허용하는 것인데다가,

데이터가 유실된다고 해도 당장 눈에 보이는 손실이 발생하는 것이 아니기 때문이다.

게다가 그 결과물도 그리 명확하지 않다.

네트워크에 장애가 나서 원인이 뭐냐고 물으면 걸핏하면 log가 남아있는 게 없어

알 수 없다고 한다. 그래서 그럼 시스템을 구축하라고 하면 그것도 구축하려면 수억이 든단다.

그래서 그럼 근거를 가져와 봐라(ROI 분석) 하면 안 가져 온다.

어쨌건 장애가 하도 발생하니 수억을 들여 구축해 주었더니,

이번에 장애가 발생한 부분은 구축 범위에서 제외된 곳에서 발생한 것이란다.

구축범위 내라서 다행히 로그가 남아 있는 경우도 뭔가 명확한 게 없단다.

그래서 이유를 물었더니 디버깅 모드가 아니라서 자세하지 않단다.

대체 무슨 소린지 알 수가 없다.

 

이런 식이니 경영진이 보기에는 개념 자체도 명확하지 않은 이 LOG 관리 시스템이라는 것이

사기같다는 생각이 들 수 밖에 없다.

특히 구축할 때는 마치 만능이던 것처럼 떠들어대던 업체 말만 듣고 구축 했는데,

막상 구축하고 보니 이래서 안되고 저래서 안되고 한다.

업체가 사기를 쳤거나 네트워크 담당자들이 무능하거나 둘 중에 하나라고 생각할 수 밖에...

그래서 담당 부서에서 뭔가를 구축하려고 한다 해도 투자를 할 수가 없다.

그러니 점점 더 모르겠다.

그래서 뭔가 알 수 없는 문제가 발생하면 항상 네트워크 쪽을 의심할 수 밖에 없다.