本章展示事件回應（Incident Response）在 Google 和 PagerDuty 的實踐，透過四個大型事件的案例研究說明事件管理如何運作，並提供實用的最佳實踐清單來幫助建立自己的事件回應流程。

事件管理的基本前提#

當一個非常規的緊急問題需要多個個人或團隊來解決時，你同時面臨管理事件回應和解決問題兩個挑戰：

  • 解決事件（Resolving）：減輕影響或將服務恢復到先前狀態
  • 管理事件（Managing）：協調回應團隊的工作，確保回應者之間及對關注事件進展的人有良好的溝通

事件回應的基本原則：

  • 維持清晰的指揮鏈
  • 指定明確定義的角色
  • 即時記錄除錯和緩解的工作紀錄
  • 儘早且頻繁地宣告事件

Google 的事件管理#

Google 的事件回應系統基於 事件指揮系統（Incident Command System, ICS），這是 1968 年由消防員建立的用於管理野火的框架。事件回應框架有三個共同目標，也稱為事件管理的「3C」：

  • Coordinate（協調）：協調回應工作
  • Communicate（溝通）：在事件回應者之間、組織內部及外界之間進行溝通
  • Control（控制）：維持對事件回應的控制

當事件回應出問題時，原因很可能在 3C 之一。精通 3C 是有效事件回應的關鍵。

事件回應的主要角色#

事件指揮官（Incident Commander, IC）：

  • 指揮和協調事件回應，按需委派角色
  • 預設承擔所有尚未被委派的角色
  • 有效溝通並保持對事件回應的控制
  • 與其他回應者合作解決事件

營運主管（Operations Lead, OL）：

  • 透過應用營運工具來緩解或解決事件

溝通主管（Communications Lead, CL）：

  • 事件回應團隊的公開面孔
  • 定期向回應團隊和利害關係人提供更新
  • 管理關於事件的查詢

CL 和 OL 都可以帶領團隊來協助管理其特定領域。如果事件範圍縮小，CL 角色可以被重新收回到 IC 角色中。

案例研究 1：軟體 Bug——Google Home 事件#

此案例展示了未能及早宣告事件如何導致團隊缺乏快速高效回應所需的工具。

背景#

Google Home 是一款智慧音箱。Google Assistant 1.88 版中的一個 bug 導致說話者辨識檔案的擷取頻率比預期高 50 倍，超出了配額限制。

事件經過#

  1. 5 月 22 日：開發者 Jasper 注意到 QPS 圖表異常，停止了已部署到 25% 使用者的 1.88 版發布，提交了 bug 報告
  2. 另一位開發者 Melinda 將問題連結到先前已知的 bug 67890，團隊請求臨時增加配額
  3. 5 月 31 日：發布繼續推進到 50%，但 bug 67890 並非真正的根本原因
  4. 客戶開始報告問題，團隊再次請求增加配額，似乎暫時緩解了問題
  5. 6 月 1 日：用戶報告問題已解決，發布繼續
  6. 6 月 3 日（週六）：發布推進到 100%，問題大規模爆發——在週末進行，開發人員不易聯繫
  7. 6 月 4 日（週日）：支援團隊終於將 bug 提升到最高優先級，但團隊未宣告事件，繼續透過 bug 追蹤系統進行「正常」除錯
  8. 下午 3:33，管理者再次增加配額，對使用者的影響停止

檢討#

做得好的： 開發人員在週末集結並提供有價值的輸入。

需要改善的：

  • 成功的事件管理不應依賴個人的英雄式努力
  • 發布應在工作日進行，或組織有薪值班輪值
  • 第一次緩解後應推遲發布直到確定根本原因
  • 團隊未宣告事件——經驗顯示被管理的事件解決更快

及早宣告事件能確保：(1) 防止團隊間的溝通不良；(2) 更早識別根本原因和解決事件；(3) 更早納入相關團隊，加速外部溝通。

集中溝通的重要性#

當災難發生時，SRE 通常聚集在「作戰室」（war room）。作戰室可以是實體的會議室，也可以是虛擬的：IRC 頻道或視訊會議。關鍵是將所有事件回應者聚集在一處，即時溝通以管理並最終解決事件。

案例研究 2：服務故障——GKE CreateCluster 事件#

此案例說明當專家團隊試圖除錯一個互動極度複雜的系統時會發生什麼。

背景#

Google Kubernetes Engine（GKE）是 Google 管理的 Kubernetes 叢集託管系統。由於 Kubernetes 是開源系統，新的外部依賴有時會透過裂縫滲入。

事件經過#

  1. 7:06：倫敦的值班 SRE Zara 因 CreateCluster 探測器故障被呼叫，確認後宣告事件
  2. 四人初始團隊開始在 IRC 頻道除錯
  3. 7:24：客戶支援工程師 Rohit 向使用者發布通知
  4. 8:22：Zara 發布調查摘要，尋找開發人員協助
  5. 8:45：西雅圖資深 SRE Il-Seong 到達辦公室，接手事件指揮
  6. Il-Seong 建立正式的事件回應結構，指定 Zara 為 OL、Herais 為 CL
  7. Herais 發送「全員到齊」（all hands on deck）電子郵件
  8. 9:56：GKE 安全團隊成員 Puanani 發現 DockerHub 的映像檔損壞
  9. Il-Seong 指派負責人同時追求兩個緩解方案
  10. 11:29：SRE Tugay 發現 GCR 鏡像已存在，但快取了損壞的映像
  11. 11:59：GCR 值班清除歐洲儲存層中的損壞映像
  12. 12:11：所有歐洲區域錯誤率降至 0%

整個事件持續 6 小時 40 分鐘，IRC 中出現 41 個獨立使用者，日誌達 26,000 字，啟動了 7 個 IMAG 工作小組，事後檢討包含 28 個行動項目。

檢討#

做得好的： 團隊有多條記錄在案的升級路徑，熟悉事件回應策略。Zara 迅速驗證了客戶受到的影響。

需要改善的：

  • 事件初期 IC 未建立正式的事件回應結構
  • 少數第一回應者在沒有協調的情況下各自調查
  • 服務缺乏通用緩解措施（generic mitigations）——在完全理解根本原因之前就能減輕使用者痛苦的行動

通用緩解措施是第一回應者在根本原因完全確定前採取的減輕痛苦的行動（如回滾最近的發布、重新配置負載均衡器避開某個區域）。它們是粗糙的工具，可能造成其他干擾，但能快速止血。開發通用緩解工具的時機是在事件發生之前，而非緊急回應時。

活動事件的處理優先順序#

  1. 評估事件的影響
  2. 緩解影響（最高優先級）
  3. 執行根本原因分析
  4. 事件結束後，修復原因並撰寫事後檢討

客戶不在乎你是否完全理解了停機的原因，他們想要的是停止收到錯誤。第一回應者必須將緩解放在一切之上。

案例研究 3：電力中斷——閃電兩次擊中同一處#

此案例展示了當遵循良好定義且清晰的回應協議時，即使是罕見的事件也能從容應對。

背景#

2015 年中，閃電在兩分鐘內四次擊中比利時一座 Google 資料中心附近的電網。備用發電機啟動供電，但磁碟托架的 UPS 電池在第三和第四次雷擊時未能切換到備用電池（因間隔太近），導致磁碟托架暫時失電。

事件處理#

  • Persistent Disk SRE 值班立即被通知，確認影響後宣告重大事件並擔任 IC
  • 營運團隊成員被指派三個目標：
    1. 安全恢復電網供電（而非備用發電機）
    2. 重啟所有未託管 VM 的機器
    3. 協調 Persistent Disk SRE 和 GCE SRE，安全地將 VM 從受影響機器遷移後再重啟
  • IC 密切監控進度，在需要時組織更多工程師編寫新工具
  • CL 負責向公司領導、有儲存疑慮的團隊、外部客戶和提交支援工單的特定客戶報告準確資訊

結果#

只有極少量的寫入（事件期間失電機器上的待處理寫入）未能寫入磁碟。由於 Persistent Disk 快照和所有 Cloud Storage 資料儲存在多個資料中心，只有 0.000001% 的資料遺失。

檢討#

透過及早宣告事件並組織有清晰領導的回應，一個精心管理的團隊有效地處理了這個複雜事件。IC 將常規問題委派給適當的 OL，而自己專注於最重要的面向：盡快解決受影響客戶的需求。

案例研究 4：PagerDuty 的事件回應#

PagerDuty 分享了他們經過多年發展和精煉的內部事件回應實踐。

培養團隊合作的方法#

參與模擬演練（Failure Friday）：

  • 受 Netflix Simian Army 啟發
  • 每週進行失敗注入演練
  • 指名 IC 候選人進行訓練
  • 主題專家使用與實際事件相同的流程和術語

進行限時模擬遊戲：

  • 使用「Keep Talking and Nobody Explodes」等遊戲
  • 以時間壓力模擬實際重大事件的緊迫感
  • 迫使玩家有效合作和溝通

從過去事件中學習：

  • 進行並定期審查事後檢討
  • 公開會議和完整文件
  • 記錄所有重大事件中的電話通話以便回顧

PagerDuty NTP 事件（2017 年 10 月 6 日）#

  • 19:53：SRE 收到 NTP 伺服器時鐘漂移告警
  • 20:20：軟體團隊 A 收到服務時鐘漂移告警
  • 21:17：軟體團隊 B 加入已在分診的 Slack 頻道
  • 21:49：SRE 宣告重大事件，通知 IC 值班
  • 21:55：IC 組建回應團隊，包含所有依賴 NTP 的服務值班工程師和客戶支援
  • 接下來 8 小時，回應團隊有條理地嘗試新的恢復方案，每 4 小時輪換值班工程師和 IC
  • 05:33：SRE 對 NTP 伺服器進行配置變更
  • 06:13：IC 驗證所有服務已恢復，宣告事件完成

PagerDuty 使用的工具#

  • PagerDuty：儲存值班資訊、服務所有權、事後檢討和事件中繼資料
  • Slack：維護專用頻道（#incident-war-room）作為資訊帳本
  • 電話會議：所有協調決策在電話會議中進行，決策結果記錄在 Slack

將最佳實踐付諸實踐#

事件回應訓練#

訓練回應者組織事件的方式，使他們在真正的緊急情況下有可遵循的模式：

  • 讓值班人員知道他們可以在事件中委派和升級
  • 鼓勵「先緩解」的回應方式
  • 定義 IC、CL 和 OL 角色
  • 包含實際操作演練，分享過去事件中做得好和不好的地方

事前準備#

決定溝通管道： 事先決定並同意溝通管道（Slack、電話橋接、IRC 等），任何 IC 都不應該在事件期間才做這個決定。

保持聽眾知情： 除非你承認事件正在發生且正被積極處理，否則人們會自動假設沒有人在解決問題。提供定期狀態更新，並事先準備 2-3 個現成的資訊分享範本。

準備聯絡人清單： 事先準備好要通知或呼叫的人員名單，節省關鍵時間。

建立事件標準： 建立一份判斷問題是否確實是事件的標準清單，可以透過審視過去的停機事件和已知高風險區域來制定。

演練#

練習是事件管理流程的最後一步。在不太嚴重的情況下練習，讓團隊養成良好的習慣和行為模式。

演練方式：

  • DiRT（Disaster Recovery Testing）：Google 全公司範圍的韌性測試，創建不影響客戶的控制性緊急情況
  • Wheel of Misfortune：針對特定事件的回應演練
  • 以大事件回應處理小問題：讓團隊在較低風險的真實情境中練習
  • 從事後檢討中創建演練場景：事後檢討包含大量事件管理演練的靈感

演練的最大價值在於事後檢視其結果，這能揭示事件管理中的差距。定期進行演練，並在每次演練後產出報告，詳述做得好的、做得不好的，以及可以改善的地方。

結論#

為災難做好準備。如果團隊定期練習和更新事件回應程序，當不可避免的停機發生時就不會恐慌。

事件指揮系統是一個簡單的概念，易於理解，可根據公司和事件的規模靈活擴展或縮減。雖然容易理解，但要在恐慌突然襲來的緊急情況中保持冷靜並遵循回應結構，需要練習。練習能建立「肌肉記憶」，給你在真正緊急情況下所需的信心。

強烈建議在團隊繁忙的日程中安排時間定期練習事件管理。確保領導層支持專門的練習時間，並讓他們了解事件回應的運作方式。災難準備能節省寶貴的數分鐘或數小時的回應時間。沒有公司每次都做對——從錯誤中學習，繼續前進，下次做得更好。

Backward On-Call Postmortem Culture: Learning from Failure Forward