인시던트 포스트모템 템플릿(Incident Post-Mortem Template)

누구도 인시던트에서 배우지 않는다. 포스트모템이 그걸 바꾼다.

2023년 11월 24일, Google Cloud는 90분 장애를 겪었고, Spotify, Discord, Snapchat을 비롯한 수십 개 서비스가 다운됐습니다. 48시간 안에 Google은 근본 원인, 타임라인, 시정 조치를 식별한 상세한 포스트모템(post-mortem)을 발표했습니다. 단지 좋은 PR이 아닙니다 — Google Cloud가 같은 실수를 두 번 하지 않는 이유입니다.

대부분의 기업은 인시던트를 매우 다르게 처리합니다. 사이트가 다운되고, 모두가 허둥대고, 누군가 수정을 배포하고, 팀은 넘어갑니다. 문서화 없음. 분석 없음. 그저 집단적 안도와 다시 일어나지 않기를 바라는 기도뿐입니다.

왜 팀은 포스트모템을 건너뛰는가 (그리고 후회하는가)

PagerDuty 설문에 따르면 조직의 77%가 반복되는 인시던트를 경험합니다 — 즉 같은 종류의 실패가 한 번 이상 발생합니다. 주요 이유는? 공식 포스트모템 프로세스 없음. 팀은 증상을 고치지만 시스템적 원인을 결코 조사하지 않습니다.

"비난 없는(blameless)"이라는 단어가 핵심이고, 들리는 것보다 어렵습니다. 새벽 2시에 배포가 잘못되고 온콜 엔지니어가 4시간 동안 깨어 있을 때, 자연스러운 인간의 본능은 잘못을 찾는 것입니다. "누가 이 변경을 승인했나?" "왜 리뷰에서 잡히지 않았나?" 그러나 비난은 학습을 닫습니다. Etsy의 전 CTO인 John Allspaw는 인간이 실수를 한다는 것 — 그리고 시스템이 그 실수를 잡거나 잡지 못한다는 것 — 을 이해했기에 비난 없는 포스트모템을 개척했습니다. 시스템이 당신이 고치는 것입니다.

최고의 포스트모템은 탐정 소설처럼 읽힙니다. 정확한 타임라인을 재구성하고, 단순한 근접 원인이 아니라 근본 원인 사슬을 식별하고, 폭발 반경(blast radius)을 정량화하고, 담당자와 마감이 있는 액션 아이템을 만들어냅니다. 포스트모템이 무언가를 바꾸지 않으면 그저 서류 작업이었던 겁니다.

이 프롬프트가 돕는 방식

이 프롬프트는 인시던트 세부사항으로 비난 없는 포스트모템을 구조화합니다. 심각도, 타임라인, 임팩트 데이터를 제공하면 — 인시던트 요약, 탐지 및 대응 타임라인, "5 Whys" 프레임워크를 사용한 근본 원인 분석, 임팩트 평가, 담당자가 있는 우선순위 매겨진 액션 아이템이 있는 문서를 만들어냅니다.

"5 Whys" 섹션은 표면적 설명을 넘어가게 하기에 특히 가치 있습니다. "데이터베이스가 크래시했다"는 "데이터베이스가 크래시한 이유는 커넥션 풀링이 잘못 구성됐기 때문이고, 그 구성이 스테이징에서 복사됐기 때문이고, 환경별 구성 검증이 없기 때문이다"가 됩니다.

언제 손이 가야 하는가

• 인시던트가 막 발생했고 세부사항이 신선할 때 문서화해야 함
• 한 번도 해본 적 없는 팀에서 포스트모템 문화를 정립할 때
• 반복되는 이슈가 계속 발생하고 시스템적 근본 원인을 찾아야 할 때
• 리더십이 "어떻게 이게 다시 안 일어나게 하는가?"를 묻고 구조화된 답이 필요할 때
• 온콜 로테이션이 인시던트마다 일관되게 사용할 수 있는 템플릿이 필요할 때

좋은 결과의 모습

강한 포스트모템은 분 단위로 정확한 타임라인, 최소 3단계 깊이로 들어가는 근본 원인 분석, 실제 숫자(영향 받은 사용자, 잃은 매출, SLA 함의)가 있는 임팩트 평가, 그리고 구체적이고 할당되고 시간이 정해진 액션 아이템을 가집니다. 톤은 호기심이 있고 비난적이지 않습니다. 비난 문서가 아니라 학습 문서로 읽힙니다.

참고 자료

• PagerDuty Post-Mortem Guide — PagerDuty
• Blameless Post-Mortems and a Just Culture — Etsy Code as Craft
• Google Cloud Incident Reports — Google Cloud