# カオスエンジニアリング (Chaos Engineering) ## 定義 カオスエンジニアリングは、「本番環境においてシステムが逆境条件に耐える能力への信頼を構築することを目的として、システム上で実験を実施する規律」である（Principles of Chaos Engineering より）。ユニットテスト・性能テストでは検出できないレジリエンス上の欠陥を、意図的な障害注入(Fault Injection)によって事前に発見・修正する。（Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.3） 実験サイクル: **Steady State の定義 → 仮説の立案（爆発半径最小化と並行）→ Fault Injection → メトリクス分析 → 障害修正 → 仮説の検証 → 実験から学ぶ → システムの改善 →（次の Steady State へ）** 標語: "Hope is not a strategy" / "Chaos in production is not about courage. It is about preparation." ## 実験カテゴリ（Bradesco 第1フェーズ 30+ シナリオ） | カテゴリ | 代表的シナリオ | |---|---| | Hardware | コンテナ/VM 障害、CPU/メモリ/ディスク枯渇、サーバ停止、強制再起動 | | Communication | ネットワーク Blackhole/レイテンシ/パケットロス、DNS 停止、ポート障害 | | App/Microservice | Circuit Breaker、キャッシュ全停止・縮退、Application Probe 停止、Retry Logic | | App/Middleware | ミドルウェアクラスタ障害、証明書失効、メッセージングシステム停止 | | App/Database | DB クラスタ停止・縮退、ストレージサブシステム障害 | （Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.6） ## 導入フェーズの典型パターン（Bradesco 事例） **第1フェーズ: SRE 依存の手動実験** 1. アーキテクチャ把握（シーケンス図・C4 図） 2. クリティカルシナリオのマッピング 3. ステークホルダー合意 4. ツール準備（Azure Chaos Studio, Chaos Toolkit, Dynatrace 等） 5. テスト実行（障害シミュレーション・メトリクス収集） 6. 修正後の再テスト **第2フェーズ: 自動化とガバナンス** 手動実験から「SRE チーム拡大なしのスケール」へ移行するために自動化が必須。再利用可能テンプレート・事前チェック/実行/事後検証パイプライン・継続的/オンデマンドテスト。Bradesco では内製ツール [[EasyPerform]] でガードレール・証跡管理・スケジュール実行を実現した。 ## 本番環境実施の前提条件（p.12） - 行動が文書化されたステージングで事前検証済み - ロールバックランブック（60 秒以内リバート）のテスト済み - フルオブザーバビリティスタック稼働（Dynatrace, Grafana, Elasticsearch 等） - 計画的な低ボリューム実行ウィンドウ - ブラストラジウム定義（1 名前空間 / 1 サービス / 1 依存） ## Principles of Chaos Engineering の5原則(一次資料: Casey Rosenthal) [[Casey Rosenthal]] は Netflix でカオスチームを 3 年間率い、2015 年末に PrinciplesofChaos.org のマニフェストを定式化した当事者である。『SREの探求』14章はその一次資料であり、検証(experiment)は次の4手順のテンプレートで構築されると記す: 1. 通常の動作を示すシステムの測定可能な出力として「定常状態」を定義する 2. この定常状態は対照群および実験群の両方で継続すると仮定する 3. サーバーのクラッシュ・ハードドライブの誤作動・ネットワーク接続の切断など、現実世界のイベントを反映する変数を導入する 4. 対照群と実験群との間の定常状態の違いを調べることによって仮説を反証しようとする さらに、実行がうまくいっているかを把握するための詳細な原則を5つ定義した: 1. **定常状態における振る舞いの仮説を立てる**: 目的はどのように機能するかを明らかにする解明(explanation)ではなく、機能するかどうかのモデルの実証(verification)である 2. **実世界の事象は多様である**: 検証に用いる変数は条件の妥当な範囲をできる限り正確に反映する必要があり、システムの履歴知識・専門知識に依存する 3. **本番環境で検証を実行する**: ステージング環境はいかなる場合も本番環境と同一にはなり得ない。ただし反証にならないと分かっている(疑われる)検証は実行せず、まず問題を修復してから検証で信頼感を確立する 4. **継続的に実行する検証の自動化**: 複雑なシステムは動的であり、信頼感は最後の検証実行から時間が経つほど薄れるため、散発的・特別イベント時のみの実行でなく継続的な自動実行が要る 5. **影響範囲を局所化する**: 検証精度が高まるほど並行実行数を増やせる好循環が生まれる。本番トラフィックの一部を対象範囲に設定することで、危険な状況を発見する検証の安全性を高められる (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.6–§14.7) ## 横断的知見 - **原典著者本人による一次資料が、二次引用経由で蓄積してきた「4ステップ実験テンプレート」を裏付けた**: 本ページはこれまで『SREをはじめよう』10章という二次資料を通じて Principles of Chaos Engineering の4ステップ構造を記述してきた(横断的知見「『カオスエンジニアリングの原則』の4ステップ構造」参照)。『SREの探求』14章は PrinciplesofChaos.org を実際に定式化した [[Casey Rosenthal]] 本人による一次資料であり、同じ4手順(定常状態の定義→対照群/実験群での継続の仮定→現実世界事象の変数導入→仮説の反証)を一字一句対応する形で記す。二次引用の正確性が原典の当事者記録によって確認されたことになる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.6, [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] §10.4) - **「詳細な原則」5項目は、本ページが既に持つ実験サイクル・前提条件の情報を原典レベルで再構成する**: Bradesco 事例(SREcon26 Americas)の実験サイクルは「爆発半径最小化と仮説の立案」を1ステップにまとめているが、Rosenthal の原典は「定常状態の仮説を立てる」と「影響範囲を局所化する」を独立した2原則として分離している。両者は同じ Principles of Chaos Engineering を出典としながら、実務事例(Bradesco)は運用ワークフロー上の便宜で複数原則を1ステップに融合し、原典はより厳密に5原則を並置するという抽象度の違いを示す——本ページ既出の「入門書は原典の実験設計思想を保持し、実務事例はガバナンスパイプラインへ翻訳する」という観察(『SREをはじめよう』10章に関する横断的知見)と同型のパターンが、原典そのものと実務事例の間でも成立する。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.7, [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **「影響範囲を局所化する」原則は [[ブラスト半径]] 概念そのものであり、原典は精度向上と実験数増加の好循環として位置づける**: Rosenthal は「カオスエンジニアリング用のツールが高度化すると検証の精度が高まり、より多くの検証を行える好循環が生まれ、より広い範囲をカバーできるようになる」と述べ、本番トラフィックの一部分を対象範囲とすることで並行実行数を増やせると説明する。これは Bradesco 事例のブラストラジウム定義(1名前空間/1サービス/1依存)を「なぜそう定義するのか」という理論的動機の面から補強する——実務側は静的な制約条件として、原典は動的な好循環の起点として blast radius を扱っている。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.7, [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.12) - **カオスエンジニアリング誕生の理論的動機として、[[複雑システム障害論]] の中核主張と同型の前提が独立に確認できる**: Rosenthal は「複雑なシステムはそのいかなる部分からも全体を理解することはできない」「複雑なシステムは不合理であり、これについて合理的に推論することはできない」と述べ、Netflix がチーフアーキテクトを置かない理由をこれに帰す。これは Richard I. Cook の「How Complex Systems Fail」命題1・6(危険は排除不可能、破滅ポテンシャルは常に存在する)や、いかなる人間も全体像を把握できないという前提と同型であり、Cook の安全工学的認識論とカオスエンジニアリングという実践的規律が、独立に同じ「複雑システムは全体理解不可能」という出発点から異なる処方箋(RCA批判 vs 実験による信頼構築)を導いたことを示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.1) - **Rasmussen の3境界モデルは、カオスエンジニアリングを「安全性シグナルの生成装置」として理論づける**: Rosenthal は Jens Rasmussen の経済・ワークロード・安全性という3境界モデルを引き、安全性だけがシグナルを欠くためシステムは無自覚に安全性境界へ漂流すると説明し、Chaos Monkey がこの欠落した安全性シグナルを人為的に生成する仕組みだったと位置づける。本ページが集約してきた「本番実施への移行タイミングの判断基準」という未解決の問いに対し、これは [[エラーバジェット]] の残量とは異なる角度——安全性シグナルの有無そのものを作り出す必要性——から動機を与える。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.4) - **金融機関(Bradesco)向けの説得ロジックと、Rosenthal の FAQ における業界横断の説得ロジックが独立に収束する**: Rosenthal は FAQ で、フィンテック業界・医療業界からの「本番環境で検証はできない」という反論に対し、「将来の障害の可能性と範囲が分かっているという想定が隠れている」と指摘し、臨床試験を「本番環境(人命)でのカオス検証」の先例として挙げる。Bradesco 事例(SREcon26 Americas)は規制環境の金融機関でもガードレール・証跡管理・段階的導入で本番カオスが実施可能であることを実証しており、Rosenthal が理論面で述べた反論を実務面で裏付ける独立した事例となっている。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.8, [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **金融機関という規制環境でも本番カオスは実施可能**: ガードレール・証跡管理・段階的導入（ステージング→自動化→本番）の3要素で規制コンプライアンスを維持しながら実験できる。Bradesco は Gremlin・Azure Chaos Studio・ToxyProxy 等を組み合わせ、EasyPerform で監査証跡を 100% 確保した。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **「SRE チームを拡大せずに信頼性フレームワークをスケールするには自動化が不可欠」**: 手動実験フェーズは SRE への高依存を生み、スケールの天井となる。自動化・再利用可能テンプレート・ガバナンスプラットフォームの組み合わせがブレークスルーとなった。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **発見された脆弱性は設定ミスが多い**: Redis フェイルオーバー（フォールバック未実装）、Hikari Timeout（30s → 1s 推奨）、Circuit Breaker（Resilience4j 未使用）、JVM の DNS キャッシュ TTL（`networkaddress.cache.ttl=30` 未設定）など、いずれも設定変更で解決可能な問題だった。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.7) - **「本番環境で何かを壊す」という俗説への反論が、実務事例と入門解説の双方から独立に確認できる**: SREcon26 Americas の Bradesco 事例は Principles of Chaos Engineering の定義(「逆境条件に耐える能力への信頼を構築するための実験」)を実務のガバナンス・自動化パイプラインとして具体化した一方、Blank-Edelman は SRE 準備知識としてカオスエンジニアリングを紹介する際に、同じ Principles of Chaos Engineering を引きつつ「本番環境で何かを壊す」ことではなく科学的探求であると明示的に釘を刺している。実践寄りソースと入門解説ソースが、同一の一次定義を参照しながら独立に同じ誤解への注意喚起に至っている。(Source: [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]], [[@2024__OReillyJapan__SREをはじめよう - Chapter 5 SREになるための準備]] §5.6.3) - **性能工学(負荷テスト等)とのセット化は、カオスエンジニアリング固有の学習効果を強調する**: Blank-Edelman は本番実験に限らずカオスエンジニアリングと性能工学を一括りにし、「質問する必要性にすら気づいていなかった疑問への答えを得る」手段と位置づける。これは Bradesco 事例の「ブラインドスポット発見」(30 シナリオ中 10 件、未解決の問い参照)という実証結果と同じ効能を、準備知識としての一般論のレベルで先取りした記述と読める。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 5 SREになるための準備]] §5.6.3) - **『カオスエンジニアリングの原則』の4ステップ構造は、Bradesco 事例の実験サイクルと同一原典に基づく2つの独立した具体化である**: 『SREをはじめよう』10章は同原則を「①定常状態を測定可能な出力と定義する→②定常状態は統制群と実験群の両方で継続すると仮定する→③現実世界の出来事を反映した変数を導入する→④統制群と実験群の定常状態の差異で仮説の反証を試みる」という4ステップとして紹介する。この構造は Bradesco 事例のサイクル(Steady State→仮説→Fault Injection→メトリクス分析→障害修正→仮説の検証→学習→改善)の前半に対応するが、統制群を明示的に置くというアカデミックな実験設計への忠実さは Bradesco の実務サイクルには明示されていない。両ソースが同じ Principles of Chaos Engineering を出典としながら、入門書は原典の実験設計思想を保持し、実務事例はそれを本番運用のガバナンスパイプラインへ翻訳しているという、抽象度の異なる2層の具体化として読める。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] §10.4) - **社会技術システムの人的側面に焦点を当てるシミュレーション型カオスエンジニアリングは、機械への障害注入とは異なる学習対象を持つ**: Blank-Edelman は Amazon の GameDays、Google の Disaster Recovery Testing(DiRT)、『SRE の探求』20章で紹介される Laura Nolan のカードゲームを、機械実験でなく「不測の事態において人々がどのように理解し反応するかを探る」人間側の実験として位置づける。Bradesco 事例のようなツールベースの Fault Injection がシステムのレジリエンスを検証するのに対し、これらのシミュレーションはインシデント対応の意思決定・コミュニケーション・役割分担というオペレーション側のレジリエンスを検証しており、[[レジリエンスエンジニアリング]] が強調する社会技術システムの両輪(機械と人間)にそれぞれ対応する2種類のカオスエンジニアリング実践として整理できる。(Source: [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] §10.4 コラム「ゲームをしませんか?」) - **「本番実施への移行タイミングをどう定量化するか」という本ページ既出の未解決の問いに対して、[[エラーバジェット]] は具体的な判断基準を1つ提供する**: Bradesco 事例や Blank-Edelman の準備知識はステージングでの検証成熟度・オブザーバビリティ充足度といったガバナンス上の前提条件を並べるが、「今この瞬間に実施してよいか」という時点の判断基準までは踏み込まない。Hidalgo(『SLO サービスレベル目標』5章)は、エラーバジェットが大量に残っている状態を、負荷テスト・ストレステスト・ブラックホール演習・エラーインジェクションといった本番実験を実行してよいというデータポイントとして明示的に使う一方、バジェットに余裕がない場合はこの種の作業を延期すべきだと述べる。これはガバナンス条件(前提が整っているか)とは独立した、運用中の残余信頼性という時点の指標であり、両者を組み合わせると「前提条件(Bradesco/Blank-Edelman)が整った上で、エラーバジェットの残量(Hidalgo)が実施可否のトリガーになる」という二層構造として整理できる (Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] §5.1.4–§5.1.6, [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] p.12)。 - **DiRT の一次資料(Google 自身の刊行物)は「リスクが高すぎて実行できなかったテスト」が自動化・定型化された経路を、Bradesco の「手動→自動化」フェーズ移行と独立に確認する**: 『SREをはじめよう』はDiRTを Amazon の GameDays や Laura Nolan のカードゲームと並ぶ「人間側のシミュレーション型カオスエンジニアリング」として一般化して紹介するにとどまる(横断的知見既出)が、Google 自身が著した Anatomy of an Incident 2章は DiRT プログラムの内部進行を一次情報として記述する。当初は実行するにはリスクが高すぎるとみなされていたテスト領域が、長年その領域に注力し続けることで「取るに足らない自動化された定期テスト」へ変わったという経緯は、Bradesco 事例の「第1フェーズ: SRE 依存の手動実験 → 第2フェーズ: 自動化とガバナンス」という移行と同型である。機械への Fault Injection(Bradesco)と人的プロセスのシミュレーション(DiRT)という異なる実践形式が、どちらも「最初は手動・高リスクで始め、継続によって自動化・定型化する」という共通の成熟パスを辿ることを示す。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **カオスエンジニアリングの対象が「本番インフラ」から「LLMエージェントシステム」へ拡張され、"Hope is not a strategy" の原理がLLM API層で再確認された**: Bradesco事例(SREcon26 Americas)やBlank-Edelmanの準備知識が扱うカオスエンジニアリングは、コンテナ・ネットワーク・DB・ミドルウェアといった本番インフラの故障モードを対象とする。[[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection|AgentChaos]]は自らを明示的に「カオスエンジニアリングフレームワーク」と位置づけ、対象をLLMエージェントシステムが依存する**LLM API層**(サーバーエラー・切り詰め・エンコーディング破損)へ広げる。Principles of Chaos Engineeringの定義「本番環境で逆境条件に耐える能力への信頼を構築する実験」は、AgentChaosの実験サイクル(Steady State=障害注入前pass@1 → 仮説=障害設定 → Fault Injection=HTTP層ラッパー → メトリクス分析=Δpass@1)にそのまま対応づけられ、Bradesco事例の「実験サイクル」構造(Steady State→仮説→Fault Injection→メトリクス分析→障害修正→仮説の検証→学習→改善)と同型であることが分野を跨いで確認できる。ただしAgentChaosは学術評価フレームワークであり、Bradescoのような「本番環境での実施」「ガードレール」「ロールバックランブック」といった運用ガバナンス面は扱わない——研究段階のカオスエンジニアリングと実務段階のカオスエンジニアリングという、成熟度の異なる2つの実践として並置できる。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) - **「発見された脆弱性は設定ミスが多い」というBradesco事例の知見と対照的に、AgentChaosが発見する脆弱性は「システム実装のアーキテクチャパターン」に起因する**: Bradesco事例はRedisフェイルオーバー・Hikari Timeout・Circuit Breaker未使用など、いずれも設定変更で解決可能な脆弱性を報告した(横断的知見既出)。AgentChaosが発見する脆弱性はより構造的で、パイプラインパターン(MapCoder)は最初の段階への単一障害でpass@1が最大83.87%低下する一方、反復パターン(EvoMAC)は後続ラウンドでの回復により同じ障害クラスでも劣化が小さい。この違いはモデル(バックボーンLLM)を跨いで一貫しており、単一の設定変更でなく**アーキテクチャレベルの再設計**(段階レベルの出力バリデーション・反復的精緻化の導入)が要る点で、Bradesco事例の「設定ミス修正で解決」パターンより解決コストが高い脆弱性のクラスを可視化している。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]], [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]]) ## 未解決の問い - **AgentChaosは学術評価フレームワークとして5システム×65障害設定という広さで頑健性を測定するが、Bradesco事例が確立した本番実施の前提条件(ステージング検証・ロールバックランブック・ブラストラジウム定義・オブザーバビリティスタック)をLLMエージェントシステムへ適用するには何が要るか**。エージェントシステムの「ブラストラジウム」(1タスク/1エージェント/1LLM呼び出し)はどう定義すべきか。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]]) - DiRT のような人的プロセス寄りのテストと、Bradesco のようなツール中心の障害注入テストとで、「手動→自動化」という成熟パスの速度や障壁は同じか、それとも対象(技術 vs 人的プロセス)によって異なるか。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) - 30 シナリオで 10 のブラインドスポット発見という比率（33%）は他組織の事例と比較してどの程度か？ - Bradesco の EasyPerform のような内製ガバナンスツールが必要な理由は、既存 OSS（Gremlin, LitmusChaos 等）ではカバーできない何があるためか？ - カオスエンジニアリングと通常の障害演習（DR テスト）の違いをどのように組織に説明するか？ - 本番実施への移行タイミングの判断基準（ステージングでの検証成熟度、オブザーバビリティ充足度）はどう定量化できるか？ エラーバジェットの残量を判断材料に加える場合、「十分残っている」をどの閾値(% やバーン率)で定義すべきかは未検討である(Source: [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] §5.1.4–§5.1.6)。 - Rosenthal の「複雑さの経済的な柱」(状態・関係・環境・不可逆性、[[Kent Beck]] のモデル)は、Bradesco の実験カテゴリ(Hardware/Communication/App-Microservice/App-Middleware/App-Database)とどう対応づけられるか。実験カテゴリは特定の柱(例: 環境・関係)に偏っているか、それとも4柱を横断しているか。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.2) - 原典の「詳細な原則」5項目のうち「実世界の事象は多様である」(原則2)を、AIOpsLab/SREGym のような合成ベンチマークの障害設計にどう反映すべきか。[[障害注入]] が集約する「注入パターンの偏り」問題との接続は未検証である。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] §14.7, [[障害注入]]) ## 関連 - [[GameDay]] — カオスエンジニアリングの演習形式。チームへのリアリスティック訓練 - [[レジリエンスエンジニアリング]] — 学術的基盤。「障害のために設計する」という思想的親族 - [[障害注入]] — 実装技術レイヤー - [[エラーバジェット]] — 本番実験の実施可否・実施時期を判断するデータポイントを提供する概念 - [[エージェントシステム運用]] — AgentChaosが対象とするLLMエージェントシステムの運用領域 - [[EasyPerform]] — Bradesco の内製ガバナンスプラットフォーム - [[Bradesco]] — 本事例の実施組織 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 5 SREになるための準備]] — SRE 準備知識としてカオスエンジニアリングと性能工学を紹介する書籍章 - [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] — 失敗から学ぶ実践としてカオスエンジニアリングの定義と実験構造を紹介する書籍章 - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] — エラーバジェットの残量を実験実施の判断材料として使う書籍章 - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — PrinciplesofChaos.org を定式化した [[Casey Rosenthal]] 本人による一次資料。4ステップ実験テンプレートと5つの詳細な原則の原典 - [[Casey Rosenthal]] — Netflix カオスチーム責任者。カオスエンジニアリングの定式化者 - [[Netflix]] — [[Chaos Monkey]]・[[Chaos Kong]] の開発元 - [[複雑システム障害論]] — 「複雑システムは全体理解不可能」という共通前提を持つ姉妹領域 - [[ブラスト半径]] — 原則5「影響範囲を局所化する」と対応する概念 ## 出典 - [[@2026__SREcon26Americas__Executing Chaos Engineering in Production at a Critical Financial Institution]] - [[@2024__OReillyJapan__SREをはじめよう - Chapter 5 SREになるための準備]] — David N. Blank-Edelman(山口能迪 訳), 『SREをはじめよう』, オライリー・ジャパン, 2024, 5章(§5.6.3) - [[@2024__OReillyJapan__SREをはじめよう - Chapter 10 失敗から学習する]] — 同書 10章(§10.4: Principles of Chaos Engineering の4ステップ、GameDays/DiRT/カードゲームによるシミュレーション) - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 5 エラーバジェットの使い方]] — Alex Hidalgo(山口能迪 監訳), 『SLO サービスレベル目標』, オライリー・ジャパン, 2023, 5章(§5.1.4–§5.1.6: 実験・負荷テスト・ブラックホール演習をエラーバジェット残量で判断) - [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]] — LLM API層を対象とするカオスエンジニアリングフレームワーク。§4.1 全体構成、§5.2-5.3 実験結果 - [[@2021__OReillyJapan__SREの探求 - Chapter 14 初めにカオスありき]] — Casey Rosenthal, 「初めにカオスありき」, David N. Blank-Edelman(編)『SREの探求』, オライリー・ジャパン, 2021, 14章