Postmortem · 事後回顧

---
doc_type: "postmortem"
variant: "light"
status: "draft"
owner: "<IC-or-service-owner>"
last_updated: "YYYY-MM-DD"
upstream:
  required: ["incident-report"]
  optional: ["chat-log", "metric-snapshot"]
---

# Postmortem: <INC-NNN · short-title>

**Status:** Draft v0.X · **Owner:** <service owner> · **IC:** <name> · **Last updated:** YYYY-MM-DD

> [!IMPORTANT]
> **AI 填寫規則：** 本範本 6 段（編號 1, 2, 3, 5, 10, 12），全部必填——刻意沿用完整版的章節編號讓兩版可對照。每結論行內加 `（依據：incident-report §XXX / chat-log §YYY）`；每量化欄位 `[H]/[M]/[L]` confidence badge；缺資料寫 `_TODO: 需要 XXX_` 不編造；**Blameless：不寫人名作為根因**，個人錯誤一律歸因為「系統未保護該操作」；action item 必須有 owner + due + 驗收條件。

---

## 1. Executive Summary

<!-- ai-fill: 3-5 行 blameless 摘要，給高層 30 秒讀完。不含人名，只談「哪個系統缺口導致什麼影響、改了什麼」 -->

<3-5 行 blameless 說明>

> **TL;DR:** <一句話：根因類別 + 影響範圍 + 最重要的改善>

| Field | Value |
|---|---|
| **Incident ref** | INC-NNN |
| **Severity** | SEV-1 / SEV-2 / SEV-3 |
| **Duration** | <e.g. 2024-XX-XX 14:32 ~ 15:48 UTC, 76 min> |
| **Impact** | <受影響使用者 / 業務功能> |
| **Error budget burn** | <% of 28d budget> |

---

## 2. Root Cause（5 Whys）

<!-- ai-rule: 5 層 why 必須往「系統 / 流程 / 訓練」收斂，不能停在「人沒做 X」 -->

| Layer | Question | Answer | Confidence |
|---|---|---|---|
| Why 1 | What did users observe? | <observed symptom> | **[H]** |
| Why 2 | Why did the symptom appear? | <cause of symptom> | **[H]** |
| Why 3 | Why did that cause exist? | <cause of cause> | **[M]** |
| Why 4 | Why was the system vulnerable? | <systemic gap> | **[M]** |
| Why 5 | Why did the org allow that gap? | <process / training / design 缺口> | **[L]** |

> **Primary cause category:** code / config / capacity / dependency / process / training / monitoring — <choose 1>

---

## 3. What Went Well / Wrong

<!-- ai-rule: 各列至少 2 條，附 source；不寫「某人做得好/不好」，寫流程或工具的訊號 -->

### What went well

- [YES] <signal 1> — incident-report §XX
- [YES] <signal 2> — chat-log §YY

### What went wrong

- [NO] <signal 1> — incident-report §XX
- [NO] <signal 2> — chat-log §YY

---

## 5. Action Items（≤ 3 條）

<!-- ai-rule: 每條必含 owner + due + severity + 驗收條件 + category；無 owner 寫 `_TODO: 待 EM 指派_` 不留空 -->

| ID | Action | Owner | Due | Severity | Category | Success criteria | Confidence |
|---|---|---|---|---|---|---|---|
| AI-001 | <e.g. 加 rollback gate 到 deploy pipeline> | <team> | YYYY-MM-DD | P0 | prevention | <how we know it's done> | **[H]** |
| AI-002 | ... | ... | ... | P1 | detection | ... | **[M]** |

---

## 10. Decision Log（key 1-2 條）

<!-- ai-rule: 每條必含 chosen + 至少 1 個 rejected + 拒絕原因 -->

| Date | Decision | Options | Chosen | Rejected why | Confidence |
|---|---|---|---|---|---|
| YYYY-MM-DD | 根因歸類 | capacity / config / dependency | capacity | config (改動點不在本次發布)、dependency (上游無異常) | **[H]** |

---

## 12. Confidence & Sources & TODO

- **整份文件最低 confidence 欄位：** <列出所有 [L] 與 [M]>
- **Fabricated assumptions（推測但 input 未明說）：**
  - <假設 1>
- **Highest-value next input:** <下一份最該補的：deploy log / DB slow-query log / chat-log 全文>

### TODO（缺資料）

- _TODO: 需要 deploy log 校準 Why 3 的時序歸因_

---

> [!CAUTION]
> **輸出前 AI 自檢：**
> - [ ] 6 段 H2 章節齊全（編號 1, 2, 3, 5, 10, 12，刻意不連號）
> - [ ] 5 Whys 收斂到系統 / 流程 / 訓練（不停在「人沒做 X」）
> - [ ] **全文 0 個人名作為根因**（blameless）
> - [ ] What went well / wrong 各 ≥ 2 條，附 source
> - [ ] Action items ≤ 3 條，每條有 owner + due + severity + 驗收
> - [ ] Decision Log ≥ 1 條，每條有 rejected reason
> - [ ] 無 YAML / JSON schema 輸出（postmortem 是給人讀的 markdown）