# 障害注入 ## 定義 障害注入(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]]) - **障害注入テストでは「注入した以外のノイズ障害」が共存し、障害特徴抽出の ground truth を汚染する**: Rao et al. SRDS 2011([[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]])は Alibaba Cloud 100 ノードクラスタの実証で、プロセスクラッシュを注入した際にランダムハードウェア障害・ソフトウェアバグ・設定誤り・ログ重大度誤設定という 4 種類のノイズ障害が同時に発生することを示した。これらのノイズ障害が生成するノイズログが Apriori/Decision Tree の障害特徴抽出を誤導し、time window 500 秒では再現率が 30% まで低下する。本 wiki の「症状を注入するか根本原因を注入するか」という議論([[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]])とは逆向きの問題——注入した根本原因以外の原因が混入する問題であり、「意図しない障害が注入プロセスを汚染する」という障害注入設計の別次元の課題を 2011 年に定量化した先駆け。(Source: [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **実本番ポストモーテム分析がカオスエンジニアリングの「注入できていないカテゴリ」を実証した**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](Li+ 2022)は 354 件の実障害から根本原因を分類し、Fig.9 でカオスエンジニアリングツールが現時点でカバーしていない 4 つの欠落カテゴリを特定した——①設定変更注入(最多根本原因である設定ミスを再現できない)、②コードスニペット注入(コードバグ・例外ハンドリングを合成できない)、③過剰リクエストのモック(リソース競合を制御できない)、④リクエストレベル障害注入(依存性障害の制御が弱い)。これは本 wiki の「症状を注入するか根本原因を注入するか」という議論([[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] の機能的障害ライブラリ、[[SREGym]] の設計方針)が問題視してきた「カオスツールは根本原因を注入できない」という批判を、実本番障害データから帰納的に補強したものと解釈できる。加えて同論文はテストデプロイメントフレームワーク・フェールオーバー/バックアップ検証・モニタリングツールの充実という 3 カテゴリの強化もガイドラインとして挙げており、障害注入は「注入ツールの拡充」だけでなくデプロイ検証と可観測性整備とセットで機能する実践として位置づけられている(Finding G1)。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **障害注入の有効性を「実障害データとの突き合わせ」で評価した最初の実証が 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]]) - **「コードレベル障害を RCA データセットで扱った最初の事例」は RCAEval 2025**: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]] は OpenStack 障害分析論文[5]を参照しつつ、リソース 4(stress-ng の CPU/MEM/DISK/SOCK)・ネットワーク 2(tc の DELAY/LOSS)・コードレベル 5(F1 Incorrect parameter values・F2 Missing parameters・F3 Missing Function Call・F4 Incorrect Return Values・F5 Missing Exception Handlers)の 11 種を組み合わせて 735 ケースの公開データセットを構築した。本論文は「RCA データセットでコードレベル障害を扱うのは我々が初」と明言する(§3.2)。これは AIOpsLab/SREGym/RFT-FaultBench が指摘した「症状でなく根本原因(コードバグ・設定ミス)を注入したい」という潮流に対し、ソースコードを直接書き換える形でコードレベル根本原因を 5 種の典型パターンに型抜きしてデータセット化した。診断側でスタックトレースからの fault line 特定が可能になるため、ベンチマークの fine-grained 評価軸を初めて担保した障害注入カタログでもある。(Source: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **stress-ng + tc + コード改変という「3 層注入の組み合わせ」が公開ベンチで横並びになった**: ChaosMesh 単一ツールでカオス注入を行う設計(FPA・AIOpsLab)に対し、RCAEval 2025 は stress-ng(コンテナ内リソース) + tc(ホスト ↔ コンテナ間のネットワーク) + ソースコード書き換え(アプリケーション層)の異なる注入レイヤを 1 データセットに混在させた。これは「症状を注入する」(stress-ng・tc)と「根本原因を注入する」(コード改変)の両方を網羅する明示的な多層注入の事例で、AIOpsLab の「機能的障害ライブラリで補完」という主張を独立ベンチ側で実装した形になる。(Source: [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - **TrainTicketTrace は「fault branch を git ブランチとして固定化」する別系統の障害注入方式を示した**: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]] は ChaosMesh・stress-ng・tc のようなランタイム注入ツールでなく、**Train-Ticket fork に 9 種の seeded fault を branch として固定**し、各 branch を EvoMaster でテスト生成しながら同一 workload で trace/metric/log を収集した。これは Zodiac の SMT による単一違反保証と同様、**注入の再現性を非決定性なツール挙動でなくバージョン管理されたソースコード差分** で担保する方向の解。同じ fault を別研究者が同条件で再現したい場合、git checkout だけで状態が確定する点が AIOpsLab/SREGym/Cloud-OpsBench とは異なる。fault 分類は Gregor+ ICST 2025 taxonomy(Exec F.→Service Faulty 7 件・Depl F.→Wrong Config 2 件・Conn F.→Timed out 1 件)で系統化、race condition・SQL error・thread-pool saturation・VIP user logic・third-party delay・config error 等を網羅。(Source: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]], [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **「テストが fault を検知できなくても trace/metric/log には残る」ことを TrainTicketTrace が実証**: 同論文の EvoMaster は seeded fault のいずれも **test assertion レベルでは検知できなかった**(つまり生成テストは fault を見落とした)が、trace の breadth/depth 分布や endpoint coverage 差として残った(F5 では `POST /ticketinfo/queryForTravel` が 173 traces で他 branch の 1,000-2,000 と顕著差)。これは AIOpsLab/SREGym/RCAEval が問題視した「カオスツールは症状しか注入できない」「84.4% silent fault」とは別軸の問題——**注入は障害化したが test 駆動の検証では捕まらない**——を示し、test layer ではなく observability layer での fault detection の必要性を実証する dataset として位置づけられる。(Source: [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **「注入した障害が本当に伝播したか」を事後の SLI 影響でなく段階的な因果経路として検証する新路線**: これまでの「注入 ≠ 障害」ギャップへの答えはいずれも二値判定(impact-driven validation の Has/No Anomaly、Zodiac のデプロイ成否、Cloud-OpsBench の自動マスク検出)だった。OpenRCA 2.0([[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]])の PAVE パイプラインはこれをさらに細分化し、注入した障害が「どの経路を辿って伝播したか」まで既知の介入 do(v_root) を使う 2 段階検証(構造的枝刈り+因果検証)で再構成する。500 インスタンスは 8,137 回の生プールから、silent injection の除外に加え(y)伝播経路が検証条件(構造適合・統計逸脱・時間整合)を満たす場合のみ残す層化選択で得られており、既存の「障害化したか否か」の二値フィルタを「どの経路で障害化したか」の段階的アノテーションへ一段深めた事例と言える。(Source: [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]] §2, §3.1) - **注入対象が「agent 生成マイクロサービス」へ拡張され、「注入 ≠ 障害」ギャップが「障害は生じたがログが意味論を捉えない」という新しい亜種で現れる**: これまでの障害注入研究は「注入したが症状が出ない」(84.4% No Anomaly、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])という silent fault 問題を扱ってきたが、[[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] は 200 個のコーディングエージェント生成マイクロサービス系に ChaosMesh で 13 種の障害(pod-kill・upstream-fail・db-down・cache-slow・time-skew 等、Table I)を注入し 1,615 件の障害インスタンスを得た評価で、**障害は確実に生じている(システムは影響を受けている)にもかかわらず、生成されたログがその障害を明示的に示す意味論を含まない**という異なる種類のギャップを定量化した(Fault Signals Rate 4.95〜13.99%)。「注入が障害化しない」問題と「障害化したがオブザーバビリティ層が捉えない」問題は独立した課題であり、後者は agent 生成システム特有の**計装能力の限界**に起因する。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **障害の「明示性」が観測可能性を左右する構図は、AIOpsLab/SREGym の「症状 vs 根本原因」注入論争と別軸で再確認された**: Table IV(per-fault FSR)によると、upstream-fail(27.45%)・pod-kill(20.33%)・cache-down(17.13%)のように明示的なエラー応答やサービス利用不能を伴う障害は "Easy" に分類され高い FSR を示す一方、time-skew(1.26%)・cpu-stress(1.44%)・net-corrupt(1.80%)のように暗黙的な影響しか生じない障害は "Hard" に分類されほぼ検出されない。これは [[障害注入]] の「症状を注入するか根本原因を注入するか」という議論とは異なる軸——**注入された障害そのものの意味論的明示性**——が観測可能性を左右することを示す。カオスツールが根本原因でなく症状しか注入できないという AIOpsLab/SREGym の批判とは独立に、症状自体が明示的か暗黙的かによって下流のオブザーバビリティ層の検出率が大きく変わる。(Source: [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) ## 未解決の問い - 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]]) - [[RCAEval]] のコードレベル障害 F1〜F5(Incorrect parameter values・Missing parameters・Missing Function Call・Incorrect Return Values・Missing Exception Handlers)は OpenStack 障害分析[5]の経験的パターンを 5 種に型抜きしたものだが、本番マイクロサービスのコードバグ分布をどこまで代表するか。F6 以降の典型バグ(off-by-one・型エラー・並行性バグ・メモリリーク等)を加えると、RCA 手法のスタックトレース推論能力に対する評価結果は変わるか。([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - 多層注入(stress-ng + tc + コード改変)の RCAEval 2025 で、レイヤ間で同時に発生する複合障害(ネットワーク劣化 + コードレベルエラー)を意図的に組み合わせた cascading injection の評価は未実施。各層単独の注入を組み合わせた合成複合障害は、依存伝播を含む現実の cascading failure([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] の Type III)を模倣できるか。([[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - TrainTicketTrace の git ブランチ固定型注入と、ChaosMesh のランタイム注入は同じ障害を同じ精度で再現できるか? 例えば `ts-error-F1` の race condition は ChaosMesh の `chaos-mesh/StressChaos` + 遅延注入で同等に再現可能か、それともコード差分でしか実現できない fault があるか([[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]]) - EvoMaster の生成 test が TrainTicketTrace の 9 fault を全件見落とした事実は、自動 test 生成がそもそも fault detection に向かないことを示すのか、それとも EvoMaster の white-box 探索が API レベルに留まり assertion を不充分に作るだけなのか? oracle 不在問題と組み合わせて、自動 test 生成 + LLM oracle の組合せで fault 検出は可能か([[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]]) - **AI システムの FI は6層それぞれで未対応の障害種別が残り、層間の「ギャップの非対称性」が浮き彫りになる**: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]]（Yu+ TOSEM 2025）は AI システムを Service / Model / Framework / Toolkit / Platform / Infrastructure の6層に分割し、142本の論文から各層の FA（障害分析）と FI（障害注入）を体系化した初の包括的サーベイである。各層のギャップテーブル（表4, 7, 10, 13, 16, 19）を見ると、AI Model 層ではミューテーションテストツール（DeepMutation / DeepCrime 等）が障害種別をほぼ網羅する一方、AI Framework 層では6種のうち4種（API 誤用・設定・性能・コード）が、AI Platform 層では11種のうち6種が FI 未対応である。これは本 wiki の既存知見——マイクロサービスランタイム注入の 84.4% silent fault 問題([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])や「症状を注入するか根本原因を注入するか」の議論——が AI システムの上位層（Service / Model）にとどまらず、Framework / Toolkit / Platform / Infrastructure のすべてで**異なる形で再現される**ことを示す。特に NCCL 障害・NVLink 障害・InfiniBand 障害といった分散 AI 訓練の基幹通信障害はどの既存 FI ツールもカバーしておらず、[[Mycroft]] が7種の集合通信障害を注入して検証したのは例外的な取り組みである。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]], [[@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]]) - **FI ツールのフレームワーク断片化は「注入の再現性」と「ツール保守コスト」の両面で障壁になっている**: 同サーベイは AI Framework 層だけで8つの FI ツール（TensorFI / InjectTF / TorchFI / PyTorchFI / TensorFI2 / SNIFF / enpheeph / MindFI）を列挙するが、それぞれが特定のフレームワーク・バージョンに縛られている（TensorFI は TensorFlow 1 のみ、TensorFI2 は TensorFlow 2、PyTorchFI は PyTorch）。唯一 enpheeph がフレームワーク非依存だが、障害種別はデータ障害とアルゴリズム障害に限定される。この断片化は TrainTicketTrace の「git ブランチ固定型注入による再現性確保」とは対照的に、注入コードの保守負荷を増大させている。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]], [[@2026__SANER-C__TrainTicketTrace - A Multi-Fault Distributed Dataset for Microservice Fault Detection and Localization]]) - **「84.4% が silent fault」問題への別解: 全数注入せず small scope hypothesis で組み合わせを枝刈りし、注入対象の絞り込みそのものを効率化する**: これまでの障害注入研究は「注入したが症状が出ない」問題を**事後検証**(impact-driven validation・Zodiac のデプロイ成否・Post Hoc Verifier)で篩ってきたが、[[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]] は逆方向から接近する——「単純な障害組み合わせが失敗するなら、それを含む複雑な組み合わせも必ず失敗する」という単調性の仮定でヒューリスティック枝刈りを行い、31 サービス・4 障害タイプで理論上 295,244 通りある組み合わせのうち 2,847 通り(枝刈り率 99.0%)だけを実行する。これは「注入 ≠ 障害」ギャップの事後検証とは異なる軸の効率化——**そもそも冗長な注入を行わない**——であり、small scope hypothesis(実運用障害の大半は 2〜3 の同時障害で説明できる)を根拠に K=3 で探索を打ち切る設計は、$K=4$ に達すると全候補が枝刈りされる自然収束として実証された。(Source: [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **ステートレスサービスの応答決定性を利用した「記録・再生」により、障害注入そのものの実行コストを削減する新路線**: 既存の障害注入研究(ChaosMesh・RCAEval の stress-ng/tc・TrainTicketTrace の git ブランチ固定)はいずれも「注入をどう構成するか」を扱うが、FaultWeave は「同じ障害を毎回実注入せず、一度記録した応答を再生する」ことで注入回数自体を減らす。W3C Baggage で障害コンテキストをリクエストヘッダーに伝播し、サイドカープロキシがキャッシュヒット時に下流サービスを完全にバイパスして応答を合成する。31 サービスのパイロットでキャッシュヒット率 89.3%・再生による高速化率 17.6× を達成し、実行結果(成功/失敗)は決定論的に記録・再生する一方、応答時間は対数正規分布としてモデル化してサンプリングする「決定論的部分と確率的部分の分離」を採用する。ただしこの record/replay の妥当性はステートレス性に依存し、50 件のサンプリング検証で不一致となった 4 件は全てステートフルコンポーネントに関わった——[[Zodiac]] の SMT による単一違反保証・Cloud-OpsBench の State Snapshot Paradigm と並ぶ「非決定的なライブ注入を決定論的な構成へ落とす」試みの一つだが、対象がランタイムの実行結果である点で異なる。(Source: [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - **枝刈りが自然に導出する Minimal Failure Set(MFS)を、診断のための差分プロファイルとして再利用する構成**: FaultWeave のヒューリスティック枝刈りの副産物として、発見される失敗シナリオは設計上すべて「最小の失敗する障害組み合わせ」(MFS)になる。これを親シナリオ(1つ少ない障害の集合、必ず合格する)との差分(構造変化・RED メトリクス・例外)として構造化し LLM 診断の入力にする発想は、[[障害注入]]の議論をベンチマーク構築(何を注入するか)から診断支援(注入結果をどう使って原因を特定するか)へ接続する数少ない事例であり、詳細は [[LLMによる根本原因分析]] を参照。(Source: [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - **実運用 512 マイクロサービス・3か月展開が「単一障害テストの盲点」を定量化した稀有な産業事例**: これまでの障害注入研究の多くはベンチマークシステム(Train-Ticket・DeathStarBench 等)上での評価だったが、FaultWeave は電力会社の実本番システム(512 マイクロサービス・156 ノード Kubernetes・99.99% SLO)へ3か月間展開し、確認された 237 件の脆弱性のうち 89%(211 件)が複数障害シナリオでのみ発現することを実証した。単一障害(k=1)は 11%、二重障害(k=2)は 40%、三重障害(k=3)は 49% を発見しており、深さが増すごとに異なる種類の弱点(基本的フォールトトレランス欠如→戦略競合→複雑なカスケード)を捉える。これは [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] が示した「オンライン障害注入が実障害の一部を回避しえた」という**事後的な効果測定**とは対照的に、**単一障害テストがどれだけの脆弱性を見落とすか**を産業規模で定量化した点で新しい。(Source: [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) ## 未解決の問い（追記） - Yu+ TOSEM 2025 が提唱するクロスレイヤ障害注入——例えば AI Framework 層の設定障害が Model 層の訓練失敗を引き起こすカスケード——を、既存のカオスエンジニアリングツール（ChaosMesh / ChaosBlade）のインフラ層注入と組み合わせて実現できるか。層をまたぐ依存関係のモデル化は Zodiac の SMT 型と Mycroft の依存駆動 RCA 型のどちらに近いか。([[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]]) - 同サーベイが「将来方向」として挙げた「LLM + 人間フィードバック強化学習による FI 方針自動生成」は、Cloud-OpsBench の MAS 閉ループ注入（Generator/Executor/Verifier）のアーキテクチャとどう統合されるか。自然言語の障害シナリオ記述から注入パラメータへの変換は、AIOpsLab の機能的障害ライブラリの「人手設計」を置き換えうるか。([[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]], [[@2026__arXiv__Cloud-OpsBench - A Reproducible Benchmark for Agentic Root Cause Analysis in Cloud Systems]]) - FaultWeave の単調性(ヒューリスティック枝刈り)仮定が破れるケース——追加障害がバックアップパス活性化のような補償機構を誘発し複雑シナリオが合格に転じる——は、本論文の3か月展開では観測されなかったが理論上ありうるとされる。他の産業システムで実際にどの程度の頻度で起きるか、単調性が成り立たない障害の型(例: フォールバック機構を持つコンポーネント)を事前に識別してヒューリスティックの適用範囲を絞り込む方法はあるか。([[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - FaultWeave は並行障害組み合わせのみを対象とし、Saga トランザクションのロールバック中の特定障害のような**逐次・時間的障害**(障害の順序・タイミングが結果を左右するケース)を扱えない。TrainTicketTrace の git ブランチ固定型注入や ChaosMesh のランタイム注入は、障害の発生順序・タイミングを制御可能な形で拡張できるか。時間的次元を加えた障害空間探索は、K=3 の有界探索と同様の枝刈り原理(small scope hypothesis)が適用できるか、それとも状態遷移ごとに全く異なる探索戦略が必要か。([[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - ステートレスサービスの record/replay がステートフルコンポーネントで 8%(50 件中 4 件)の不一致を生んだことは、[[障害注入]] の既存議論(84.4% silent fault・impact-driven validation の oracle problem)とは独立の「キャッシュ再生の精度」問題を提起する。ステートフルサービスに対して record/replay と実注入を自動的に切り替える閾値・判定基準はどう設計すべきか。分散トランザクション・分散ロックを持つサービスの状態を追跡し、キャッシュ利用可否を動的に判定する仕組みは可能か。([[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) ## 関連 - ソース: [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]] / [[@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]] / [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]] / [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]] / [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]] - 概念: [[根本原因分析]] / [[Fault Localization]] / [[SRE Benchmark]] / [[異常検知]] / [[Metastable Failure]] / [[設定マイニング]] / [[Infrastructure as Code]] / [[強化ファインチューニング]] / [[集合通信]] / [[耐障害LLM訓練]] / [[オブザーバビリティ]] / [[コーディングエージェント評価]] / [[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]] ## 出典 - [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]](Algorithm 1 有界障害空間探索, Algorithm 2 MFS Contextualization, §5.3 RQ1-RQ3 実験結果, §6 単調性仮定の限界) - [[@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. オンライン注入の効果差) - [[@2011__SRDS__Identifying Faults in Large-Scale Distributed Systems by Filtering Noisy Error Logs]](§I ノイズ障害 4 種類の共存・障害特徴抽出への影響の定量化, §IV 図 3 再現率 30% 低下の実証) - [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]](§3.2 11 種障害=リソース 4 / ネットワーク 2 / コードレベル 5、§3.3 stress-ng + tc + コード改変の 3 層注入パイプライン、Table 2 RE1/RE2/RE3 の 735 ケース統計) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]](6層 AI システムの FA/FI ギャップテーブル=表4/7/10/13/16/19、142本の体系的分析、Framework 層8ツールの断片化、NCCL/NVLink/InfiniBand FI 不在の指摘、§11 クロスレイヤ FI と LLM ベース FI 方針生成の将来方向) - [[@2026__arXiv__OpenRCA 2.0 - From Outcome Labels to Causal Process Supervision]](§2 PAVE の 2 段階検証=構造的枝刈り+因果検証、§3.1 8,137 回の生プールから 500 インスタンスへの層化選択、§D.5-D.8 検出閾値とハイパーパラメタ) - [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]](Table I 13 種の障害プリミティブ=ChaosMesh の PodChaos/NetworkChaos/HTTPChaos/StressChaos/TimeChaos、Table III/IV FSR 4.95〜13.99%・per-fault 難度分類、200 系×13 障害で 1,615 件の障害インスタンス)