엔지니어링 포스트모템 템플릿 (책임 추궁 없이, 실행 가능하게)

포스트모템이 책임 추궁의 자리로 변하는 이유

포스트모템은 특정한 방식으로 실패합니다. 회의실이 공유된 타임라인을 갖기도 전에 원인을 지목하기 시작하는 것입니다. 누군가는 배포 시점이 확인되기도 전에 "이건 배포 때문이야"라고 말합니다. 다른 누군가는 그 상황에 맞게 알림이 설정되어 있었는지도 모른 채 "알림이 안 울렸어"라고 말합니다. 무슨 일이 어떤 순서로 실제로 일어났는지 아무도 확립하기 전에, 대화는 인과에 대한 논쟁으로 변합니다.

해법은 구조적입니다. 누구도 근본 원인을 지목하기 전에, 포스트모템 시작 시점에 장애 타임라인을 함께 세우는 것입니다. 회의실 전체가 사건의 순서 — 무엇이 언제 바뀌었고, 누가 어느 시점에 무엇을 봤는지 — 를 살펴보고 나면, 원인은 훨씬 논하기 쉬워지고 책임 추궁으로 무너질 가능성도 훨씬 줄어듭니다. 이것이 대부분의 템플릿이 저지르는 순서 실수입니다. 템플릿의 목적이 근본 원인이다 보니, 근본 원인을 타임라인 앞에 둡니다. 그러나 근본 원인을 정직하게 만들어 주는 것은 바로 타임라인입니다.

아젠다 (복사해서 붙여넣으세요)

소요 시간: 단순한 장애는 60분. 복잡한 다중 시스템 장애는 90분
형식: 진행자 주도. 모든 대응자와 온콜 엔지니어 참석. 사전 배포 문서로 비동기 준비

섹션 1 — 장애 요약 (5분)

장애 발생 일시와 지속 시간
심각도 분류와 영향받은 시스템
누가 어떻게 감지했는지(고객 신고, 알림, 엔지니어, 모니터링)
이 섹션은 오직 사실만 다룹니다. 아직 분석은 없습니다

섹션 2 — 타임라인 (20분)

미리 작성한 문서가 아니라, 화면에서 함께 타임라인을 세웁니다
순서: 무엇이 바뀌었고, 무엇이 관찰되었으며, 누가 행동했고, 무엇이 결정되었는지
모든 타임스탬프에는 출처가 있어야 합니다(로그 라인, PagerDuty, Slack 메시지)
타임라인이 완성되면 물으세요: 모두가 이것이 실제로 일어난 일이라는 데 동의합니까? 넘어가기 전에 이견을 해소하세요

섹션 3 — 영향 요약 (5분)

고객 영향: 누가, 얼마나 오래, 어떤 방식으로 영향받았는지
사업 영향: 매출, SLA, 평판
내부 영향: 온콜 시간, 팀 업무 지장
이 부분은 사실 위주로 유지하세요. 논평 없이 "얼마나 심각했나"라는 질문을 붙들어 줍니다

섹션 4 — 근본 원인과 기여 요인 (20분)

근본 원인: 장애를 가능하게 만든 가장 근접한 변경이나 조건
기여 요인: 상황을 악화시키거나, 감지를 어렵게 하거나, 해결을 늦춘 조건들
가장 유용한 포스트모템은 근본 원인과 더불어 3~5개의 기여 요인을 짚어냅니다. 근본 원인만 고치면 시스템적 조건을 놓치는 경우가 많습니다
각 요인에 대해 물으세요: 당시 확보 가능한 정보를 놓고 볼 때 어떤 개인이나 팀이 합리적으로 보이는 결정을 내렸는가? 그렇다면 그 요인은 개인적인 것이 아니라 시스템적인 것입니다

섹션 5 — 잘된 것 (5분)

어떤 감지나 대응이 기대보다 잘 작동했는가?
어떤 기존 프로세스나 도구가 피해 범위를 제한했는가?
이것들은 정식화할 가치가 있는 관행입니다. 런북이 20분을 아꼈다면, 런북이 계속 관리되도록 그것을 기록하세요

섹션 6 — 액션 아이템 (15분)

각 액션 아이템은 일반적인 개선이 아니라 근본 원인이나 기여 요인을 다룹니다
항목당 담당자 한 명. 긴급도를 반영한 완료 기한
분류하세요: 더 빨리 감지 / 더 빨리 복구 / 재발 방지
포괄적인 안정성 로드맵이 아니라, 다음 장애 전까지 팀이 현실적으로 완료할 수 있는 조치로 제한하세요

포스트모템 템플릿을 실패하게 만드는 것

근본 원인 우선의 순서가 주된 구조적 문제입니다 — 앞에서 이미 다뤘습니다. 두 번째는 "액션 아이템"을 하나의 범주로 취급하는 것입니다. 감지 개선, 복구 개선, 예방 개선은 서로 다른 담당자와 서로 다른 일정을 요구합니다. 이것들을 섞으면 6개월에 걸치고 세 팀에 걸치는 목록이 나오는데, 그러면 책임이 흩어지고 어느 것도 완료되지 않습니다.

세 번째 실패 유형은 "잘된 것"을 건너뛰는 것입니다. 장애 뒤에 부적절한 낙관처럼 느껴지기 때문입니다. 그렇지 않습니다 — 그것은 압박 속에서 작동한 관행을 짚어내고 정식화하는 유일한 체계적 방법입니다. 문제를 잡아낸 모니터링이 아무의 로드맵에도 없던 것이었다면, 그것이 중요했다는 사실을 알게 된 것은 기록할 가치가 있습니다. 그러지 않으면 장애의 기억이 옅어진 뒤 우선순위에서 밀리고, 다음번에 여러분은 눈을 감은 채로 있게 됩니다.

기여 요인이 방치된 장애, 그리고 잘 작동한 런북이 관리되지 않은 채로 방치된 것의 누적 비용은 빠르게 쌓입니다. 회의세는 반복되는 회의 부담과 장애 리뷰 부채가 어떻게 맞물리는지 다룹니다.

포스트모템 기록이 유독 어려운 이유

포스트모템 논의는 빽빽하고 구조화되지 않은 내용을 빠르게 만들어 냅니다. 타임라인 재구성, 상충하는 해석, 여러 사람에게 걸친 액션 아이템 배정, 맥락 없이 녹취록에 담기면 이해되지 않을 기술적 세부 사항이 그것입니다. 기억이나 편집된 오디오로 작성한 포스트모템 요약은 거의 항상 불완전하고, 불완전한 포스트모템 기록은 장애 전반의 패턴 인식에는 쓸모가 없습니다.

Pavleur는 전체 포스트모템 논의를 포착해 보고서를 자동으로 생성합니다. 재구성된 타임라인, 지목된 기여 요인, 회의에서 진술된 담당자와 분류가 붙은 액션 아이템까지 담습니다. 누군가 화면을 공유해 로그 발췌, 모니터링 그래프, 울리지 않은 알림 설정을 보여줬다면, 그 시각 자료는 보고서의 일부가 됩니다. 오디오만 다루는 도구는 이것을 완전히 놓칩니다. 그래프가 빠진 포스트모템 기록은 증거가 빠진 기록입니다. 장애 이후에 합류한 엔지니어를 포함해 팀의 누구든, 누군가에게 재구성을 부탁하지 않고도 시각적 맥락이 포함된 완전한 기록을 읽을 수 있습니다. 이 점에 대한 다른 도구와의 직접 비교는 Pavleur와 대안 비교를 참고하세요.

포스트모템 주기에 관하여

세부 사항이 생생할 때, 장애 해결 후 48시간 이내에 포스트모템을 진행하세요. 오래 미룰수록 타임라인 재구성은 로그보다 기억에 더 의존하게 되고, 압박 속의 기억은 믿을 만하지 않습니다. 고심각도 장애라면 24시간이 더 낫습니다. 경미한 장애라면 비동기 포스트모템 — 구조화된 질문이 담긴 공유 문서를 동기식으로 검토하는 방식 — 이 전체 회의보다 더 효율적일 수 있습니다. 회의 형식은 장애가 모호했거나, 공유된 해석이 중요할 만큼 중대했을 때 가장 가치가 있습니다.