chaos-engineering

カオスエンジニアリング

本番システムの実際の弱点を、障害を引き起こすことなく明らかにする実験を設計します。多くの「カオスエンジニアリング」の試みでは、定常状態の測定が省略され、中止基準が定義されず、影響範囲にも上限が設けられていません。このスキルでは、カオス実験を安全かつ有用にするための規律を徹底します。

使用する場面

• カオス実験を計画するとき（何を、どこで、いつ、どのように中止するか）
• 実験を実行する前に影響範囲を計算するとき
• 既存の実験計画の安全性を確認するとき
• カオスツールを選ぶとき（Chaos Toolkit / Chaos Mesh / Litmus / Gremlin / AWS FIS）
• カオス実験のポストモーテムを書くとき
• Game Day 演習を実施するとき

使用しない場面

• 一般的なインシデント対応（incident-response を使用してください）
• 脅威ハンティング／レッドチーム（red-team、threat-detection を使用してください）
• パフォーマンス負荷テスト（目的が異なります。カオスは容量ではなく障害モードを対象とします）
• 本番環境のデバッグ（カオスは事後ではなく、事前に弱点を発見します）

核となる原則：中止基準のないカオスは障害です

カオスエンジニアリングの 4 原則（Netflix、2016 年）：

1. 定常状態の振る舞いに基づいて仮説を立てます。 「何が壊れるか？」ではなく、「X は維持されているが、障害 Y の下でも維持されるか？」と考えます。
2. 現実世界の事象を変化させます。 ノードの停止、ネットワークの遅延、キャッシュの喪失、依存先のスロットリングなど、現実的な障害を注入します。
3. 本番環境で実験を実行します。 ステージング環境で同じ障害モードが発生することはありません。小さく始めます。
4. 実験を自動化して継続的に実行します。 一度きりのカオスはプレスリリースであり、継続的なカオスこそエンジニアリングです。

5 つ目の原則を加えます。中止基準を事前に定義します。 中止基準のないカオス実験は、呼び方を変えただけの障害です。

クイックスタート

SKILL=engineering/chaos-engineering/skills/chaos-engineering

# 1. Design an experiment
python "$SKILL/scripts/experiment_designer.py" --target "checkout-svc" --hypothesis "p99 latency stays <500ms" --attack latency --duration-min 15

# 2. Calculate blast radius
python "$SKILL/scripts/blast_radius_calculator.py" --traffic-share 0.05 --user-pop 1000000 --duration-min 15

# 3. Generate postmortem after the experiment
python "$SKILL/scripts/experiment_postmortem.py" --plan experiment.json --result-log results.txt

3 つの Python ツール

すべて標準ライブラリのみを使用します。--help を指定して実行してください。

experiment_designer.py

入力から、構造化された実験計画を生成します。必須セクション（仮説、定常状態の指標、影響範囲、中止基準、ロールバック）を徹底します。

python scripts/experiment_designer.py \
  --target "checkout-svc" \
  --hypothesis "p99 latency stays <500ms when payment-svc is slow" \
  --attack latency \
  --magnitude "+200ms" \
  --duration-min 15 \
  --blast-radius "5% of US traffic" \
  --abort-if "p99 > 1000ms OR error_rate > baseline + 1pp"

出力される Markdown 計画には、仮説、定常状態、攻撃、規模、期間、影響範囲、中止基準、ロールバック手順、監視ダッシュボード、学習のための問いが含まれます。

blast_radius_calculator.py

計画中の実験の影響範囲を計算します。トラフィックの割合、ユーザー数、期間から、影響を受けるユーザーの予測数、予想されるエラーバジェットの消費量、リスクスコアを算出します。

python scripts/blast_radius_calculator.py \
  --traffic-share 0.05 \
  --user-pop 1000000 \
  --duration-min 15 \
  --baseline-availability 0.999 \
  --expected-impact-availability 0.95

出力：

• 影響を受けるユーザーの予測数
• 消費されるエラーバジェット（エラーバジェットの分数）
• リスクスコア：GREEN / YELLOW / RED
• 推奨事項：PROCEED / REDUCE / ABORT

GREEN = エラーバジェットの 1% 未満、YELLOW = 1～10%、RED = 10% 超です。

experiment_postmortem.py

実験計画と結果から、構造化されたポストモーテムを作成します。学びが記録されていない、フォローアップアクションがない、非難を含む表現が使われている、といったよくあるポストモーテムの失敗を検出します。

python scripts/experiment_postmortem.py --plan experiment.json --result-log results.txt

出力される Markdown には、概要、仮説（確認されたか、反証されたか）、得られた学び、予想外だったこと、担当者を含むフォローアップアクション、次の実験へのリンクが含まれます。

7 種類の攻撃（分類）

攻撃の種類によって明らかになる弱点は異なります。詳細は references/attack_taxonomy.md を参照してください。

攻撃	テストする内容	ツール
レイテンシ	タイムアウト、リトライ、サーキットブレーカー	tc、Chaos Mesh NetworkChaos
エラー	エラー処理、フォールバック経路	Chaos Mesh HTTPChaos、Toxiproxy
リソース（CPU、メモリ、ディスク）	飽和時の処理、自動スケーリング	Chaos Mesh StressChaos、stress-ng
ネットワーク分断	スプリットブレイン、コンセンサス、フェイルオーバー	Chaos Mesh NetworkChaos partition
依存先の障害	グレースフルデグラデーション、フォールバック	サービスメッシュの障害注入
時間	クロックスキュー、NTP の問題	libfaketime、Chaos Mesh TimeChaos
インフラストラクチャ（インスタンスの停止）	自動復旧、フェイルオーバー	AWS FIS、Chaos Monkey

仮説に合った攻撃を選びます。「X の動作が遅くなったらどうなるか？」ならレイテンシ、「X がネットワークを失ったらどうなるか？」なら分断です。

ツール選定

ツール	最適な用途	料金	スタック
Chaos Toolkit	軽量で言語に依存せず、JSON 実験に対応	OSS	任意
Chaos Mesh	Kubernetes ネイティブで、豊富な CRD とクラスター内実行に対応	OSS	Kubernetes
Litmus	Kubernetes、Argo との統合、豊富なライブラリ	OSS + Enterprise	Kubernetes
Gremlin	エンタープライズ向け SaaS、マルチクラウド、監査	有料	任意
AWS FIS	AWS ネイティブ、IAM 統合、EC2/ECS/EKS	有料（AWS）	AWS
カスタム	ニッチなニーズ、単一クラウド、低予算	なし	任意

選定ルール：

• k8s のみのスタック + OSS → Chaos Mesh または Litmus（Litmus のほうが実験ライブラリが豊富です）
• マルチクラウド + OSS → Chaos Toolkit
• AWS 中心 + シンプルなニーズ → AWS FIS
• エンタープライズ + 監査／コンプライアンス → Gremlin

トレードオフについては references/tooling_landscape.md を参照してください。

ワークフロー

ワークフロー 1：単一の実験を設計して実行する

1. State a hypothesis: "When [fault], steady-state metric X stays within Y."
2. Identify the steady-state metric — must be measurable BEFORE the experiment.
3. Run blast_radius_calculator.py — confirm GREEN before proceeding.
4. Run experiment_designer.py to produce the plan.
5. Get a peer review of the plan; confirm abort criteria are concrete.
6. Notify the on-call team in #incidents (or whatever channel).
7. Run the experiment with monitoring open.
8. If abort criteria are hit, abort immediately; record what happened.
9. Run experiment_postmortem.py to capture learnings.
10. File follow-up actions; link to next experiment.

ワークフロー 2：ゲームデー演習

1. Pick a scenario (e.g., "primary database fails over").
2. Identify all dependent services that should keep working.
3. Build a multi-experiment plan covering each layer.
4. Schedule with stakeholders; on-call coverage required.
5. Run with a facilitator who manages the scenario.
6. Capture observations in a shared doc as they happen.
7. Single combined postmortem covering all observations.
8. Track follow-up actions in a board with owners.

ワークフロー 3：継続的なカオス（ゲームデーから毎日へ）

1. Start: weekly Game Day in staging.
2. Move to: weekly Game Day in production with limited blast radius.
3. Mature to: continuous chaos via scheduled experiments (Litmus chaos schedule, Gremlin scenarios).
4. Wire to deployment: every prod deploy triggers a baseline chaos sweep.
5. Track: experiments per week, weaknesses discovered, MTTR trend.

他のスキルとの組み合わせ

このスキルは、このライブラリの他の 2 つのスキルと明示的に組み合わせて使用します。

スキル	組み合わせ方
feature-flags-architect	そこで定義したキルスイッチを、ここでの中止トリガーとして使います
kubernetes-operator	オペレーターはカオス実験の一般的な対象です（障害発生時の reconcile をテストします）
incident-response	エスカレーションに至ったカオス実験はインシデントになります

アンチパターン

• 仮説がない — 「何かを壊してみよう」はエンジニアリングではなく、妨害行為です
• 定常状態の指標がない — ベースラインがなければ、X が壊れたかどうか判断できません
• 影響範囲に制限がない — 制限のない本番環境全体での実験は、障害につながります
• 中止基準がない — 前述のとおり、必須です
• オンコール体制がない — 監視なしのカオス実験は、監視されていない本番環境を意味します
• ステージングのみでのカオス実験 — ステージングには本番環境の障害モードがありません
• 開発環境でのカオス実験 — 役に立ちません。開発環境の障害モードは本番環境とは異なります
• 一度きりのカオス実験 — 単発の実験はプレスリリースにすぎません。学びには繰り返しが必要です
• 責任追及型のポストモーテム — 責任を追及せず、原因を記録してください。そうしなければ、チームはカオス実験を行わなくなります

参考資料

• references/chaos_principles.md — 4 つの原則、歴史、開始時期
• references/experiment_design.md — 仮説の構成、定常状態の指標、中止基準
• references/attack_taxonomy.md — 7 種類の攻撃と、その例およびツール
• references/tooling_landscape.md — Chaos Toolkit / Mesh / Litmus / Gremlin / FIS / DIY

スラッシュコマンド

/chaos-experiment — 3 つのツールをすべて実行する、対話型の実験設計ウィザードです。

アセットテンプレート

• assets/experiment_template.md — 記入式の計画テンプレート
• assets/postmortem_template.md — 構造化されたポストモーテムのテンプレート

検証可能な成功基準

このスキルを使用するチームは、次の成果を達成できるはずです。

• カオス実験の 100% で、仮説、中止基準、影響範囲の計算が文書化されている
• 単一の実験による影響範囲が、エラーバジェットの 10% を超えない
• カオス実験の平均間隔が 14 日未満（単発ではなく継続的に実施）
• 各実験で 1 件以上のフォローアップアクションが生まれ、リリースされる
• 直近 90 日間で、顧客に影響するインシデントにエスカレーションしたカオス実験がない