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

ドキュメント