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 つだけ — 挙動を十分に理解するまでは、一度に変更する障害条件は 1 つだけにします
• 安全策なしで本番環境を使わない — 顧客向け環境では、サーキットブレーカー、フィーチャーフラグ、またはカナリア分離が必要です
• 最後までやり遂げる — すべての実験で、学びの概要を文書化し、少なくとも 1 件の改善を追跡します

出力テンプレート

カオスエンジニアリングを実装するときは、次を提示します。

1. 実験設計ドキュメント（仮説、メトリクス、影響範囲）
2. 実装コード（障害注入スクリプト／マニフェスト）
3. モニタリングの設定とアラート構成
4. ロールバック手順と安全制御
5. 学びの概要と改善の提案

具体例：Pod 障害実験（Litmus Chaos）

以下では、Kubernetes 上の Litmus Chaos を使用した、仮説からロールバックまでの実験全体を示します。

ステップ 1 — 定常状態を定義して実験を適用する

# Verify baseline: p99 latency < 200ms, error rate < 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
  # Limit blast radius: only 1 replica at a time
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"          # seconds
            - name: CHAOS_INTERVAL
              value: "20"          # delete one pod every 20s
            - name: FORCE
              value: "false"
            - name: PODS_AFFECTED_PERC
              value: "33"          # max 33% of replicas affected

# Apply the experiment
kubectl apply -f chaos-pod-delete.yaml

# Watch experiment status
kubectl describe chaosengine my-service-pod-delete -n production
kubectl get chaosresult my-service-pod-delete-pod-delete -n production -w

ステップ 3 — 実験中にモニタリングする

# Tail application logs for errors
kubectl logs -l app=my-service -n production --since=2m -f

# Check ChaosResult verdict when complete
kubectl get chaosresult my-service-pod-delete-pod-delete \
  -n production -o jsonpath='{.status.experimentStatus.verdict}'

ステップ 4 — 定常状態に違反した場合にロールバック／中止する

# Immediately stop the experiment
kubectl patch chaosengine my-service-pod-delete \
  -n production --type merge -p '{"spec":{"engineState":"stop"}}'

# Confirm all pods are healthy
kubectl rollout status deployment/my-service -n production

具体例：toxiproxy を使用したネットワーク遅延

# Install toxiproxy CLI
brew install toxiproxy   # macOS; use the binary release on Linux

# Start toxiproxy server (runs alongside your service)
toxiproxy-server &

# Create a proxy for your downstream dependency
toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy

# Inject 300ms latency with 10% jitter — blast radius: this proxy only
toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30

# Run your load test / observe metrics here ...

# Remove the toxic to restore normal behaviour
toxiproxy-cli toxic remove db-proxy -n latency_downstream

具体例：Chaos Monkey（Spinnaker／スタンドアロン）

# chaos-monkey-config.yml — restrict to a single ASG
deployment:
  enabled: true
  regionIndependence: false
chaos:
  enabled: true
  meanTimeBetweenKillsInWorkDays: 2
  minTimeBetweenKillsInWorkDays: 1
  grouping: APP           # kill one instance per app, not per cluster
  exceptions:
    - account: production
      region: us-east-1
      detail: "*-canary"  # never kill canary instances

# Apply and trigger a manual kill for testing
chaos-monkey --app my-service --account staging --dry-run false

@jeffallan（Synergetic Solutions のプリンシパルコンサルタント）が保守しています

ドキュメント