본문 바로가기

Sorry Architecture

Correction of Error (CoE)

고객 영향이 있는 서비스 장애를 검토하고 개선할 점과 재발 방지대책을 식별하는 것은 중요하다. 이러한 과정을 사후 분석(Post-incident Analysis)라고 부르는데, 중요한 결과물로 근본 원인 분석(Root Cause Analysis, RCA)와 개선 계획 [각주:1]이 있다. 이를 위한 메커니즘 중 한 가지로 오류의 정정(Correction of Error, CoE) 절차가 있는데,[각주:2] 이를 활용하면 원인을 식별 및 규명하고, 근본 원인을 해소하여 동일한 원인으로 발생할 수 있는 사고를 방지하는 안전 장치(Fail-safe mechanism)[각주:3]를 만드는데 많은 도움을 얻을 수 있다.
 
CoE의 구성요소에는 사고 요약(Incident Summary), 영향(Impact), 지표(Metric), 5 가지 질문(5 Whys), 개선 항목(Action Items), 관련 항목(Related Items)이 있다. 가장 먼저 사고 요약은 가장 앞에 위치하지만, 사실 가장 마지막에 작성해야하는 항목이다. 사고 요약에서는 누가 영향을 받았고, 언제 어디서 어떻게 발생했는 지 자세한 내용을 포함하여 사건의 전반적인 맥락을 제공해야 한다. 그리고 문제를 확인하기 까지 걸린 시간과 조치 방법, 그리고 재발 방지 계획에 대한 자세한 내용도 포함해야 한다. 그러면서도 CEO 같은 주요 관계자에게 출장보고 메일을 작성하듯이 간략하게 요약해야 한다.
 
다음으로 사건이 영향을 끼친 범위를 다루는 영향(Impact) 부분이 있다. 여기에서는 고객과 비지니스에 얼마나 영향을 끼쳤는 지 보여줄 수 있도록 정량화 할 필요가 있으며, 이를 위해서 영향 받은 고객 수와 같은 구체적인 정보를 수집하는 것이 중요하다. 

  • 몇 명의 고객이 영향을 받았는가?
  • 기능적인 요구사항 외 영향을 받은 것은 무엇인가? (보안, 성능 효율성, 비용 최적화 등)
  • 사건의 결과는 무엇인가? (이 사건이 또 다른 사건을 유발했는가?)

 
다음으로 근본 원인 규명 위한 일관성있는 접근법을 제공하는 다섯가지 질문(5 Whys)이 있다. 최대 5번의 질문을 통해 사고의 본질적인 원인을 살펴보는 과정을 거치는데, 여기서 중요한 것은 비난 없는(Blame-free) 방식으로 진행해야 하는 것이며, "누가" 보다는 "왜"에 더 집중하는 것이다. 이렇게 하면, 책임자를 찾고 끝내버리기 보다는, 근본 원인을 찾아서 시스템을 개선하는 방향으로 나아갈 수 있다. 예를 들어, "인적 오류" 가 근본 원인이었다고 보고서에 작성했다면, 이 것은 점검 항목이나 안전 장치가 부족했다는 것을 의미할 수 있다.    
 
예제:

  • A 클라우드 컴퓨팅 제공업체의 리전(Region)에서 동작하는 서비스들이 60분동안 사용 불가능했다.
  • #1 이 사고가 왜 일어났는가?
    • 서버들이 로드 발란서 또는 다른 서버의 IP 주소를 조회하지 못했기 때문이다.
  • #2 서버들은 왜 IP 주소를 찾지 못했는가?  
    • DNS 서버가 없었기 때문이다.
  • #3 DNS 서버는 왜 없었는가?
    • DNS 서버의 자동 확장(Auto-Scaling) 정책에서 용량이 0으로 설정되어 있었다.
  • #4 설정은 왜 변경되었는가?
    • 배포 과정에서 용량 설정이 0으로 변경되었다.
  • #5 현재 절차에서 설정을 검증하는 과정이 왜 없었는가?
    • 자동 확장 정책에는 검증하는 기능이 없었다.

개선 항목(Action Items)
개선 항목은 오류의 정정 절차의 주요 결과물이다. 개선 항목의 목적은 근본 원인의 진단, 해결, 방지를 개선할 수 있는 실행 가능한 항목을 식별하여 향후 같은 원인으로 인한 사고가 나지않도록 하는 것이다. 개선 항목의 바른 사례는 구체적인 목표 일정과 실행 내용을 포함하고 있다. 
 
예제:

  • DNS 서버 자동 확장 정책에 제약 사항을 추가한다 (7월 7일까지): 최소 용량 > 1, 목표 용량 > 최소 용량

 

'Sorry Architecture' 카테고리의 다른 글

About Pull Requests  (0) 2019.06.01
Chaos Engineering  (0) 2019.05.21
Version Control System  (0) 2019.03.28
Security as Code  (0) 2019.03.03
Polymorphism  (0) 2019.02.21