Ch12. 효과적인 장애 조치

이번 장에서는 장애 조치의 일반적인 과정에 대해 알아보도록 하자. 

 

1. 이론

장애 조치 방법은 가설 연역 방법이라고 생각하면 된다.

장애의 잠재적 원인에 대해 가설을 세우고 가설을 시험하는 과정을 반복하기 때문이다.

 

가설을 검증하는 방법은 크게 두 가지가 존재한다.

 

1. 관찰한 시스템의 상태를 이론과 비교하여 정황들이 들어맞는지 확인
2. 시스템을 고쳐보고 그 결과를 다시 관찰

둘 중 어떤 방법을 사용하든, 근본 원인이 발견될 때까지 계속해서 테스트를 수행하고 원인이 발견되면 장애 재발을 방지하기 위해 그에 대한 조치를 수행한 후 포스트 모텀 문서를 작성한다.

 

2. 통상적인 문제

비효율적인 장애 조치 세션은 장애 등급 선정, 분석 및 진단 단계에 영향을 미친다. 이들 중 대부분은 시스템에 대한 깊은 이해가 부족해서 발생한다. 통상적으로 피해야하는 문제점들은 아래와 같다.

• 관련이 없는 증상을 보거나 시스템의 지표 의미를 잘못 이해하는 경우
• 장애 원인에 대한 가능성이 희박한 가설을 세우거나 과거에 발생한 문제의 원인과 결부시켜 한 번 발생한 문제는 다시 발생할 것이라고 결부해 버리는 행위
• 사실은 우연히 발생했거나 혹은 동일한 원인에 의해 발생한 관련 현상들을 계속해서 쫒아다니는 행위

 

위에서 가장 마지막에 말한 연관 현상은 유의할 점이 많다. 우연히 발생한 장애임에도 불구하고 마치 다른 장애와 관련되어 발생한 것처럼 보이는 경우가 발생할 수 있기 때문이다.

 

3. 문제의 우선순위 판단

심각한 장애 상황에서 가장 먼저 취해야 할 조치는 시스템이 정상적으로 동작하게 만드는 것이라고 한다. 나는 생각이 조금 다르다. 장애 상황을 전파하고 시스템이 정상적으로 동작하게 만드는 것이 좋다고 생각한다. 정상적으로 동작하게 만드는 동안 문의가 들어올 수 있고 혹은 장애가 다른 장애를 유발할 수도 있기 때문에 커뮤니케이션을 담당하는 동료에게 전파한 후 장애 처리에 집중하는 것이 좋다고 생각한다.

 

4. 문제를 관찰하기

모니터링 시스템, 로그를 통해 문제가 어디서 발생했는지 확인할 수 있다. 확인 못하는 경우 전체 스택에 걸쳐 요청을 추적하는 대퍼와 같은 도구를 활용할 수도 있다. 그리고 가장 마지막으로 수정된 부분에 주목하는 것도 좋은 방법이다.

 

5. 조치

가능한 원인들을 파악했다면 이들 중 어떤 것이 실제로 문제를 일으킨 근본 원인인지를 파악해야 한다. 실험적인 방법이지만 가설을 하나씩 넣어보거나 혹은 하나씩 제거해 나가는 방법을 사용해 볼 수 있다.

 

장애 조치 과정

 

위 과정을 통해 조치가 완료되었다면 그 과정을 꼼꼼히 기록해야 한다. 이러한 문서는 같은 과정을 반복하는 상황을 피할 수 있게 만들어주기 때문에 아주 큰 도움이 된다. 부정적인 결과가 나왔더라도 꼭 기록하자.

 

6. 결론

장애 조치 과정에 대해서 간략하게 알아보았다. 사실 현업에 바로 적용할 수 있는 내용은 그렇게 많지 않았다. 자신의 상황에 따라 장애를 대응하는 방법은 다르기 때문에 구글에서는 이렇게 하고 있구나, 이런 부분은 적용해도 괜찮겠다는 관점으로 읽으면 좋을 것 같다.