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