chaos-engineer

Chaos Engineer

何時使用此技能

• 設計與執行混沌實驗
• 實作故障注入框架（Chaos Monkey、Litmus 等）
• 規劃與主持遊戲日演練
• 建立爆炸半徑控制與安全機制
• 在 CI/CD 中設定持續混沌測試
• 根據實驗結果改善系統韌性

核心工作流程

1. 系統分析 - 繪製架構、相依性、關鍵路徑與故障模式
2. 實驗設計 - 定義假設、穩定狀態、爆炸半徑與安全控制
3. 執行混沌 - 在監控與快速回滾下執行受控實驗
4. 學習與改善 - 記錄發現、實作修正、強化監控
5. 自動化 - 將混沌測試整合至 CI/CD 以持續提升韌性

參考指南

根據情境載入詳細指引：

主題	參考文件	載入時機
實驗	references/experiment-design.md	設計假設、爆炸半徑、回滾
基礎設施	references/infrastructure-chaos.md	伺服器、網路、可用區域、區域故障
Kubernetes	references/kubernetes-chaos.md	Pod、節點、Litmus、Chaos Mesh 實驗
工具與自動化	references/chaos-tools.md	Chaos Monkey、Gremlin、Pumba、CI/CD 整合
遊戲日	references/game-days.md	規劃、執行、從遊戲日中學習

安全檢查清單

每個實驗必須強制執行的非顯而易見限制：

• 先確認穩定狀態 — 在注入任何故障前，定義並驗證基線指標
• 爆炸半徑上限 — 從最小影響範圍開始；僅在驗證後才擴大
• 自動回滾 ≤ 30 秒 — 中止路徑必須在實驗開始前撰寫腳本並測試
• 單一變數 — 一次只改變一個故障條件，直到行為充分理解為止
• 無安全網則不上生產 — 面對客戶的環境需要斷路器、功能開關或金絲雀隔離
• 閉環 — 每個實驗必須產出書面學習摘要及至少一項追蹤改善

輸出範本

實作混沌工程時，應提供：

1. 實驗設計文件（假設、指標、爆炸半徑）
2. 實作程式碼（故障注入腳本/清單）
3. 監控設定與警示配置
4. 回滾程序與安全控制
5. 學習摘要與改善建議

具體範例：Pod 故障實驗（Litmus Chaos）

以下展示從假設到回滾的完整實驗，使用 Litmus Chaos 於 Kubernetes。

步驟 1 — 定義穩定狀態並套用實驗

# 驗證基線：p99 延遲 < 200ms，錯誤率 < 0.1%
kubectl get deploy my-service -n production
kubectl top pods -n production -l app=my-service

步驟 2 — 建立並套用 Litmus ChaosEngine 清單

# chaos-pod-delete.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: my-service-pod-delete
  namespace: production
spec:
  appinfo:
    appns: production
    applabel: "app=my-service"
    appkind: deployment
  # 限制爆炸半徑：一次僅影響 1 個副本
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"          # 秒
            - name: CHAOS_INTERVAL
              value: "20"          # 每 20 秒刪除一個 Pod
            - name: FORCE
              value: "false"
            - name: PODS_AFFECTED_PERC
              value: "33"          # 最多影響 33% 的副本

# 套用實驗
kubectl apply -f chaos-pod-delete.yaml

# 查看實驗狀態
kubectl describe chaosengine my-service-pod-delete -n production
kubectl get chaosresult my-service-pod-delete-pod-delete -n production -w

步驟 3 — 實驗期間監控

# 追蹤應用程式日誌以檢查錯誤
kubectl logs -l app=my-service -n production --since=2m -f

# 完成時檢查 ChaosResult 判決
kubectl get chaosresult my-service-pod-delete-pod-delete \
  -n production -o jsonpath='{.status.experimentStatus.verdict}'

步驟 4 — 若穩定狀態被破壞則回滾/中止

# 立即停止實驗
kubectl patch chaosengine my-service-pod-delete \
  -n production --type merge -p '{"spec":{"engineState":"stop"}}'

# 確認所有 Pod 健康
kubectl rollout status deployment/my-service -n production

具體範例：使用 toxiproxy 進行網路延遲

# 安裝 toxiproxy CLI
brew install toxiproxy   # macOS；Linux 請使用二進位發行版

# 啟動 toxiproxy 伺服器（與服務並行執行）
toxiproxy-server &

# 為下游相依服務建立代理
toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy

# 注入 300ms 延遲與 10% 抖動 — 爆炸半徑：僅此代理
toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30

# 在此執行負載測試 / 觀察指標 ...

# 移除 toxic 以恢復正常行為
toxiproxy-cli toxic remove db-proxy -n latency_downstream

具體範例：Chaos Monkey（Spinnaker / 獨立版）

# chaos-monkey-config.yml — 限制至單一 ASG
deployment:
  enabled: true
  regionIndependence: false
chaos:
  enabled: true
  meanTimeBetweenKillsInWorkDays: 2
  minTimeBetweenKillsInWorkDays: 1
  grouping: APP           # 每個應用程式殺死一個實例，而非每個叢集
  exceptions:
    - account: production
      region: us-east-1
      detail: "*-canary"  # 絕不殺死金絲雀實例

# 套用並觸發手動殺死以進行測試
chaos-monkey --app my-service --account staging --dry-run false

文件