Chaos Engineer

このスキルを使用する場合

• カオスエンジニアリング実験の設計と実行
• フェイルアinjectionフレームワークの実装(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、カオスメッシュ実験の場合
ツール・自動化	references/chaos-tools.md	Chaos Monkey、Gremlin、Pumba、CI/CD統合の場合
ゲームデイ	references/game-days.md	ゲームデイの計画、実行、学習の場合

安全性チェックリスト

すべての実験で強制する必要がある、明白でない制約:

• 定常状態が先 — 障害を注入する前に、ベースラインメトリクスを定義し検証
• ブラストラディウスの上限 — 最小限の影響スコープから開始し、検証後のみ拡大
• 自動ロールバック ≤ 30秒 — 中止パスはスクリプト化され、実験開始前にテスト済み
• 単一変数 — 動作がよく理解されるまで、一度に1つの障害条件のみ変更
• 本番環境は安全ネットなしで実行しない — カスタマーフェーシング環境ではサーキットブレーカー、フィーチャーフラグ、またはカナリア分離が必須
• ループを閉じる — すべての実験は書面での学習サマリーと、少なくとも1つの追跡済み改善を生成する必要がある

出力テンプレート

カオスエンジニアリングを実装する場合、以下を提供します:

1. 実験設計ドキュメント(仮説、メトリクス、ブラストラディウス)
2. 実装コード(フェイルアinjectionスクリプト/マニフェスト)
3. 監視設定とアラート構成
4. ロールバック手順と安全コントロール
5. 学習サマリーと改善推奨事項

具体例: Pod障害実験(Litmus Chaos)

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

ステップ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秒ごとに1つの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           # クラスターごとではなく、アプリごとに1つのインスタンスを削除
  exceptions:
    - account: production
      region: us-east-1
      detail: "*-canary"  # カナリアインスタンスは削除しない

# 適用してテスト用に手動キルをトリガー
chaos-monkey --app my-service --account staging --dry-run false