Postmortem(사후 분석) 문서를 작성할 때 가장 중요한 요소

 

Postmortem 문서는 장애의 원인과 대응 과정을 기록하고, 재발 방지 대책을 수립하기 위한 문서입니다. 이를 위해 장애 개요, 감지 및 대응 타임라인, 근본 원인 분석(RCA), 해결 조치, 재발 방지 대책, 프로세스 개선 사항을 포함해야 합니다.

 

 

Postmortem 문서는 장애(Incident) 발생 후 원인을 분석하고, 재발 방지 대책을 마련하기 위해 작성하는 문서입니다.
SRE 관점에서 Postmortem 문서는 책임을 추궁하는 것이 아니라, 서비스 안정성을 개선하는 데 초점을 맞추어야 합니다.

---

📌 1️⃣ Postmortem 문서의 핵심 목적

• 장애의 원인을 정확히 기록하고, 서비스 안정성을 향상시키기 위한 개선책을 도출
• **Blameless Culture(비난 없는 문화)**를 유지하여 투명한 장애 분석 및 공유
• 팀 전체가 학습할 수 있도록 문서화하여, 같은 유형의 장애가 반복되지 않도록 예방

---

📌 2️⃣ Postmortem 문서의 필수 구성 요소

1️⃣ 장애 개요 (Incident Summary)

✔ 장애가 언제, 어디에서 발생했는지 간략한 요약
✔ 비즈니스 영향(사용자 수, 서비스 영향, 매출 손실 등) 명확히 기술

✅ 예시:
"2024년 3월 5일 14:30 (UTC)부터 15:15까지, 주문 API의 응답 시간이 3~5초로 증가하여 사용자의 주문 처리가 지연되었습니다.
총 5,000건의 주문이 영향을 받았으며, 매출 손실이 약 50,000달러로 추정됩니다."

---

2️⃣ 장애 감지 및 대응 시간 (Timeline of Events)

✔ 장애 감지부터 대응 완료까지의 주요 이벤트 타임라인 기록
✔ Alerting 시스템이 언제 감지했으며, 어떤 조치가 취해졌는지 단계별로 정리

✅ 예시:

시간(UTC)이벤트

14:30	Prometheus가 API 응답 지연(>3초) 감지, PagerDuty 알림 전송
14:32	온콜 엔지니어 장애 확인 후 대응 시작
14:40	Kibana 로그 분석을 통해 DB Lock Contention 문제 확인
14:45	Rate Limiting 및 캐싱 적용하여 부하 감소
15:00	응답 속도 정상화 시작
15:15	장애 대응 완료 및 정상 운영 복구

---

3️⃣ 장애 원인 분석 (Root Cause Analysis, RCA)

✔ 단순한 현상이 아닌, 근본적인 장애 원인을 깊이 분석
✔ 기술적 원인과 비즈니스적 영향을 모두 포함
✔ Five Whys(5번의 왜?) 분석 기법 적용하여 근본 원인 도출

✅ 예시:

• 표면적인 원인: 블랙프라이데이 트래픽 급증으로 주문 API 응답 시간이 지연됨
• 근본 원인:
  1. 주문 서비스의 MySQL 데이터베이스에서 트랜잭션 Lock Contention 발생
  2. 읽기/쓰기 요청이 같은 테이블에 집중되면서 병목 발생
  3. Auto Scaling이 설정되어 있었으나, DB 쿼리 최적화가 미흡하여 문제 해결되지 않음

---

4️⃣ 장애 대응 및 복구 과정 (Mitigation & Recovery Actions)

✔ 장애 대응 과정에서 어떤 조치를 취했는지 기록
✔ 즉시 해결책(Short-term Fix)과 장기적인 해결책(Long-term Fix) 구분

✅ 예시:
✔ 즉시 조치 (Hotfix & Mitigation)

• API Gateway에서 Rate Limiting 적용하여 과도한 요청 차단
• Redis 캐싱을 추가하여 주문 상태 조회 API의 DB 부하 감소

✔ 근본 해결책 (Permanent Fix)

• 주문 테이블의 인덱스 최적화 및 쿼리 성능 개선
• 데이터베이스 읽기/쓰기 분리(Read-Replica) 적용
• Circuit Breaker 도입하여 특정 서비스 장애 발생 시 graceful degradation 수행

---

5️⃣ 장애 재발 방지를 위한 개선 사항 (Preventive Measures & Action Items)

✔ 이번 장애를 통해 학습한 내용 및 향후 개선 방안 명확히 정의
✔ 다음 대응 방안을 실행할 담당자 및 기한(Task Owner & Deadline) 명시

✅ 예시:

개선 조치담당자마감 기한

주문 테이블의 인덱스 최적화	DB 엔지니어	2024-03-10
Read-Replica 적용 및 DB 부하 테스트 수행	SRE 팀	2024-03-15
Auto Scaling 임계값 조정 및 테스트	DevOps 팀	2024-03-12
Chaos Engineering 실험을 통해 유사 장애 발생 가능성 점검	SRE 팀	2024-03-20

---

6️⃣ 장애 대응 프로세스 개선 (Process Improvements)

✔ 장애 대응 속도를 높이기 위한 운영 프로세스 개선 사항 포함
✔ 모니터링 시스템 강화, 온콜 프로세스 조정 등의 개선점 도출

✅ 예시:
"이번 장애에서 장애 감지(Alerting) 후 대응까지 10분이 소요되었습니다.
이를 개선하기 위해, Prometheus Alert Threshold를 조정하고, Grafana에서 SLO 기반 대시보드를 추가하여 장애 탐지를 더욱 빠르게 수행할 예정입니다."

---

📌 3️⃣ Postmortem 작성 시 가장 중요한 요소 요약

✅ 1. 장애 개요 (Incident Summary)

→ 장애가 발생한 시간, 영향, 비즈니스적 영향(사용자 수, 매출 손실) 포함

✅ 2. 장애 감지 및 대응 타임라인 (Timeline of Events)

→ 장애 감지부터 해결까지의 주요 이벤트 정리

✅ 3. 근본 원인 분석 (Root Cause Analysis, RCA)

→ Five Whys 기법을 활용하여 장애의 핵심 원인을 파악

✅ 4. 장애 해결 과정 (Mitigation & Recovery Actions)

→ 즉시 해결책(Hotfix)과 장기 해결책(Permanent Fix) 구분

✅ 5. 장애 재발 방지 대책 (Preventive Measures)

→ 향후 개선 조치 명시 및 담당자/기한 설정

✅ 6. 장애 대응 프로세스 개선 (Process Improvements)

→ 장애 감지 속도, 온콜 프로세스, 모니터링 개선 사항 포함