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