장애관리와 문제관리

ITIL Service Management Practice 중에 Problem Management 영역이 있습니다.

보통 서비스 유지보수 절차로는 장애 프로세스 또는 장애/이벤트프로세스, 장애예방 프로세스, 문제관리프로세스 등으로 분류하고 있습니다.

 

장애 발생시 전파/보고에 대한 절차가 장애 절차라고 한다면, 문제관리 프로세스는 장애 재발방지 및 예방을 위한 근본원인 분석 및 관리에 촛점을 두고 있습니다. 물론 이 두가지 프로세스는 독립적이 아니라 밀접한 관련이 있습니다.

장애에 대한 용어 설명은 굳이 하지 않아도 이해하고 계시겠지만, 이벤트라는말은 생소할 수 있습니다.

이벤트의 뜻은 ‘고객에게 제공하는 서비스에 영향즉, 장애를 유발할 수 있는 시스템의 징후’ 라고 정의할 수 있습니다.
예) 파일시스템 용량초과, CPU 과다, 서비스 프로세스(데몬) 다운 등을 말합니다.

결국, 장애/이벤트관리란, 서비스의 일부 또는 전체 기능을 이용할 수 없는 상태 뿐만 아니라, 그상태를 유발할 가능성이 있는 징후를 관리하고 예방하는 활동을 의미합니다.

 

장애관리의 가장 큰 목적은 ‘신속복구’ 입니다. 그러기 위해서, 발생된장애/이벤트의 기록, 장애등급 분류, 장애보고절차, 중복장애관리가 중요하겠죠.

그리고 신속복구를 위해서 SPoC(Single Point of Contact)개념이필요합니다. 고객은 장애인지 아닌지 정확하게 모를 수 있지만, 뭔가시스템이 이상있거나, 문제가 있다고 생각되는 부분, 단순문의, 기능개선사항을 문의하고 싶어하는데 누구에게 문의를 해야할 지 모릅니다. 이에헬프데스크 같은 서비스데스크 제도를 구성하여 최일선에서 고객의 문의나 장애 신속복구를 위해 의사소통을 하고 있습니다. 24시간 서비스데스크를 운영하기 어렵기 때문에 서비스데스크를 대신할 웹시스템을 구축하여 고객 문의, 장애 접수를 하기도 하죠. e-SPoC 이라는 이름의 접두사 "e"는 electronic 입니다.

장애, 단순문의, 기능개선(CSR) 이 모든 고객이 요청하는 Action을 인시던트(Incident)라고 합니다. 고객으로부터 접수받은 Incident를 분석하여 infra 영향이 있으면 infra 담당자에게 연결하고, 응용의 문제나 개선요청사항이면 SM부서 담당자에게 연락하며, 기 알려진 문의사항이나 문제에 대한문의라면 KEDB를 활용해서 신속대응하는 것입니다.

 

장애를 신속복구를 하는 것이 무엇보다도 중요하지만 재발 방지를 위해서는 근본원인을 찾아서 재발방지를 하는 것이 더 중요할 겁니다.

장애를 신속복구 했더라도 이건 임시해결책(Workaround) 일겁니다.

장애를 유발시킨 근본원인(Root Cause)를 찾아 제거하는 활동을해야 합니다. 이게 바로 문제(Problem) 관리입니다.

전사표준에서 정의된 문제의 뜻은 ‘1개 또는 그 이상의 장애에 내재하는근본원인(root cause)이 파악되지 않은 장애를 의미한다. 문제는여러 장애의 결과일 수 있다.’ 라고 되어 있습니다.

여기서,장애 및 이벤트에 대한 근본원인이 해결되어 임시 해결 방안, 영구 해결 방안(Solution) 등이 등록되어 유사/중복 장애 및 이벤트의 발생시 활용이 가능하도록 되어 있는 데이터베이스 혹은 문서 형식의 장애/이벤트 해결 저장소를 KEDB(Known Error DataBase)라고 합니다.

장애가 발생되면 KEDB에서 유사 장애에 대한 해결방안이나 정보를확인해서 신속복구에 활용을 한 후 근본원인을 분석해서 Solution을 찾고, 이에 따라 인프라 또는 응용 변경이 필요한 경우 CSR을 작성해서변경요청을 하게 되는 절차입니다.

 

장애 및 문제 관리프로세스는 인프라에만 해당되는 것이 아니라 Application 영역에도모두 적용됩니다.
– 즉, 모든 사람이 절차에 관련되어 있다는것이고, 누구든지 응용관련 장애 등록, 보고, 해결책을 찾을 때 이 절차에 따라 업무를 수행해야 한다는 뜻입니다.