긴급한 사항 '장애'가 발생했을 때 우리는 어떻게 움직이는가

시스템을 운영하고 유지보수하는 사람에게 가장 민감한 단어가 '장애'라는 단어일 것입니다.
우리 회사 블로그에 어떤 분이 가장 좋아하는 것과 싫어하는 것을 정의하였는데 싫어하는
단어 중 하나가 '장애' 이더군요,,

N bank의 사례에서도 보았듯이 장애라고 하는 것은 어느 한 사람 뿐만 아니라 조직과 회사 전체
심지어 국가적인 상황에 대해서도 위기상황을 몰고 갈 수 있는 키워드가 됩니다.

이번에는 이 장애에 대해서 우리가 준비해야 하는단어를 Proactive, Reactie, Predictive로 정의하여

정리해 볼까 합니다. 어떤 상황이든 장애에 대해서는 세가지 상황으로 정리하는 것이 중요합니다.

장애가 나는 상황을 '★'복구하여 시스템이 가동인 상황을 '○'로 가정하여 시스템 가동에 대해서
시간에 따라 각각 별로 형상화하면 다음과 같이 나타낼 수 있습니다.

이 설명에서는 MTTR과 MTBF, MTTF등의 용어설명은 생략하도록 하겠습니다.
다만 장애에 대해서 준비해야 하는 관점 측면에서만 설명하도록 하겠습니다.

장애 복구
<------------------------------------★-------------○------------------------->
③ ① ② ---> Time

Predictive 영역 Proactive영역 Reactive영역

① Proactive영역에서 대비해야 할 사항들은 다음과 같습니다.

미리 장애가 발생하지 않도록 정기적으로 시스템의 Health상태를 검증하는 측면입니다.

매순간, 매일, 매주, 매월 체크해야 하는 사항을 주기적으로 가져가는 것이 가장 베스트한

방법입니다.

모니터링과 Report 측면
- 순간적으로 튀어오르는 이벤트를 감지하여 대처하는 체계 마련 - 이벤트(알람), SMS
- 매일 아침 시스템의 Health(에러메시지 등)를 점검할 수 있는 점검 레포트
- 매주 시스템의 Health)백업/복구 등)의 상황을 점검할 수 있는 레포트
- 매월 시스템의 health(용량추이 등)를 측정할 수 있는 레포트

시스템 작업의 측면
- 일정한 절차(명령어 레벨)에 의해서 체계적으로 작업하는 부분
- 작업의 영향도를 고려하여 CCB를 수행하는 부분
- 테스트환경에서 충분한 검증을 했는지의 부분
- 유사시 Back-off Plan에 대한 부분

② Reactive영역에서 대비해야 할 사항들은 다음과 같습니다.

장애가 발생했을 때 '우왕좌왕', '제멋데로', '체계없음'이라는단어가 나오지 않도록 준비하는 방법

입니다. 이런단어가 장애 이후 나온다면 곤란하겠지요,,,

장애에 대한 조치와 의사소통의 측면
- 장애 조치자와 장애에 대해서 의사소통할 사람의 구분

- 장애 처리과정의 현황을 공유하는 측면(칠판 등 필요)
- 어떤 포인트에서 장애가 발생했는지 체계적으로 발견하는 오류트리
- 순간적으로 개인 뿐만아니라 공동의 많은 사람이 해당 장애에 대한 지식을 공유하고 집약할
수 있는 연락체계(SMS, 전화 등)
- 연관된 운영담당자의 신속한 정보공유와 의사소통 체계및 유지보수 담당자와 연락 체계
- 해당 장애에 대한 histroy를 파악할 수 있는 지식DB의 체계

장애 조치 엔지니어의 측면
- 백업에 대한 완전성 확인
- 파라미터 변경 등 발생시 영향동 제 3자 검증 반드시 수행
- 기술적인 커뮤니케이션을 공개적으로 수행
- 조치시 발생할 수 있는 2차 위험성에 대해서 의사소통 담당자에게 이야기
- 복구 이후 사용자 관점(End user)의 시스템 사용성을 검증함

③ Predictive영역에서 대비해야 할 사항들은 다음과 같습니다.
직접적인 장애에 대한 대비보다는 장기적으로 시스템이 장애로 이어질 수 있는 환경적인 요인 및
장애에 대한 기술력 등을 고려한 활동을 Pre-dictive한 영역으로 정의하여 활동 할 수 있습니다.

시스템 Health측면
- 시스템 용량(디스크, 메모리, CPU, 트랜잭션의 수, Shared Memory등)의 추이가 어떤 지를
미리 파악하여 대비하도록 함
- 유사시 대체 서비스할 수 있는 이중화의 환경이 적정한지 검증하고 필요시 구성함
- 백업/복구에 대한 완전성을 검증하고 유사시 최적의 경로로 복구할 수 있는 체제를 준비함

장애 조치 엔지니어의 측면
- 장애사례에 대해서 기술적인 정보를 공유할 수 있는 체계를 갖춤
- 시스템의 문제가 발생할 경우, 또는 장애가 발생할 경우 핵심적으로 처리해야 하는 기술요소를
사전에 정의하여 내재화 하도록 함

장애는 시스템을 담당하는 사람에게 특히 DBA에게 가장 민감한 영향을 주는 단어이지만,

장애가 있으므로 인해 DBA가 있다는 생각을 반대로 할 수 있습니다.

이것은 마치 병이 있으므로 의사가 있고 바이러스가 있으므로 보안을 하는 사람과 소프트웨어가 있는

것과 비슷한 위치이지요,,

장애를 기점으로 시스템을 잘 운영할 것을 미리 준비하고 대비하면 시스템이 가져다 주는 Value를 극대화

하는 방법이 될 것입니다.