IT장애, 왜 반복되는가?

[지디넷코리아]IT조직에게 ‘장애’는 두려운 존재다. 장애가 발생하는 경우 IT조직의 무능함을 질타하는 사용자 측의 비난을 만나게 된다. 들 불처럼 일어나는 장애에 대한 관심도 IT조직의 입장에서 부담스럽다. 그런데 이렇게 두려운 장애임에도 불구하고, 장애에 대응하는 일부 IT조직의 접근법은 나이브(naïve)하기 그지없다.

 

이들 IT조직들은 장애의 직접적인 발생원인을 찾아내는 데에만 집중할 뿐, 장애가 발생하게 된 다양한 원인들을 찾아내는 활동은 게을리하고 있다. 장애에 대한 단순한 대응은, 유사한 원인으로 인한 장애의 재발을 막을 수가 없다. 단순한 장애 대응으로 IT장애를 반복하고 있는 IT조직에 대해서 이야기 해보겠다.

 

■ 장애 대응의 사례

 

A회사 IT조직의 장애 기록을 검토하면서 발견한 장애 대응 사례를 하나 소개하겠다.

 

업무시간 중에 회사 내에서 여러 개의 어플리케이션을 동시에 사용하지 못하는 장애가 발생했다. 사용자로부터 많은 신고 전화가 들어왔고, IT조직에서는 장애를 유발한 곳이 어딘지 찾기 시작했다.

 

우여곡절 끝에 이 IT조직은 신규로 들여온 네트워크 장비가 장애를 유발한 것이라는 것을 알아냈다. 네트워크 장비의 설정 파일 값이 잘못 입력되어 있었던 것이다.

 

이 IT조직이 장애의 원인을 찾아내는 동안, 장애로 인한 사용자들의 불만이 쏟아졌으나, 장애의 원인이 된 네트워크 장비의 설정 파일 값을 수정한 이후로는, 사용자들의 불만이 잦아들었고, 정상 상황이라고 판단한 IT조직은 이 장애를 종결 처리하였다.

 

이 IT조직이 작성한 장애의 기록은 여기까지다.

 

장애 기록에는 장애의 근본원인을 분석하는 공간이 있었으나 비어있었고, 장애의 원인을 찾았으니 장애의 종료는 당연한 것이 아니냐 하는 담당자의 반문 섞인 설명이 뒤따랐다.

 

■ 데자뷰(déjà vu)?

이 IT조직의 장애 대응 방식은 우리 사회 어디에서 본듯한 모습이 아닌가?  남대문화재, 대구지하철사고, 물류창고 화재사고 등 우리 나라의 재해를 다루는 모습과 겹쳐진다고 생각하지 않는가?

 

재해가 발생하면 재해의 발생 원인을 찾느라 호들갑을 떨다가 어느 정도 소명이 되는 발생 원인을 찾게 되고, (웃긴 건지 슬픈 건지 모르겠지만, 우리나라는 주로 처벌을 목적으로 발생 원인을 찾는다.) 희생자 처리와 담당자 처벌이 완료되면 해당 재해는 자연스럽게 종료되어 버린다. 유사한 재해가 또다시 반복되고 있고, 앞으로도 반복될 수 밖에 없는 운명이다.

 

위에서 언급한 장애대응 사례는 대한민국 사회의 ‘후진국형 재해 대응 방식’과 너무나 닮아있다.

 

■ 무엇이 문제인가?

장애의 원인은 장애를 유발하게 만든 ‘직접적인 원인’과 그 직접적인 원인을 유발하게 하는 ‘환경적인 원인’으로 나뉜다.

 

장애의 ‘직접적인 원인’은 IT조직뿐만 아니라, 사용자 측에서 워낙 관심이 많기 때문에 IT조직입장에서는 반드시 찾아내서 소명해야만 한다.

 

반면에 ‘환경적인 원인’은 IT조직 ‘내부’의 프로세스나 업무 방식에 관련된 것이기 때문에 IT조직의 외부, 즉 사용자 측에서는 별 관심이 없는 경우가 대부분이다. 따라서 사용자 측에 대한 ‘대응’에만 유독 집중하는 IT조직의 경우, 굳이 환경적인 원인까지 찾아낼 필요성을 크게 느끼지 못하게 된다.

 

장애의 ‘재발’은 이러한 장애의 ‘환경적인 원인’을 등에 업고 발생하게 된다. 환경적인 원인을 찾아내서 제거하지 못하면 유사한 장애의 재발을 막는 것은 불가능하다.

 

위에서 언급한 장애 대응 사례의 경우, 직접적인 원인은 ‘네트워크 장비의 설정 값 오류’라고 할 수 있다. 하지만 네트워크 장비의 설정 값 오류를 일으킨 ‘환경적인 원인’은 밝혀내려고 시도 조차하지 않은 것이 문제이다.

 

■ ‘부실한 변경 프로세스’가 환경적인 원인

 

그러면 이 장애의 경우 ‘환경적인 원인’은 무엇일까? 이를 확인하기 위해서는 장비를 설치할 당시로 거슬러 올라가야 한다.

 

이 IT조직은 장비설치를 할 때는 반드시 ‘변경 프로세스’를 거치도록 규정하고 있다. 그래서 해당 네트워크 장비의 변경 기록을 검토해 보았다.

 

변경 기록에는 장비의 ‘설치 계획’과 ‘설치 결과’가 포함이 되어 있었다. 그러나 설치 계획과 설치 결과의 내용이 너무 빈약했고, 설치 결과에는 ‘정상’이라고만 기술되어 있었다. 단순하게 생각해보자. 설치 결과가 ‘정상’인데, 왜 네트워크 설정 파일 값이 잘못 설정되어 장애가 발생했을까?
 
이미 짐작한 사람이 있겠지만, 이 IT조직의 ‘변경 프로세스’ ‘수준’으로는 네트워크 설정 파일 값의 오류를 사전에 ‘검증’할 수가 없다는 것이 그 이유이다.

 

설치계획에는 언제 어떤 순서로 누가 설치하겠다는 정도로만 기술이 되어 있고, 설치 이후에는 네트워크 장비가 잘 ‘작동’된다는 점만을 확인하여 설치 결과를 기록하고 있기 때문에, 이 IT조직에서는 ‘정상적인 네트워크 설정 파일 값’이 무엇이며, 설치과정에서 제대로 설정했는지를 확인할 수 있는 방법이 없다.

 

변경 프로세스의 ‘디테일’을 강화하지 않는 한 위와 같은 유사한 장애의 재발을 방지할 수가 없다는 얘기다.
이 장애대응사례의 경우, 결국 IT조직 내부의 부실한 변경 프로세스가 장애의 ‘환경적인 원인’인 것이다.
반복되는 장애의 배경에는 이처럼 IT조직 내부의 ‘부실한 프로세스들’이 또아리를 틀고 있다.

 

■ 장애의 선진 사례- 장애 사후 검토(Post incident review)

단순한 장애대응에서 벗어나 적극적으로 장애를 대응하기 위해, 선진국이나 선진 기업에서 도입하고 있는 방법 중에 하나가 ‘장애 사후 검토’ 활동이다.

 

‘장애 사후 검토’ 활동은 ISO 20000 표준과 ITIL에서 다루고 있는 문제 관리 프로세스(Problem management process)를 좀더 확장한 것이라고 보면 된다.

 

문제 관리 프로세스는 ‘밝혀지지 않은’ 장애의 ‘근본 원인’을 조사하는 것이 목적인 반면에, 장애 사후 검토 활동은 밝혀지지 않은 장애의 근본 원인뿐만 아니라, 위에서 언급한 ‘환경적인 원인’과 장애 발생 이후 IT조직의 대응 과정이 예상대로 또는 성공적으로 진행이 되었는지 여부도 검토하는 것이다.

 

문제관리 프로세스를 잘 운영하고 있는 IT조직은 별도로 장애사후검토 활동을 가질 필요가 없이, 기존 문제관리 프로세스의 검토항목을 추가한다면 장애 사후 검토 활동의 이득을 모두 누릴 수가 있다.

 

■ 장애를 대하는 태도가 바뀌어야 한다

 

장애를 뿌리뽑겠다고 선언하는 IT조직을 종종 만나게 된다. 그러나 ‘의욕’은 장애의 환경적인 원인이라는 강력한 암초를 만나면서 꺾이는 경우를 보게 된다.

 

환경적인 원인을 찾아야 한다는 필요성을 이해하고, 환경적인 원인을 찾아내는 데까지는 성공했으나, 그 원인을 제거하기 위해서는 결국 부실한 내부 IT 프로세스에 ‘메스’를 데야 한다는 사실을 알게 되는 순간, 들고 있는 ‘메스’를 주머니에 다시 집어넣어버리는 IT조직을 경험한 적이 있다.

 

발생한 장애는 어쩔 수 없다. 그러나 유사한 장애가 재발하지 않도록 하는 것은 IT조직이 사용자들에게 지켜야 하는 의무이자 약속이다.

 

이 약속을 지키기 위해서는, 어떤 희생을 치르더라도 IT조직 내부의 프로세스를 과감하게 뜯어고치겠다는 결심이 뒤따라야 한다는 ‘냉정한’ 현실을 IT조직은 분명히 알아야 한다. 이 정도의 노력과 용기도 없이 ‘무 장애’ 선언과 같은 ‘공수표’를 날리지 말라는 말이다.

http://www.zdnet.co.kr/ArticleView.asp?artice_id=20090417101741

위의 글처럼 충분히 사전점검을 하고, 장애를 대하는 태도가 바뀌어야 한다는것에 백배공감...
하지만 대부분은 보통 어쩔수 없이 몇건정도는 발생한다라고 생각하고, 허용을 해주는것이 더욱더 결함이 생기게된 계기가 아닐까 싶다...