事件報告與根因分析範本（Incident Report & Root Cause Analysis）#
參照標準：ITIL 4（Incident Management & Problem Management）/ ISO/IEC 20000-1:2018 / SRE Postmortem
文件用途：記錄生產環境事件、分析根本原因、制定改善行動，防止問題再次發生
適用階段：維運監控階段（Operations Phase）— Continuous Improvement
📋 章節目錄#
- 事件摘要
- 時間軸
- 影響評估
- 根因分析
- 解決方案
- 改善行動計畫
- 經驗教訓
- 附錄
1. 事件摘要#
📝 範本#
| 項目 | 內容 |
|---|
| 事件編號 | INC-{YYYYMMDD}-{序號} |
| 事件標題 | {一句話描述事件} |
| 嚴重等級 | SEV1（Critical）/ SEV2（Major）/ SEV3（Minor）/ SEV4（Low） |
| 事件狀態 | 調查中 / 已解決 / 已關閉 |
| 發生時間 | {YYYY-MM-DD HH:MM} (UTC+8) |
| 偵測時間 | {YYYY-MM-DD HH:MM} |
| 解決時間 | {YYYY-MM-DD HH:MM} |
| 事件持續時間 | {N} 分鐘/小時 |
| MTTD | {偵測時間 - 發生時間} |
| MTTR | {解決時間 - 偵測時間} |
| 受影響系統 | {系統/服務名稱} |
| 受影響使用者 | {人數/比例} |
| 事件負責人 | {Incident Commander} |
| 報告撰寫者 | {姓名} |
| 報告日期 | {YYYY-MM-DD} |
📖 使用說明#
- 嚴重等級定義：
- SEV1：核心業務完全中斷，影響全部使用者
- SEV2：核心功能嚴重降級，影響大部分使用者
- SEV3：非核心功能異常，影響部分使用者
- SEV4：輕微異常，幾乎不影響使用者
- MTTD（Mean Time To Detect）：衡量監控能力
- MTTR（Mean Time To Resolve）：衡量恢復能力
- 事件報告需在事件解決後 3-5 個工作日 內完成
- Blameless 原則：報告聚焦系統與流程改善，不歸咎個人
💡 範例#
| 項目 | 內容 |
|---|
| 事件編號 | INC-20260520-001 |
| 事件標題 | HRMS 薪資查詢 API 持續回傳 500 Error |
| 嚴重等級 | SEV2（核心功能嚴重降級） |
| 發生時間 | 2026-05-20 10:15 |
| 偵測時間 | 2026-05-20 10:18（Grafana 告警） |
| 解決時間 | 2026-05-20 10:28（回滾完成） |
| 事件持續時間 | 13 分鐘 |
| MTTD | 3 分鐘 |
| MTTR | 10 分鐘 |
| 受影響使用者 | ~200 人（薪資查詢功能不可用） |
| 事件負責人 | 張 SRE |
2. 時間軸#
📝 範本#
| 時間 (UTC+8) | 事件 | 執行者 | 備註 |
|---|
| {HH:MM} | {發生/偵測/行動/解決} | {人員} | {補充說明} |
📖 使用說明#
- 時間軸是事件報告最有價值的部分，需精確到分鐘
- 涵蓋：事件發生 → 偵測 → 通知 → 診斷 → 緩解 → 解決 → 驗證
- 資料來源：監控日誌、Slack 訊息時間戳、告警記錄
- 時間軸讓團隊復盤流程效率，找出可改善的環節
💡 範例#
| 時間 (UTC+8) | 事件 | 執行者 | 備註 |
|---|
| 10:12 | v2.1.0 部署完成，新版上線 | DevOps 林 | K8s Green deployment 完成 |
| 10:15 | 薪資計算排程 CronJob 啟動（與 API 衝突） | System | 排程被新設定觸發 |
| 10:15 | DB Lock 衝突開始，API 回應逾時 | System | PostgreSQL row-level lock |
| 10:18 | Grafana 告警：5xx rate > 5% | Alert System | #hrms-alerts 頻道 |
| 10:19 | SRE 張確認告警，開始調查 | SRE 張 | 檢查 Pod 日誌 |
| 10:21 | 確認問題：DB Lock contention | SRE 張 | pg_stat_activity 發現 lock wait |
| 10:23 | 聯繫 Tech Lead 決策：啟動回滾 | SRE 張 → Tech Lead 王 | Slack 通訊 |
| 10:24 | Tech Lead 確認回滾，授權執行 | Tech Lead 王 | |
| 10:25 | 開始執行回滾腳本 | SRE 張 | ./rollback-hrms-v2.1.0.sh |
| 10:27 | 流量切換至 v2.0.3 完成 | SRE 張 | Blue deployment |
| 10:28 | 健康檢查通過，冒煙測試通過 | SRE 張 + QA 陳 | 服務恢復 |
| 10:30 | 通知團隊：服務已恢復 | SRE 張 | Slack + Email |
| 10:45 | 通知受影響使用者：服務已恢復 | PM 林 | 系統公告 |
3. 影響評估#
📝 範本#
3.1 業務影響#
| 影響維度 | 評估 |
|---|
| 受影響功能 | {功能清單} |
| 受影響使用者數 | {人數/比例} |
| 收入損失 | {金額/無法計量} |
| 資料損失 | {是/否，描述} |
| SLA 違反 | {是/否，影響 SLA 指標} |
| 信譽影響 | {高/中/低} |
3.2 技術影響#
| 影響維度 | 評估 |
|---|
| 受影響服務 | {服務清單} |
| 相依服務影響 | {是否連鎖影響} |
| 資料一致性 | {是否受影響} |
| 安全性影響 | {是否有安全疑慮} |
📖 使用說明#
- 影響評估用於確認嚴重等級是否正確、作為改善優先級依據
- 業務影響由 PM/產品團隊提供；技術影響由工程團隊評估
- SLA 違反需記錄，可能涉及客戶賠償或內部 KPI
💡 範例#
3.1 業務影響#
| 影響維度 | 評估 |
|---|
| 受影響功能 | 薪資查詢、薪資條下載 |
| 受影響使用者數 | ~200 人（嘗試查詢薪資的員工） |
| 收入損失 | 無直接收入損失（內部系統） |
| 資料損失 | 無 |
| SLA 違反 | 否（SLA 99.5% 月度，本月仍在 SLA 內） |
| 信譽影響 | 低（事件持續 13 分鐘，非上班尖峰） |
4. 根因分析#
📝 範本#
4.1 根本原因#
Root Cause Statement：
{用 1-2 句話精確描述根本原因}
4.2 原因分析方法#
5 Whys 分析：
| 層次 | 問題 | 原因 |
|---|
| Why 1 | {現象} | {直接原因} |
| Why 2 | 為什麼{直接原因}？ | {深層原因} |
| Why 3 | 為什麼{深層原因}？ | {更深原因} |
| Why 4 | 為什麼{更深原因}？ | {系統性原因} |
| Why 5 | 為什麼{系統性原因}？ | 根本原因 |
4.3 貢獻因素#
| 因素 | 分類 | 說明 |
|---|
| {因素} | 人/流程/技術/環境 | {如何促成事件} |
📖 使用說明#
- 5 Whys 是最常用的根因分析方法，追問至系統/流程層面
- 根本原因通常不是「個人失誤」，而是系統/流程允許失誤發生
- 貢獻因素：多個因素共同導致事件，即使單一因素消除也可能避免
- 其他分析方法：魚骨圖（Ishikawa）、故障樹分析（FTA）
💡 範例#
4.1 根本原因#
Root Cause Statement：
新版部署時新增的薪資計算排程 CronJob 被立即觸發（非預期），與正在處理使用者請求的 API 發生資料庫 Row-Level Lock 競爭，導致 API 逾時回傳 500 Error。
4.2 5 Whys 分析#
| 層次 | 問題 | 原因 |
|---|
| Why 1 | API 回傳 500 Error | DB 查詢逾時（Lock Wait Timeout） |
| Why 2 | 為什麼 DB 查詢逾時？ | 薪資計算排程持有 Row-Level Lock，阻塞 API 查詢 |
| Why 3 | 為什麼排程在此時執行？ | CronJob 部署時立即觸發（Concurrency Policy 未設定 Forbid） |
| Why 4 | 為什麼 CronJob 會立即觸發？ | K8s CronJob startingDeadlineSeconds 未設定，過去未觸發的排程被補執行 |
| Why 5 | 為什麼部署流程未驗證此行為？ | 整合測試未涵蓋 CronJob + API 並發場景；部署 Checklist 未包含排程影響評估 |
4.3 貢獻因素#
| 因素 | 分類 | 說明 |
|---|
| 排程與 API 共用 DB 連線池 | 技術 | 排程大量佔用連線，壓縮 API 可用連線 |
| 部署時間選擇上班時段 | 流程 | 增加使用者受影響的機率 |
| 整合測試未含並發場景 | 流程 | 無法在測試階段發現此問題 |
| CronJob 設定無 Peer Review | 流程 | 設定錯誤未被第二人檢查 |
5. 解決方案#
📝 範本#
5.1 緊急緩解（Mitigation）#
5.2 永久修復（Resolution）#
| 修復項目 | 描述 | 狀態 | 預計完成 |
|---|
| {項目} | {描述} | 未開始/進行中/完成 | {日期} |
📖 使用說明#
- 緊急緩解：立即恢復服務（如回滾、Feature Flag、重啟）
- 永久修復：根治根本原因，防止再次發生
- 緊急緩解是「止血」，永久修復是「治本」，兩者都需要
💡 範例#
5.1 緊急緩解#
| 行動 | 時間 | 效果 |
|---|
| 執行 Blue-Green 回滾至 v2.0.3 | 10:25-10:28 | 服務立即恢復 |
| 關閉薪資排程 CronJob | 10:28 | 防止排程再次觸發 |
5.2 永久修復#
| 修復項目 | 描述 | 狀態 | 預計完成 |
|---|
| CronJob 設定修正 | 增加 concurrencyPolicy: Forbid + startingDeadlineSeconds: 300 | 完成 | 2026-05-21 |
| 排程使用 Read Replica | 薪資計算排程改讀取唯讀副本，不與 API 競爭 | 進行中 | 2026-05-25 |
| DB Lock 超時設定 | lock_timeout = 5s，避免無限等待 | 完成 | 2026-05-21 |
| 整合測試補充 | 新增 CronJob + API 並發壓力測試案例 | 未開始 | 2026-05-30 |
6. 改善行動計畫#
📝 範本#
| 行動 ID | 改善項目 | 類型 | 負責人 | 期限 | 狀態 |
|---|
| AI-{xxx} | {改善描述} | 預防/偵測/回應 | {人員} | {日期} | 未開始/進行中/完成 |
📖 使用說明#
- 改善行動分三類：
- 預防：避免問題再次發生（最重要）
- 偵測：更快發現問題
- 回應：更快解決問題
- 每個行動需有明確的負責人與期限
- 行動追蹤至完成（不能只建立不追蹤）
- 建議在 Sprint Planning 中納入改善行動
💡 範例#
| 行動 ID | 改善項目 | 類型 | 負責人 | 期限 | 狀態 |
|---|
| AI-001 | 部署 Checklist 增加「排程任務影響評估」 | 預防 | DevOps 林 | 2026-05-25 | 完成 |
| AI-002 | CronJob 設定需經 Peer Review（PR template） | 預防 | Tech Lead 王 | 2026-05-25 | 完成 |
| AI-003 | 整合測試增加 CronJob + API 並發場景 | 預防 | QA 陳 | 2026-05-30 | 進行中 |
| AI-004 | 薪資排程改用 Read Replica | 預防 | DBA 陳 | 2026-05-25 | 進行中 |
| AI-005 | 新增 DB Lock Wait 監控告警（> 3s 告警） | 偵測 | SRE 張 | 2026-05-22 | 完成 |
| AI-006 | 回滾腳本增加「停止排程」步驟 | 回應 | DevOps 林 | 2026-05-22 | 完成 |
| AI-007 | 部署排程調整為非上班時段（18:00 後） | 預防 | PM 林 | 2026-06-01 | 未開始 |
7. 經驗教訓#
📝 範本#
7.1 做得好的（What Went Well）#
7.2 需要改善的（What Needs Improvement）#
7.3 運氣成分（Where We Got Lucky）#
📖 使用說明#
- 經驗教訓遵循 Blameless Postmortem 文化
- 不問「是誰的錯」，而問「系統/流程如何允許這件事發生」
- 「運氣成分」特別重要 — 下次可能沒那麼幸運，需要改善
- 經驗教訓應分享至整個組織（不僅限事件團隊）
💡 範例#
7.1 做得好的#
- 監控告警在 3 分鐘內觸發（MTTD 優秀）
- SRE 快速定位問題（2 分鐘內確認根因）
- 回滾腳本預先準備且測試過，執行順利
- Blue-Green 架構使回滾近乎零停機
- 團隊溝通順暢，決策快速（從告警到回滾決策 6 分鐘）
7.2 需要改善的#
- CronJob 設定沒有 Code Review 流程
- 整合測試缺乏排程 + API 並發場景
- 部署 Checklist 未涵蓋排程任務影響
- 部署在上班時間進行，增加影響範圍
7.3 運氣成分#
- 發生在 10:15 而非上班尖峰 09:00（若在尖峰影響人數 5x）
- DB Migration 向後相容，回滾不需還原資料庫（否則停機時間可能 > 30 分鐘）
- 當天 SRE 恰好有 PostgreSQL 經驗，快速辨認 Lock 問題
8. 附錄#
📝 範本#
8.1 相關證據#
| 類型 | 內容 | 連結/位置 |
|---|
| 監控截圖 | {描述} | {連結} |
| 日誌片段 | {描述} | {連結} |
| 告警記錄 | {描述} | {連結} |
8.2 參與人員#
| 角色 | 姓名 | 參與時段 |
|---|
| Incident Commander | {姓名} | {時段} |
| Technical Lead | {姓名} | {時段} |
| Communications | {姓名} | {時段} |
8.3 簽核#
| 角色 | 姓名 | 日期 | 簽核 |
|---|
| 事件負責人 | {姓名} | {日期} | ☐ |
| 技術主管 | {姓名} | {日期} | ☐ |
| 部門主管 | {姓名} | {日期} | ☐ |
📖 使用說明#
- 附錄提供事件報告的佐證材料
- 監控截圖保存事件發生時的系統狀態（事後可能已消失）
- 簽核確保報告經過審閱，改善行動有人負責追蹤
- SEV1/SEV2 事件需部門主管簽核；SEV3/SEV4 技術主管即可
💡 範例#
8.1 相關證據#
| 類型 | 內容 | 連結/位置 |
|---|
| Grafana 截圖 | 5xx rate spike 圖表 | evidence/INC-20260520-001/grafana-5xx.png |
| Pod 日誌 | Lock Wait Timeout 錯誤訊息 | evidence/INC-20260520-001/pod-logs.txt |
| pg_stat_activity | 當時的 Lock 狀態快照 | evidence/INC-20260520-001/pg-locks.csv |
| Slack 對話 | 事件處理溝通記錄 | #hrms-ops, 2026-05-20 10:18~10:30 |
8.2 參與人員#
| 角色 | 姓名 | 參與時段 |
|---|
| Incident Commander | SRE 張 | 10:18 - 10:45 |
| Technical Lead | Tech Lead 王 | 10:23 - 10:35 |
| Communications | PM 林 | 10:30 - 10:50 |
| QA | QA 陳 | 10:27 - 10:35 |
📌 範本使用注意事項
- 本範本依據 ITIL 4 Incident/Problem Management 與 Google SRE Postmortem 文化編製
- Blameless 原則：聚焦系統改善而非個人究責
- SEV1/SEV2 事件必須在 5 個工作日內 完成報告
- 改善行動需追蹤至完成，建議每週在 Stand-up 中檢視進度
- 搭配「回滾計畫範本」— 回滾是事件解決的常見手段
- 搭配「SOP 範本」— 事件中發現的操作問題可轉化為新 SOP