postmortem-write

name	postmortem-write
description	인시던트 포스트모템(사후 분석) 문서를 작성한다. 타임라인·근본 원인·재발 방지 대책을 템플릿에 맞춰 정리하고, 실행 가능한 액션 아이템으로 분해한다.
argument-hint	[인시던트 개요 또는 관련 커밋 범위] (선택: 장애 발생 일시)
user-invocable	true
disable-model-invocation	true
allowed-tools	Read, Grep, Glob, Bash(git log *), Bash(git diff *)

당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.

목적

인시던트(장애·사고)에 대한 포스트모템(사후 분석) 문서를 작성한다.
Blame-free(개인 책임 추궁 금지) 원칙에 따라, 사실 기반 타임라인, 근본 원인 분석(RCA), 재발 방지 대책을 체계적으로 정리한다.

재발 방지 대책은 실제로 티켓 발행이 가능한 수준까지 구체적으로 분해한다.

입력

• 인시던트 개요 (무슨 일이 발생했는가) (필수)
• 선택: 관련 커밋 범위 또는 배포 시점
• 선택: 장애 발생 시각 및 복구 시각
• 선택: 영향 사용자 수 또는 기능 범위
• 선택: 이미 파악된 원인 또는 대응 내용
• 정보가 부족하면 사용자에게 질문한다

절차

1. 사실 수집

   • git log --oneline --since="[장애 전일]" --until="[장애 후일]"로 관련 기간 커밋 확인
   • git diff [장애 전 커밋]...[장애 후 커밋]로 변경 내용 분석
   • Grep으로 에러 처리, 설정 변경, 의존성 변경 코드 검색
   • Read로 관련 코드 파일 확인

2. 타임라인 구성

   • 아래 흐름을 기준으로 시계열 정리:
     • 코드 변경 → 배포 → 최초 이상 탐지 → 에스컬레이션 → 대응 시작 → 복구
   • 각 이벤트 시각을 가능한 정확히 기록
   • TTD(Time To Detect: 탐지까지 소요 시간)와
     TTR(Time To Recover: 복구까지 소요 시간) 계산

3. 근본 원인 분석 (RCA)

   • 5 Whys 기법으로 원인을 단계적으로 분석
   • 직접 원인(기술적 원인)과 기여 요인(프로세스·조직 요인)을 분리
   • “왜 사전에 방지되지 못했는가”, “왜 탐지가 늦었는가”도 분석 대상에 포함

4. 영향 범위 평가

   • 영향 사용자 수 및 요청 수 추정
   • 장애 범위 기록 (전체 중단 / 부분 중단 / 성능 저하)
   • 비즈니스 영향 (매출 손실, SLA 위반 등) 기록

5. 재발 방지 대책 수립

   • 다음 3단계로 구분:
     • 즉시 대응 (1주 이내): 임시 수정, 모니터링 강화
     • 단기 대응 (1개월 이내): 근본 수정, 테스트 추가
     • 장기 대응 (분기 내): 프로세스 개선, 아키텍처 개선
   • 각 대책을 담당자·기한을 명시한 실행 단위로 분해

출력 형식

## 포스트모템: [인시던트 제목]

**작성일**: [날짜]
**심각도**: P1 / P2 / P3
**상태**: Draft

## 요약

[3~5줄로 인시던트 개요 정리]

## 영향

- **기간**: [발생 시각] 〜 [복구 시각] (총 [N]시간 [M]분)
- **영향 범위**: [영향받은 기능·서비스]
- **영향 사용자 수**: [추정치]
- **TTD (탐지 시간)**: [N분]
- **TTR (복구 시간)**: [N분]

## 타임라인

| 시각 | 이벤트 | 수행자/시스템 |
|------|--------|--------------|
| [HH:MM] | [이벤트 내용] | [사람/시스템] |

## 근본 원인 분석

### 직접 원인
[기술적 직접 원인 설명]

### 5 Whys
1. 왜 [현상] 이 발생했는가? → [답변]
2. 왜 [답변1] 이 발생했는가? → [답변]
3. 왜 [답변2] 가 발생했는가? → [답변]
4. 왜 [답변3] 이 발생했는가? → [답변]
5. 왜 [답변4] 가 발생했는가? → [근본 원인]

### 기여 요인
- [프로세스 요인]
- [조직 요인]

## 교훈 (Lessons Learned)

### 잘된 점
- [긍정 요소]

### 개선 필요 사항
- [개선 사항]

## 재발 방지 액션 아이템

### 즉시 대응 (1주 이내)

| # | 작업 내용 | 담당 | 기한 | 상태 |
|---|----------|------|------|------|
| 1 | [작업 내용] | [미정] | [날짜] | 미착수 |

### 단기 대응 (1개월 이내)

| # | 작업 내용 | 담당 | 기한 | 상태 |
|---|----------|------|------|------|
| 1 | [작업 내용] | [미정] | [날짜] | 미착수 |

### 장기 대응 (분기 내)

| # | 작업 내용 | 담당 | 기한 | 상태 |
|---|----------|------|------|------|
| 1 | [작업 내용] | [미정] | [날짜] | 미착수 |

유의사항

• Blame-free 원칙을 준수한다. 개인 이름을 원인으로 명시하지 않는다.
• 타임라인에는 사실만 기록하고, 추측이나 감정 표현은 배제한다.
• 고객 데이터, 내부 URL, 인증 정보 등 기밀 정보는 포함하지 않는다.
• git diff 결과에 시크릿이 포함될 경우 반드시 마스킹한다.
• 근본 원인은 기술적·프로세스적 문제로 기술하며, 개인 책임으로 귀결시키지 않는다.

종료 조건

위 형식에 맞춘 포스트모템 문서를 작성하면 종료한다. 요약, 타임라인, 근본 원인 분석, 재발 방지 액션 아이템(담당·기한 포함)이 반드시 포함되어야 한다. 문서 리뷰 및 실제 액션 발행은 사용자의 추가 지시를 기다린다.