장애 회고(포스트모템) 작성법과 템플릿

비난 없는 원칙으로 시작하기

회고의 목적은 누가 실수했는지가 아니라 시스템이 왜 그 실수를 막지 못했는지를 찾는 것입니다. 사람의 판단은 결과가 아니라 당시 얻을 수 있던 정보로 평가합니다.

타임라인은 관찰과 판단을 나눠 적기

타임라인 표에는 “무엇이 보였는가”와 “무엇을 판단했는가”를 다른 칸에 적습니다. 두 칸이 섞이면 나중에 결정이 틀렸는지, 정보가 부족했는지 구분할 수 없습니다.

원인 분석: 직접 원인과 탐지 공백

직접 원인은 하나로 좁히고, 발견이 늦어진 이유를 따로 적습니다. 장애가 길어진 이유는 대개 탐지 공백입니다. 아래 사례는 파이썬 가비지 컬렉션과 포크 프로세스의 메모리 문제가 대규모 작업 실행에서 드러난 경우입니다.

정규표현식 성능 저하처럼 버전을 올린 뒤 나타나는 문제도 같은 방식으로 씁니다. 어떤 변경이 원인이었는지, 그 변경을 검증할 수 있었는지를 함께 적습니다.

영향 범위와 복구

영향은 사용자 수, 기능, 데이터 손실 여부로 나눠 적습니다. 대량 작업이 걸린 환경에서는 한 번의 장애가 많은 작업을 동시에 멈추므로 영향 범위를 작업 단위로도 적습니다.

재발 방지 항목

재발 방지 항목은 담당자와 완료 기준이 있어야 합니다. “모니터링을 강화한다”처럼 확인할 수 없는 문장은 항목으로 인정하지 않습니다. 예를 들어 메모리 사용량 임계치 알림을 추가하고, 임계치를 넘는 상황을 테스트로 재현하는 식으로 씁니다.

템플릿(복사용)

## 1. 요약

- 무엇이 언제부터 어떻게 깨졌나 (사용자 관점)
- 영향받은 기능과 규모

## 2. 타임라인

| 시각 | 관찰한 사실 | 판단과 조치 |
|---|---|---|

## 3. 원인 분석

- 직접 원인
- 왜 발견이 늦었나 (탐지 공백)

## 4. 영향 범위

- 사용자 수, 데이터 손실 여부, 복구 방법

## 5. 재발 방지

| 항목 | 담당 | 완료 기준 |
|---|---|---|