1 개요

2 사후검토 활동이란?

3 무엇을 검토하는가?

4 사후 활동이 부실한 IT조직들

5 사후 검토 활동의 방법

6 사후 검토활동을 위한 전제조건

7 재해에 대한 사후검토활동

8 변경작업에 대한 사후검토활동

9 사후검토활동의 중요성

IT조직의 성숙도가 높아지면서, IT의 운영활동들은, 사건이나 요청이 발생하면, 움직이는 ‘수동’적인(Re-active) 대응에서, 사건이나 요청이 발생하기 전에 미리 검증 또는 예측하는 ‘적극’적인(Pro-active) 예방활동으로 중심이동을 하게 된다. 자동차 업계나 가전 업계에서 애프터서비스(after service) 대신, 비포서비스(before service)를 채택하게 되는 것과 비슷한 맥락이라고 볼 수 있다. 국내 IT조직들도, 규모나 성숙도 측면에서 하위 그룹을 제외한다면, 대체로 적극적인 예방활동을 경영층에서 주도적으로 주문하고 있는 모습을 목격하게 된다. 하지만, 국내 IT조직들을 관찰해보면, 사전예방활동의 저변 확대에 비해서, 중대한 사건이나 이벤트가 발생한 이후, 이에 대한 ‘대응’이 적절했는지를 검토하는 ‘사후검토(Post review)’ 활동은 별로 관심을 기울이지 않고 있는 경우가 많다.

IT분야에서 일상적으로 또는 비일상적으로 발생하게 되는 사건이나 이벤트는 어떤 것이 있을까? 장애, 재해, 변경작업 및 각종 요청처리 등이 IT조직내에 흔히 또는 드물게 일어나는 사건이나 이벤트들이다. 이들 중에 IT조직 또는 IT조직의 이해당사자들에게 ‘영향(impact)’을 줄 수 있는 것들을 골라본다면, 장애, 재해 및 변경작업 정도가 된다. IT분야를 포함한 다양한 영역의 글로벌 표준이나 글로벌 조직에서는, 이처럼 조직이나 이해당사자들에게 ‘영향’을 줄 수 있는 사건이나 이벤트들에 대해서는 ‘사건 종료 이후’에 객관적인 검토 활동을 수행하도록 하고 있다.

IT조직내에서 일상적으로 발생하는 ‘장애’를 예로 들어보자. IT조직중에 장애 대응절차를 만들어 놓고 있지 ‘않는’ 조직을 본 적이 없다. IT조직의 장애 ‘관심도’(주로, 경영진의 관심도)에 따라, 단순한 비상연락 절차만을 가지고 있는 IT조직이 있는가하면, 외관상 복잡한 통지 경로와 대응 순서를 포함한 상세한 장애 대응절차를 가지고 있는 IT조직이 있다.

장애가 발생하고 종료된 이후에, 검토해야 하는 가장 중요하고도 기본적인 ‘대상’은, 장애가 발생하면 따르기로 한 ‘장애 대응절차’다. 장애로 인한 수년간의 고초(?)와 비난을 겪으면서, 탄생하게 된 장애 대응절차가, 이번 장애에서 정상적으로 작동되었는지를 검토하는 것은 너무나 당연한 일이지 않은가. 만약, 이번 장애에서는 장애 대응절차가 전체적으로 무시되었거나, 부분적으로 차이가 발생하였다면, 그 원인을 찾아보는 것도 검토 대상의 하나가 되겠다.

국내 IT조직들이 장애가 종료된 이후에 수행하는 활동은, 장애보고서를 ‘작성’하여 경영층에 장애 결과를 ‘보고’하는 자리를 갖는 것이 대부분이다. 장애가 ‘갓’ 종료된 시점에 나온 장애보고서 내용은, 당연히 장애의 발생 경위, 피해, 그리고 어떻게 조치했는지 정도의 내용이 담겨져 있을 수 밖에 없다. 그 이후에 해당 장애와 관련하여 진행되는 활동이라고 해봤자, 장애담당자(사실 국내에서는 장애담당자라는 말보다는, ‘하필이면’ 장애가 발생한, 그 시스템의 담당자라는 표현이 맞겠다.)가 가끔씩 생각날때마다 호출하는 경영자를 위해, 장애보고서의 버젼을 업데이트하는 정도다. 위에서 언급한, 장애 대응절차의 정상적인 작동 여부를 검토하는 활동을 수행하고 있는 국내 IT조직을 발견하기는 쉽지 않다.

장애 대응절차의 정상적인 작동 여부를 검토하는 활동을 수행하기 위해서는, 장애발생 당시에 장애의 시작부터 종료때까지 관여한 모든 임직원들이 참여해야 한다. 또, 이 검토활동을 위해서는, 장애 대응 과정에서의 대응활동, 의사결정, 해결이나 조사를 위해 사용된 시스템 명령어들을 정확한 시간과 함께 기록해야 한다. 모든 담당자와 장애 대응 기록을 가져다 놓고, 기존에 보유하고 있던 장애대응절차와 비교하면서, 검토 활동을 진행하게 되는 것이다.

대부분 IT조직에서는, 장애가 발생하게 되면, 장애담당자가 장애의 모든 역할 및 책임을가지고 있어, 위에서 언급한 상세한 장애기록을 만들어낼 수가 없다. 장애를 조치하는 사람과 기록하는 사람이 동일인이기 때문이다. 장애 조치자는 본인이 어떤 대응을 또는 어떤 명령어를, 몇시 몇분에 사용했는지를 ‘복기’하기 어려울 뿐더러, 장애 대응과정에 관여하는 ‘다른’ 사람들이 어떤 대응을 했는지를 알 수가 없다. IT조직이 장애를 매우 중요한 사건으로 다룬다면, 장애 발생 시점에 기록을 할 수 있는 사람이나 방법을 반드시 마련해야 한다. 그래야만, 장애에 대한 사후 검토활동을 ‘의미’있는 활동으로 보장할 수 있다.

글로벌 표준과 글로벌기업에서는, 너무도 당연한 얘기지만, 재해가 발생한 경우에도 동일한 개념의 사후 검토활동을 수행하도록 요구하고 있다. 이때 사후 검토의 비교대상은 장애대응매뉴얼이 아니라, 인시던트관리계획(Incident management plan) 또는 비즈니스연속성 계획(Business continuity plan)이 되게 된다. 사후검토활동에 참여하는 대상도 장애보다는 더 많으며, 한 번이 아닌 여러번에 걸쳐 사후검토활동이 진행되기도 한다. IT분야는 아니지만, 재해가 발생했을 때, 어떻게 사후검토활동을 수행하는지는 영국의 번스필드 인시던트 조사위원회(MIIB, Buncefield Major Incident Investigation Board)의 홈페이지(http://www.buncefieldinvestigation.gov.uk/index.htm)를 벤치마킹하면 도움이 될 수 있다.

변경작업에 대한 사후검토활동은 ITIL에서 사후 구현 검토(Post implementation review)라고 부르는 용어와 일치한다. 변경작업에 대한 사후검토활동은, 해당 변경작업을 실행하기 전에 수립한, ‘변경계획’, ‘변경영향 검토 결과’ 및 ‘사전에 식별된 위험결과’를 대상으로, 변경작업결과와 비교하는 활동이다. 변경작업은 ‘장애’나 ‘재해’와는 달리, 긍정적인 목적을 달성하기 위해서 의도적으로 실행하게 된다. 따라서, 변경에 대한 사후검토활동에서는, 추가적으로, 변경작업이 반복장애의 해결, 사용자 기능개선, 잠재적인 문제의 해결과 같은 ‘이득’을 실질적으로 달성했는지도 검토 대상에 포함시킨다. 또 하나 추가되는 것은, 변경작업으로 인해, 원하는 목적은 달성했으나, 다른 IT기능들에 장애나, 비정상적인 영향을 유발하고 있지는 않은지(흔히, side effect라고 부른다.)도 검토 대상에 포함한다.

과거나 현재보다 더 높은 IT 수준을 원하는 IT조직은, 사후검토활동을 내부의 공식프로세스로 도입하는 것을 검토해볼 필요가 있다. 모든 장애, 재해, 변경작업에 대해 일괄적으로 적용할 수도 있고, 그 중에 중요하다고 판단하거나 분류한 것들을 ‘선택’해서 적용할 수도 있다. 또, 이것을 응용하여, IT조직내에서 일어나는 다양한 이벤트들, 그 중에서 계획을 하거나, 예측을 준비했던 이벤트들(예. IT프로젝트, 설비이전, 모의훈련 등)에는 하나같이 이러한 사후검토활동을 적용해 볼 수 있다. IT조직내에서 일어나는 많은 계획된, 또는 돌발적인 사건과 이벤트에 대해서, 미리 계획이나 준비를 가지고 있고, 사건과 이벤트를 경험했다면, 잊혀져버리기 전에 사후검토활동을 실행해보자. IT조직이 그간 준비한 계획이나 준비의 수준이 ‘괄목’할만하게 정밀해지고 정확해진다는 경험을 하게 될 것이다.

트랙백 주소 : http://www.zdnet.co.kr/Reply/trackback.aspx?key=20100817082527