工具-注入故障與韌性演練

🎯 什麼情境該想到我

當你有一份寫得很漂亮的復原程序，但從來沒有人真的執行過它，你不確定真出事那天它管不管用時。

先定義失效模式，再測它。書中的判準很直接：不設計自己的失效模式，你就只會拿到隨機而且通常很危險的那種。
日常層級——持續注入故障：Chaos Monkey 的做法是持續且隨機殺掉生產伺服器，目的是逼服務做到不需人工介入就能自動復原。關鍵排程判準：在正常上班時間製造與修復這些問題，不要留給半夜。
年度層級——辦 Game Day（五步驟）：
1. 先排定一個未來的災難事件（例如模擬摧毀整座資料中心）
2. 給團隊時間準備——消除所有單點故障、建好監控與 failover 程序
3. 定義並執行演練（資料庫 failover、關掉重要網路連線），遇到問題就修、修完再測
4. 到了排定時間真的執行——Amazon 的做法是不預告地把一整座設施斷電，讓系統自然失效、讓人照著自己的流程走到底
5. 逐次加強強度與複雜度，目標是讓它感覺像「平凡一天的一部分」
收成的是潛伏缺陷：那些只有在注入故障後才會冒出來的問題——例如「復原用的監控系統本身也被你製造的故障關掉了」。

（以下頁碼為原書 PDF 的實體頁。）

書中對這件事的定義是：注入故障是為了確認系統「以特定且受控的方式失效」（PDF p.379）。不是隨便弄壞，而是驗證你事先設計好的壞法。拆成四道護欄：

護欄	書中依據	做之前要能回答
★ 架構要能降級	Netflix 的架構有 fail fast（積極 timeout）、fallback（降級成較低品質呈現）、feature removal（拖慢頁面的非關鍵功能直接拿掉），在這之上同時持續跑 Chaos Monkey（PDF p.367、p.384 註腳）	這個元件掛了，呼叫它的人會被 timeout 擋住，還是一起卡死？
★ 先寫下「該怎麼壞」	先決定哪些功能不可或缺，再設計失效模式讓裂縫遠離它們（Nygard 的潰縮區比喻）；先定義失效模式，再測它是否照設計運作（PDF p.379）	壞掉時，哪個功能必須活著？哪個功能允許降級成什麼樣子？
範圍逐級放大	pre-production 與 production 都持續注入（PDF p.368）；注入的規模「ever-larger」（PDF p.89）；Netflix 的工具從隨機殺掉程序與伺服器的 Chaos Monkey（PDF p.89），一路到模擬整個可用區（Chaos Gorilla）、整個區域（Chaos Kong）失效（PDF p.479）	這次只動一台？一個服務？還是一整區？上一級跑穩了沒？
在上班時間進行	在正常上班時間持續找出並修好問題（PDF p.368）	出事時，懂這個系統的人是不是都在線上？

正常狀態與中止條件：書中沒有用「steady state」「abort condition」這兩個詞。以下是把書中兩個工具接起來的經驗推論：

「正常」用遙測的平均值與標準差來定義：書中教的作法是算出指標的平均與標準差，偏離常態太多就告警（PDF p.298）。經驗推論：演練前先記下該指標的平常區間，演練中超出這個區間就是越線。
「中止」靠 feature toggle：書中說 toggle 能用改設定的方式快速、安全地關掉出問題的功能，也能在下游服務失效時關掉功能、停止呼叫下游（PDF p.242）。經驗推論：注入故障的開關本身也做成 toggle，越線就關掉，不必等人重新部署。

排期時：寫下要模擬的災難與日期（書例：摧毀一整座資料中心）（PDF p.381）。
準備期：消除單點故障，補齊監控與 failover 程序；先跑小演練，例如資料庫 failover（模擬主庫失效，確認次要資料庫接得起來）、關掉一條重要網路連線。遇到問題就修，修完再測一次（PDF p.381）。
人與流程也要測：系統測試和業務流程測試分不開（PDF p.382）。DiRT 踩過的坑可直接當檢查項：工程師工作站的 failover 有沒有用？會議橋接大家會不會進、容量夠不夠（曾經只容得下五十人）？緊急採購有沒有程序（曾有人刷個人信用卡買 5 萬美元柴油）（PDF p.382–383）？
當天：真的執行，讓系統自然失效，讓人照自己的流程一路走到底（Amazon 是不預告地把整座設施斷電）（PDF p.381）。
看什麼：潛伏缺陷，例如復原要用的監控或管理系統，被你製造的故障一起關掉了；或你原本不知道的單點故障（PDF p.381–382）。
收尾：開無指責事後檢討，定出對策、指派負責人與時程；「把這類故障排進定期 Game Day 演練」本身就是書中列的一種對策（PDF p.373）。

書中案例都是 Amazon、Google、Netflix 等級，沒有講小團隊怎麼開始。以下全部是經驗推論：

原文：「a service is not really tested until we break it in production.」（Jesse Robbins，Amazon 的 “Master of Disaster”）

這件事的前提是心理安全感與無指責文化。在會究責的組織裡刻意弄壞生產環境，只會讓人學會不要當那個按下按鈕的人。書中把「注入故障」與「無指責事後檢討」並列為正義文化的兩根支柱，順序不能顛倒。
沒有降級設計就別注入（經驗推論）。書中 Netflix 是在鬆耦合、每個元件設積極 timeout、每個功能都能降級的架構之上持續注入故障（PDF p.367）；少了這層，注入的就不是演練，是事故。
只測機器不測人等於沒測完。DiRT 的三個發現裡，有兩個（會議橋接、柴油採購）跟技術架構無關（PDF p.382–383）。
事故少了，門檻要跟著往下調。書中說事故減少後要「降低容忍度」，才能繼續學習（PDF p.383）。演練不是做到不出事就可以停。