포스트모텀(Post-Mortem)은 인시던트 해결 후 근본 원인을 분석하고 재발을 방지하기 위한 공식 절차다. 비난 없는(Blameless) 문화를 기반으로 시스템과 프로세스 개선에 집중한다.
포스트모텀 구조
markdown
# 포스트모텀: 결제 API 30분 장애 (2025-05-18)
## 요약
2025-05-18 14:30~15:00 KST, 결제 API에서 503 에러 발생.
영향: 결제 시도의 45% 실패, 추정 손실 1,500만원.
## 타임라인
- 14:30: CloudWatch 알람 발동 (5xx 에러율 30% 초과)
- 14:35: On-call 엔지니어 인시던트 선언 (SEV1)
- 14:42: 원인 특정 - DB 커넥션 풀 고갈
- 14:55: 커넥션 풀 크기 50→200 증가, 에러율 정상화
- 15:00: 인시던트 종료
## 근본 원인 (5-Why)
1. 왜 장애가 났나? → DB 커넥션 풀 고갈
2. 왜 고갈됐나? → 슬로우 쿼리로 커넥션 점유 시간 증가
3. 왜 슬로우 쿼리가 발생했나? → 배포된 코드의 N+1 쿼리
4. 왜 N+1 쿼리가 배포됐나? → 부하 테스트 없이 배포
5. 왜 부하 테스트를 안 했나? → CI 파이프라인에 성능 테스트 없음
## 액션 아이템
| 조치 | 담당자 | 기한 |
|---|---|---|
| CI에 k6 성능 테스트 추가 | 백엔드팀 | 5/25 |
| DB 커넥션 풀 자동 스케일링 | 인프라팀 | 5/22 |
| 슬로우 쿼리 알람 추가 | DBA | 5/20 |
비난 없는(Blameless) 문화
❌ "왜 배포하기 전에 테스트를 안 했나요?"
✓ "배포 전 성능 테스트를 수행할 수 있는 프로세스가 없었습니다."
목표: 시스템과 프로세스 개선, 개인 비난 없음
결과: 솔직한 분석 가능, 숨기는 문화 방지
관련 개념