# 障害注入 ## 定義 障害注入(fault injection)は、評価・訓練のために制御された障害をシステムへ意図的に導入する取り組みで、AIOps/SRE のベンチマーク構築の根幹をなす。マイクロサービス環境では [[ChaosMesh]] 等のカオスエンジニアリングツールで Pod kill・ネットワーク欠落・資源逼迫・コードレベル障害(JVM エージェント経由)・HTTP セマンティクスの操作などを注入し、生じたテレメトリと既知の注入パラメタ(= ground truth)を対にして検知・[[Fault Localization|箇所特定]]・[[根本原因分析|RCA]]・[[障害緩和|緩和]]の評価データを作る。注入の**何を**(障害種別)・**どこに**(対象コンポーネント)・**どれだけ**(強度)・**どう検証するか**(ユーザー影響の有無)の設計が、ベンチマークの妥当性を左右する。([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) ## 横断的知見 - **SRE Book のテスト戦略は、障害注入を信頼性の確信度を定量化する手段として位置づける**: [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]] はテストを「信頼性の確信度を高めるプロセス」と定義し、カナリアテストにおける障害の次数（U = 影響を受ける利用者の割合）と段階的ロールアウト（1 マシン → 1 クラスタ → 全体）の原則を示す。21,000 テストに対して個々の信頼性を 99.9999% 以上に保つ必要があるという統計的制約は、注入ベースのベンチマーク設計で「何件の障害シナリオが必要か」を定量化する基礎となる。また、ハーメチックテスト（外部依存を排除した密閉テスト）と本番テスト（カナリアテストやブレークグラスメカニズム）の区分は、本ページの「合成環境 vs ライブ注入」の議論と対応する。DiRT（Disaster Recovery Testing）は Google 全社規模の障害注入演習として、テスト環境でなく本番に近い環境での注入の重要性を 2003 年の Oppenheimer et al. と独立に確認する。(Source: [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]]) - **「症状を注入する」か「根本原因を注入する」かでツール評価が割れる**: [[AIOpsLab]] は [[ChaosMesh]] を統合しつつ「カオスツールはシステムの症状しか注入できず、設定ミスやソフトウェアバグのような細粒度の根本原因をモデル化できない」として独自の機能的障害ライブラリで補う。[[SREGym]] はさらに踏み込み、カオスツールを「症状を注入するだけで根本原因を注入しない」として設計原則上避ける。一方 [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] は ChaosMesh を全面採用し、JVM エージェント経由のコードレベル障害や HTTP セマンティクス操作まで含む 31 種の障害空間を構成する——同じ ChaosMesh でも「資源障害だけの症状注入」と見るか「コード/プロトコル層まで届く障害注入」と見るかで評価が分かれる。(Source: [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **注入したからといって障害が観測可能になるとは限らない(silent fault 問題)**: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] は 9,152 回の注入の **84.4% が「No Anomaly」**(ユーザー影響を生まない)だったと定量化した。資源障害は強度の校正窓が狭く(弱すぎると無反応、強すぎると OOM killer が介入)ほぼ全数が無影響、JVM 系は対象メソッドが呼ばれず無影響。これは AIOpsLab/SREGym の「症状しか注入しない」批判をさらに進め、**そもそも注入が障害化しない比率の高さ**を可視化したもの。注入の強度と位置の両方を精密に校正しないと、ベンチマークは無効なケースで埋まる。(Source: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **「ユーザー影響で篩う」impact-driven validation の功罪**: 同論文は SLI(成功率・レイテンシ)への識別可能な影響を持つ注入だけを採用する impact-driven selection を導入し、自動化可能なデータ品質基準とした。しかし論文自身が **oracle problem** として認めるように、この基準は subtle だが真の劣化(gray failure・metastable state 等)を「無効」と誤ラベルし、高度なモデルを不当に不利にする。[[Metastable Failure]] のようにユーザー影響が出る前/出ない形で進む障害は、ユーザー向け SLI 基準の篩からこぼれる。注入の妥当性検証を「ユーザー影響」に固定すると、システム層の重要障害が評価対象から落ちる。(Source: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **注入パターンの偏りが評価を歪める**: 既存ベンチマークの障害ケースは Type I(注入サービスのみに症状が局所化)0.68 + Type II(どのサービスにも顕著な症状が出ない)0.18 = 0.86 を占める。Type I の局所化が「最多アラートのサービス = 根本原因」という単純ヒューリスティック(SimpleRCA)を効かせ、Type II は信号が弱すぎて誰も解けない。注入が「過度に局所化」か「過少発現」かのどちらかに寄ると、ベンチは RCA モデルを弁別できなくなる。注入設計のゴールは Type III(注入サービス以外でより強い症状=symptom drift)を意図的に作り、真の原因と最も目立つ症状を切り離すこと。(Source: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **注入は「障害化しない」問題をレイヤーを越えて抱え、ground truth 化には実環境での観測が要る**: マイクロサービス**ランタイム**への注入が 84.4% silent([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])だったのと同型の問題が、IaC の**デプロイ時**注入にも現れる。[[Zodiac]]([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]])はセマンティックチェック c を検証するため、IaC プログラムを mutate して c を違反させる negative test case $t_n$ を生成しデプロイするが、$t_n$ が問題なくデプロイできてしまう(=注入したが障害化しない)ケースをチェックの偽陽性として弾く。注入対象がテレメトリでも構成グラフでも、「注入 ≠ 障害」のギャップを実環境(マイクロサービス=SLI 影響、IaC=デプロイ成否)の観測で詰めないと ground truth にならない、という構図が共通する。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **「単一の根本原因だけを違反させる」注入の精密化を、[[Zodiac]] は SMT で形式的に保証する**: 注入ベンチの中心課題は「真の原因と最も目立つ症状の切り離し」「複数同時違反の回避」だが([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] の Type 分類)、[[Zodiac]] は negative test case が**ただ 1 つのチェックのみを違反**するよう SMT ソルバに制約を解かせ、他の検証済み/候補チェックには適合させる。これは「注入が複数障害を同時に引き起こすと根本原因を特定できない」という注入設計の悩みに対する、ソルバ支援の構成的な答えになっている。ランタイム注入(ChaosMesh の確率的パラメタ)とは違い、構成空間が離散的・宣言的なため形式手法で「単一違反」を保証できる点が IaC 側の強み。(Source: [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **注入対象が「サービス」から「モデル訓練ループ」へ拡張され、silent fault 問題に "オンライン注入 + 事後検証" で答える**: [[RFT-FaultBench]]([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]])は、マイクロサービスでなく [[強化ファインチューニング]] の訓練ループ(rollout 生成・報酬計算・方策/価値更新・ツール相互作用)へ 16 種の障害をオンライン注入する。注目すべきは「注入したが障害化しない」silent fault 問題([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] の 84.4% No Anomaly)への対処が同型である点——RFT-FaultBench は注入後に Post Hoc Verifier が fault 固有規則で「意図した異常が誘発され、テレメトリが期待 signature と一致するか」を検証し、合格ランのみを保持する。これはマイクロサービスの impact-driven validation(SLI 影響で篩う)・IaC のデプロイ成否で篩う Zodiac と同じ「注入 ≠ 障害のギャップを実観測で詰める」骨格を、訓練テレメトリ(reward/KL/entropy)上で実装したもの。さらに scaled/intermittent/gradual/delayed の難度次元は、マイクロサービス注入の「強度校正窓」問題を訓練ダイナミクスへ持ち込んだ対応物にあたる。(Source: [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **注入の妥当性検証を「事後フィルタ」でなく「閉ループの自己修正」に組み込む**: silent fault 問題への既存の答えは、注入後に妥当性を篩う事後検証だった——マイクロサービスの impact-driven validation(SLI 影響で篩う)、IaC のデプロイ成否で篩う [[Zodiac]]、RFT-FaultBench の Post Hoc Verifier。[[Cloud-OpsBench]]([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]])は同じ「注入 ≠ 障害」のギャップを、3 エージェント MAS(Generator/Executor/Verifier)の**閉ループ**で詰める。Kubernetes の自己修復(Pod 再スケジュール等)が注入を打ち消す「自動マスク」を Verifier が検出し、注入強度を上げて再実行する自己修正を回す。事後に合否を判定するだけの静的なカオス注入と違い、「注入が本当に効いたか」を検証して強度を動的に調整する点が新しい。障害を ⟨P,A,S⟩(Precondition/Action/State)で形式化し、ChaosBlade + atomic kubectl で実行、40 種・7 カテゴリ(表2)を構成する。(Source: [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **決定論的再現を「ライブで毎回注入」でなく「一度注入した状態の凍結・再生」で得る**: ランタイム注入(ChaosMesh の確率的パラメタ)は非決定的で、同じ注入が毎回同じ障害を生むとは限らない([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] の 84.4% silent もこの非決定性の表れ)。[[Cloud-OpsBench]] は注入後の状態(メトリクス・ログ・コントロールプレーン設定・データプレーン状態)を凍結した決定論的デジタルツイン(State Snapshot Paradigm)を作り、再現性を注入の繰り返しでなく snapshot の保存・再生で得る。これは [[Zodiac]] が IaC のデプロイ時注入を SMT で「単一違反」に固定して再現性を担保したのと同じ「非決定的なライブ注入を決定論的な構成へ落とす」方向の、ランタイム側での対応物。(Source: [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]], [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **障害注入の有効性を「実障害データとの突き合わせ」で評価した最初の実証が 2003 年に存在する**: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] は Online の 40 件のサービス障害を事後的に分析し、オンライン障害注入・負荷テストが 6 件のサービス障害を回避し得たと推定した。さらに障害の露出・監視の強化が 12 件の修復時間を短縮し、オンライン正当性テスト（26 件）に次ぐ 2 番目に有効な緩和技法とされた。現代の障害注入ベンチマーク（AIOpsLab・SREGym・Cloud-OpsBench）が合成環境で障害化率や RCA 精度を測定するのに対し、Oppenheimer et al. は実障害への事後的適用可能性を測定する「逆方向の評価」を行った点で対照的である。しかし同論文が指摘した「オフラインテスト環境は本番と微妙に異なるため、オンラインでの障害注入の方が効果的」という知見は、現代のライブ注入 vs. snapshot ベースの議論（SREGym のライブ注入 vs. Cloud-OpsBench の State Snapshot）にもそのまま通じる。(Source: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **障害注入が「マイクロサービス/IaC/訓練ループ」に続き「集合通信ハードウェア」へ広がる**: 注入対象はサービスランタイム・IaC デプロイ・RFT 訓練ループと拡張してきたが、[[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]] は LLM 訓練の[[集合通信]]層へ 7 種のハードウェア/システム障害(NIC シャットダウン・NIC 帯域制限・PCIe ダウングレード・GPU パワーリミット・バックグラウンド計算・バックグラウンドトラフィック・NCCL 遅延)を注入し、依存駆動 RCA が 7 種すべてで根本原因を正確に特定できることを検証する。注目すべきは、マイクロサービスの 84.4% silent fault 問題([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])と違い、これらの注入は明確な観測可能信号(完了ログ欠落・GPU_ready 停滞・送受信不均衡)を生む——注入が確実に障害化するのは、対象が確率的なサービス負荷でなく決定的なハードウェア状態だからで、「注入 ≠ 障害」のギャップは対象層の状態の決定性に依存する。(Source: [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) ## 未解決の問い - impact-driven validation の oracle problem をどう緩和するか。ユーザー向け SLI 以外に、gray failure や [[Metastable Failure]] のようなシステム層障害を自動で ground truth 化する検証オラクルは設計できるか。 - 注入の 84.4% が silent になる問題に対し、障害化する強度・位置を効率的に探索する方法は何か。human-in-the-loop の feedback(本論文)以外に、過去の注入結果から障害化確率を学習して注入点を選ぶ能動的サンプリングは有効か。 - カオスツール(ChaosMesh)の「症状注入」と、設定ミス・コードバグのような「根本原因注入」(AIOpsLab の機能的障害ライブラリ、SREGym の設計)を統合した障害空間はどう設計すべきか。両者を同一ベンチで扱う統一フォーマットはありうるか。 - 単一システム([[Train-Ticket]])への注入で得た失敗モードは、他のマイクロサービスシステムへ一般化するか。注入ベンチの外的妥当性をどう担保するか。 - 注入パラメタから階層ラベル(Service/Pod/Container/Function)を導く ground truth は、cascading failure で真に曖昧さがないか。複数コンポーネントが同時に異常化する伝播ケースで「単一の根本原因」を仮定してよいか。 - [[Zodiac]] が IaC のデプロイ時注入で達成した「SMT による単一違反の保証」を、マイクロサービスのランタイム注入へ持ち込めるか。確率的なカオス注入でなく、ソルバ/プランナで「狙ったコンポーネントだけが障害化し、副作用が他へ波及しない」注入を構成できるか([[障害注入]]の Type III 設計の自動化)。 - [[RFT-FaultBench]] の Post Hoc Verifier(fault 固有規則で「期待 signature と一致するか」を検証)は、マイクロサービスの impact-driven validation や IaC のデプロイ検証と同じ「注入の妥当性検証」だが、検証規則を fault 種別ごとに人手設計する。マイクロサービスの 84.4% silent fault 問題は訓練ループ注入でも同程度起きるのか、それとも訓練信号(reward/KL)の方が注入の効果が観測されやすいのか。訓練ダイナミクスへの注入の「障害化率」は未報告。([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]) - [[Cloud-OpsBench]] の MAS 閉ループ注入(Verifier が自動マスクを検出して注入強度を調整)は、Kubernetes のように自己修復機構が強い基盤を前提にした自己修正である。Pod 再スケジュール等の自動マスクが弱い・ない基盤(自己修復の薄い VM 群や物理層)でも、Verifier の「注入が効いたか」検証と強度調整の閉ループは有効に働くか。マスク検出の信号がない環境では閉ループの利点が薄れないか。([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - [[Cloud-OpsBench]] の State Snapshot(注入後状態を凍結した決定論的デジタルツイン)は、ある時点の状態をスナップショットする。時間発展する障害——カスケード故障や [[Metastable Failure]] のように注入後に伝播・遷移していく障害——を、凍結された snapshot はどこまで忠実に再現できるか。診断ツール T1〜T10 の平均 487 呼び出しを事前計算(Maximum Information Coverage)する設計は、伝播の途中経過まで保持できるのか、それとも単一時点の凍結に留まるのか。([[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) ## 関連 - ソース: [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] / [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] / [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] / [[@2024__IEEE Access__MetricSifter - Feature Reduction of Multivariate Time Series Data for Efficient Fault Localization in Cloud Applications]] / [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]] / [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] / [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]] - 概念: [[根本原因分析]] / [[Fault Localization]] / [[SRE Benchmark]] / [[異常検知]] / [[Metastable Failure]] / [[設定マイニング]] / [[Infrastructure as Code]] / [[強化ファインチューニング]] / [[集合通信]] / [[耐障害LLM訓練]] - エンティティ: [[ChaosMesh]] / [[Train-Ticket]] / [[AIOpsLab]] / [[SREGym]] / [[Meltria]] / [[Online-Boutique]] / [[Sock Shop]] / [[DeathStarBench]] / [[Zodiac]] / [[RFT-FaultBench]] / [[Cloud-OpsBench]] / [[ChaosBlade]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[SRE - MOC]] ## 出典 - [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]](§3 Type I/II/III 分類, §4.4 Fault Space, §4.7 Impact-Driven Selection, §6.1.1 84.4% No Anomaly, §7.2.1 oracle problem) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](ChaosMesh 統合と機能的障害ライブラリ) - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]](カオスツールを設計原則上避ける根拠) - [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]](§4 デプロイ時の negative test case 生成=構成への障害注入、SMT による単一違反保証、§5.6 注入が障害化しない偽陽性) - [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]](§III-B Anomaly Injection の online injection + Post Hoc Verifier、図2、表I/II 障害分類と統計) - [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]](§3.3.3 注入 MAS=Generator/Executor/Verifier の閉ループ・自動マスク検出と強度調整・⟨P,A,S⟩ 形式化、表2 40 種 7 カテゴリ、§3.2 State Snapshot Paradigm=決定論的デジタルツイン) - [[@2025__SOSP__Mycroft - Tracing Dependencies in Collective Communication Towards Reliable LLM Training]](7 種の集合通信障害注入=NIC/PCIe/GPU/トラフィック/NCCL 遅延、全種で根本原因を正確特定) - [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]（§4 表6 障害緩和技法の事後評価、オンライン障害注入・負荷テスト 6 件回避可能、オフライン vs. オンライン注入の効果差）