# 障害注入 ## 定義 障害注入(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]]) ## 子概念 - [[GameDay]] - [[SRE Benchmark]] - [[クラウド障害ライフサイクル]] - [[ネットワークトラブルシューティングエージェントベンチマーク]] - [[フェイルスローハードウェア]] - [[運用障害分析]] ## 横断的知見 - **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 等)を「無効」と誤ラベルし、高度なモデルを不当に不利にする。[[メタ安定障害]] のようにユーザー影響が出る前/出ない形で進む障害は、ユーザー向け 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?]]) - **注入の「何を・どこに」に続き「いつ」を制御する第三軸が独立して定式化された**: これまでの障害注入研究は「何を注入するか」(fault type)と「どこに注入するか」(target component/API)を主軸とし、時間・タイミングの扱いは強度校正窓(resource FI の narrow calibration window)や record/replay の応答時間分布のような**副次的な確率パラメタ**として現れるにとどまっていた。[[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]] はこれを「いつ注入するか」(temporal guard)という明示的な第三の設計軸として定式化し、post-effect(状態変化後)・order-sensitive(応答順序)・k-of-n(出現回数)という 3 つの原始的な時間的制約に分解する。既存の「症状を注入するか根本原因を注入するか」(AIOpsLab/SREGym)、「単一障害か複数同時障害か」(FaultWeave の K=3 有界探索)という既存の 2 軸とは直交する新しい軸であり、同じ静的ターゲット(例: Payment API)に対しても「いつ」が異なれば全く異なる復旧義務を持つ障害を作り分けられることを示す。(Source: [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]], [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - **「注入 ≠ 障害」ギャップとは異なる新しい失敗モード:「早すぎる注入」「意図した occurrence を外す注入」**: 既存の「注入 ≠ 障害」ギャップ(84.4% silent fault、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])は「注入したが症状が出ない」問題だったが、SequenceFI が明らかにしたのは**静的な request-level/phase-level FI が、症状は出るが意図した時間窓と異なる位置で発火してしまう**という別種のギャップである。Static-Req は温存された時間的証拠を持たず全パターンで TS=0%(premature 100%)、Static-Phase は phase 一致が偶然ガード条件と重なる post-effect でのみ成功し(100%)、順序依存(66.7%)・出現回数依存(0%)では premature/miss/multiple のいずれかに転ぶ。「症状が出るか出ないか」の二値でなく「意図した時間窓で厳密に一度だけ発火したか」という時間的精度の欠如が、静的 FI の隠れた限界として定量化された。(Source: [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **TFIC 探索空間の組合せ爆発を、FaultWeave の枝刈りとは異なる「静的/時間的の分離 + hitting set 最小化」で解く**: FaultWeave は障害**組み合わせ**の探索空間(31 サービス×4 障害タイプ=295,244通り)を単調性仮定によるヒューリスティック枝刈りで 99.0% 削減する。SequenceFI が扱う TFIC 探索空間は同種の組合せ爆発(3 イベントガードで最大 404 万通り、Table III)だが、性質が異なる——障害の**組み合わせ**でなく単一障害の**時間的トリガ条件**の空間である。SequenceFI は静的ターゲット選択(LDFI/FastFI 由来)と時間的ガード合成(distinguishing set の minimum hitting set 問題)を分離することで、H-Random(ヒューリスティックサンプリング)比 95.91%、3MileBeach-Random(無誘導列挙)比 99.86% の探索時間削減を実現し、全ベンチマークで平均試行回数を 1 に圧縮する。「枝刈りで空間を削る」(FaultWeave)と「問題を最小被覆問題に厳密還元する」(SequenceFI)という、探索空間爆発への異なる解法が同じマイクロサービス障害注入領域で並立する。(Source: [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]], [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - **サイドカーの非侵入性を「サービスメッシュのフルデータプレーン」でなく「FIC 関連イベントのみの狭いスコープ」で達成し、Istio 比で軽量化する**: FaultWeave は record/replay でサイドカープロキシが下流呼び出し自体をバイパスすることでコストを削減したが、SequenceFI のサイドカー TFIProxy は実運用の全リクエストを毎回通過させつつ、伝播するのは「FIC に関連するイベントのみ」を符号化したコンパクトなバイナリベクトルに限定する設計でオーバーヘッドを抑える。汎用サービスメッシュ(Istio/Envoy)と比較して CPU 41.5%・メモリ 2.3% という結果は、時間的障害注入という**限定目的**のサイドカーが、汎用データプレーンの持つ機能(ルーティング・認可・可観測性全般)を持たないことの代償として軽量性を得ている構図を示す。(Source: [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]]) - **障害注入の用途が「評価ベンチマークの ground truth 生成」から「強化学習の訓練データ生成」へ拡張された**: 本 concept が蓄積してきた注入研究(AIOpsLab・SREGym・RCAEval・Cloud-OpsBench 等)はいずれも RCA モデルを**評価**するためのベンチマーク構築を目的とするが、[[OpsLLM]]([[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]])は Chaos Mesh の StressChaos・NetworkChaos で Online Boutique に注入した障害(CPU hog・メモリ枯渇・ネットワーク遅延・パケットロス)を、RCA ポリシーの **SFT・RL 訓練データ**として使う。RCA Generator(LLM)が推論トレースを生成し正解と食い違えば reflection で再生成、RCA Evaluator が論理的整合性を検証したトレースのみを採択する reflection-and-verification 機構で、注入から得た生テレメトリ(約60MB)を圧縮率99%超で20KBの構造化プロンプトへ凝縮する。「注入 ≠ 障害」ギャップ(silent fault)への対処は本 concept の主要な関心事だったが、OpsLLM は評価オラクルとしてでなく学習信号としての注入データの質(推論トレースの論理的整合性)を問題にする点で、既存の注入ベンチマーク研究とは異なる利用文脈を提示する。(Source: [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]]) - **LDFI の一次資料(著者本人による『カオスエンジニアリング』12章)は、本 concept が SequenceFI 経由で「静的ターゲット選択の由来」としてのみ参照してきた LDFI の内部機構を明らかにする**: 本 concept は既に SequenceFI の記述を通じて「静的ターゲット選択(LDFI/FastFI 由来)」という一行の由来注記を記録してきたが(既出「TFIC 探索空間の組合せ爆発」)、その中身は未詳のままだった。12章([[Peter Alvaro]] 著、[[Disorderly Labs]] の LDFI 研究)は、成功した実行のコールグラフトレースが示す冗長性の構造(レプリケーション・フェイルオーバー・ソフト依存関係の枝分かれ)をブール式としてモデル化し、「バグやまだモデル化されていない冗長性を見つけられる可能性の高い実験」の選択を充足可能性(SAT)問題へ、グラフのトポロジーと故障の発生しやすさに基づくランキングを用いた優先順位づけを整数線形計画法(ILP)問題へ、それぞれ還元すると説明する。後継の FaultWeave・SequenceFI が探索空間爆発を単調性仮定によるヒューリスティック枝刈りや hitting set 最小化で解くのに対し、LDFI は充足可能性問題への還元というより形式的な解法を採っていたことが一次資料から判明する。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] §12.2.1.1, [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]]) - **障害注入の対象レイヤーがマイクロサービス/クラウドから物理ネットワークへ広がり、注入手段がドメイン固有の技術スタックへ分岐する**: 本 concept が蓄積してきた注入研究(ChaosMesh・stress-ng ベースの RCAEval・SequenceFI 等)はいずれもコンテナ/アプリケーション層を対象とするが、[[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]](NIKA)はネットワークインフラそのものを対象に、リンクレベルの障害を Linux Traffic Control (TC)、ソフトウェア資源競合を stress-ng(本 concept で既出のツールと同一)、デバイスレベルの障害(プロセスクラッシュ・誤設定)をカスタムスクリプトで注入する三層構成を採る。「症状注入 vs 根本原因注入」の既存の論争軸に対し、NIKA は I = (Dev, Comp, RC) という 3 つ組でネットワーク問題を形式化し、根本原因(RC)を明示的にターゲットとする点でクラウド SRE ベンチマーク([[AIOpsLab]]・[[SREGym]])の設計思想を踏襲しつつ、対象レイヤー(ネットワークデバイス・リンク)に応じて注入ツールを使い分ける。640 通りのインシデント(54 種の根本原因 × 5 シナリオ)をパラメトリックテンプレートで生成する設計は、[[SREGym]] の「50 の障害プリミティブ × 139 サービス」の組み合わせ的量産と同じ発想をネットワークドメインに適用したものと言える。(Source: [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]]) - **障害注入は自動テストツールに限らず、人的プロセスを対象とする「災害ロールプレイング」という形式でも実践されており、両者は同じ「リスクの高い領域への継続的注力が自動化・定型化を生む」という成熟パスを共有する**: 本 concept が蓄積してきた注入研究はいずれも ChaosMesh・stress-ng・tc・コード改変などツールによる**システム**への注入を扱うが、Google 自身が著した Anatomy of an Incident 2章は、DiRT(Disaster Resilience Testing)プログラムと Wheel of Misfortune(週次の災害ロールプレイング)という**人**への障害注入(実際には起きていない障害シナリオを人間の対応プロセスに注入し弱点を発見する)を一次情報として記述する。同章は、当初リスクが高すぎて実行できなかったテスト領域が長年の注力によって自動化・定型化された定期テストへ変わったと述べており、これは本 concept の「単一の根本原因だけを違反させる」注入の精密化や snapshot による決定論的再現の議論とは異なる粒度だが、「実行が難しい/リスクが高いケースほど継続的な投資で解決可能である」という成熟モデルの適用範囲がシステムへの技術的注入を超えて人的プロセスへも及ぶことを示す。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) - **注入対象が「マイクロサービス/クラウドインフラ」から「LLM API という新しい共有トランスポート層」へ拡張され、演繹的タクソノミー構築という手法が独立に再発見された**: 本 concept が蓄積してきた注入研究(ChaosMesh・stress-ng・tc・SequenceFI 等)はいずれもマイクロサービスのネットワーク層・OS層・コード層を対象とするが、[[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection|AgentChaos]] はエージェントシステムが共通して依存する **LLM API の HTTP request-response 層**を新たな注入対象に据える。全エージェントシステムが同一のHTTPインターフェースでLLMにアクセスするという観察は、本 concept で繰り返し現れる「共有層を突けば個別実装に手を入れずに済む」という設計原理(ChaosBlade の OS/コンテナ/ネットワーク層、SequenceFI のサイドカー)の、LLM エージェント領域における対応物である。タクソノミー構築の方法論も特徴的で、AgentChaos は[[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]]の crash/omission/valueという古典的ディペンダビリティ分類をLLM APIレスポンスの固定フィールド構造(content/tool_calls)へ演繹的に適用し、6種の障害タイプを**網羅的に**導出する。これは既存の障害注入研究の多くが開発者調査やインシデント分析から**帰納的**にタクソノミーを構築する(本 concept の[[A Survey on Failure Analysis and Fault Injection in AI Systems]]や[[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]等)のと対照的な方法論であり、対象システムの構造が既知で固定的な場合に演繹的アプローチが成立しうることを示す一事例といえる。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]], [[@2004__TDSC__Basic Concepts and Taxonomy of Dependable and Secure Computing]]) - **「最も深刻(severe)な障害が最も有害(harmful)とは限らない」という知見が、症状明示性の議論([[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]])と異なる角度から独立に確認された**: 本 concept は既に「障害の明示性が観測可能性を左右する」(upstream-failのような明示的障害はFault Signals Rateが高くtime-skewのような暗黙的障害は低い)という知見を持つが、AgentChaosはこれと直交する軸で類似の非対称性を示す——crash障害(error・timeout、HTTPエラーコードのように「深刻に見える」)よりomission障害(empty・truncate、有効なHTTP 200を返すため「深刻に見えない」)の方が、MADでのempty content(38.46%低下)とtimeout content(22.33%低下)の比較が示すように**同等以上にタスク成功率を低下させる**場合がある。さらにAgentChaosはomission障害が最も診断しづらい(truncateのタイプ精度はルールベース4.3%)ことも定量化し、「深刻に見えない障害ほど有害かつ診断困難」という二重の逆説を提示する。これは silent fault 問題(注入したが症状が出ない、84.4% No Anomaly)や意味論的明示性の議論(Fault Signals Rate)とは異なる軸——**障害の見た目の深刻さと実際の有害性・診断可能性の乖離**——を、マイクロサービス領域の外(LLMエージェント領域)で独立に発見した事例である。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]], [[@2026__arXiv__Can Large Language Models Generate Observability-Aware Code?]]) - **トリガー検証(trigger verification)は「注入 ≠ 障害」ギャップへの新しい対処パターンで、事前の強度校正でなく事後のフィルタリングによって未発火タスクを除外する**: 本 concept が蓄積してきた「注入 ≠ 障害」ギャップへの対処は、impact-driven validation(SLI影響で篩う)・Zodiacのデプロイ成否・Cloud-OpsBenchの自動マスク検出・RFT-FaultBenchのPost Hoc Verifierといった、いずれも**注入後に生じた結果**を検証するものだった。AgentChaosのトリガー検証はこれらと同じ「事後フィルタ」パターンに属するが、対象とするギャップの性質が異なる——マイクロサービス注入の84.4% silentは「注入は発火したが症状が観測されない」ケースであるのに対し、AgentChaosが扱うのは「注入がそもそも発火しない」ケース(タスクが短く終わり障害設定位置に到達しない、intermittent戦略が確率的に選ばれない、target field guardがフィールド不一致でスキップする)である。AutoGenのトリガー率が48.30%(平均呼び出し回数1.72)と他システム(86〜99%)より顕著に低いことは、この種のギャップが**システムの呼び出しパターンの長さ**に強く依存することを示す——短い呼び出し連鎖を持つシステムほど、狙った位置に障害を注入しにくい。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]]) - **「変数選択が容易さに流されやすい」という2008年代の実務的警告(3章)が、2026年のAgentChaosによる「深刻に見える障害ほど有害とは限らない」という定量的発見と同型である**: 『カオスエンジニアリング ― 回復力のあるシステムの実践』3章のコラム「ラクな道を選ばないようにしよう」は、インスタンス停止・CPU張り付き・メモリ枯渇のような「結果が予期できる」変数が、レイテンシ変動やレスポンスタイプ変更のような実装コストの高い(だがより有意義な)変数より安易に選ばれがちだと警告する——変数の選びやすさと学習上の価値は一致しないという経験則である。AgentChaosが独立に定量化した「crash障害(HTTPエラーコードのように深刻に見える)よりomission障害(HTTP 200を返すため深刻に見えない)の方が同等以上にタスク成功率を下げ、かつ診断もしづらい」という知見(既出)は、この経験則を別ドメイン(LLMエージェント)・別時代(2026年)・定量データで裏付ける——「注入の見た目の分かりやすさ」と「注入の実際の学習価値・有害性」が乖離するという同じ構造が、Netflixの実務知(2020年出版当時)からLLMエージェントのベンチマーク研究(2026年)まで、20年近い時間差と全く異なる対象システムを越えて再確認されたことになる。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] §3.3.2, [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]]) - **「なぜ本番で注入するのか」という問いに対する2012年の実務的一次回答が、DDIA 2E の理論的位置づけと同じ結論に達している**: 本 concept の DDIA 2E に関する既存知見は、障害注入(Chaos Monkey・Jepsen・DST)を「アルゴリズムが実装でも性質を満たすかを経験的に検証する」手法として形式手法(モデル検査)と対比する。[[@2012__CACM__Fault Injection in Production]] はこれより早く、実務者の視点から同じ問いに答えている——本番とステージング環境の間には常に何らかの差異があり、その差異自体が不確実性を持ち込む上、ステージングでは「復旧できなかった場合の結果が実質的に存在しない」ため、フォールトトレランス設計に無意識の甘い前提が入り込みやすい。DDIA が「モデル検査は簡略化モデルしか検証しない」と述べる限界を、Allspaw は「ステージング環境は本番と本質的に異なる」という運用上の言葉で先取りしていた。(Source: [[@2012__CACM__Fault Injection in Production]], [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]) - **博士論文の再録章と一次論文を数値レベルで突き合わせても矛盾は生じない——「再録」であることが検証可能な形で確認できた事例**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]](Chen 2026博士論文第2章)は [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]](NSDI'23)の再録章であり、4パターンのバグ taxonomy(no error handling 29件・throwing unrelated exceptions 23件・silent semantic violations 4件・state divergence 17件、計73件)、報告66件・確認55件・修正51件、誤検知52/2,654件(1.96%)、C4のexhaustive baseline比64.47%削減、Orleansの394,172件(99.04%)削減といった主要数値を1件ずつ照合した結果、食い違いは一件も見つからなかった。むしろ博士論文側は、ポリシー×オラクル別のバグ内訳(Table 6)やDistributedLock-132(900件超のリクエストのうちわずか4件が発生源のcall siteでのみ露見)のような一次論文の要約からは読み取れない補足事例を追加している。「拡張版だから数値が変わっている」という予断を、少なくともRainmaker章については明確に否定できる観測事実である。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]] §2.7, [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]] §5.1–5.3) - **注入が「気づかれなくなる」ことの評価は、silent fault問題と正反対の方向で語られてきた**: 本concept の中心的な横断的知見は、注入した障害が症状として現れない(84.4% No Anomaly、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])ことをベンチマークの欠陥として問題視してきた。[[@2012__CACM__Fault Injection in Production]] は同じ「注入したのに目立たない」という現象を、ベンチマークの妥当性でなく**組織文化における慢心(complacency)の温床**として問題視する——障害が透過的かつ優雅に処理され続けると、それが気づかれなくなり、本来維持すべき「失敗への健全な緊張感」自体が失われる。同じ表面的現象(注入の効果が観測されない)が、技術的評価の文脈では「ベンチマークが無効になる」問題として、組織論の文脈では「慢心が忍び寄る」問題として、独立に指摘されている点は、障害注入研究がカバーすべき評価軸が技術的観測可能性だけでないことを示唆する。(Source: [[@2012__CACM__Fault Injection in Production]], [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **「注入対象の削減」という課題は、2011〜2013 年の学術的 AI-for-fault-injection 研究で既に定量化されていた——本 concept が蓄積してきた探索空間削減(FaultWeave の単調性枝刈り・SequenceFI の hitting set 最小化)は、10 年以上前のクラスタリング・決定木ベースの手法と同じ目標を異なる技術で追う後継である**: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] §4.1.2 が扱う fault injection サブカテゴリは、本 concept が主に扱ってきたマイクロサービス/クラウドのカオスエンジニアリングベンチマーク(ChaosMesh・RCAEval 等、2020年代)より一世代前の学術文献を対象とする。Siami Namin et al. は mutation testing の mutator 選択に回帰モデル+クラスタリングを適用し、mutant 集合を初期サイズの 8% まで削減した。Natella et al. は決定木(MR/LR 分類)+ k-means クラスタリング(低 fan-in/fan-out コンポーネントへの障害集中)で MySQL・RTEMS・PostgreSQL の faultload サイズを -22%〜-69% 削減しつつ fault representativeness を +4%〜+26% 改善した。これは本 concept の FaultWeave(単調性仮定によるヒューリスティック枝刈りで 295,244 通りを 99.0% 削減)・SequenceFI(hitting set 最小化)と同じ「網羅的な注入は計算コストが高すぎるため、代表性を保ったまま探索空間を削減する」という目標を、2010年代前半の段階でクラスタリング・決定木という単純な教師なし/教師あり学習で達成していたことを示す。ただし Notaro et al. のサーベイ自身が明言するとおり、fault injection への AI 適用は「switching mechanism というアルゴリズム的な行為そのもの」ではなく「選択ポリシーの最適化」に限定されており、これは本 concept が記録してきた AgentChaos の演繹的タクソノミー構築や Cloud-OpsBench の MAS 閉ループ注入のように、注入プロセス自体を AI(LLM エージェント)が担う近年の潮流とは対照的な、より限定的な AI の関与のあり方である。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] §4.1.2, [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]]) - **6 層構造の定義そのもの(表1)は、本 concept が既に蓄積してきた層別ギャップの議論の「なぜ層で切るのか」に答える出発点であり、FA→FI のライフサイクルモデル(図3)は層をまたいだギャップが構造的に生じる理由を説明する**: 本 concept は既に AI Framework 層の FI ツール断片化(8 ツールが互いに非互換)や NCCL/NVLink/InfiniBand の FI 不在([[A Survey on Failure Analysis and Fault Injection in AI Systems]] の既出知見)を記録してきたが、これらはいずれも第4〜9章の層別ギャップテーブル(表4/7/10/13/16/19)由来である。[[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 1 Introduction]] の表1は、AI Service(API 呼び出しで完結するサービス、代表 ChatGPT)・AI Model(GPT-4)・AI Framework(PyTorch)・AI Toolkit(CUDA)・AI Platform(Ray)・AI Infrastructure(GPU/TPU)という 6 層を、下位ほどハードウェアに近く上位ほどユーザー向けサービスに近いスタックとして定義し、この層構造そのものが第4〜9章の章立て(§4〜§9)と一対一対応する分類軸になっている。一方 [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 2 Background and Definitions]] の図3(Fault→Failure Mitigation→Failure Analysis→Fault Injection の4段階ループ)は、FA の知見が FI シナリオ設計へフィードバックされるべきだと規範的に述べる一方、本 concept が既に定量化した「Framework 層で6種のうち4種が FI 未対応、Platform 層で11種のうち6種が FI 未対応」というギャップは、この図3のループが層ごとに程度の異なる断絶を抱えていることの実証データにあたる——層構造(表1)は「どこで切るか」を、ライフサイクル(図3)は「なぜ切れ目でギャップが生じるか」を、それぞれ補完的に説明する。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 1 Introduction]], [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 2 Background and Definitions]], [[A Survey on Failure Analysis and Fault Injection in AI Systems]]) - **AI システムとクラウドシステムの障害比較(図2)は、本 concept のマイクロサービス/クラウド中心の議論が AI システムへそのまま持ち込めない理由を明示する**: 本 concept が蓄積してきた注入研究(ChaosMesh・stress-ng・tc 等)はいずれもクラウドネイティブなマイクロサービスを対象とするが、[[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 2 Background and Definitions]] はクラウドシステムがロジックベースのプログラミングパラダイム、AI システムがデータ駆動型プログラミングパラダイムに立脚するという構造的違いを指摘し、GPU 障害のようにクラウドでは軽微だが AI システムでは深刻な障害が存在するとする。本 concept の「症状を注入するか根本原因を注入するか」という論争軸(AIOpsLab/SREGym)は暗黙にロジックベースのシステム(設定ミス・コードバグが根本原因になりうる)を前提としており、データ駆動型の AI モデルでは「根本原因」の概念自体(データ品質・概念ドリフトのような統計的性質)が異なりうることを示唆する。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 2 Background and Definitions]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **AI Service層とAI Model層のFIは、対象への介入点が根本的に異なる——前者は外部からのブラックボックス的な入力・トラフィック操作、後者は白箱的な訓練プロセスへの直接改変である**: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 4 FA and FI in AI Service]] のFIはデータ摂動(JENGA)・サービスAPI障害(Istio)・低品質ネットワーク(Toxiproxy・ChaosBlade)・敵対的/プロンプト攻撃(FGSM・IPI等)という、いずれもデプロイ済みシステムの境界(API・ネットワーク・入力)を外側から操作する手法である。対して [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 5 FA and FI in AI Model]] のFIは「ミューテーションテスト」と呼ばれ、DeepMutation・DeepMutation++・MuNN・DeepCrimeがいずれも訓練データ・ハイパーパラメータ・重み・層構造そのものを直接改変する。本conceptが蓄積してきたChaosMesh系の外部注入(Pod kill・ネットワーク欠落等)は前者と同じ「境界操作」型であり、AI Model層のミューテーションテストは本conceptに新しく現れた「内部構造への直接介入」型のFIである。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 4 FA and FI in AI Service]] §4.2, [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 5 FA and FI in AI Model]] §5.2) - **AI Service層のギャップ(表4)はDefective Code・Configuration Faultの2種が完全に未対応(Covered=False)なのに対し、AI Model層のギャップ(表7)は10種すべてがCovered=Trueだが被覆ツール数に偏りがある——「未対応」と「単一ツールのみ対応」という異なる水準のギャップが層ごとに現れる**: AI Service層で唯一Covered=Falseとなる「Defective Code」は、本conceptが既に記録してきた[[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]のコードレベル障害F1〜F5(Incorrect parameter values等)と同種の「コード欠陥そのもの」であり、マイクロサービス側でもRCAEval以前は同様に扱われていなかった障害型である。AI Model層で「Inappropriate LR, Epochs, and BS」がDeepCrime単独でしか対応されない状況は、複数ツールを組み合わせても被覆されない領域が残るAI Service層の問題とは異なる、単一ツールへの依存という別種の脆弱性を示す。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 4 FA and FI in AI Service]] §4.3, [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 5 FA and FI in AI Model]] §5.3, [[@2025__WWW Companion__RCAEval - A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data]]) - **AIプラットフォーム層とAIインフラ層のFIギャップは、上位層(Service/Model)とは異なる2つの新しい軸を示す——「AI特化設計の欠如」と「模擬障害の物理的リアリズム欠如」**: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 8 FA and FI for AI Platform]](表16)は、既存FIツール(ChaosBlade・CoFI・CrashFuzz等)がKubernetesのような従来型クラウド基盤向けに設計されており、AIプラットフォームが強く依存するGPU資源競合を模擬できるツールが皆無であると指摘する——これは「症状注入か根本原因注入か」という本conceptの既存論争軸(AIOpsLab/SREGym)とは別の、**対象システムの想定自体がAI以前のクラウド設計に固定されている**という軸である。さらに [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 9 FA and FI for AI Infrastructure]](表19・§9.3)は、GPU/FPGA向けFIツール(SASSIFI・LLFI-GPU・NVBitFI等)の大半がSASS/PTX/LLVM IRレベルの計装かRTL/ゲートレベルのシミュレーションで動作するため生成される障害を「模擬された障害(emulated faults)」として明示的に区別し、実ハードウェア故障を引き起こす物理プロセス(放射線・温度変化等)を正確に表現できない可能性があると認める。本conceptが蓄積してきた「注入 ≠ 障害」ギャップ(84.4% silent fault等)はソフトウェア層でのシグナル欠落を扱うが、ハードウェアアクセラレータのFIでは**シグナルは確実に生じるがその物理的忠実性自体が疑わしい**という第三の失敗モードが現れる。[[GPUレジリエンス]] が特徴づける本番LLM訓練クラスタ(Delta A100/H100等)のMTBE・コンポーネント別故障率という実測統計は、この「模擬障害のリアリズム」を検証しうる独立した参照点になりうるが、両者を定量的に突き合わせた研究はまだ存在しない。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 8 FA and FI for AI Platform]] §8.3, [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 9 FA and FI for AI Infrastructure]] §9.3, [[GPUレジリエンス]]) - **AI Framework 層の FI が「計装」中心なのに対し、その1段下の AI Toolkit 層の FI は「ファジング」中心へと手法の性質が転換する**: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 6 FA and FI for AI Framework]] が挙げる TensorFI・TorchFI・PyTorchFI 等はいずれもテンソル・重み・レイヤー出力を直接改変する計装型で表9の`Instrumented`列がほぼ全て True であるのに対し、[[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] が挙げる Simulee・CUDAsmith・CLsmith はいずれもランダム/差分テスト生成でコンパイラ・プログラムのバグを探す**ファジング**に基づく(FastFIT のみ集団通信インタフェースへの直接ビットフリップという計装型)。対象がモデルパラメータのような「値」から CUDA/OpenCL コンパイラのような「プログラム生成系」へ移るにつれ、有効な FI 技法の系統が変わることを示す一事例であり、本 concept が蓄積してきた FaultWeave の record/replay・SequenceFI の hitting set 最小化のような「注入戦略の最適化」議論とは異なる、**注入手段そのものの技術的系統がレイヤーに応じて分岐する**という観察を加える。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 6 FA and FI for AI Framework]] 表9, [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] 表12) - **NCCL・NVLink 障害の FI 不在は AI Framework 層(表10)に限らず、より下位の AI Toolkit 層(表13)でも一貫して観測される**: 本 concept は既に「NCCL 障害・NVLink 障害・InfiniBand 障害はどの既存 FI ツールもカバーしていない」と6層横断で記録してきたが、[[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] の表13はこれをハードウェアに最も近い AI Toolkit 層の粒度で再確認する——Simulee・CUDAsmith・CLsmith・FastFIT の4種のうち、FastFIT が MPI Fault のみをカバーし、NCCL Fault・NVLink Fault はいずれも Covered=False のままである。AI Toolkit 層の FI ツール総数(4種)は AI Framework 層(8種)よりもさらに少なく、Temporal Safety Fault・Failed Free Operation・Intra-Dependency Fault も未対応であり、分散 AI 訓練の基幹通信障害に対する FI 能力の欠如は「特定の層の見落とし」ではなく「フレームワークからハードウェアに至る垂直方向すべてで共通する構造的空白」であることを示す。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] 表13, [[A Survey on Failure Analysis and Fault Injection in AI Systems]]) - [HPC ジョブスコープの低権限注入] SLoFI(HPC・Slurm)は Table I 比較で「Supercomputer job allocation」層かつ「User」権限のみで動く唯一のツールであり、HDFIT(N/A)・LLFI(コンパイラ IR 層・User)・ChaosBlade/FINJ(User (partial))・Chaos Mesh/LitmusChaos/HPCArrow(Admin)のいずれとも異なる。root 権限・カーネル改変・常駐デーモンなしに、Slurm ジョブ割り当てを安全境界・オーケストレーション境界・計測境界の 3 役に使う設計により、症状指向(symptom-oriented)の擾乱(CPU/メモリ/プロセス/ネットワーク遅延・損失・ノイズ/ディスク)をユーザー空間プロセスとして注入し、ジョブ完了後にクリーンアップする(Source: [[@2026__ISSRE__SLoFI : Low-Privilege Fault Injection for Reliability Testing in Production Supercomputers]])。 ## 未解決の問い - **Natella et al. [105] の「低 fan-in/fan-out コンポーネントに障害を集中させる」というクラスタリングベースの選択戦略は、本 concept が蓄積してきた 2020 年代の障害注入研究(FaultWeave・SequenceFI・Cloud-OpsBench 等)のいずれでも採用されていない。コンポーネント間の依存構造(fan-in/fan-out)に基づく注入対象の絞り込みは、マイクロサービスの依存グラフ(Mycroft の依存駆動 RCA 等)と組み合わせれば、FaultWeave の単調性枝刈りや SequenceFI の hitting set 最小化と並ぶ第三の削減軸になりうるか**: それとも 2010 年代のモノリシックなソフトウェア(MySQL・RTEMS・PostgreSQL)を対象とした知見は、疎結合なマイクロサービスには構造的に転用できないか。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] §4.1.2) - **AgentChaosのLLM API層注入と、本concept既出のマイクロサービス層注入(ChaosMesh・stress-ng等)を組み合わせた複合障害注入は可能か**: 現実のエージェントシステムは、LLM API障害(AgentChaos)とインフラ障害(ChaosMesh)の両方に同時に晒されうる。両者は異なる層(HTTP透過型ラッパー vs. OS/コンテナ/ネットワーク)で動作するため技術的な統合は自明ではないが、統合できれば「LLM推論を担うマイクロサービス群」というより現実的な複合システムの頑健性評価が可能になる。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]]) - **AgentChaosの65障害設定は5システム×7ベンチマークに一様分配されるため各設定あたり平均4.6件のトリガー済みタスクしか得られず、Δpass@1の変動が大きい(Table3の負値)。本concept既出のSREGym/AIOpsLabのような「50障害プリミティブ×139サービス」のスケール量産アプローチをLLM API障害タクソノミーに適用すれば、この統計的不安定性は解消できるか**。(Source: [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]]) - DiRT のような人的プロセスへの障害注入(災害ロールプレイング)は、本 concept の技術的注入研究(ChaosMesh・stress-ng 等)と同じ「silent fault」問題(注入したが検知・対応に至らない)を抱えるか。抱えるとすれば、その検証(妥当性確認)はどのようなオラクルで行うべきか。(Source: [[@2022__OReilly__Anatomy of an Incident - Chapter 2 Practicing Incident Response Readiness (Preparedness)]]) - ネットワークトラブルシューティングエージェントベンチマーク NIKA は診断(検知・箇所特定・RCA)のみを評価し、緩和(mitigation)の評価は改善策の安全性検証(Batfish 統合)を含めて将来課題としている。クラウド SRE ベンチマークで確立された「状態ベースの緩和成功判定」(SREGym 等)は、ネットワーク改善策の検証(構文的正しさ+ネットワークモデルに対する安全性)にそのまま転用できるか、それともネットワーク到達性解析のようなドメイン固有の検証が必要か。([[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]]) - **OpsLLM の RCA Generator/Evaluator による reflection-and-verification が、本 concept の他の「注入 ≠ 障害」検証機構(impact-driven validation・Zodiac のデプロイ成否・Cloud-OpsBench の自動マスク検出)とどう関係するかは未整理**: OpsLLM の検証は「注入が障害化したか」でなく「生成された推論トレースが正解ラベルと論理的に整合するか」を問うため、対象が異なる(注入結果の妥当性 vs 生成データの品質)。同一データセット上で両者を組み合わせた場合、訓練データの質はさらに向上するか。(Source: [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]]) - SequenceFI の After ガードは正の出現回数エビデンスのみを扱う単調な設計であり、Before・Until のような非単調演算子や有界区間・イベント不在条件を表現できない。FaultWeave の単調性仮定(障害組み合わせが破れるケース)と SequenceFI の時間的ガードの単調性(After のみ)は独立した制約だが、両者を同時に破る「補償機構が発火して復旧に転じるタイミング」のような複合ケースを、どちらのフレームワークも現状扱えない。単調性を仮定しない時間的障害注入は、探索空間の性質をどう変えるか。([[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]], [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - SequenceFI の時間的ガード(いつ)と FaultWeave の障害組み合わせ(いくつ同時に)は直交する軸として定式化されているが、両者を統合した「k 個の障害を特定の時間順序で発火させる」注入フレームワークは存在しない。統合した場合、探索空間はどちらの枝刈り原理(FaultWeave の単調性 vs SequenceFI の hitting set 最小化)に従うべきか、あるいは両者を組み合わせた新しい枝刈りが必要か。 - SequenceFI の評価指標(TS・CW・PS・Prem・Miss・Mult)は時間的トリガリングの精度を測るが、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] が指摘した「注入がユーザー影響を持つか」(impact-driven validation)とは独立した軸である。時間的に正確な注入が必ずしもビジネスインパクトを持つとは限らない場合、両方の基準を同時に満たす注入をどう設計すべきか。 - 3MileBeach(シリアライゼーション層計装)と SequenceFI(通信層サイドカー)はいずれも時間的前提条件を扱うが、直接的な定量比較は行われていない(SequenceFI 論文は 3MileBeach のランダム化 TFIC 生成戦略のみを 3MileBeach-Random として再実装して比較しており、3MileBeach 自体の時間的トリガリング精度とは未比較)。同一ベンチマーク・同一時間的障害パターンで両者の TS・オーバーヘッドを直接比較すると、どちらの割り込み点(シリアライゼーション層 vs 通信層)がより高精度か。 - impact-driven validation の oracle problem をどう緩和するか。ユーザー向け SLI 以外に、gray 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(注入後状態を凍結した決定論的デジタルツイン)は、ある時点の状態をスナップショットする。時間発展する障害——カスケード故障や [[メタ安定障害]] のように注入後に伝播・遷移していく障害——を、凍結された 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層それぞれで未対応の障害種別が残り、層間の「ギャップの非対称性」が浮き彫りになる**: [[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: [[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: [[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]]) - **注入対象が「マイクロサービス間」から「アプリケーション⇔マネージドクラウドサービス間」へ広がり、HTTP プロキシによる REST 層注入という新しい注入点を確立する**: これまでの障害注入研究(ChaosMesh・FaultWeave・RCAEval 等)はマイクロサービス間の通信(Pod・ネットワーク・コード)を対象としてきたが、[[Rainmaker]]([[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]], NSDI'23。[[Agentic Failure Management of Cloud Systems]]第2章に再録)は視点を変え、**単一アプリケーションが Azure Storage・AWS S3 等の RESTful マネージドクラウドサービスを呼び出す境界**に着目する。スタンドアロン HTTP プロキシで outbound REST 呼び出しを傍受し、request 側に 5XX、response 側にタイムアウトを注入することで、SDK のリトライ機構がアプリケーションコードとどう衝突するかを検証する。既存の「症状注入 vs 根本原因注入」の議論(AIOpsLab/SREGym)とは軸が異なり、**注入対象が「クラウド内部の障害伝播」でなく「クラウドサービスの契約(SDK リトライ・非冪等性)とアプリケーションのエラー処理の食い違い」**である点が新しい。既存 SDK・API の振る舞いの不統一(同じ論理エラーでもサービスごとに異なる HTTP コードを返す等、例えば Azure Blob Storage は同一の HTTP 409 に対し 44 種の異なるエラーコードを持つ)を悪用する 4 パターンの taxonomy(no error handling / throwing unrelated exceptions / silent semantic violations / state divergence)を定義し、11 の .NET アプリケーションに push-button 適用して 73 件の新規バグ(誤検知率 1.96%)を発見した。(Source: [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]] §2.2.1, §3, §5.1) - **call-site 単位のカバレッジ指標と inheritable thread-local storage (ITLS) が、外部プロキシから見えない「どこに注入したか」の可視性ギャップを埋める**: HTTP プロキシのような分離プロセスからの注入は、[[障害注入]]の他事例(ChaosMesh 等)と同じく「注入対象がテレメトリ上どこに現れるか」を追跡する必要があるが、Rainmaker は非同期実行下でも call site 情報を HTTP ヘッダーへ伝播させる ITLS という仕組みで、プロキシ側に call site 単位のカバレッジ(C1–C4)を計算可能にした。マイクロサービスのランタイム注入が「注入したが症状が出ない」84.4% silent fault 問題([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])に悩まされるのに対し、Rainmaker は網羅すべき call site を先に定義してから注入するため、C4 の全 call site カバレッジ下で exhaustive baseline に対し平均 64.47% のテスト実行回数削減を達成しつつ、全パターンのバグを検出できる(Orleans では反復ストレステストの重複呼び出しを削減し、削減なしでは 588 日かかる実行を現実的な時間に短縮)。「症状が出るかを事後検証する」のでなく「注入すべき対象を事前に特定し尽くす」という、注入戦略における別の効率化の軸を示す。(Source: [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]] §4.2.2, §5.3) - **DDIA 2E は Jepsen・Chaos Monkey・決定論的シミュレーションテスト(DST)を「アルゴリズムの性質を経験的に検証する」という単一の枠組みに位置づけ、モデル検査(TLA+)と対比する**: 本 wiki のこれまでの障害注入研究(ChaosMesh・AIOpsLab・SREGym 等)はマイクロサービスの症状/根本原因注入という実装上の論争を扱ってきたが、DDIA 第9章はより一段抽象化し、障害注入を「理論的に証明されたアルゴリズムが実装でも実際に性質を満たすかを検証する」経験的手法として、形式手法(モデル検査)と並置する。Netflix の Chaos Monkey が普及させた本番環境への障害注入(chaos engineering)、Jepsen フレームワークによる体系化、そして FoundationDB・TigerBeetle が採用する DST(ネットワーク・I/O・クロックをモックし大量のランダム化実行を決定論的に再実行可能にする手法)を、「モデル検査は実コードでなく簡略化モデルを検証する」「DST は実コードを検証するが状態空間の網羅性はモデル検査に劣る」という明確なトレードオフの上で相補的に位置づける。本 concept が蓄積してきた「注入 ≠ 障害」ギャップ(silent fault 問題)の議論は主に**注入後にテレメトリへ現れるか**を扱うが、DST はこの問題を原理的に回避する——シミュレータが全ての実行順序を制御するため「注入したが症状が観測されない」という非決定性そのものが生じない。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Fault injection", "Deterministic simulation testing") - **DST の3つの決定性獲得戦略(アプリケーションレベル・ランタイムレベル・マシンレベル)は、本 concept が蓄積してきた「非決定的なライブ注入を決定論的な構成へ落とす」試み群の最も徹底した形態である**: Zodiac の SMT による単一違反保証・Cloud-OpsBench の State Snapshot Paradigm・FaultWeave の record/replay はいずれも注入の一部分(対象・状態・応答)を決定論化するが、DDIA が紹介する DST はネットワーク・I/O・クロックという実行の全側面を制御下に置く。FoundationDB の Flow(アプリケーションレベル)・FrostDB や Rust MadSim(ランタイムレベル)・Antithesis のカスタムハイポバイザー(マシンレベル)という 3 層は、決定性をどのレイヤーで獲得するかという設計選択の分類軸を、本 concept の既存事例群に対して提供する。(Source: [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]] "Deterministic simulation testing") - **「注入空間の枝刈り」の根拠として、バグスタディが導く構造的制約は探索アルゴリズムの工夫より強い**: FaultWeave の有界探索(K=3)・Rainmaker の call-site カバレッジ・Chronos の深さ優先探索はいずれも探索アルゴリズム側で空間を圧縮するが、[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] は 48 件の実障害の分析から「フェイルスローハードウェア障害バグは同期機構とタイムアウト機構に 100% 集中する」という構造的制約を先に見つけ、静的解析で注入対象そのものを絞る。ZooKeeper で候補障害点が 1905→1266(S/T 絞り込み)→856(グルーピング)に減り、全 I/O に注入する FATE・Legolas が 2000 実行で届かなかったバグを検出できた。「どこに注入すべきか」をバグスタディで先に決める方が、「どう探索するか」を工夫するより効く場合があることを示す事例である。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §3・§6.2, [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]], [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]]) - **注入の粒度は「多いほど強い」ではなく、粗すぎる障害はフォールトトレランス機構に吸収されてバグを隠す**: 本 concept のこれまでの議論は「単一障害では見落としが多い」(FaultWeave の 89% が複数障害でのみ発現)という方向で複雑さを増す軸を扱ってきたが、[[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] は逆向きの制約を示す——フェイルスロー NIC のかわりにフェイルストップ NIC を注入すると heartbeat も止まり、follower がリーダー選出を始めてクラスタが健全に戻るため、バグが**再現しなくなる**。注入設計における粒度は強度の軸ではなく、フォールトトレランス機構の検知網をすり抜けるかどうかという別の軸である。この観点は既存のカオスエンジニアリング基盤(ChaosMesh の PodChaos 等)が提供する粗粒度障害プリミティブの構造的な限界を示唆する。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §1, [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - **「注入 ≠ 障害」ギャップの逆問題として「障害 ≠ 真のバグ」ギャップがあり、LLM エージェントが後者の一次スクリーニングに使われ始めた**: 本 concept は silent fault 問題(注入したが症状が出ない、84.4%)を蓄積してきたが、Sieve が直面したのは逆側——チェッカが疑わしいと印を付けた実行のうち、どれが本物の FSH バグかを判定する負担である。Sieve は opencode + claude-opus-4.7 のエージェントに FSH 障害の定義・検証手順・判定基準を skill として与え、`TRUE_BUG` / `FALSE_POSITIVE` / `UNCERTAIN` を 1 件あたり平均 120.74 秒・約 0.50 ドルで判定させた。[[LLMによる根本原因分析]] の議論が「障害からの原因特定」を扱うのに対し、これは「注入結果のトリアージ」という別の適用点である。ただし評価は ZooKeeper の 10 件のみで、正解ラベルが著者判定に依存する点は共通の課題として残る。(Source: [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] §4.7・§6.3, [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - **分散データベースの開発チーム自身が実践する故障注入は、本concept が蓄積してきたマイクロサービス向けツールの「システム層をまたぐ断片化」問題(Yu+ TOSEM 2025)に対し、単一チームが4層すべてを自前で統合した稀有な事例を提供する**: [[A Survey on Failure Analysis and Fault Injection in AI Systems]]（既出）は AI Framework 層だけで8つの断片化した FI ツールが並立すると指摘し、[[障害注入]] 全般でも ChaosMesh(Pod/ネットワーク/資源) と ChaosBlade(OS/コンテナ) のようにツールごとに対象層が分かれがちであることが本 concept の他項目からも読み取れる。[[TiDB]] を開発する [[PingCAP]] は([[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]])、アプリケーション(プロセスkill/停止)・CPU/メモリ(ビジーループ・cgroup)・ネットワーク(tc・iptables・プロキシ・分断3タイプ)・ファイルシステム([[FUSE]] 経由のI/Oフック)という4層すべてを、単一のカオスエンジニアリング実践(Nemesis)としてSchrodingerに統合している。汎用オーケストレーション層(ChaosMesh)を外部提供しつつ、自社製品固有のカオス実践は別の統合ツールで行うという構図は、汎用ツールと製品固有ツールの役割分担がPingCAP社内で両立していることを示す。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] §19.2.2–§19.2.6, [[A Survey on Failure Analysis and Fault Injection in AI Systems]]) - **ネットワーク分断の学術的定量研究(Alquraan+ OSDI'18)が、本concept のマイクロサービス中心の議論に「分散データベース特有の被害の大きさ」という実証データを補う**: 本 concept はこれまでネットワーク障害注入を tc・iptables 等のツールレベルで扱ってきたが、[[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] が引用する Ahmed Alquraan らの研究(25件のOSSシステム分析、136件のネットワーク分断起因の故障を特定)は、分断由来の故障の80%が壊滅的で27%がデータ喪失を伴うと定量化し、分散データベースとの関連が特に深いと結論づける。これは [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]] が定量化した「注入の84.4%がNo Anomaly」というマイクロサービスの傾向とは対照的に、**ステートフルな分散データベースではネットワーク分断注入が高確率で深刻な症状(データ喪失)に至りやすい**ことを示唆し、対象システムの状態性(ステートレス vs ステートフル)によって注入の障害化率が構造的に異なる可能性を示す。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] §19.2.5、引用元 Ahmed Alquraan et al., OSDI'18, [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) ## 未解決の問い（追記） - TiDBのFUSEベースのファイルシステム故障注入(パスごとのルールでI/Oに遅延・エラーを注入)は、本concept の他のファイルシステム/ストレージ層への注入事例(フェイルスローハードウェア研究の同期・タイムアウト機構への注入等)と比べて、どの程度の粒度制御が可能か。バイトコード計装(Sieve)やマウントポイント単位のフック(TiDB のFuse)のどちらが、より細粒度な「特定のI/O呼び出し1つだけを遅くする」注入に近いかは未比較である。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] §19.2.6, [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) - 粗粒度障害プリミティブしか持たない既存のカオスエンジニアリング基盤(ChaosMesh・ChaosBlade)に、Sieve のような細粒度注入(特定の I/O 呼び出し 1 つだけを遅くする)を載せる現実的な経路は何か。サービスメッシュの sidecar で「呼び出し単位の遅延」を実現できるか、それともバイトコード計装のようなプロセス内介入が不可欠か。([[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) - Sieve の障害点解析は Java の同期・タイムアウトキーワードの列挙に依存する。Go の `select` / `context.WithTimeout`、Rust の `tokio::time::timeout` のような非同期ランタイム上では「同期スコープ」の定義自体が変わるが、同じ枝刈り原理は成立するか。([[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]]) - Yu+ TOSEM 2025 が提唱するクロスレイヤ障害注入——例えば AI Framework 層の設定障害が Model 層の訓練失敗を引き起こすカスケード——を、既存のカオスエンジニアリングツール（ChaosMesh / ChaosBlade）のインフラ層注入と組み合わせて実現できるか。層をまたぐ依存関係のモデル化は Zodiac の SMT 型と Mycroft の依存駆動 RCA 型のどちらに近いか。([[A Survey on Failure Analysis and Fault Injection in AI Systems]]) - 同サーベイが「将来方向」として挙げた「LLM + 人間フィードバック強化学習による FI 方針自動生成」は、Cloud-OpsBench の MAS 閉ループ注入（Generator/Executor/Verifier）のアーキテクチャとどう統合されるか。自然言語の障害シナリオ記述から注入パラメータへの変換は、AIOpsLab の機能的障害ライブラリの「人手設計」を置き換えうるか。([[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]]) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 9 FA and FI for AI Infrastructure]](§9.3)が指摘する「模擬された障害(emulated faults)のリアリズム欠如」は、[[GPUレジリエンス]] が蓄積する本番環境の実測統計(Delta A100/H100 の MTBE・GSP/PMU/NVLink 等コンポーネント別故障率)で検証できるか。SASSIFI・NVBitFI 等のソフトウェアレベルFIが生成するビットフリップ/スタックアット障害の統計分布は、実本番で観測される故障分布とどの程度一致するか、あるいは乖離するか。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 9 FA and FI for AI Infrastructure]] §9.3, [[GPUレジリエンス]]) - 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]]) - Rainmaker の taxonomy は「1回の REST API 呼び出しインタラクション」に閉じた障害モデルを対象とし、相関する複数呼び出し(例: あるサービスへの書き込みと別サービスからの読み込みの間の不整合)にまたがるバグは対象外とされる(論文自身が明言)。マイクロサービス間の cascading failure・Type III symptom drift の議論([[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])と、この「単一呼び出し障害モデル」をどう統合すれば、アプリケーション⇔クラウドサービス間とマイクロサービス間の両方の障害伝播を扱える統一的な注入フレームワークになるか。博士論文本体(第2章 Summary)もこの限界を「actively investigating」とだけ述べ、具体的な統合案は示していないため、この問いは執筆時点でも未解決のまま残る。([[Agentic Failure Management of Cloud Systems]], [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]] §2.9) - DST が原理的に回避する「注入 ≠ 障害」ギャップ(silent fault 問題)は、マイクロサービスのようにネットワーク・I/O・クロックの全側面を制御しきれない環境(サードパーティ SaaS 依存・物理ハードウェア等)ではどこまで再現できるか。マイクロサービス向けの ChaosMesh 系ツールと DST を組み合わせ、制御可能な部分は決定論的に、制御不能な部分は事後検証で扱うハイブリッド設計は可能か。([[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]) - LDFI(12章)の SAT/ILP ベースの実験選択は、FaultWeave の単調性仮定によるヒューリスティック枝刈りや SequenceFI の hitting set 最小化と比べて、探索空間の爆発(31 サービス×4 障害タイプ=295,244 通り等)にどこまでスケールするか。12章は LDFI を Netflix・Huawei・eBay で運用したと述べるが、具体的な探索空間サイズや実行時間の記載がなく比較検証されていない。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] §12.2.1.1, [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - AI Model層のミューテーションテスト(DeepMutation系)は訓練データ・重み・層構造という「モデル内部」への直接介入である一方、本conceptが蓄積してきたDST(決定論的シミュレーションテスト)はネットワーク・I/O・クロックという「実行環境」を制御下に置くことで決定性を得る。両者はいずれも「非決定的な外部要因を排し、注入結果を再現可能にする」方向を向いているように見えるが、モデル内部への直接改変(ミューテーション)と実行環境の決定論化(DST)は同じ枠組みで統合できるか、それとも対象(モデルの学習ダイナミクス vs 分散システムの実行順序)が違いすぎて別々に扱うべきか。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 5 FA and FI in AI Model]] §5.2, [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]) - AI Framework 層(表8)の Dependency に相当する障害は明示的なグループとして立てられていないが、AI Toolkit 層(表11)では Intra-/Inter-Dependency Fault という独立グループとして定義される(例: CUDA バージョンと PyTorch バージョンの不一致による「driver too old」障害)。フレームワーク⇔ツールキット境界をまたぐ依存関係の不整合(例: PyTorch のバージョンアップが要求する CUDA バージョンと実機にインストール済みの CUDA のずれ)を、単一の FI ツールで模擬する手法は本サーベイのいずれの層にも存在しない。AI Framework 層の計装型 FI(TorchFI 等)と AI Toolkit 層のファジング型 FI(CUDAsmith 等)を組み合わせた層をまたぐ複合障害注入は設計可能か。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 6 FA and FI for AI Framework]] 表8, [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] 表11) - AI Toolkit 層の Memory Safety Fault(Out-of-Bounds Access・Temporal Safety Fault・Failed Free Operation)は、通常の C/C++ ソフトウェア向けメモリ安全性ファザ(AddressSanitizer 系等)が長年蓄積してきた技法と概念的に近いはずだが、本サーベイが挙げる CUDA 向け FI ツール(Simulee・CUDAsmith)はいずれも同期障害・コンパイラバグの検知に主眼を置き、Temporal Safety Fault・Failed Free Operation は未対応のまま残る(表13)。汎用メモリ安全性ファザを GPU カーネルコード(CUDA/OpenCL)向けに適応させる経路は、本サーベイのいずれの章でも具体的に検討されていない。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] 表11・表13) - Yu+ TOSEM 2025 第11章は、GPUリソース競合・メモリリーク・設定誤りという既存FIツールが未対応の障害型を狙い撃ちする注入戦略の開発を将来方向に挙げる。GPUリソース競合(訓練・推論中のGPUメモリ・計算資源への人為的遅延・制約)は、本conceptが蓄積してきたマイクロサービス向け資源障害注入(stress-ngのCPU/MEM/DISK/SOCK)やRainmakerのAPI層障害注入(5XX・タイムアウト)と対象・粒度が異なるが、狙いは同じ「特定資源への競合を模擬する」ことである。マイクロサービス側で確立された強度校正窓の知見(弱すぎると無反応・強すぎるとOOM killerが介入、[[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]])は、GPUメモリ・計算資源への競合注入にもそのまま転用できるか、それともGPUスケジューラ固有の別の校正問題(例: SM占有率・メモリ帯域の競合)が生じるか。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 11 Future Opportunities of FI in AI Systems]] §11.1, [[@2025__arXiv__Rethinking the Evaluation of Microservice RCA with a Fault Propagation-Aware Benchmark]]) - 同章は現行FIツールが単一層への単一障害注入に限定される点を課題とし、複数障害の同時注入(single layer 内での並行注入)を将来方向として挙げる。これは本conceptが既に蓄積してきた「複数障害の組み合わせ」研究——FaultWeaveのK=3有界探索(31サービス・4障害タイプで99.0%枝刈り)や、実運用512マイクロサービスで確認された脆弱性の89%が複数障害シナリオでのみ発現するという実証——と同種の課題設定に見えるが、対象がAIシステムの単一層内(例: 単一GPUノード上の複数障害)である点で異なる。FaultWeaveの単調性仮定によるヒューリスティック枝刈りは、AIインフラ層(GPU/FPGA/TPU・ネットワーク・ノード、第9章Table 17〜19)のような障害空間へそのまま転用できるか、それともAI層特有の障害間の相互作用(例: GPUメモリ不足がネットワーク送受信の遅延を誘発する)には別の枝刈り原理が必要か。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 11 Future Opportunities of FI in AI Systems]] §11.1, [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) - 同章は現行FIツールがフレームワーク・バージョンごとに断片化している(PytorchFIはPyTorch専用、TensorFIはTensorFlow 1専用でTensorFlow 2にはInjectTFが別途必要)ことを課題に挙げ、複数層・複数フレームワークを横断できる統一ツールの設計を将来方向とする。この断片化は本conceptが既に観察した「AI Framework層だけで8つのFIツールが並立する」という知見(既出、TensorFI/InjectTF/TorchFI/PyTorchFI/TensorFI2/SNIFF/enpheeph/MindFI)の裏返しにあたるが、唯一フレームワーク非依存とされるenpheephも障害種別がデータ障害とアルゴリズム障害に限定される。フレームワーク横断の統一FIツールは、対象言語がPythonに共通する利点(第11章が非計装型注入の根拠として挙げるPythonバイトコード改変の可能性)を使って実現できるか、それとも各フレームワークの内部データ構造(テンソル表現・計算グラフ)の違いが統一を妨げるか。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 11 Future Opportunities of FI in AI Systems]] §11.2) - 同章は現行FIツールの多くがフレームワークのソースコード改変のような計装を要求し利用難度を上げていることを課題に挙げ、Pythonバイトコード改変やeBPFによる非計装型注入(non-instrumented injection)を将来方向とする。本conceptが蓄積してきた「非計装性」の議論——Rainmakerの外部HTTPプロキシによるアプリケーションコード非改変での注入、FaultWeaveのサイドカープロキシによるrecord/replay——はいずれもネットワーク層・API層での非計装を実現しているが、第11章が挙げるのはより低レベルな「フレームワーク内部の障害(パラメータ破損・演算子挙動の改変等)をコード計装なしに注入する」課題である。eBPFはOS・カーネルレベルの計装なしフックを提供するが、Python/PyTorchのようなユーザ空間の言語ランタイム内部状態(テンソル値・勾配)まで非計装で到達できるか、それともバイトコード改変(ユーザ空間での動的パッチ)でなければ届かない障害種別が残るか。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 11 Future Opportunities of FI in AI Systems]] §11.2, [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]], [[@2026__FSE Companion__FaultWeave - Bounded Resilience Testing with Failure Diagnosis Capability for Microservice Applications]]) ## 関連 - ソース: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 4 FA and FI in AI Service]] / [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 5 FA and FI in AI Model]] / [[@2012__CACM__Fault Injection in Production]] / [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]] / [[@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]] / [[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?]] / [[Agentic Failure Management of Cloud Systems]] / [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]] / [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]] / [[@2025__arXiv__A Network Arena for Benchmarking AI Agents on Network Troubleshooting]] / [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] / [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] / [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] / [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 8 FA and FI for AI Platform]] / [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 9 FA and FI for AI Infrastructure]] / [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 6 FA and FI for AI Framework]] / [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]] / [[@2026__ISSRE__SLoFI : Low-Privilege Fault Injection for Reliability Testing in Production Supercomputers]] - 関連 concept: [[GameDay]] — 本番環境での障害注入をチーム対応演習として定式化した実践形式 - 概念: [[根本原因分析]] / [[Fault Localization]] / [[SRE Benchmark]] / [[異常検知]] / [[メタ安定障害]] / [[設定マイニング]] / [[Infrastructure as Code]] / [[強化ファインチューニング]] / [[集合通信]] / [[耐障害LLM訓練]] / [[オブザーバビリティ]] / [[コーディングエージェント評価]] / [[LLMによる根本原因分析]] / [[カオスエンジニアリング]] / [[フェイルスローハードウェア]] / [[グレイ障害]] / [[ネットワークトラブルシューティングエージェントベンチマーク]] / [[分散システム障害]] / [[GPUレジリエンス]] - エンティティ: [[ChaosMesh]] / [[Train-Ticket]] / [[AIOpsLab]] / [[SREGym]] / [[Meltria]] / [[Online-Boutique]] / [[Sock Shop]] / [[DeathStarBench]] / [[Zodiac]] / [[RFT-FaultBench]] / [[Cloud-OpsBench]] / [[ChaosBlade]] / [[Rainmaker]] / [[Peter Alvaro]] / [[Disorderly Labs]] / [[Netflix]] / [[Sieve]] / [[PingCAP]] / [[TiDB]] / [[Schrodinger]] / [[FUSE]] / [[PyTorch]] / [[TensorFlow]] / [[CUDA]] / [[NCCL]] - 概念(理論的位置づけ): [[システムモデルと安全性・活性]] / [[軽量形式手法]] / [[TLA+]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] / [[SRE - MOC]] ## 出典 - [[@2012__CACM__Fault Injection in Production]](John Allspaw, "Fault Injection in Production: Making the Case for Resilience Testing", Communications of the ACM, Vol.55 No.10, 2012, pp.48-52: Etsy 決済システムでの GameDay 実施報告、本番 vs ステージングの不確実性の議論、自動化された継続的障害注入のパラドックス) - [[@2026__arXiv__OpsLLM - Construction of Large Language Model for Software Operations with Multi-stage Learning]](§III-B Chaos Mesh StressChaos/NetworkChaos による Online Boutique 障害注入、reflection-and-verification による RCA サンプル生成、60MB→20KB・圧縮率99%超の representation fusion) - [[@2026__arXiv__SequenceFI - Non-intrusive Temporal Fault Injection for Microservice Systems]](§III 3 つの時間的障害パターン=post-effect/order-sensitive/k-of-n、§IV-B TFIC 生成=静的ターゲット選択+hitting set 最小化による時間的ガード合成、Table IV/V RQ1 時間的トリガリング精度、Table VI RQ2 探索時間削減、§VI-D RQ3 サイドカーオーバーヘッド) - [[@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 ケース統計) - [[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 件の障害インスタンス) - [[Agentic Failure Management of Cloud Systems]](第2章 Rainmaker: §2.2 4パターンのバグ taxonomy, §2.3–2.5 フォールトインジェクションポリシー P1–P4・call-site カバレッジ C1–C4・ITLS による call site 伝播, §2.6 Exception/Assertion Oracle, §2.7 11 アプリ・73 件新規バグ・誤検知率 1.96%) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]](上記第2章の章単位 source ページ。NSDI'23 との数値照合結果を含む) - [[@2026__OReilly__Designing Data-Intensive Applications 2E - Chapter 9 The Trouble with Distributed Systems]]("Fault injection": Jepsen・Chaos Monkey・chaos engineering の概説, "Deterministic simulation testing": FoundationDB/TigerBeetle/FrostDB/MadSim/Antithesis の3層決定性戦略) - [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]](Rainmaker の一次論文、NSDI'23: §2 エラー通知の3要素の不整合, §3 taxonomy=Figure 2, §4.2 フォールトインジェクションポリシー P1–P4=Figure 6・網羅率指標 C1–C4=Table 3, §4.3 Exception/Assertion Oracle, §5.1 73 件新規バグ=Table 5, §5.2 誤検知率 1.96%, §5.3 exhaustive baseline 比 64.47% 削減=Figure 9) - [[@2026__TOCS__Fail-Slow Hardware Failure Bug Analysis and Detection for Cloud Systems]](§2 バグスタディの方法論=JIRA キーワード検索と 48 件の選定, §3 Finding 1-6 と Table 2-4, §4.3 同期/タイムアウトスコープの静的特定, §4.4 グルーピング+文脈依存注入戦略, §4.7 エージェントによる障害検証, §6.1-6.3 未知バグ 6 件・チェッカ別内訳・代替手法比較・偽陽性) - [[@2026__ASE__AgentChaos - Chaos Engineering for Agent Systems via Programmatic Fault Injection]](§3 crash/omission/value タクソノミー=Table 1、§4.2 65 障害設定の構成=Table 2、§4.3 HTTP層ラッパーによる非侵入的注入、§4.4 トリガー検証、§5.2-5.4 RQ1-RQ3=Table 3-9) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 3 原則の全体像]] — Casey Rosenthal, Nora Jones, 「原則の全体像」, Casey Rosenthal・Nora Jones 編『カオスエンジニアリング ― 回復力のあるシステムの実践』, オライリー・ジャパン, 2022, 3章(§3.3.2 コラム「ラクな道を選ばないようにしよう」) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 12 実験の選択に関する課題（と、その解決策）]] — Peter Alvaro, 「実験の選択に関する課題(と、その解決策)」, 同書, 12章(§12.2.1.1: 系統ドリブンな故障注入(LDFI)によるブール式モデリングとSAT/ILPベースの実験選択・優先順位づけの自動化) - [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 19 データベースにおけるカオスエンジニアリング]] — Liu Tang, Hao Weng, 「データベースにおけるカオスエンジニアリング」, 同書, 19章(§19.2.2–§19.2.6: アプリケーション/CPU・メモリ/ネットワーク/ファイルシステムの4分類故障注入、ネットワーク分断3タイプ、FUSEによるファイルシステム故障注入) - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]](§4.1.2 Fault Injection: F/A/R/M の定式化、SFI と Mutation Testing の区別、Siami Namin et al. の mutant 集合 8% 削減、Natella et al. の faultload -22%〜-69% 削減・代表性 +4%〜+26% 改善) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 4 FA and FI in AI Service]](§4.1 FA 5分類・Table 2、§4.2 FI 4次元・Table 3=JENGA/Istio/ChaosBlade/敵対的攻撃/プロンプト攻撃、§4.3 Gap分析・Table 4=Defective Code/Configuration FaultがCovered=False) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 5 FA and FI in AI Model]](§5.1 FA 3分類・Table 5、§5.2 ミューテーションテスト=DeepMutation/DeepMutation++/MuNN/DeepCrime・Table 6、§5.3 Gap分析・Table 7=10障害型すべてCovered=Trueだが被覆ツール数に偏り) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 8 FA and FI for AI Platform]](§8.1 FA 3分類10障害型・Table 14、§8.2 FI 5ツール(汎用系ChaosBlade/CoFI/CrashFuzz + Spark専用系TRANSMUT-SPARK/DepFuzz)・Table 15、§8.3 Gap分析・Table 16=11型中6型未対応、Kubernetes等の従来型クラウド基盤向け設計でGPU資源競合を模擬できるツールが皆無) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 9 FA and FI for AI Infrastructure]](§9.1 FA 3分類10障害型=Hardware Accelerator/Network/Node・Table 17、§9.2 FI 11ツール=GPU(ソフトウェア/ハードウェア-シミュレーション/ハイブリッド)・FPGA(再構成/計装)・ネットワーク・ノード・Table 18、§9.3 Gap分析・Table 19=ハードウェア特化とネットワーク特化への分裂、模擬された障害(emulated faults)のリアリズム欠如) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 6 FA and FI for AI Framework]](§6.1 FA 6グループ16障害型=Data/API/Configuration/Performance/Code/Algorithm・表8、§6.2 FI 8ツール=TensorFI/InjectTF/TorchFI/PyTorchFI/TensorFI2/SNIFF/enpheeph/MindFI・表9、§6.3 Gap分析・表10=Performance Fault・Configuration Fault等4型未対応、フレームワークダイバージェンス=TensorFI がTensorFlow 1のみ対応) - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 7 FA and FI for AI Toolkit]](§7.1 FA 4グループ11障害型=Synchronization/Memory Safety/Dependency/Communication・表11、§7.2 FI 4ツール=Simulee(ファジング)/CUDAsmith(ファジング)/CLsmith(ファジング)/FastFIT(計装)・表12、§7.3 Gap分析・表13=Temporal Safety Fault・NCCL Fault・NVLink Fault等5型未対応、分散・並列計算向けFI能力の欠如)