awoooi/docs/templates/POSTMORTEM-TEMPLATE.md

AWOOOI 事後分析報告模板（Postmortem Template）

文件類型: 事後分析標準模板
版本: v1.0
建立日期: 2026-04-14（台北時間）
建立者: Claude Sonnet 4.6（首席架構師）
使用方式: 複製本模板，替換 {佔位符} 後提交至 docs/postmortems/YYYY-MM-DD-{alertname}.md
對齊: report_generation_service.format_postmortem() 自動填入欄位已標記 [AUTO]

---

事後分析：{INCIDENT_TITLE}

Incident ID: {INC-YYYYMMDD-XXXXXX}
告警名稱: {alertname}
嚴重等級: {P0 / P1 / P2 / P3}
發生時間: {YYYY-MM-DD HH:MM}（台北時間） [AUTO]
解決時間: {YYYY-MM-DD HH:MM}（台北時間） [AUTO]
停機時長: {N} 分鐘 [AUTO]
撰寫人: {統帥 / SRE / AI 自動生成}
審查日期: {YYYY-MM-DD}

---

0. 執行摘要（Executive Summary）

三行以內，給不想讀全文的決策者看

• 發生了什麼: {一句話描述事件}
• 根本原因: {一句話描述根因}
• 最終處置: {人工介入 / 自動修復 / 降級 / 重啟}
• 影響範圍: {受影響服務} × {停機 N 分鐘} × {用戶影響程度}

---

1. 時間軸（Timeline）[AUTO from AIDecisionChain]

時間（台北）	事件
{HH:MM}	Alertmanager 觸發告警：{alertname}
{HH:MM}	AWOOOI API 接收 webhook（POST /webhooks/alerts）
{HH:MM}	LLM RCA 完成，hypothesis：{LLM假設}，confidence：{0.XX}
{HH:MM}	Telegram 審核卡發出（TYPE-{1/2/3/4}）
{HH:MM}	{統帥} 審核：{APPROVE / REJECT / 未審核}
{HH:MM}	自動執行：{kubectl command / SSH command / NO_ACTION}
{HH:MM}	告警解除（Alertmanager resolved）
{HH:MM}	Playbook 萃取完成，知識庫更新

總耗時: {分析延遲 Xs} + {等待審核 Xm} + {執行 Xs} = {總計 Xm}

---

2. 根本原因分析（Root Cause Analysis）[AUTO]

2.1 AI 假設

{AIDecisionChain.hypothesis 欄位內容}

AI 信心度: {AIDecisionChain.confidence}
模型: {AIDecisionChain.model_used}
推理步驟:

{AIDecisionChain.reasoning_steps 列表}

2.2 實際根因（人工確認）

填寫：AI 假設是否正確？若不正確，真正的根因是？

• AI 假設是否正確: {是 / 否 / 部分正確}
• 實際根因: {描述}
• 觸發鏈: {A → B → C → 告警}

2.3 原因分類

選擇適用的類別（可複選）

• 硬體問題（磁碟、記憶體、網路卡）
• 資源耗盡（磁碟滿、OOM、連線池滿）
• 程式碼 Bug（logic error、memory leak）
• 配置錯誤（YAML 錯誤、環境變數缺失）
• 依賴服務故障（外部 API、上游服務）
• 容量不足（流量峰值超出設計）
• 人為操作錯誤（誤刪、誤改）
• 告警誤報（規則設定過於敏感）
• 其他：{描述}

---

3. 影響評估（Impact Assessment）

維度	內容
受影響服務	{services} [AUTO from affected_services]
用戶影響	{無 / 部分功能降級 / 完全中斷}
停機時長	{N 分鐘} [AUTO]
資料影響	{無資料遺失 / 部分資料遺失 / 需確認}
SLO 影響	SLO-1 成功率：{X%} / Error Budget 消耗：{X%}
業務影響	{描述具體業務損失或用戶體驗影響}

---

4. 處置過程（Resolution）[AUTO + 人工補充]

4.1 自動修復

執行指令: {approval.action}
執行結果: {成功 / 失敗}
執行者:   AIOps 自動執行
執行時間: {YYYY-MM-DD HH:MM}（台北）

4.2 人工介入

若有人工操作，填寫以下內容

• 操作者: {統帥 / SRE}
• 操作時間: {YYYY-MM-DD HH:MM}（台北）
• 執行步驟:

  {步驟 1}
  {步驟 2}
  ...
  

• 為何需要人工介入: {AI 信心不足 / 自動修復失敗 / P0/P1 強制審核 / Kill Switch 啟動}

4.3 修復驗證

• 驗證方式: {curl 測試 / Pod 狀態確認 / 告警解除 / 用戶確認}
• 驗證結果: {服務恢復正常 / 部分恢復 / 降級運行}

---

5. 飛輪學習（KM Update）[AUTO]

本次 Incident 是否產生了新的 Playbook？

• Playbook 萃取: {是 / 否}
• Playbook ID: {PB-YYYYMMDD-XXXXXX} [若有]
• 修復步驟: {動作描述}
• 加入知識庫: {是 / 否（原因：{效果評分 < 3 / 統帥不建議}）}
• 知識庫查詢觸發: {下次同類告警將自動匹配此 Playbook}

效果評分: {1-5} / 統帥回饋: {如有}

---

6. 預防措施（Action Items）

#	類型	描述	負責人	截止日期	狀態
AI-1	監控優化	{告警規則閾值調整}	{統帥}	{YYYY-MM-DD}	{TODO}
AI-2	系統加固	{修復根本原因}	{統帥}	{YYYY-MM-DD}	{TODO}
AI-3	知識庫	{更新 Playbook / 新增規則}	AIOps	{自動}	{自動}
AI-4	演練計畫	{定期演練此類故障}	{統帥}	{YYYY-MM-DD}	{TODO}

---

7. 五個為什麼（5 Whys）

用於複雜/P0 事件；追溯到技術或流程根源

1. 為什麼服務中斷？
   → {描述直接原因}

2. 為什麼 {直接原因} 發生？
   → {描述次級原因}

3. 為什麼 {次級原因} 沒有被預防？
   → {描述}

4. 為什麼 {原因3} 存在？
   → {描述}

5. 為什麼 {原因4} 沒有在系統設計中被考慮？
   → {根本原因 — 技術債 / 流程缺失 / 資源不足}

根本改善方向: {描述}

---

8. 附件（Appendix）

8.1 相關 Logs

# 關鍵錯誤日誌（僅附最相關的 5-10 行）
{log lines}

8.2 相關截圖

附 Grafana / SignOz / Telegram 截圖路徑

• docs/postmortems/assets/{INC-ID}-grafana.png
• docs/postmortems/assets/{INC-ID}-telegram.png

8.3 參考資料

• Incident DB: SELECT * FROM incidents WHERE incident_id = '{INC-ID}'
• Langfuse Trace: https://langfuse.awoooi.internal/trace/{trace_id}
• 相關 ADR: {ADR-XXX}
• 相關 Playbook: {PB-ID}

---

使用說明

何時填寫: P0/P1 事件 24 小時內；P2 事件 72 小時內；P3 可選

自動填入欄位 [AUTO]: 由 report_generation_service.format_postmortem() 自動填入，人工只需補充 2.2、4.2、5、6

存放位置:

docs/postmortems/
  YYYY-MM-DD-{alertname}-{incident_id}.md
  assets/
    {incident_id}-*.png

提交方式: git push gitea main → 自動部署

---

本模板由 Claude Sonnet 4.6 於 2026-04-14 台北時間建立