인시던트 관리가 문제사항에 대해 즉시적인 해결을 하는 게 목적이라면, 문제 관리의 목적은 인시던트의 원인을 파고들어 근본 원인(root cause)을 밝혀냄으로써 해당 원인과 관련된 인시던트가 반복되지 않도록 하는 것이다. 즉, 인시던트 관리 프랙티스가 조치 및 수정을 다룬다면, 문제 관리 프랙티스는 예방에 중점을 둔다고 할 수 있다. 또한 인시던트 관리는 신속성이, 문제 관리는 정확성이 핵심이다.
ITIL에서 정의하는 문제(Problem)란 다음과 같다.
ITIL 문제 정의
"A cause, or potential cause, of one or more incidents"
"한 개 이상 인시던트의 실재하는 원인이나 잠재적 원인"
인시던트의 근본원인을 알 수 없을 때에만 문제로 등록이 되며, 근본원인이 식별되면 문제 관리 프로세스에 따라 진행한다.
앞서 알아본 바와 같이 인시던트는 보통 모니터링 도구에서 이벤트를 통해 자동으로 발행되거나 사용자가 직접 등록할 수도 있다. 반면 문제는 근본원인을 알 수 없는 인시던트에 대해 이를 추적관리가 필요하다고 판단한 IT 팀에서 등록하는 것이 일반적이다. (사용자와 이벤트는 문제 등록 주체가 아님) 대부분은 인시던트를 가지고 문제를 등록하지만, 특정 이벤트가 반복되는 패턴을 보고 이를 문제로 등록할 수도 있다.
PC가 갑자기 안 될 때 우리는 우선 전원을 껐다 켜 보기도 하고 프로그램을 지우고 다시 설치하기도 한다. 그렇게도 해결이 안 되어 다시 면밀하게 원인 분석을 해 본 결과 하드웨어 드라이버를 최신으로 업데이트하면 해결된다는 것을 알게 되었고 이를 적용하여 PC가 다시 정상으로 돌아왔다.
이렇게 문제를 해결하기 위한 과정과 활동들을 문제 관리 프랙티스라고 할 수 있다. 이 활동을 통해 문제의 영구적인 솔루션을 찾는다.
문제 관리에서 중요한 몇 가지 용어가 있다.
• 근본원인 Root Cause
지붕에서 물이 새는 것은 이벤트이고, 물이 새서 방바닥을 흥건이 적셨다면 인시던트이며, 세숫대야로 떨어지는 물을 받는다면 이는 인시던트를 해결한 것이다. 그러나 이렇게 하는 것은 진정한 해결책이 아니다. 나중에 비가 오면 물은 또 샐 것이므로 근본원인을 찾아 조치해야 한다. 물이 새는 근본 원인은 지붕에 구멍이 생겼기 때문이다.
• 근본원인 분석 Root-Cause Analysis
RCA라는 근본원인 분석 활동을 통해 근본원인을 찾는다. 복잡한 인시던트의 근본원인을 찾는 것은 쉬운 일이 아니므로 관련 분야의 전문가가 함께 수행해야 한다.
• 영구적인 솔루션 Permanent Solution
문제의 근본원인을 찾았으면 다음 활동은 영구적인 솔루션을 찾아 적용하는 것이다. 그러나 조직의 판단에 따라 이를 적용하지 않을 수도 있다. (기술적, 재정적 이유 등)
• 워크어라운드 Workaround
인시던트의 영향도와 발생 가능성을 감소시키거나 아예 제거하기 위한 임시방법(솔루션). 위에서 언급한 대로 상황에 따라 영구적인 해결책을 적용하지 못할 수도 있다. 가령 매우 노후화된 서버가 매일 한 번씩 죽는데 이를 신규 장비로 대체하기에는 서비스 종료가 얼마 안 남았기 때문에 적절하지 않다고 판단된다면 그냥 그때그때 WAS를 재기동하는 워크어라운드를 최종 솔루션으로 생각할 수도 있다.
• 알려진 오류 Known Error
에러는 인시던트를 유발할 수 있는 결함 및 취약점이며, Known Error (KE)란 분석이 완료되었으나 아직 해결되지 않은 상태의 문제로 근본원인이나 워크어라운드가 파악된 문제이다.
• KEDB Known Error Database
모든 KE가 등록된 데이터베이스이다. 여기에는 인시던트 및 문제, 에러, 증상, 워크어라운드 및 해결방안(솔루션) 등이 기록된다. 단 영구적인 솔루션이 적용된 문제는 제외된다. 비가 새는 지붕을 수리하여 더이상 비가 안 샌다면 솔루션이 영구적으로 적용된 것이므로 더이상 KEDB에 있을 필요가 없다.
문제관리는 다음의 단계로 구성된다.
• 문제 식별 Problem Identification
인시던트 기록을 정기적으로 분석해서 유사하거나 반복적인 것들을 식별한다. 발생하는 추세를 분석하는 것도 한 방법이다. 또 개발 기간동안 해결되지 않은 버그는 운영 단계의 문제로 전환될 수도 있다. 문제를 식별할 때는 공급업체와 서드파티에게도 정보를 제공하여 적극적으로 참여할 수 있도록 해야 한다.
COTS(상용제품)의 경우는 잠재적인 문제의 목록을 소비자에게 공지하기도 한다.
• 문제 통제 Problem Control
식별된 문제를 분석하여 근본원인 및 영구적인 솔루션. 워크어라운드, KE 등을 문서화한다. 여기서는 문제를 카테고리 별로 분류하고 문제 간의 우선순위를 결정한다. 분류기준은 인시던트와 동일하게 하며, 우선순위는 문제의 발생가능성(probability)과 영향도(impact)를 바탕으로 부여한다.
근본원인이 식별되면 이를 구현할지 결정하는데, 영구적인 솔루션을 구현할 수 없을 때는 어떻게 할지 결정해야 한다.
• 에러 통제 Error Control
KEDB에 있는 영구적인 솔루션이 적용되지 않은 오류나 KE에 대해 상태를 정기적으로 점검해서 고객 및 비즈니스 영향도, 영구적 솔루션 가능여부 및 구현 비용, 워크어라운드의 효과성 등에 대해 평가한다. 솔루션 적용을 위한 변경 요청은 변경 촉진(Change Enablement) 프랙티스로 이어진다.
