事件報告與根因分析範本（Incident Report & RCA Template）
事件報告與根因分析範本（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： ...