철저한 사후 분석 실시

Google Cloud Well-Architected Framework의 안정성 부문에서 이 원칙을 따르면 장애 및 인시던트 발생 후 효과적인 사후 분석을 수행하는 데 도움이 되는 권장사항을 확인할 수 있습니다.

이 원칙은 안정성의 학습 중점사항과 관련이 있습니다.

원칙 개요

사후 분석은 인시던트, 인시던트의 영향, 인시던트를 완화하거나 해결하기 위해 취한 조치, 근본 원인, 인시던트가 재발하지 않도록 하는 후속 조치를 기록한 것입니다. 사후 분석의 목표는 실수로부터 배우는 것이지 비난을 할당하는 것이 아닙니다.

다음 다이어그램은 사후 분석의 워크플로를 보여줍니다.

사후 분석 워크플로에는 다음 단계가 포함됩니다.

• 사후 분석 만들기
• 사실 정보 캡처
• 근본 원인 파악 및 분석
• 미래를 위한 계획
• 계획 실행

다음과 같은 주요 이벤트 및 비주요 이벤트 후 사후 분석을 실시합니다.

• 특정 기준점을 초과하는 사용자에게 표시되는 다운타임 또는 성능 저하
• 모든 종류의 데이터 손실
• 출시 롤백 또는 트래픽 재라우팅과 같은 당직 엔지니어의 개입
• 정의된 기준을 초과하는 해결 시간
• 모니터링 실패: 일반적으로 수동 사고 발견을 의미합니다.

권장사항

사고가 발생하기 전에 사후 분석 기준을 정의하여 사후 분석이 필요한 시점을 모든 사람이 알 수 있도록 합니다.

효과적인 사후 분석을 수행하려면 다음 하위 섹션의 권장사항을 고려하세요.

비난 없는 사후 분석 실시

효과적인 사후 분석은 프로세스, 도구, 기술에 초점을 맞추며 개인이나 팀을 비난하지 않습니다. 사후 분석의 목적은 유죄인 사람을 찾는 것이 아니라 기술과 미래를 개선하는 것입니다. 누구나 실수를 합니다. 목표는 실수를 분석하고 실수를 통해 배우는 것입니다.

다음 예에서는 비난을 할당하는 의견과 비난이 없는 의견의 차이점을 보여줍니다.

• 책임을 묻는 의견: '복잡한 백엔드 시스템 전체를 다시 작성해야 합니다. 지난 3분기 동안 매주 문제가 발생했으며, 모두가 부분적으로 문제를 해결하는 데 지쳐 있을 것입니다. 진짜, 한 번만 더 호출되면 내가 직접 다시 작성할 거야'라고 말했습니다.
• 책임 없는 피드백: '전체 백엔드 시스템을 다시 작성하는 작업 항목이 실제로 이러한 페이지가 계속 표시되지 않도록 할 수 있습니다. 이 버전의 유지보수 매뉴얼은 매우 길고 완전히 교육받기가 정말 어렵습니다. 향후 당직 엔지니어들이 고마워할 겁니다."

모든 대상 잠재고객이 포스트모템 보고서를 읽을 수 있도록 설정

보고서에 포함할 각 정보가 청중이 발생한 상황을 이해하는 데 중요하고 필요한지 평가합니다. 보충 데이터와 설명을 보고서의 부록으로 이동할 수 있습니다. 추가 정보가 필요한 검토자는 정보를 요청할 수 있습니다.

복잡하거나 과도하게 설계된 솔루션 방지

문제의 해결 방법을 모색하기 전에 문제의 중요도와 재발 가능성을 평가하세요. 다시 발생할 가능성이 낮은 문제를 해결하기 위해 시스템에 복잡성을 추가하면 불안정성이 증가할 수 있습니다.

사후 분석을 최대한 널리 공유

문제가 해결되지 않은 상태로 남아 있지 않도록 사후 분석 결과를 많은 사람들에게 게시하고 경영진의 지원을 받으세요. 사후 분석의 가치는 사후 분석 후 발생하는 학습에 비례합니다. 인시던트에서 더 많은 사람이 학습할수록 유사한 실패가 반복될 가능성이 줄어듭니다.