비난 없는 인시던트 포스트모템 진행하기(Conduct a blameless incident post-mortem)

비난 없는 포스트모템: 사람이 아니라 시스템

포스트모템의 품질이 팀이 신호로 달려가느냐 신호로부터 숨느냐를 결정합니다. Atlassian의 인시던트 관리 글과 Google re:Work의 심리적 안전 연구 모두 같은 주장을 합니다: 비난이 들어간 포스트모템은 엔지니어가 위기 일발(near-miss)을 보고하지 않도록 훈련시키며, 다음 인시던트를 예방하는 데 필요한 데이터를 침식합니다. 프레이밍 규율 — "사람이 아니라 시스템" — 이 부하지지(load-bearing) 규범입니다.

Conduct a blameless incident post-mortem 프롬프트의 작동 방식

프롬프트는 먼저 타임라인을 재구성하고(MTTD/MTTA/MTTR — 측정 가능한 지표), 단일 근본 원인을 찾는 대신 다섯 카테고리에 걸쳐 기여 요인을 나열하며, 문서가 개인 이름을 댈 수 없도록 비난 없는 재작성을 강제합니다. "6개월 전에 했어야 했던 액션" 출력은 보통 포스트모템 액션 아이템에서 빠져나가는 잠재 기술 부채를 표면화합니다.

언제 사용할까

• 프로덕션 인시던트가 막 발생했을 때.
• 포스트모템 문화가 비난으로 퇴화했을 때.
• MTTR이 오르고 있는데 누구도 이유를 모를 때.
• 새 엔지니어링 리더가 인시던트 위생을 리셋하고 싶을 때.
• 고객이 공개 가능한 포스트모템을 요청할 때.

흔한 함정

• 단일 근본 원인. 인시던트는 거의 단일 근본 원인을 가지지 않습니다. 카테고리에 걸친 기여 요인 나열이 더 나은 예방을 만들어냅니다.
• 이론은 비난 없음, 톤은 비난. 문서를 다시 읽고 합리적 독자가 개인 비난으로 추론할 만한 언어를 모두 제거하세요.
• 담당자나 날짜 없는 액션 아이템. 주인 없는 액션 아이템은 문서화 연극입니다. 사람과 날짜를 명명하세요.

참고 자료

• Agile Metrics — Atlassian
• Google re:Work — Google
• The Pragmatic Engineer — Gergely Orosz
• Begin with Trust — Harvard Business Review