장애 이후 blameless post-mortem을 어떻게 진행합니까?

Question

Accepted Answer

**blameless post-mortem**은 장애를 사람이 아니라 *시스템과 조건*의 실패로 다룹니다. 질문은 결코 "누가 고장 냈는가"가 아니라 "우리 시스템이 합리적인 사람이 이것을 일으키도록 어떻게 내버려두었는가, 그리고 다음번엔 어떻게 불가능하게 만들 것인가?"입니다.

## 프로세스

1. **Timeline을 구성한다.** 무슨 일이 있었는지를 분 단위로 재구성합니다: 탐지, 에스컬레이션, 완화, 해결. 사실에 충실하세요.
2. **기여 요인을 찾는다.** 대부분의 장애에는 여러 요인이 있습니다. **5 Whys** 같은 기법으로 표면 증상을 넘어 **root cause**에 도달하세요 — 누락된 alert, 잘 깨지는 deploy, 불분명한 runbook.
3. **Action item을 만든다.** 각각은 **구체적이고, 주인이 있으며, 마감일이 있습니다**. "더 조심하자"는 action item이 아닙니다. "배포 전 migration 체크를 추가"가 action item입니다.
4. **널리 공유한다.** 그 방에 있던 사람뿐 아니라 조직 전체가 배우도록 문서를 공개합니다.

## 실제의 blameless

- **누구**의 잘못인지가 아니라 **무슨 일**이 있었고 **그 당시 왜 그게 합리적이었는지**를 설명합니다.
- 모두가 가진 정보로 합리적으로 행동했다고 가정합니다.
- 단일 인간의 행동이 production을 다운시킬 수 있다면, 그것은 개인의 잘못이 아니라 **시스템 결함**입니다.

## psychological safety가 중요한 이유

사람들이 비난받을까 두려워하는 순간, 그들은 세부사항을 숨기고, 자신의 역할을 축소하며, 진짜 원인은 묻혀 있게 됩니다. **psychological safety가 정직함을 이끌고**, 정직함은 실제로 지속되는 수정을 만들어내는 유일한 것입니다.

## 왜 중요한가

장애는 비싼 수업료입니다 — blameless post-mortem은 그 교훈을 실제로 얻는 방법입니다. 잘 하면 같은 장애가 재발하지 않고, 시스템은 실패할 때마다 더 탄력적으로 되며, 팀은 실수를 인정하는 것이 상황을 더 나쁜 게 아니라 더 나아지게 만든다고 신뢰합니다.