Chaos Engineering
Vibe Prompt
「幫我用 Chaos Mesh 在 K8s 中注入 Pod 故障，測試系統是否自動恢復。」
安裝 Chaos Mesh
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-mesh --create-namespace
Pod 故障實驗
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: pod-kill-example
namespace: chaos-mesh
spec:
action: pod-kill
mode: one
selector:
namespaces: ["production"]
labelSelectors:
app: my-app
duration: "60s"
scheduler:
cron: "@every 10m"
網路延遲實驗
kind: NetworkChaos
apiVersion: chaos-mesh.org/v1alpha1
metadata:
name: network-delay
spec:
action: delay
mode: all
selector:
namespaces: ["production"]
delay:
latency: "1000ms"
correlation: "50"
jitter: "100ms"
duration: "180s"
scheduler:
cron: "@every 30m"
遊戲日
每月固定一天進行 Chaos Game Day，團隊分為攻擊組與防禦組。
關鍵要點
- ✅ Chaos Engineering ≠ 亂搞，而是「用受控實驗發現系統弱點」
- ✅ 核心原則：Steady State → 提出假設 → 引入變數 → 驗證假設
- ✅ 爆炸半徑 (Blast Radius) 必須先控制在最小範圍
- ✅ 生產環境的實驗必須有自動 Rollback 機制
- ✅ 遊戲日 (Game Day) 定期演練讓團隊保持戰備狀態
成熟度模型
| 等級 | 描述 | 範例 | |:----:|------|------| | L0 | 被動，等出事了才處理 | 沒有 Chaos Engineering | | L1 | 開發環境手動測試 | 開發者手動 Kill Pod | | L2 | 自動化非生產測試 | CI/CD 中自動注入故障 | | L3 | 受控生產測試 | 用 Gremlin/Chaos Mesh 執行實驗 | | L4 | 持續自動驗證 | Chaos Engineering 是文化，不是工具 |
常見實驗清單
| 實驗 | 工具 | 預期發現 | |------|------|---------| | Kill 一個 Pod | Chaos Mesh | 是否有足夠副本？ | | 注入網路延遲 | Toxiproxy | 是否有 Timeout 設定？ | | 耗盡 CPU | Stress-ng | Auto Scaling 是否正常？ | | 切斷 AZ 網路 | AWS AZ 故障模擬 | 是否有跨 AZ 備援？ | | 注入磁碟 I/O 高負載 | FIO | 資料庫是否受影響？ |
混沌工程：故意弄壞系統來測試
Netflix 的 Chaos Monkey 隨機終止 production 服務，確保系統能在部分故障時正常運作。
實驗步驟
- 定義穩態（什麼是正常？）
- 假設：關掉一台伺服器仍可維持穩態
- 真的關掉一台伺服器
- 觀察結果，修復弱點
下一章預告：SRE 儀表板
即時監控 SLO、Error Budget、事件狀態。
混沌工程的實踐方法
How：怎麼做混沌工程？
混沌工程不是隨便關掉伺服器來測試——它是一個有系統的實驗過程。
混沌實驗的五個步驟
① 定義穩態
什麼是「系統正常」？例如：API 可用性 > 99.9%、P95 延遲 < 500ms
② 提出假設
如果某台 API Server 掛了，系統仍能維持穩態（因為有 Load Balancer + 多副本）
③ 注入故障
真的關掉一台 API Server（在生產環境或 staging 環境）
④ 觀察結果
監控系統的指標：錯誤率有沒有上升？延遲有沒有增加？Auto Scaling 有沒有啟動？
⑤ 改進或驗證
如果系統維持穩態 → 假設成立，系統夠強韌
如果系統無法維持穩態 → 發現弱點，修復它
常見的混沌實驗
| 實驗 | 工具 | 模擬的情境 | 預期發現的問題 | |:----|:----|:---------|:------------| | Kill Pod | Chaos Mesh | 一台伺服器當機 | 副本數夠不夠？ | | 網路延遲 | Toxiproxy | 跨 AZ 網路變慢 | Timeout 設定是否合理？ | | DNS 故障 | 修改 hosts | DNS 解析失敗 | 有沒有 DNS 快取？ | | 磁碟滿 | dd if=/dev/zero | 日誌塞爆硬碟 | 有沒有磁碟監控？ | | CPU 吃滿 | stress-ng | 惡意程式耗盡 CPU | Auto Scaling 是否正常？ |
爆炸半徑控制（Blast Radius）
混沌工程最重要的原則是控制爆炸半徑——在有限的範圍內進行實驗，即使出問題也不會影響所有用戶。
# Chaos Mesh - 只在 staging 環境執行
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
name: pod-kill-test
namespace: staging # 只在 staging 執行，不是 production
spec:
action: pod-kill
mode: one # 只殺一個 Pod
selector:
namespaces: ["staging"]
labelSelectors:
app: my-api
duration: "60s" # 60 秒後自動恢復
Why：為什麼需要混沌工程？
傳統測試的侷限：
- 單元測試和整合測試只能驗證「功能是否正確」
- 壓力測試只能驗證「效能是否達標」
- 但以上都無法驗證「系統在故障時是否正常」
真實世界的案例：
- Netflix 的 Chaos Monkey 每天隨機終止 production 的服務——因為他們發現工程師寫的容錯程式碼只有在真的遇到故障時才會被驗證是否正確
- Amazon 的「遊戲日」（Game Day）讓團隊模擬各種故障情境
What：混沌工程的成熟度模型
| 等級 | 描述 | 做法 | |:----:|:----|:----| | L0 | 被動 | 等出事了才處理，沒有混沌工程 | | L1 | 開發環境手動測試 | 開發者手動 Kill Pod 測試 | | L2 | 自動化非生產測試 | CI/CD 中自動注入故障 | | L3 | 受控生產測試 | 用 Chaos Mesh 在 production 執行有限實驗 | | L4 | 持續自動驗證 | 混沌工程是文化，不是工具 |
名詞解釋
| 名詞 | 解釋 | |:----|:----| | Blast Radius | 爆炸半徑，故障影響的範圍 | | Steady State | 穩態，系統正常運作的狀態 | | Hypothesis | 假設，實驗前預期的結果 | | Game Day | 遊戲日，團隊模擬故障的演練活動 | | Chaos Monkey | Netflix 的工具，隨機終止 production 服務 | | Rollback Plan | 復原計畫，實驗失敗後的補救措施 |
為什麼要學混沌工程？
系統的容錯能力不是「宣稱」出來的，是「測試」出來的。混沌工程讓你在使用者抱怨之前就發現系統的弱點。這就像消防演習——你不需要真的等火災發生才開始練習怎麼逃生。
下一章預告：SRE 儀表板
混沌工程確保系統夠強韌。但你需要一個地方能看到所有這一切的狀態——下一章的 SRE 儀表板把 SLO、Error Budget、事件狀態、容量使用率全部整合在同一個畫面。