Streamline Incident Management

Talk Summary

在 DevOpsDays Taipei 2024 分享如何簡化與優化事件管理流程，提升團隊的事件回應效率與系統可靠性。從「非受管事故」的混亂時代出發，介紹如何透過 Incident Bot 與自動化流程，將事故管理從散亂的溝通整合為標準化、可追蹤的 SOP，並建立無責文化（Blameless Culture）來推動有效的事後檢討。

💡 「Incident 就像禮物：只要不收到重複的禮物，你都會喜歡它們。」

涵蓋主題

• Incident Bot 流程標準化 — 透過 Slack /911 command 用 Incident Bot 串起整個 Incident Management 流程
• 事故等級與自動化通知 — S0–S3 分級定義與自動聯防機制
• 角色分工 — IC(Incident Commander) / TL(Tech Lead) / CL(Communication Lead) / EM(Engineering Manager) 角色的職責劃分
• 事故生命週期 — 從事件發生到 Postmortem 的完整流程
• 技術實現 — Incident Middleware 與 Slack 互動整合

混亂的「非受管事故」時代

• 事故是必然的 — 承認系統出錯是工作的一部分，重點在於如何應對
• 資訊散落各處 — 在導入自動化前，資訊散落在不同的 Slack 頻道、Telegram 與私訊中，缺乏統一對話窗口
• 痛點總結 — 資訊分散、缺乏溝通、且沒有標準作業程序（SOP）

Incident Bot：受管事故的核心

透過 Incident Bot 驅動所有事故流程，使用 /911 系列指令進行事故初始化、狀態更新、查看歷史紀錄與指標摘要。

核心功能

• /911 init — 無論問題大小，統一透過此指令啟動事故流程，確保所有相關人員第一時間收到通知
• 自動創建事故頻道 #incident-xxx，將原本口耳相傳的 SOP 固化在 Bot 的互動流程中
• Bot 作為事故處理的「副駕駛（Copilot）」，協助創群、拉人、同步訊息，讓工程師專注於修復系統

事故等級與自動化通知

等級定義（S0–S3）

等級	定義	影響範圍
S0	主要功能完全失效或重大安全事件	大規模用戶影響
S1	主要功能部分失效	顯著用戶影響
S2	非主要系統異常	有限用戶影響
S3	無用戶影響的潛在問題	無直接影響

自動化聯防

根據事故等級，自動拉入對應的群組（如 SRE、PM、客服、行銷）並通知相關頻道，確保資訊即時同步、不遺漏關鍵角色。

事故處理的角色分工

• IC（Incident Commander） — 負責彙整解決方案，推動流程但不介入技術細節處理
• TL（Tech Lead） — 主導技術分析、修復任務的分派與資源協調
• CL（Communications Lead） — 負責對外（客戶、廠商）通知事故影響範疇與時間
• EM (Engineering Manager) - 負責統籌 RCA、彙整並追蹤 Follow-up items、並召開 Postmortem meeting

事故生命週期與事後檢討

五大階段

1. 初始化 — 透過 Incident Bot 建立事故頻道並通知相關人員
2. 調查與修復 — TL 帶領團隊進行技術分析與修復
3. 驗證 — 確認問題已解決並驗證影響範圍
4. 關閉事故 — 正式結束事故流程
5. 事後檢討（Postmortem） — 撰寫包含時序（Timeline）、根因（Root Cause）與追蹤事項（Follow-up Items）的報告

Postmortem 文化

• 提倡 無責文化（Blameless Culture），專注於「什麼事（What）」而非「誰（Who）」
• 採用 Just Culture 而非 Bad Apple Theory，不歸咎個人，讓大家願意提供細節以防止未來再次發生
• S0/S1 等級事故必須召開檢討會議，撰寫完整 RCA 報告

縮短 MTTR 技術實現：Incident Middleware

• 告警整合 — 整合 Alertmanager Webhook，實現從告警產生到自動開啟事故頻道的無縫銜接
• Slack 互動性 — 透過 Slack Interactivity Webhook，讓工程師能直接在 Slack 介面上點擊按鈕建立事故
• Middleware 架構 — 作為 Alertmanager 與 Slack 之間的組件，接收 Webhook 並根據預設規則判斷是否需要轉換成事故