東西會壞是現實；組織長期的健康，取決於人在緊急時刻怎麼回應。好的應變不是臨場英雄主義，而是靠事前準備與週期性演練練出來的——這需要管理層捨得花時間、金錢甚至 uptime 去打磨流程。
🧠 Intuition
TIP
別恐慌。你是受過訓練的專業人員，沒有人有生命危險——再糟也就是「半個網際網路掛掉」。深呼吸、必要時叫援軍（極端情況可以 page 整間公司），有事件回應流程就照流程走。
- 第一優先是止血、不是找根因：先讓系統盡量運作，之後再細究原因。
- 觸發事件的人通常握有最多狀態——好好利用，別急著責怪。
- 所有問題都有解，即便當下不顯然；找不到解就把網撒大：找隊友、找外援、用盡手段。
- 三個真實故障的起因各異（主動測試、設定變更、退役自動化），應變的共通點卻一致：不恐慌、必要時叫人、詳細記錄、從過去學、把教訓內化進系統與流程。
⚖️ Tradeoffs
故障當下 — 三個真實案例教的事
- 測試誘發：對一個測試 DB 阻擋存取，數分鐘內大批相依服務癱瘓。做得好的是立刻升級、果斷中止實驗、並行「繞過測試 DB」加速恢復；學到的是——回滾程序沒在測試環境驗證過，導致回滾本身有 bug。
- 變更誘發：週五全球推送設定觸發 crash-loop，幾乎所有對外服務同時掛。救命的是頻外通訊（out-of-band）讓人在主系統不可用時仍能協調；被影響系統的速率限制意外替 crash-loop 踩了剎車；一個關鍵運氣是推送工程師正盯即時頻道、第一時間發現並回滾。
- 流程誘發：退役自動化因缺少「空集合安全檢查」，把全球同類機器送進 Diskerase 佇列清空硬碟。On-Call 工程師停掉所有團隊自動化、導離流量止血，但復原花了 3 天（重灌基建無法同時處理數千台）。
事件過後 — 把一次故障變成組織的免疫力
- 寫完整、誠實、深入靈魂的事後檢討，找出戰略性的預防（根治），不只戰術性的修補；公司內公開易檢索，並嚴格追蹤行動項目，確保歷史不重演。
- 問大膽、看似不可能的問題：大樓停電怎辦？機架泡在兩呎深的水裡怎辦？主資料中心全黑怎辦？有人入侵 web server 怎辦？你有計畫、也知道系統會怎麼反應嗎？
- 鼓勵主動測試：失敗的理論和現實是兩回事，系統真的壞之前你不會知道它與相依系統怎麼反應。你寧可它壞在週六凌晨兩點，還是平日上班、最聰明的同事就在旁邊？（Google 用 DiRT 破壞測試主動找弱點正是此意。）
🔑 Takeaways
- 緊急時的鐵律：不恐慌、先止血、必要時叫人；觸發者手上狀態最多，善用而非究責。
- 三種起因（測試 / 變更 / 退役自動化）教會同一課：canary 一切變更不論感覺有沒有風險、備妥頻外通訊、把回滾程序也拿去測。
- 事後要留完整誠實的檢討、追蹤戰略性行動項目、問「不可能的問題」、並持續主動測試來驗證修復而非只相信文件——這個迭代循環讓組織愈來愈強壯。
No notes yet — jot your takeaways or Q&A here.