失敗的理論和現實是兩個領域——系統真的壞之前，你不會知道它與相依系統會怎麼反應。混沌工程把這句話變成日常紀律：主動、定期、甚至持續地向生產環境注入故障，確認系統能以特定且可控的方式失敗，在小問題還小的時候就發現並修掉。
🧠 Intuition
TIP
Michael Nygard（《Release It!》作者）的比喻：就像汽車的潰縮區吸收撞擊、保護乘客，你可以決定哪些功能不可或缺，並主動設計失敗模式來保護它們。你不設計自己的失敗模式，就會拿到無法預測、通常也很危險的那一種。
- 這不是「等它壞」，而是在正常上班時間、可控地把它弄壞——趁大家清醒、聰明的同事就在旁邊，而不是週六凌晨兩點。
- Netflix 從 2009 年把單體 J2EE 重構為 cloud native，並打造 Chaos Monkey：持續隨機關閉生產環境伺服器，逼服務證明自己能自動恢復。第一次在生產跑時，服務以團隊從未預見的方式失敗——但在正常工時反覆發現與修復，迭代出更具韌性的服務。
- 韌性的實證：2011 年 AWS US-EAST 整個可用區當機、拖垮 Reddit 與 Quora，Netflix 幾乎毫髮無傷；2014 年「Great Amazon Reboot」重啟近 10% EC2、Netflix 2,700 多個 Cassandra 節點被重啟 218 個（22 個沒起來），該週末仍是零停機。
⚖️ Tradeoffs
Game Day — 排程一場災難，讓人與流程一起受檢
- Game Day 由 Jesse Robbins 推廣，源自韌性工程——他把它定義為「透過對關鍵系統進行大規模故障注入來提升韌性的演練」。
- 做法：排定一場災難性事件（如模擬整個資料中心毀壞）→ 給團隊時間消除單點故障、備好監控與容錯 → 定義並執行演練（DB 容錯切換、關掉重要網路連線）→ 發現的問題識別、處理、再測 → 到點真的執行停機，讓系統自然失敗、讓人依流程走。
- Google 的 **DiRT（Disaster Recovery Program）**是規模化範例：模擬過矽谷地震讓 Mountain View 園區斷線、主資料中心全黑、甚至外星人攻擊工程師所在城市。
統計性測試 — 不可重現，但仍有價值
- Lemon（fuzz）、Chaos Monkey、Jepsen 這類工具不是可重現的測試：每次亂動的地方不同，不像單元測試能穩定重跑。
- 但價值真實：記下所有隨機動作（用 RNG seed）就能事後重放；把 log 改寫成 release test 多跑幾次，可估「修復信心」；觀察故障的變形能定位可疑區域；後續執行還可能暴露更嚴重的衝擊。
- 代價與心態：這是機率性地找 bug，不保證覆蓋；且要接受「高績效團隊更常失敗」——更頻繁部署本就帶來更多失敗，重點是從中快速學習，而非追究個人。
🔑 Takeaways
- 混沌工程＝主動、可控地注入生產故障，趁小問題還小時發現；不設計失敗模式，就會拿到危險的那種。
- Chaos Monkey 隨機關生產伺服器逼出自動恢復；Game Day（Jesse Robbins，韌性工程）排程整場災難演練，讓人與流程一起受檢；Google DiRT 是規模化範例。
- 這類統計性測試不可重現，但用 RNG seed 記錄後可重放、可估修復信心——是驗證韌性、而非只相信文件的手段，Netflix 在多次 AWS 大當機中的零停機就是實證。
No notes yet — jot your takeaways or Q&A here.