chaos-engineering

カオスエンジニアリングとは、システムが不安定な状況に耐えられるという確信を築くために、システムを対象に実験する分野です。無作為に破壊するのではなく、仮説に基づいた制御された実験によって、障害を引き起こす前に弱点を明らかにします。「デモでは動く」リトライ処理も、決済 API がタイムアウトすると、気付かないうちに顧客への二重請求を引き起こすことがあります。それを知る唯一の方法は、タイムアウトを発生させて挙動を確認することです。

クイックルート

状況	移動先
初めての実験で、チームも慣れていない	小さく始める → 最初の 3 つの実験
1 つの実験を設計する	カオス実験のワークフロー（5 ステップ）
環境に適したツールを選ぶ	ツール → ツール選択の判断フロー
チームでセッションを実施する	ゲームデーの計画
実行可能な障害注入コマンドや設定が必要	references/fault-injection.md
人手を介さずに中止処理を実行したい	references/fault-injection.md → 自動中止

---

確認事項

まず .agents/qa-project-context.md を確認します。存在する場合はコンテキストとして使用し、すでに回答されている質問は省略します。

環境と準備状況：

• カオス実験はどこで実施しますか？（本番前環境のみ、承認を得て本番環境で実施、本番環境では実施しない）
• チームの監視体制はどの程度整っていますか？ リアルタイムに問題を検知できますか？
• チームはインシデント対応の訓練を行っていますか？ ランブックはありますか？
• カオスエンジニアリングについて経営陣の賛同を得ていますか？（本番環境で実験する場合は重要です）

アーキテクチャ：

• アーキテクチャはどのようなものですか？（モノリス、マイクロサービス、サーバーレス、ハイブリッド）
• 重要な依存先は何ですか？（データベース、キャッシュ、メッセージキュー、サードパーティ API）
• 単一障害点はありますか？（単一のデータベース、単一リージョン、冗長性なし）
• どのような冗長化とフェイルオーバーの仕組みがありますか？

現在のレジリエンス対策：

• サービスにヘルスチェックはありますか？ 何を確認していますか？
• サーキットブレーカー、リトライロジック、タイムアウト設定はありますか？
• 依存先が利用できない場合、何が起きますか？（適切な縮退、致命的な障害、不明）
• 予期しない障害を経験したことはありますか？ 何が失敗しましたか？

チームと文化：

• チームは制御された障害に抵抗なく対応できますか？（不安を感じるのは自然なことで、対処する必要があります）
• カオスエンジニアリングを推進する担当者は誰ですか？（この取り組みに責任を持つ人が必要です）
• 導入に対する意欲はどの程度ですか？（小さく始めるか、すぐに本格的に取り組むか）

---

基本原則

1. 仮説に基づく：障害を注入する前に期待される挙動を定義する

カオス実験はすべて、次のような仮説から始めます。「［障害 X］が発生した場合、システムは［期待される挙動 Y］になると考えます」。仮説がなければ、ただシステムを壊しているだけです。仮説では、具体的な定常状態のメトリクス（ベースラインメトリクス）として、エラー率、レイテンシ、スループットと、それぞれの許容変動範囲を明示します。

仮説の例：「プライマリデータベースが利用できなくなった場合、アプリケーションは読み取りリクエストにキャッシュデータを返し、書き込みリクエストを最大 5 分間キューに保持することで、ユーザーに見えるエラーを発生させないと考えます。影響範囲：ステージング環境の単一サービス。定常状態のベースライン：エラー率 <0.1％、P95 レイテンシ <300ms。」

2. 小さく始める：単一サービスで影響範囲を制御する

最初のカオス実験で「本番環境を停止する」ことは避けましょう。「ステージング環境の重要度が低い単一サービスに 200ms のレイテンシを追加する」ことから始めます。確信が深まり、ツールが成熟するにつれて、対象範囲を段階的に広げます。

3. 監視は前提条件

リアルタイムに問題を検知できなければ、安全に障害を注入することはできません。監視なしのカオス実験は、余計な手順を加えた障害にすぎません。実験を実施する前に、ダッシュボード、アラート、オンコールプロセスを確認してください。

4. ゲームデーで対応を体得する

自動化されたパイプラインでカオス実験を実施することにも価値はありますが、ゲームデー、つまりチームが予定を立てて一緒に実験を行い、対応を訓練するセッションでは、実際のインシデント発生時に重要となる人のスキルを磨けます。

---

カオス実験のワークフロー

カオス実験はすべて、次の 5 ステップで進めます。

ステップ 1：定常状態の仮説を定義する

「正常」を定義するメトリクスを特定し、実験中に何が起こるかを予測します。

Experiment: Database failover
Steady state:
  - Error rate: < 0.1%
  - P95 latency: < 300ms
  - Successful orders per minute: > 50

Hypothesis: When the primary database fails over to the replica,
  - Error rate will spike to < 2% for < 30 seconds
  - P95 latency will increase to < 1s for < 60 seconds
  - No orders will be permanently lost
  - The application will recover without manual intervention

ステップ 2：変数を導入する

明確な対象範囲と期間を設定し、障害を制御された方法で注入します。

Injection:
  Target: primary database (PostgreSQL)
  Method: block TCP port 5432 on the primary instance
  Scope: single database instance
  Duration: 60 seconds
  Blast radius: staging environment only (first run)

  Abort conditions:
    - Error rate > 10% for > 2 minutes
    - Any data corruption detected
    - Manual abort by experiment owner

ステップ 3：観察する

実験中は、関連するすべてのメトリクスをリアルタイムで監視します。特定のダッシュボードを担当する観察者を割り当てます。

Observation assignments:
  - Engineer A: application error rate and latency dashboard
  - Engineer B: database metrics (connections, replication lag, failover status)
  - Engineer C: application logs (search for database connection errors)
  - Engineer D: business metrics (order count, payment processing)

ステップ 4：復旧とデータの整合性を分析する

実験後、実際に起きたことと予想していたことを分析します。

Analysis checklist:
  - Did the system behave as hypothesized? (Y/N, with details)
  - How long was the impact? (Expected vs. actual duration)
  - Were any errors visible to users?
  - Was any data lost or corrupted?
  - Did monitoring and alerting detect the problem correctly?
  - How long before alerts fired?
  - What was the recovery time?

ステップ 5：修正して反復する

結果を記録し、レジリエンスの不足箇所を修正したうえで、修正を検証するための再実行を予定します。

Findings document:
  Experiment: Database failover (2026-03-20)
  Hypothesis: Confirmed / Partially confirmed / Disproved
  Recovery time: 45s (expected vs actual: expected <10s, actual 45s)
  Data integrity: no rows lost; 3 writes returned 500 instead of queueing

  Findings:
    - Connection pool did not detect stale connections for 45 seconds (expected: <10s)
    - Retry logic worked correctly for read operations
    - Write operations returned 500 errors for 38 seconds (expected: queued)

  Action items (every one has an owner and a due date — no item is deferred):
    - [ ] Configure connection pool health checks — assigned to @maria, due 2026-03-31
    - [ ] Implement write queue with 5-minute buffer — assigned to @dan, due 2026-04-02
    - [ ] Re-run experiment after fixes deployed (re-run scheduled 2026-04-03);
          specific metrics to check on re-run: stale-connection detection <10s,
          zero write 500s, error rate <2%

---

障害注入の種類

ネットワーク障害

障害	ツール	使用例
レイテンシの注入	tc、toxiproxy、Gremlin	ネットワークの遅延や遠隔リージョンをシミュレートする
パケット損失	tc netem、Chaos Mesh	不安定なネットワークをシミュレートする
DNS 障害	iptables、CoreDNS の操作	DNS の停止をシミュレートする
ネットワーク分断	iptables、Chaos Mesh	スプリットブレインのシナリオをシミュレートする
帯域幅の制限	tc、toxiproxy	ネットワークの輻輳をシミュレートする

tc netem のレイテンシ／パケット損失コマンドと toxiproxy のレイテンシ設定については、references/fault-injection.md を参照してください。

サービス障害

障害	方法	使用例
サービスのクラッシュ	プロセスの終了、Pod の削除	予期しないクラッシュをシミュレートする
サービスの処理速度低下	CPU 負荷、スレッドプールの枯渇	過負荷状態のサービスをシミュレートする
エラーの注入	500／503 の返却、例外のスロー	アプリケーションエラーをシミュレートする
メモリ負荷	stress-ng、Chaos Mesh	メモリリークをシミュレートする

kubectl delete pod コマンドと LitmusChaos の Pod 削除用 ChaosEngine マニフェストについては、references/fault-injection.md を参照してください。

インフラストラクチャ障害

障害	方法	使用例
ディスク容量の枯渇	fallocate、dd	ディスク容量の枯渇をシミュレートする
CPU の枯渇	stress-ng	CPU 飽和状態をシミュレートする
メモリの枯渇	stress-ng	OOM 状態をシミュレートする
クロックのずれ	chrony の操作、timedatectl	時刻のずれをシミュレートする

fallocate によるディスク容量の充填と、stress-ng による CPU／メモリ負荷のコマンドについては、references/fault-injection.md を参照してください。

依存関係の障害

障害	方法	使用例
API の停止	toxiproxy、モックサーバー	サードパーティの停止をシミュレートする
データベースの利用不可	ポートのブロック、プロセスの終了	データベースの停止をシミュレートする
キャッシュの利用不可	Redis ポートのブロック	キャッシュミスの大量発生をシミュレートする
メッセージキューの満杯	キューを満杯にする、コンシューマーをブロックする	バックプレッシャーをシミュレートする

Redis を無効にし、正常な縮退動作を検証する、toxiproxy のプログラムによる統合テストについては、references/fault-injection.md を参照してください。

---

ツール

ツール	種類	最適な用途
LitmusChaos (3.29.x)	Kubernetes ネイティブ、CNCF	K8s 環境、CI/CD との統合。ChaosCenter UI。GameDay-as-code のワークフロー。MCP サーバー（2025 年 10 月）は AI アシスタントから実験を実行します
Chaos Mesh (2.8.x)	Kubernetes ネイティブ、CNCF	細かな制御が必要な K8s 環境。カーネル精度の障害を発生させる、bpfki ランタイム経由の eBPF カオス
AWS FIS	AWS マネージドサービス	AWS ワークロード（EC2、ECS、RDS、EKS）向けのクラウドカオス。CloudWatch アラームによる自動中止用の停止条件 — クラウドネイティブの主要な選択肢です
Gremlin	マネージドプラットフォーム	ガイド付き実験とコンプライアンスレポートを求めるチーム。SLO 違反時に Health Checks が実験を停止してロールバックします
Steadybit	マネージドプラットフォーム	Kubernetes、クラウド、オンプレミスにまたがる信頼性ハブ。Gremlin の直接的な代替製品です
kube-monkey	オープンソース	Litmus／Chaos Mesh が重く感じられる場合の軽量な K8s 代替製品です
Pumba	オープンソース	Docker 専用のカオス（コンテナ、ネットワーク）。K8s 導入前やエッジ向けです
toxiproxy	ネットワークプロキシ、オープンソース	統合テストでのネットワーク障害注入
tc (traffic control)	Linux カーネル	ネットワーク遅延とパケットロス
stress-ng	Linux ユーティリティ	CPU、メモリ、ディスクのストレステスト
k6 (+ xk6-disruptor)	負荷テストツール	負荷とカオスを組み合わせたシナリオ

避けるべきもの：新規プロジェクトでの Chaos Monkey (Netflix) — 活動が低調で、Spinnaker 専用の経路です（2026 年半ば時点）。 現在も動作し、リポジトリもアーカイブされていませんが、インスタンスの終了を注入する機能しかなく、Spinnaker のデプロイパイプラインが必要です。新規開発では Chaos Mesh、LitmusChaos、または AWS FIS を選んでください。（古い SimianArmy リポジトリは 2021 年にアーカイブされました。両者を混同しないでください。）

ツールの選び方

Decision tree:
  Running on Kubernetes?
    → Cloud-managed AWS workloads: AWS FIS (cloud-native, IAM-integrated)
    → On K8s with sidecar tolerance: Chaos Mesh (eBPF, fine-grained)
    → On K8s wanting workflows + UI: LitmusChaos (ChaosCenter, Workflows)
    → On K8s lightweight: kube-monkey

  Running on plain VMs / Docker?
    → Docker only: Pumba
    → Linux: tc + stress-ng (manual)

  Need network fault injection in integration tests?
    → toxiproxy (lightweight, programmatic API)

  Need to combine load testing with chaos?
    → k6 with xk6-disruptor extension

  Need managed platform with UI and compliance?
    → Gremlin or Steadybit (both commercial)

GameDay-as-code

2026 年のトレンドは、カオスをアドホックなイベントではなく、スケジュールされた CI ジョブとして扱うことです。Litmus Workflows、Steadybit reliability hub、Gremlin Scenarios では、カオス実行を YAML で定義し、cron で CI からトリガーできます。以下の Game Day 計画セクションと組み合わせてください。人が取り組むことは依然として重要であり、自動化によって「スケジュールする時間がなかった」というボトルネックを解消するだけです。cron で制御する具体的なパイプライン（オフピーク時間帯に毎晩 pod-delete を実行）と、自動中止／停止条件の例については、references/fault-injection.md を参照してください。

LitmusChaos は 2025 年 10 月に MCP サーバーをリリースしました。Claude などの AI アシスタントを ChaosCenter に直接接続し、YAML を手書きする代わりに、自然言語で実験の一覧表示、実行、停止ができます（「フロントエンドのポッドで pod-delete を実行して」「ネットワーク遅延の実験を停止して」など）。チームがすでに AI エージェントを通じて運用を行っている場合に有用です。

---

Game Day の計画

Game Day は、チームが一緒にカオス実験を実行し、インシデント対応を練習し、システムのレジリエンスに対する信頼を築くための、予定されたセッションです。

準備チェックリスト

2 weeks before:
  - [ ] Define 2-3 experiments to run (don't overload the schedule)
  - [ ] Write hypotheses for each experiment
  - [ ] Get approval from engineering leadership and affected teams
  - [ ] Notify support team and stakeholders
  - [ ] Verify monitoring and alerting are working
  - [ ] Identify rollback procedures for each experiment
  - [ ] Schedule 3-4 hour block (experiments + analysis + retro)

1 day before:
  - [ ] Confirm all participants and their roles
  - [ ] Test that fault injection tools work in the target environment
  - [ ] Verify rollback procedures work (dry run)
  - [ ] Prepare dashboards and observation assignments
  - [ ] Brief the on-call team
  - [ ] Confirm abort criteria for each experiment

コミュニケーションと役割

事前（予定、範囲、中止権限）、実施中（専用チャネルで 15 分ごとに状況を共有）、事後（調査結果とアクションアイテムをまとめた概要を 24 時間以内に共有）にコミュニケーションを行います。

各実験の役割を割り当てます。実験オーナー（実行を担当し、中止を判断する）、オブザーバー（アプリケーションのメトリクス、インフラストラクチャのメトリクス、ログ、ユーザーエクスペリエンスを監視する）、記録係（タイムラインと判断を記録する）です。

Game Day 後の振り返り

各実験について、仮説は裏付けられましたか？ 予想外だったことは何ですか？ どのようなアクションアイテムがありますか？ プロセスについて、監視で問題を検知できましたか？ アラートは発報しましたか？ 影響範囲に問題はありませんでしたか？ 担当者と期限を含むアクションアイテムを決め、次回の Game Day を予定して締めくくります。

---

小さく始める：最初の 3 つの実験

カオスエンジニアリングを初めて行うチームは、まず本番前環境で次の 3 つの実験から始めてください。

実験 1：データベースの遅延

最初に行う理由： データベースの遅延は、ユーザーに見える動作が遅くなる最も一般的な原因であり、実験の設定と元に戻す作業も簡単です。

Hypothesis: When database latency increases by 500ms, the application
will remain functional with response times under 3 seconds.

Injection: Add 500ms latency to the database connection using toxiproxy.
Duration: 5 minutes.
Environment: staging.

What to observe:
  - Application response times (should increase by ~500ms, not 10x)
  - Connection pool behavior (should not exhaust connections)
  - Timeout handling (requests should not hang indefinitely)
  - Circuit breaker activation (if implemented)
  - Cache effectiveness (cached reads should be unaffected)

実験 2：サードパーティ API が 500 エラーを返す

**2 番目の理由：**サードパーティの依存先は定期的に障害を起こしますが、アプリケーションがその障害にどう対処するかは、テストされていないことがよくあります。

Hypothesis: When the payment provider returns 500 errors, the
application will show a user-friendly error message and allow
retry without duplicate charges.

Injection: Configure mock/proxy to return 500 for payment API calls.
Duration: 10 minutes.
Environment: staging.

What to observe:
  - Error message quality (user-friendly, not stack traces)
  - Retry behavior (does the application retry? How many times?)
  - Idempotency (retries don't create duplicate transactions)
  - Fallback (is there an alternative payment path?)
  - Monitoring (does the payment failure show up in alerts?)

実験 3：キャッシュが利用できない

**3 番目の理由：**キャッシュ障害は「サンダリングハード」問題を引き起こします。すべてのトラフィックが突然データベースに集中し、多くの場合、連鎖的な障害につながります。

Hypothesis: When Redis becomes unavailable, the application will fall
back to direct database queries with degraded but functional performance.

Injection: Block Redis port using toxiproxy or iptables.
Duration: 5 minutes.
Environment: staging.

What to observe:
  - Database query volume (should increase but not overwhelm)
  - Response times (should increase but remain under 5 seconds)
  - Error rate (cache miss should not cause errors)
  - Connection pool (database connections should not exhaust)
  - Recovery (when cache returns, does the application resume normal behavior?)

---

アンチパターン

監視なしのカオス

影響を観測できない状態で障害を注入するのは、カオスエンジニアリングではなく、妨害行為です。ユーザーから苦情が出るまで、実験で問題が明らかになったことに気付けません。

**対策：**カオス実験を行う前に、エラー率、レイテンシ、スループット、依存先の健全性をリアルタイムで確認できることを確かめてください。それができない場合は、まず監視に投資してください。さらに一歩進めて、監視を実験に組み込み、しきい値を超えたときに自動で中止するようにしてください。AWS FIS の CloudWatch 停止条件、Gremlin Health Checks、または mode: Continuous の Litmus promProbe が使えます（references/fault-injection.md を参照）。

最初から規模を大きくする

最初のカオス実験で「本番データベースを停止する」べきではありません。影響の小さい実験でチームが経験を積む前に、影響の大きい実験から始めると、不安や実際の障害につながるおそれがあります。

**対策：**まずステージング環境から始めてください。重要度の低いサービスから始めてください。元に戻せる障害注入（データ破損ではなく、レイテンシの注入など）から始めてください。少しずつ自信をつけていきます。ステージングで複数回の実験を成功させてから、本番環境に進んでください。

ロールバック計画がない

「実験は 60 秒だけだから、ロールバック計画はいらない」。その後、障害注入ツールがクラッシュし、障害がいつまでも続きます（コマンドが途中で失敗すると、5 分間の tc によるレイテンシ注入が 2 時間の停止につながるのは、まさにこのようなケースです）。

**対策：**すべての実験に、30 秒以内に実行できるロールバック手順を文書化してください。実験を実行する前にロールバックをテストし、実験の責任者が実行できない場合に備えて、中止できる人をもう 1 人待機させてください。人がキルスイッチを押すのを待つよりも、ツールによって適用される停止条件を優先してください（references/fault-injection.md の「自動中止」を参照）。また、組み込みのタイムアウトがある注入方法（stress-ng --timeout、Litmus TOTAL_CHAOS_DURATION）を選び、誰も監視していなくても障害が自動で解消されるようにしてください。

承認を得ずに本番環境でカオス実験を行う

エンジニアリングリーダーシップや影響を受けるチームから明確な承認を得ずに本番環境でカオス実験を行うと、信頼とキャリアを損ないます。

**対策：**本番環境で実行する前に、エンジニアリングリーダーシップから明示的かつ文書化された承認を得てください。影響を受けるチームに通知し、オンコールチームとサポートチームに概要を説明してください。対象範囲と実施時間を伝え、氏名を明記した中止権限者に中止基準を共有してください。また、影響範囲が実行可能な最小限の対象に限定されていることを確認してください。まずステージング環境から始めてください。ここで省略したことが、制御された実験をインシデントに変えてしまいます。

インシデント発生中にカオス実験を実行する

すでに問題が発生しているシステムに制御された障害を追加すると、原因の特定が難しくなり、停止時間が延びます。

**対策：**システムが安定した状態でない場合は、カオス実験を中止または延期してください。開始前に、進行中のインシデントがないか確認してください。実験中に無関係なインシデントが発生した場合は、直ちに実験を中止してください。

発見事項に対処しない

実験によって、サーキットブレーカーが正しく機能しないことが明らかになりました。チームは「興味深い」と言って先に進み、発見事項は修正されないままです。次の実際の停止でも、同じ障害が発生します。

**対策：**カオス実験の発見事項はすべて、担当者と期限を設定したチケットにしてください。修正後、実験を再実行して確認してください。カオス実験での発見事項のバックログを、本番インシデントのアクション項目と併せて追跡してください。

---

検証

本番環境での実験を一度でも信頼する前に、安全機構が機能することを証明してください。実際に一度も作動させたことのない中止経路は、制御ではなく仮説です。まずは最小限のチェックから始めます。

1. ステージング環境で障害を注入し、元に戻します。 影響範囲が最も小さい障害注入（例：tc qdisc add dev eth0 root netem delay 200ms）をステージングサービス1つに対して実行し、定常状態のダッシュボードに変化が現れることを確認します。次に、文書化されたロールバック（tc qdisc del dev eth0 root）を実行し、メトリクスがベースラインに戻ることを確認します。ロールバックにかかる時間を計測してください。規定の時間内（30秒未満）に完了する必要があります。
2. 自動中止を作動させます。 AWS FIS CloudWatch stop-conditions、Gremlin Health Check、または mode: Continuous の Litmus promProbe に接続した実験で、監視対象のメトリクスをしきい値より高くします（エラー率を停止条件より高くします）。人の操作なしで実験が自動的に停止することを確認します。作動しない場合、中止機構は未検証です（references/fault-injection.md を参照）。
3. 自動解除されるタイムアウトを確認します。 制限時間付きの障害注入（stress-ng --cpu 4 --timeout 60s、または Litmus TOTAL_CHAOS_DURATION: '60'）を開始して、その場を離れます。誰も中止しなくても、期限が来ると障害が自動的に解除されることを確認します。
4. 調査結果を最後まで追跡できることを確認します。 ステージングでの実行後、ベースラインと実測値を比較した数値を含む調査結果ドキュメントが作成されており、各ギャップが担当者付きの追跡対象チケットになっていることを確認します。成果物は実験記録であり、障害注入そのものではありません。

ステージングで手順1～3を実証できない場合、その実験を本番環境へ進めるのは安全ではありません。

---

完了条件

• すべての実験について、障害を注入する前に仮説（「[障害 X] が起きた場合、システムは[期待される動作 Y]をするはずです」）を記録している
• 影響範囲が明確に限定されている。対象範囲、実施時間、中止条件を実験記録に記載し、同じ実験をステージングで少なくとも1回成功させるまでは、本番環境で実施しない
• 各実験記録に定常状態のスナップショット（ダッシュボードへのリンク、またはベースラインの実測値）を添付し、障害注入の直前に取得している
• 各実験について、ベースラインと実測値の比較、復旧時間、データの完全性チェック（損失／破損：はい／いいえ）を明記した調査結果ドキュメントがある
• 発見された弱点ごとに、担当者、期限、および修正を検証するため同じ実験を再実施する予定日を記載した追跡対象チケットがある

参考ファイル（references/ 内）

• fault-injection.md — 各障害クラスを注入する実行可能なコマンド、設定、テストコード：tc netem と toxiproxy のネットワーク障害、kubectl／LitmusChaos のサービス障害（engineState: active の ChaosEngine）、fallocate／stress-ng のインフラ障害、プログラムによる toxiproxy の依存関係障害テストに加え、自動中止／停止条件の例（AWS FIS、Gremlin、Litmus プローブ、Litmus MCP）と、cron で実行を制御する継続的カオスの CI ジョブ。

関連スキル

• testing-in-production — リリース中の安全なロールアウト手法（フィーチャーフラグ、カナリア、ダークローンチ）について。カオスエンジニアリングでは弱点を見つけるために意図的に障害を起こします。testing-in-production では、障害の影響範囲を限定します。ロールアウトについてはそちらを、障害注入についてはこちらを参照してください。
• observability-driven-testing — 本番環境のテレメトリ（トレース、ログ、エラーパターン）を、設計するテストや実験を決めるための入力として使う場合に参照してください。テレメトリが仮説の根拠となり、カオスエンジニアリングでそれを検証または反証します。可観測性は安全なカオスエンジニアリングの必須前提でもあります。
• performance-testing — 負荷テストはカオスエンジニアリングを補完します。負荷と障害を組み合わせて、現実的な障害シナリオを作成します（k6 + xk6-disruptor を参照）。
• release-readiness — カオス実験の結果は、リリースの実施可否と信頼性の評価に役立ちます。
• test-environments — 本番前環境は、カオス実験を安全に始めるための環境です。
• qa-metrics — カオス実験の結果（復旧時間、エラーの影響）は、追跡する価値のある品質メトリクスです。