東西會壞——這就是現實。組織的長期健康，取決於人們在緊急時刻的回應方式。良好的應變需要準備與週期性的實作演練，而這需要管理層支援，捨得花時間、金錢甚至 uptime 來打磨流程。
系統壞掉時該做什麼#
別恐慌。你是受過訓練的專業人員，沒有人有生命危險——再糟也就是「半個網際網路掛掉」。深呼吸，然後動手。
- 感到負擔過大時，叫援軍——必要時可以 page 整間公司
- 公司有事件回應流程（見第 14 章）就照流程走
本章透過三個真實案例展示「應該怎麼做」與「我們學到了什麼」。
案例一：測試誘發的緊急事件#
Google 主動以「破壞測試」找出系統弱點（DiRT），多數時候測試結果符合預期；但偶爾現實與假設天差地遠。
事件#
- 計畫：阻擋對「大型分散式 MySQL」中的「一個測試 DB」的所有存取
- 結果：數分鐘內，許多依賴服務報告外部與內部使用者無法存取
- 應變：立即中止測試，但回滾權限失敗 → 改回滾到 replica 與 failover；同步聯絡開發者修 DB 應用層 lib
- 一小時內完全恢復
反思#
✅ 做得好：
- 受影響的服務立刻向公司內升級
- 假設「實驗失控了」並果斷中止
- 並行的「繞過測試 DB」策略加快了恢復
❌ 學到了：
- 對相依系統的互動理解不足
- 事件回應流程剛上線數週，未充分宣導 → 沒走流程
- 沒在測試環境驗證回滾程序，導致回滾本身有 bug
案例二：變更誘發的緊急事件#
事件#
- 一個保護服務免於濫用的基礎建設，週五全球推送設定變更
- 觸發了 crash-loop bug → 幾乎所有對外服務同時 crash-loop
- 因內部基建也依賴自家服務 → 內部應用也大量不可用
應變#
- 數秒內告警爆量；On-Call 工程師因公司網路也掛掉，被迫移到備援「panic room」
- 5 分鐘內，推送工程師意識到自己的變更可能是元凶 → 推送反向變更
- 10 分鐘內依事件流程通知全公司
- 部分服務因衍生問題還是花了一個小時才完全恢復
反思#
✅ 做得好：
- 監控立刻偵測（雖然反而告警爆量淹沒了通訊頻道）
- 頻外通訊系統（out-of-band）讓人在主系統不可用時仍能協調——SRE 平時就維持高可靠、低開銷的備援系統
- 命令列工具與替代存取管道讓 rollback 能成功執行
- 被影響系統的速率限制意外起作用——限制了客戶取得壞版本的速度，等於替 crash-loop 踩剎車
- 一個關鍵運氣：推送工程師正在追即時頻道，第一時間發現大量「無法存取」抱怨，立即 rollback
❌ 學到了：
- 早期 canary 沒觸發此 bug——因該設定關鍵字非常罕見 → 後續一律嚴格 canary，不論「感覺有沒有風險」
- 內部排障工具本身依賴受影響的系統 → 如果再久一點就無法除錯
案例三：流程（自動化）誘發的緊急事件#
事件#
- 自動化測試流程連發兩次「退役」請求給同一組即將下線的伺服器集合
- 第二次因 bug，把全球所有此類安裝送進 Diskerase 佇列——硬碟全部被清
應變#
- 第一個 site 下線時 On-Call 工程師收 page → 排查發現是 Diskerase → 把流量導離
- 全球告警接連爆出 → On-Call 工程師停掉所有團隊自動化
- 一小時內所有流量轉走，使用者僅見延遲增加
- 接下來是漫長的復原：網路擁塞、TFTP 重灌速度極慢、BIOS 處理失敗不佳
- 3 天內恢復絕大多數容量；零星機器後續 1–2 個月
反思#
✅ 做得好：
- 大型機房的反向代理與小型機房不同 → 大型未受影響，可吃下流量
- 雖然監控也被退役掉了，但 On-Call 工程師快速還原監控
- 事件回應流程比一年前成熟得多——跨團隊、跨公司溝通順暢
❌ 學到了：
- 根因：退役自動化伺服器沒做空集合的安全檢查——空回應被當成「全部」傳給機器資料庫
- 重灌基礎建設無法同時處理數千台機器，QoS 設定錯誤、timeout 沒調好、會強迫已就緒的 kernel 重灌——這些都是平日「不會被測到」的退化
所有問題都有解#
系統會壞，且常以你想不到的方式壞。但永遠有解——即便當下不顯然。
- 找不到解就把網撒大：找隊友、找外援、用盡所有手段
- 第一優先是快速止血
- 觸發事件的人通常持有最多狀態——好好利用
事件緩解後別忘了：留時間清理、寫事件報告、學習。
從過去學，不要重複#
保留故障歷史#
- 寫完整、誠實、深入靈魂的事後檢討
- 找出戰略性的預防動作，不只戰術性的修補
- 公司內公開、易檢索的事後檢討文件庫
- 對「行動項目」的追蹤要嚴格——確保歷史不再重演
問大膽、看似不可能的問題#
- 大樓停電怎辦？
- 網路機架泡在兩呎深的水裡怎辦？
- 主資料中心突然全黑怎辦？
- 有人入侵了 web server 怎辦？
你有計畫嗎？你知道系統會怎麼反應嗎？身邊的同事也知道嗎？
鼓勵主動測試#
失敗的理論和現實是兩個不同的領域。系統真的壞之前，你不會知道它與相依系統會怎麼反應。
你寧可故障發生在週六凌晨 2 點（大家還在 Black Forest team-building），還是平日上班時間在你最聰明的同事旁邊？
結語#
三個事件起因不同（主動測試、設定變更、退役自動化），但應變方式有共通點：
- 不恐慌
- 必要時叫人
- 從過去事件學習
- 把學到的內化成系統設計與流程
- 詳細記錄、跨團隊分享
- 持續主動測試以驗證修復而非僅相信文件
這個迭代循環會隨事件累積讓組織愈來愈強壯——本章方法不限 Google 規模，任何組織皆可套用。