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

🎯 什麼情境該想到我

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

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

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

這件事的前提是心理安全感與無指責文化。在會究責的組織裡刻意弄壞生產環境，只會讓人學會不要當那個按下按鈕的人。書中把「注入故障」與「無指責事後檢討」並列為正義文化的兩根支柱，順序不能顛倒。