Google Cloud Well-Architected Framework의 안정성 부문에서 이 원칙을 따르면 장애 및 사고 후 효과적인 사후 분석을 수행하는 데 도움이 되는 권장사항을 확인할 수 있습니다.
이 원칙은 안정성의 학습 중점사항과 관련이 있습니다.
원칙 개요
사후 분석은 사고, 사고의 영향, 사고를 완화하거나 해결하기 위해 취한 조치, 근본 원인, 사고 재발을 방지하기 위한 후속 조치에 대한 서면 기록입니다. 사후 분석의 목표는 실수로부터 배우고 비난하지 않는 것입니다.
다음 다이어그램은 사후 분석의 워크플로를 보여줍니다.
사후 분석 워크플로에는 다음 단계가 포함됩니다.
- 사후 분석 만들기
- 사실 정보 수집
- 근본 원인 파악 및 분석
- 미래를 위한 계획
- 계획 실행
다음과 같은 주요 이벤트 및 비주요 이벤트 후에 사후 분석을 수행합니다.
- 특정 기준점을 초과하는 사용자에게 표시되는 다운타임 또는 성능 저하
- 모든 종류의 데이터 손실
- 출시 롤백 또는 트래픽 재라우팅과 같은 긴급 대기 엔지니어의 개입
- 정의된 기준을 초과하는 해결 시간
- 모니터링 실패(일반적으로 수동 사고 발견을 의미)
추천
사후 분석이 필요한 시점을 모두가 알 수 있도록 사고가 발생하기 전에 사후 분석 기준을 정의합니다.
효과적인 사후 분석을 수행하려면 다음 하위 섹션의 권장사항을 고려하세요.
비난 없는 사후 분석 실시
효과적인 사후 분석은 프로세스, 도구, 기술에 초점을 맞추고 개인이나 팀을 비난하지 않습니다. 사후 분석의 목적은 기술과 미래를 개선하는 것이지, 잘못한 사람을 찾는 것이 아닙니다. 누구나 실수를 합니다. 실수를 분석하고 이를 통해 배우는 것이 목표가 되어야 합니다.
다음 예시는 비난을 가하는 피드백과 비난 없는 피드백의 차이를 보여줍니다.
- 비난하는 피드백: "복잡한 백엔드 시스템 전체를 다시 작성해야 합니다. 지난 3분기 동안 매주 중단되었으며 모두가 문제를 조금씩 해결하는 데 지쳤을 것입니다. 진짜로 한 번만 더 호출되면 내가 직접 다시 작성할 거야…"
- 비난 없는 피드백: '전체 백엔드 시스템을 다시 작성하는 작업 항목은 실제로 이러한 페이지가 계속 발생하는 것을 방지할 수 있습니다. 이 버전의 유지보수 설명서는 상당히 길고 완전히 숙지하기가 매우 어렵습니다. 미래의 대기 엔지니어들이 우리에게 감사할 것입니다."
모든 대상이 사후 분석 보고서를 읽을 수 있도록 합니다.
보고서에 포함할 각 정보에 대해 해당 정보가 독자가 발생한 상황을 이해하는 데 중요하고 필요한지 평가합니다. 보충 데이터와 설명은 보고서의 부록으로 이동할 수 있습니다. 추가 정보가 필요한 검토자는 정보를 요청할 수 있습니다.
복잡하거나 과도하게 설계된 솔루션 피하기
문제 해결 방법을 살펴보기 전에 문제의 중요성과 재발 가능성을 평가합니다. 다시 발생할 가능성이 낮은 문제를 해결하기 위해 시스템에 복잡성을 추가하면 불안정성이 증가할 수 있습니다.
사후 분석을 최대한 널리 공유
문제가 해결되지 않은 상태로 남아 있지 않도록 사후 분석 결과를 광범위한 대상에게 게시하고 경영진의 지원을 받습니다. 사후 분석의 가치는 사후 분석 후에 발생하는 학습에 비례합니다. 더 많은 사람이 장애로부터 배울수록 유사한 장애가 다시 발생할 가능성이 줄어듭니다.