🎯 什麼情境該想到我
當你「有一整套災難復原文件，但從來沒有人真的把電源關掉試過一次」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：以大規模故障注入（large-scale fault injection）進行的災難復原演練，目的不只是驗證系統，更是驗證業務流程與人。
由來：Game Day 一詞由 Jesse Robbins 推廣，他在 Amazon 負責確保站點可用性的相關專案，內部被稱為 “Master of Disaster”。他把韌性工程定義為「一項為了透過跨關鍵系統的大規模故障注入來提升韌性而設計的演練」。
五個步驟（照順序做）
- 先排定一個未來的災難事件——例如模擬摧毀一整座資料中心，並訂在未來某個時間點發生。
- 給團隊準備時間——消除所有單點故障（single points of failure），建立必要的監控程序、failover 程序等。
- Game Day 團隊定義並執行演練——例如進行資料庫 failover（模擬主資料庫失效、確認次要資料庫可用），或關掉一條重要的網路連線以暴露既定流程中的問題。遇到的任何問題與困難都要被指認、處理，然後再測一次。
- 到了排定的時間，真的執行斷電——Amazon 的做法是「literally power off a facility—without notice」，然後讓系統自然失效、讓人們照著他們的流程一路走到底。這樣才會暴露出潛伏缺陷（latent defects）：那些只有在注入故障後才會浮現的問題，例如「復原過程所仰賴的某些監控或管理系統，本身就被你所編排的那個故障關掉了」。
- 逐次加強強度與複雜度——這些演練要以越來越強烈、越來越複雜的方式進行，目標是讓它感覺像是平凡一天的一部分（just another part of an average day）。
Google DiRT（Disaster Recovery Program）
- Kripa Krishnan 是 Google 的技術專案總監，撰書當時已帶這個專案超過七年。期間模擬過：矽谷地震導致整個 Mountain View 園區與 Google 斷線、主要資料中心完全失電、甚至外星人攻擊工程師居住的城市。
- Krishnan 強調最常被忽略的測試領域是業務流程與溝通——系統與流程高度交纏，把系統測試與業務流程測試分開並不實際：「a working system is not very useful without the right personnel.」
- 三個具體發現：
- 連線中斷時，到工程師工作站的 failover 根本沒有作用。
- 工程師不知道怎麼接入電話會議橋接，或橋接只能容納五十人，或需要一家「允許他們把某個讓整場會議變成待機音樂的工程師踢出去」的新會議供應商。
- 資料中心備援發電機的柴油用盡時，沒有人知道向供應商緊急採購的程序，結果有人用個人信用卡買了價值 5 萬美元的柴油。
- 另一項產出常被低估：人們真的知道該打給誰、該找誰談——他們與其他部門的人建立起關係，於是事故當下能一起工作，把有意識的動作變成無意識的例行動作。
原文（Robbins 的判準）：「a service is not really tested until we break it in production.」（L10510–10511）
原文（Amazon 的執行方式）：「would literally power off a facility—without notice—and then let the systems fail naturally and [allow] the people to follow their processes wherever they led.」（L10527–10529）
原文（DiRT 的柴油）：「When the data centers ran out of diesel for the backup generators, no one knew the procedures for making emergency purchases through the supplier, resulting in someone using a personal credit card to purchase $50,000 worth of diesel.」（L10567–10570）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 步驟 2 不能跳過。書中的順序是「先排定災難日期 → 給團隊時間消除單點故障與建立 failover → 才執行」。跳過準備期直接斷電，得到的是事故不是演練。
- 演練強度是逐次遞增的，一開始就上最猛的規模只會讓組織拒絕再辦第二次。
- 只測系統不測人是白測——DiRT 的三個發現有兩個（電話橋接、柴油採購）完全與技術架構無關。
- 每次演練結束都應該接一次 廣泛公開事後檢討，否則發現的潛伏缺陷會停在某個人的記憶裡。