🎯 什麼情境該想到我
當你「不知道某個相依服務掛掉時系統會怎麼壞，只能等它真的掛了才知道」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：定期（甚至持續不斷地）把故障注入 pre-production 與 production 環境，確認系統以特定且受控的方式失效，而不是以某種不可預測的方式失效。
核心判準：先定義失效模式，再測試它們是否如設計般運作。 Michael Nygard 的類比：就像在車上造出潰縮區來吸收撞擊、保護乘客，你可以決定系統中哪些功能是不可或缺的，並建立能讓裂縫遠離那些功能的失效模式；如果你不設計自己的失效模式，你就會拿到任何碰巧冒出來的那種——通常不可預測而且危險。
Chaos Monkey 的做法
- 一個「持續且隨機地殺掉生產伺服器」來模擬 AWS 失效的服務。
- 目的講得很明確：他們要讓所有工程團隊習慣雲端上持續存在的失效水位，好讓服務能「automatically recover without any manual intervention」（無需任何人工介入就自動復原）。
- Netflix 是為了取得「我們確實達成了維運韌性目標」的保證，才持續把故障注入 pre-production 與 production 環境。
關鍵排程判準：在正常上班時間製造與修復這些問題。
第一次在生產環境跑 Chaos Monkey 時，服務以他們從未預測或想像過的方式失效——正是因為在正常上班時間持續找出並修好這些問題，Netflix 工程師才能快速迭代出更有韌性的服務，同時（一樣在正常上班時間！）創造組織學習。
搭配的架構模式（缺一不可）
- fail fasts：設定積極的 timeout，讓失效元件不會拖垮整個系統。
- fallbacks：每個功能都設計成可降級或退回到較低品質的呈現。
- feature removal：當非關鍵功能在某個頁面上跑得很慢時，直接把它移除，避免影響會員體驗。
Simian Army 全家族（Appendix 9）
- Chaos Gorilla：模擬整個 AWS 可用區（availability zone）失效。
- Chaos Kong：模擬整個 AWS 區域失效，例如北美或歐洲。
- Latency Monkey：在 RESTful 用戶端／伺服器通訊層注入人工延遲或停機，模擬服務降級，確保相依服務有正確反應。
- Conformity Monkey：找出並關閉不遵守最佳實務的 AWS 執行個體（例如不屬於任何 auto-scaling group、或服務目錄裡沒有升級聯絡工程師的 email）。
- Doctor Monkey：接上每個執行個體的健康檢查，找出不健康的執行個體，若擁有者未及時修復根因就主動關閉它。
- Janitor Monkey：確保雲端環境沒有雜物與浪費，搜尋未使用的資源並處置掉。
- Security Monkey：Conformity Monkey 的延伸，找出並終止有資安違規或漏洞的執行個體，例如組態不正確的 AWS security group。
成果驗證：Great Amazon Reboot of 2014
- 為套用一個緊急的 Xen 安全修補，近 10% 的整個 Amazon EC2 伺服器機隊必須重啟。
- Netflix 生產環境的 2,700 多個 Cassandra 節點中有 218 個被重啟，其中 22 個沒有成功重啟。
- 結果：Netflix 那個週末經歷了零停機（0 downtime）。更驚人的是，當時不僅沒有人在處理失效節點造成的事故，根本沒有人在辦公室——他們人在好萊塢慶祝一個併購里程碑的派對上。
原文（核心判準）：「Resilience requires that we first define our failure modes and then perform testing to ensure that these failure modes operate as designed.」（L10461–10462）
原文（Chaos Monkey 的目的）：「automatically recover without any manual intervention.」（L10108–10109）
原文（排程判準）：「by constantly finding and fixing these issues during normal working hours, Netflix engineers quickly and iteratively created a more resilient service」（L10117–10118）
原文（2014 重啟事件的結果）：「Netflix experienced 0 downtime that weekend. Repeatedly and regularly exercising failure, even in the persistence [database] layer, should be part of every company’s resilience planning.」（L10478–10481）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 沒有 fail fasts / fallbacks / feature removal 這類架構模式墊底，注入故障只會製造事故。 Netflix 是先重新架構成鬆耦合、每個元件都有積極 timeout、每個功能都能優雅降級之後，才敢跑 Chaos Monkey。
- 不要在半夜或週末跑。書中反覆強調 during normal working hours——這是把「事故」轉換成「學習」的關鍵條件。
- 目標不是「證明系統很強」，而是找出你原本無法預測或想像的失效方式；因此第一次跑之前要先接受服務會壞。
- 這一條與 遊戲日 是同一組的兩半：這條是持續、隨機、小顆粒；Game Day 是排定、大規模、演練業務流程與人。