混沌工程的重點不是弄壞系統，而是把救火變成訓練

這篇 Threads 用 Netflix 的 Chaos Monkey 講混沌工程，但真正值得留下的不是「故意弄壞伺服器」這個戲劇化橋段，而是：把罕見事故變成可控訓練，讓系統與組織在真的出事前先暴露弱點。

Netflix 的 Chaos Monkey 會隨機終止 production 環境中的 VM instances 或 containers。官方 README 對它的描述很直接：更頻繁地讓工程師暴露在失敗情境中，會迫使團隊建立更有韌性的服務。這不是惡作劇，而是一種把失敗前移的工程管理方法。

混沌工程的正式定義來自 Principles of Chaos Engineering：在系統上做實驗，建立它能承受 production 中動盪條件的信心。它不是單純把東西打壞，而是透過可觀測、可控、可復原的實驗，找出分散式系統裡會在真實世界放大的弱點。

典型流程是：

1. 先定義穩態：用可量測指標描述系統正常時應該長什麼樣子，例如錯誤率、延遲、成功率、訂單完成率。
2. 提出假設：即使某個服務變慢、某台機器掛掉、某個 dependency 出問題，穩態仍應維持在可接受範圍。
3. 注入真實世界變數：例如關掉 instance、增加 latency、切斷網路、讓 dependency 回傳錯誤。
4. 觀察是否破壞穩態：如果實驗組和控制組出現明顯差異，就代表找到需要補強的弱點。

Threads 原文補充 Netflix 當年不只 Chaos Monkey，還有 Chaos Kong、Latency Monkey、Conformity Monkey，合稱 Simian Army。這點方向是對的：Netflix 的思路不是只測一種故障，而是把雲端環境裡可能遇到的不同風險拆成多種「猴子」，持續刺激組織面對異常。

但留言裡有一個很重要的提醒：混沌工程不是壓力測試的同義詞，也不只是 monkey testing。壓力測試通常關注流量、容量與性能邊界；monkey testing 偏向隨機操作或輸入以找 bug；混沌工程更偏向「在 production-like 或 production 環境中驗證韌性假設」。它關心的是系統、流程、告警、人員應變是否能一起承受真實事故。

另一個關鍵前提也不能跳過：先有監控，再做混沌。沒有 observability 的團隊不該貿然在 production 亂關服務。你至少要知道：

• 什麼是正常狀態
• 哪些指標代表客戶受影響
• 告警會不會響
• on-call 是否知道怎麼處理
• rollback 或自動修復是否可用
• blast radius 是否可控

否則「演練事故」會變成「製造事故」。

對 BigIntTech 這種多專案、小團隊環境，我會把它翻成更務實的做法：不用一開始就做完整 Chaos Engineering，但可以做「低風險韌性演練」。例如：

• 每季選一個非核心服務，演練 restart、rollback、DB 連線失敗、第三方 API timeout。
• 對重要專案建立最小 runbook：哪裡看 logs、哪裡看 metrics、怎麼重啟、怎麼回滾、誰要被通知。
• 刻意讓非主要負責人照 runbook 處理一次，測試知識是否真的能轉移。
• 對關鍵人依賴做「人員混沌測試」：某個人休假一天，團隊是否還能完成基本操作。
• 先在 staging / demo 做 fault injection，再逐步靠近 production。

這篇最有價值的延伸其實是組織管理：不要只喊「不要讓自己不可取代」，而是定期做小規模替換與演練。真正的韌性不是大家平常都在，而是某個服務掛了、某個人不在、某個供應商失效時，公司仍能保持基本運作。

我的判斷：混沌工程對小團隊最大的價值，不是導入 Chaos Monkey，而是改變事故處理文化。把救火從英雄主義變成訓練科目，把「靠某個人知道」變成「文件、監控、流程、權限都能跑」。這才是值得偷的精髓。

來源：

• Threads：https://www.threads.com/@evan_decoded/post/DXvdvkkm_Jz?xmt=AQF0WLFuyM0UHHKUu-Sj9wyLI2avVU_qbb1hSO_5CoCtRuf8rvWW7kJxBf-NxYUHu8n2K2w&slof=1
• Netflix Chaos Monkey README：https://github.com/Netflix/chaosmonkey
• Principles of Chaos Engineering：https://principlesofchaos.org/