有效的事件管理是「降低衝擊、儘速恢復正常」的關鍵。沒有預演的應變流程在真實事件中往往失靈。

本章用「失控事件 vs. 受管理事件」兩段對照,呈現 Google 對應的事件管理框架(衍生自美國 Incident Command System)。

失控的事件:一段警世故事#

週五下午 2 點,On-Call 工程師 Mary 的 pager 響了——黑箱監控顯示一個資料中心停止服務。10 分鐘內第二個、第三個也掛——剩餘的兩個吃不下流量,全面過載。

  • Mary 埋頭看 log,回滾到舊版——沒效
  • 打給開發者 Josephine(凌晨 3:30,睡眼惺忪)來看
  • 同事 Sabrina、Robin 各自摸索,沒有協調
  • VP 急著要 ETA、丟出「增大 page size」這類無關但難以反駁的建議
  • Josephine 把問題轉告 Malcolm,Malcolm 自己對 CPU affinity 有靈感 →直接推上線
  • 推送幾秒後伺服器全死

為什麼失控#

每個人都「在做自己該做的事」——但事件還是失控。三大陷阱:

  • 過度聚焦於技術問題:第一線工程師沒餘力看整體
  • 溝通不良:沒人知道別人正在做什麼,VP 也得不到統一資訊
  • 單兵冒進(freelancing):Malcolm 善意推送變更卻沒和現場協調,把情況變更糟

事件管理流程的要素#

一個設計良好的事件管理流程,是用來引導熱忱,避免每個人各自為政。

1. 角色的遞迴分離#

角色職責清楚劃分反而給每個人更多自主——不必互猜彼此正在做什麼。

當某角色負擔過重時,可請求 Planning Lead 加派人力,或自行委任副手、分出子事件。

四個核心角色#

  • 事件指揮官(Incident Command, IC)
    • 維持事件的高階全貌
    • 設計任務編組、依優先級分派責任
    • 凡未委任的職責,IC 都默認自己擔任
    • 為 Ops 排除卡點
  • 運維工作(Ops Lead)
    • 與 IC 配合執行實際修復
    • 事件期間,只有 Ops Team 可以變動系統
  • 溝通(Communication Lead)
    • 事件回應任務組的對外窗口
    • 定期向團隊與利害關係人發更新(通常 email)
    • 維護事件文件
  • 規劃(Planning Lead)
    • 處理長期面:開 bug、訂晚餐、安排交班、追蹤「系統偏離常態」的清單以便日後還原

2. 已知的「指揮所」#

  • 多人協調可在實體 War Room
  • 或留在原座位、透過 email 與 IRC 同步狀態
  • Google 用 IRC 紀錄事件對話:
    • 高可靠
    • 自動留下時間軸(事後檢討的寶物)
    • 寫 bot 自動 log 告警事件
    • 跨地理區團隊好協調

3. 即時事件狀態文件#

事件指揮官最重要的職責是維持一份活的事件文件——多人可同時編輯。

Google 多數團隊用 Google Docs;Google Docs 的 SRE 用 Google Sites(畢竟你正在修的軟體就是 Docs 本身)。

  • 用模板加速產生
  • 最重要的資訊放在最上面
  • 訊息可亂、但要可用
  • 保存供事後檢討用

4. 清晰的即時交班#

下班前必須明確地把指揮權交出去:

  • 透過電話或視訊把狀況同步給新 IC
  • 明確說一句:「你現在是 IC,OK?
  • 在對方明確答覆前不離線
  • 對全體公告交班完成

受管理的事件:另一個版本#

同樣的開場:兩個資料中心垮掉、Mary 的 pager 響。

  • Mary 立刻拉 Sabrina 接 IC:「妳接 command 好嗎?」Sabrina 接了,把現況寫進 email 與事件文件
  • 第三個告警出現時,Sabrina 在 IRC 同步、發 email 更新讓 VP 看到高階狀態而不被細節淹沒
  • 請對外溝通代表開始草擬使用者公告
  • 詢問 Mary 是否要拉開發者,得到許可後通知 Josephine
  • Robin、Josephine 自願協助;Sabrina 提醒他們所有動作須優先聽 Mary,且須回報
  • 兩人快速看完事件文件即融入狀況
  • 5 點開始準備交班:5:45 短會、6 點正式交給跨大西洋的同事
  • 隔天 Mary 上班時,事件已被同事們緩解、關閉、開始事後檢討——Mary 喝口新煮的咖啡,著手結構性改進

何時宣告為「事件」#

寧可早宣告、之後簡單關閉,也別等到問題滾大才啟動框架。

滿足任一條件即視為事件:

  • 修問題需要第二個團隊介入
  • 故障對使用者可見
  • 集中分析 1 小時後仍未解決

事件管理能力不用就會退化。對策:

  • 把框架套用到「跨時區的變更管理」等日常運維上
  • 災難復原演練(DiRT)時也要演練事件管理
  • 角色扮演已解決過的事件,輪流擔任不同角色

結語#

提前演練、可擴展的流程設計、頻繁演練——這三件事讓 Google 的 MTTR 顯著縮短,也讓緊急時刻的工作壓力可控。

事件管理最佳實踐:

  • 優先順序:先止血、恢復服務,保留證據以利根因分析
  • 準備:與相關人員一起預先設計與文件化流程
  • 信任:在指派角色內給予完全自主
  • 內省:留意自己的情緒;感到恐慌就找援軍
  • 考慮替代方案:定期評估目前的方向是否仍正確
  • 常常演練:把流程練到變成第二天性
  • 輪換角色:每個成員都熟悉每個角色