[칼럼]장애 중단시간을 줄이는데 무관심한 IT조직들

어떤 이유에서건 장애가 발생하지 않기를 간절히 기도(?)하는 심정은 IT조직의 동병상련이다. 하지만 장애가 발생하지 않는다는 것이 불가능한 목표라는 것을 IT조직뿐만 아니라, IT외부에서도 인정하고 있는 추세다.

그렇다면, IT조직은 장애가 발생한 이후의 ‘대응’(response)에 대해서 좀더 노력을 집중해야 할 때다. 왜냐하면, 발생한 장애에 대한 IT조직의 대응에 따라, 장애의 영향 또는 피해를 최소화할 기회가 줄어들거나 늘어나기 때문이다.

특히, 장애의 ‘신속한’ 대응을 통해 장애의 ‘중단 시간’ 자체를 줄인다면, IT조직과 사용자들에게 여러 가지 면에서 혜택을 줄 수 있다.

하지만, 국내외 IT조직들을 관찰해본 결과, 장애 중단 시간을 줄이기 위해서 무엇을 어떻게 해야 할지에 대한 고민이나 노력들이 부족하다는 것을 느껴왔다. 이번 칼럼에서는 장애 중단 시간과 관련된 IT조직의 문제점에 대해 이야기 해보겠다.

■ 장애의 ‘수명’

사람이 탄생, 성장 및 사망의 라이프사이클을 가지고 있듯이, 장애도 탄생, 진행 및 종료의 라이프사이클이 존재한다. 사람의 경우는 라이프사이클의 전체 기간이 ‘늘어나기’를 기대하는 반면, 장애의 경우는 태어나자마자 ‘즉시 종료’되기를 (사람이) 기대한다는 차이점이 있다.

장애가 짧은 수명을 가지고 사망(!)하게 된다면, IT조직은 전체 가용성 목표에 긍정적인 효과를 얻을 수 있고, 사용자들도 줄어든 장애 시간에 따른 IT활용도를 높일 수 있는 장점이 있다.

장애가 ‘여러 건’ 발생한 경우와 장애 중단 시간이 긴 ‘한 건’의 장애가 발생해서 사용자들에게 중단의 피해를 준 경우를 비교해보면, 중단으로 인해 사용자가 IT를 사용하지 못한 총 시간은 결국 같을 수 있다.

따라서, 단 한 건의 장애라도 장애의 중단 시간을 줄이는 것은 여러 건의 장애 중단을 상쇄하는 효과를 지닌다고 할 수 있다.

■ 장애의 수명을 줄이는 방법?

장애의 중단 시간을 줄이기 위해서 어떤 활동을 해야 하는지 특별한 아이디어가 없는 IT조직들이 있다. 이런 IT조직들은 주로 장애 발생이라는 ‘사실’에만 신경 쓰거나, 발생한 장애를 어떻게 무마(?)할 것인지에 대해 관심을 기울이는 경향이 있다.

이러한 IT조직들이 장애의 중단 시간을 줄이기 위해서는 어떤 활동을 해야 할까?

장애의 중단 시간을 줄이기 위해서는, 우선 장애의 ‘라이프사이클’을 실험대에 올려다 놓고 ‘해부’해 봐야 한다. 그간 발생한 장애 중 한 건을 골라서, 장애가 ‘발생’한 시간과 완전히 ‘종료’된 시간 사이에 어떤 일들이 발생했는지를 상세하게 분석해봐야 한다는 얘기다.

장애는 통상적으로 ‘발생’-> ‘탐지’->’대응’->’복구’->’종료’의 순서로 일생을 마무리한다. 장애의 해부를 통해 위의 개별 과정에서 어떠한 일들이 일어났는지를 살펴본다면, 장애의 중단 시간을 줄이기 위한 방법들을 뽑아낼 수 있다.

■ ‘탐지’의 지체

장애가 발생했으나, 이를 ‘즉각’ 인지하는 데 실패하게 되면, 그만큼의 중단시간이 늘어나게 된다. 예를 들면, 장애가 오전 10시5분에 발생했으나, IT조직이 이를 알아챈 시간은 10시30분일 수가 있다. 탐지하는 데만 25분이 소요된 것이다.

일정 규모 이상의 IT조직에서는 장애나 이벤트 상황을 즉각 인지하기 위한 모니터링시스템을 도입하고 있다. 그러나 일부 장애는 기술적으로 모니터링 시스템에서 인지하기 어려운 경우가 존재하며, 인지를 하더라도 마침 그 시간에 모니터링 요원이 자리를 비운 경우에는 위와 같은 탐지의 ‘지체’가 발생할 수 있다.

위에서 언급한 탐지의 지체를 요인을 제거하는 위해서는 모니터링 시스템에 좀더 세밀한 설정을 ‘장치’하거나, 모니터링 요원의 업무 배치 방식을 ‘전환’하는 시도를 해야 한다.

■ ‘대응’의 지체

탐지를 한 이후에는 해당 장애를 가장 잘 대응할 수 있는 적임자가 대응에 나서야 한다. 그런데 불행하게도 해당 담당자가 출장이나 휴가로 인해 대응활동을 즉각 수행하지 못하는 경우가 있을 수 있다. 또 최초로 탐지한 IT직원이 해당 장애의 적임자가 누구인지를 즉시 알지 못하는 경우도 있다. 이때 ‘대응’의 지체가 발생한다.

대응의 지체를 제거하기 위해 고려하는 방법 중의 하나는, 한 명의 IT담당자에게 의존하는 IT업무를 줄여나가는 것이다. 대부분의 IT조직들은 이런 경우 ‘정’과 ‘부’ 담당자를 두는 방법으로 의존도를 제거하고 있다. 간혹, 이러한 의존도 제거를 구조조정 위험의 ‘증가’로 오해하는 IT담당자들이 있다. 그래서 많진 않겠지만, 의존도 제거의 긍정적인 목적을 IT담당자에게 추가적으로 설명해야 하는 껄끄러운 상황이 발생하기도 한다.

■ ‘복구’의 지체

적임자가 대응에는 나섰으나, 장애의 해결방법을 즉시 알아내지 못하게 되면 ‘복구’의 지체가 발생하게 된다.

IT에서는 장애의 ‘해결방법’을 두 가지 성격으로 분류한다. 장애의 해결방법이 ‘장비 리부팅’과 같은 원시적인 ‘임시조치’인지 아니면, ‘장비 교체’와 같은 ‘완전한 해결책’인지로 나누어서 판단한다. ‘임시조치’든 ‘완전한 해결책’이든 간에 장애로 인한 중단 상황을 평상시 상황으로 복구하는 것이 장애 대응의 목적이므로 위 두 가지 솔루션을 얼마나 빨리 찾아내는 가가 관건이다.

IT조직중의 상당수가 위와 같은 장애의 해결방법들을 IT담당자의 경험에 의존하고 있는 경우가 많다. IT담당자의 경험에 의존하여 장애를 해결하는 경우가 빈번한 IT조직은 ‘복구’에 소요되는 시간 자체가 결국 들쭉날쭉 할 수 밖에 없다. 이런 IT조직은 ‘복구’의 지체를 ‘자연’스러운 것으로 받아들이는 경향이 있다.

선진화된 IT조직의 경우는, 장애의 해결을 돕기 위해 지식DB(knowledge database)와 구성요소DB를 동시에 유지하고 있다. 지식DB에는 기존 장애 해결방법과 담당자가 발굴한 노하우를 담고 있고, 구성요소DB에는 장애가 발생한 장비나 어플리케이션의 살아온 이력과 최근에 벌어진 일들에 관련된 정보를 제공하고 있다.

하지만, 지식DB와 구성요소DB가 있다 하더라도 복구의 지체는 발생할 수 있다. 원하는 장애의 해결방법을 방대한 양의 지식DB와 구성요소DB에서 빨리 찾아내지 못한다면 지식DB와 구성요소DB의 ‘무용론’이 제기될 수 밖에 없다. 장애 대응의 라이프 사이클 중 마지막인 종료과정에서도 IT조직의 사용자 통지 방법에 따라 사용자 측면의 ‘종료’ 지체가 발생할 수 있다.

■ 장애의 상세한 기록 없이는 불가능

장애의 중단 시간을 줄이기 위한 활동을 의욕적으로 시작해보고자 하는 IT조직은 황당한 상황을 맞이할 수 있다. 그 동안의 장애 기록을 뒤져보니 장애를 해부할 수 있을 정도의 장애 기록이 하나도 없다는 사실을 발견한 것이다.

그러나 어쩔 것인가? 이제부터라도 발생한 장애에 대해서는 시간 기록을 포함한 상세한 장애 기록을 남기기 시작해야 하고, 상세한 장애 기록이 어느 정도 쌓였다고 생각한 이후에 중단 시간을 줄이기 위한 활동을 시도할 수 밖에 없다.

장애가 발생하면 대응하느라 바쁜데 어떻게 상세한 기록을 남길 수 있는지를 반문하는 분들이 간혹 있다. 이런 경우, 선진화된 IT조직에서는 장애 대응하는 사람과 기록하는 사람이 ‘한 조’로 움직이는 방법을 사용하고 있다라는 얘기를 들려 준다.

■장애를 현상으로 바라봐야 한다

일반적으로 사건의 당사자들은 사건을 객관적으로 바라보기가 어렵다. IT조직은 장애의 당사자이므로 장애를 바라볼 때 객관적인 입장을 취하기 어려울 수 밖에 없다.