障害緩和 - yuuk1's Digital Garden

# 障害緩和 ## 定義障害緩和(software remediation / mitigation)は、障害診断の結果を入力に、適切な復旧アクションを実行してシステムを健全な状態へ戻す、ソフトウェア保守ライフサイクル(異常検知 → 障害診断 → 障害緩和)の最終段。アクション指向の段階で、診断洞察(局所化された故障領域 $r_i$、故障種別 $c_i^*$、現在状態 $S_t$)を具体的な復旧戦略や実行可能な修復スクリプトに具体化する($R: (r_i, c_i^*, S_t) \to A_i$)。アクションはサービス再起動・設定のロールバック・リソース再割り当て・パッチ適用等を含み、緩和後の状態 $S_{t+1}$ を観測する閉ループ最適化として形式化できる。戦略は recovery plan を合成する **plan-based** と実行可能なスクリプトを生成する **script-based** に大別される。([[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]] §B.3) [[AIOps]] の 4-level taxonomy では最上位(最難)の Mitigation に対応する([[AIOpsLab]])。 [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] は緩和(assisted remediation)を**自動化レベル昇順の 5 段**に整理する(§4.3, Fig.9):(1) **Assisted Questioning**(運用者の質問に LLM が回答)、(2) **Mitigation Solution Generation**(緩和策を生成。LLM 以前から存在する唯一の段)、(3) **Command Recommendation**(次に打つコマンドを推薦)、(4) **Script Generation**(修復スクリプトを直接生成)、(5) **Automatic Execution**(生成と実行まで自動)。(2) 以外はすべて LLM 時代に出現した新タスクで、Microsoft 系論文の entity 整理と提携企業 OCE へのインタビューで定めた。 ## 横断的知見 - **SRE Book の緊急対応は「テスト誘発型障害 vs 訓練なし障害」の対比で、事前準備と段階的ロールアウトの価値を実証する**: [[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]] は 3 つの緊急事態の事例研究（テスト誘発型障害 2 件、訓練なし障害 1 件）を通じて、事前にテストされた障害は迅速なロールバックで緩和されるが、訓練なしの障害では混乱と長期化を招くことを示す。「人間は深刻な事態であるほど、思考停止せずに冷静に判断し創造的に対応する能力が重要」という知見は、[[agentic SRE]] のエージェントが自律緩和する場合に「判断の質」をどう保証するかという問題と直結する。Ch17（[[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]]）はカナリアテストにおける障害の次数（U）と段階的ロールアウトの原則を定量化し、緩和の前段としてのテスト投資が信頼性の確信度を高めるメカニズムを示す。(Source: [[@2016__OReilly__SRE Book - Chapter 13 Emergency Response]], [[@2016__OReilly__SRE Book - Chapter 17 Testing for Reliability]]) - **「緩和」が独立した評価対象として切り出された**: [[AIOpsLab]] は緩和を検知・箇所特定・RCA と並ぶライフサイクルの 1 タスクとして扱い、[[SREGym]] はエンドツーエンドのループの帰結として緩和成功を見る。これに対し [[MicroRemed]] は緩和(より厳密には診断レポート→実行可能なプレイブックの生成=E2E-MR)だけを切り出し**専門ベンチマーク化**した初例。AIOps 評価が「ライフサイクル全体のカバレッジ」から「最難段である緩和の深掘り」へ分化しつつある。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **緩和は試行錯誤であり「安全に巻き戻せる反復」が鍵**: 緩和は実行時にしか結果が観測できない多段計画であるため、複数の独立した研究が「一発生成より反復・反省」に収束する。[[MicroRemed]] の [[ThinkRemed]] はリフレクション(失敗からの再生成)がワンショットを平均 +7.07% 上回り、アブレーションでリフレクション(-7.16%)がプローブ(-1.57%)より寄与が大きいと示す。[[Stratus]] は巻き戻しと再試行を [[Transactional No-Regression]] として形式化し「安全な探索が自律的な緩和を改善する」と主張、[[SREGym]] も最高性能を巻き戻しと再試行の機構ゆえと観測する。緩和性能の源泉は情報収集の量でなく**反省と安全な再試行**にあるという像が複数ソースで一致。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **情報の取りすぎは緩和を害し得る**: [[MicroRemed]] はプローブ(実行時の情報収集)を除去すると一部設定で精度が**上がる**ことを観測し、現行モデルの文脈推論が限られるため過剰なプロービングがノイズになると分析する。これは [[AIOpsLab]] の「成功するエージェントほど get_metrics/get_traces を控えめに使い、雑な消費はコンテキストウィンドウの圧迫と性能低下を招く」という観測、[[SREGym]] の「貪欲な手法への固着」と同じ向きの知見。緩和でもテレメトリの取捨選択が性能を左右する([[agentic SRE]] と接続)。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]]) - **緩和は「安全」と「誠実」が別問題(STRATUS 本文で裏取り)**: [[Stratus]] の TNR は「状態を悪化させない」ことを重大度 µ の単調非増加として保証するが、「正しく直す」ことは保証しない。本文・付録 C は [[ITBench]] 18 問中 8 問を「注入した障害が Pod 再起動後に残らない」性質を悪用した Pod 再起動で解いており、**undo agent の有無でタスク成功率が変わらない(共に 9/18)**と報告。論文自身がこの戦略は persistent fault(誤設定・ハードウェア欠陥)には現実に効かないと明言する。[[SREGym]] が状態ベースの判定で報酬ハッキングを防ごうとするのと裏腹に、判定がアラートの有無に依ると緩和エージェントは「症状消し」に最適化されうる。安全な緩和(no-regression)と誠実な緩和(根本を直す)は直交し、後者は評価設計に依存する。(Source: [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **実行ベース / 状態ベースの検証で「本当に直ったか」を測る**: [[MicroRemed]] は出力のテキスト類似でなく playbook を実行し、注入した障害のみを標的に検査して回復を判定する(検証精度 100% を主張)。[[SREGym]] もアラート抑制でなく状態ベースで緩和成功を判定し報酬ハッキングを防ぐ。緩和評価が「もっともらしい出力」から「実環境での状態回復」へ統一されつつある。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]], [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]]) - **本番 GenAI インシデントの緩和戦略はベンチマークが想定するより多様で、自己回復が 2 割を占める**: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] は GenAI クラウドサービスの緩和戦略を 7 類に分類し、アドホック修正 22.4%・自己回復 19.7%・ロールバック 15.2%・設定修正 13.0%・インフラ修正 12.1%・外部修正 10.0%・コード修正 7.6% と報告。[[MicroRemed]] が評価する Ansible プレイブック生成（script-based）は本番ではコード修正 7.6% に相当し、緩和の最少カテゴリ。注目すべきは自己回復が 19.7% を占める点で、[[AIOpsLab]]/[[SREGym]]/[[MicroRemed]] のいずれも「介入不要で自然に回復する」シナリオを含んでおらず、エージェント評価は本番の約 2 割を占める「何もしないのが最適」ケースの判別能力を測っていない。さらにコード修正が根本原因のコードバグ 21.5% に比べ 7.6% に留まるのは、CI/CD の所要時間からロールバックやアドホック修正が優先されるため——時間制約下の現実の緩和選択は「正しく直す」より「速く止める」に傾く。(Source: [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]], [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - **サーベイの自動化 5 段の上位 2 段に、vault の一次ソースがちょうど位置する**: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] の緩和 5 段(assisted questioning → mitigation solution → command recommendation → script generation → automatic execution)で、[[MicroRemed]]/[[ThinkRemed]] の「診断レポート → Ansible playbook 生成」は Lv4(script generation)、[[Stratus]]/[[SREGym]] の閉ループ実行は Lv5(automatic execution)に対応する。サーベイは Lv5 を「関連研究は限られ実効性は未検証」とカットオフ 2024 時点で評価したが、2025–2026 の vault 一次ソースはまさにその Lv5 を [[Transactional No-Regression]] のような安全制約付きで攻める段に踏み込んでいる。「自動実行は未検証」というサーベイの空白を、安全な巻き戻し付き自動実行が後続で埋めつつある。(Source: [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - **LLexus の「計画前置+決定論的実行」が示す緩和の別設計軸——反省でなく確実性の向上**: [[MicroRemed]] の ThinkRemed が反復リフレクションで緩和精度を高めるのに対し、[[LLexus]]([[@2024__OSR__LLexus - an AI agent system for incident management]])は全く別の角度から同じ「LLM 非決定性が本番緩和を妨げる」問題に対処する。LLexus は LLM をインシデント時に使うのでなく、事前の計画フェーズで TSG を BPMN 風フローチャート(アクション/条件分岐/イベントノード)に変換し、実行時は既存ツール(Powershell・Kusto クエリ等)を決定論的に呼び出すだけにする。これにより「緩和の非決定性」と「LLM コスト増大」を同時に解消する。ただし LLexus 自身が認めるように、この手法は**既知の反復インシデントにのみ適用可能**であり、新種のインシデントには依然として ReAct 型エージェントが必要となる。反省ループ型(ThinkRemed)と計画前置型(LLexus)は、「未知の障害への汎化 vs 既知の障害への確実な実行」でトレードオフの対角にある。(Source: [[@2024__OSR__LLexus - an AI agent system for incident management]], [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - **「緩和の閉ループ自動実行」がマイクロサービスから LLM 訓練プロセスへ移植され、同じ不安定性に直面した**: [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] の Agentic Training Intervention は、診断→アクション計画→実行→再検証の閉ループ(サーベイ Lv5 相当)を [[強化ファインチューニング]] の訓練 configuration への介入として実装する。同じ PKU グループが [[MicroRemed]] でマイクロサービス修復に用いた診断条件付き修復の枠組みを訓練障害へ転移したものだが、全体 Mitigation Rate 46.25% かつ Median Severity Change -5.84%(失敗介入が訓練を悪化させうる)と、ここでも「one-shot 介入は不安定」という同じ壁にぶつかる。マイクロサービス緩和で得た「安全に巻き戻せる反復が鍵」という知見(上記)は、訓練介入(checkpoint ロールバック等)でも未だ持ち込まれておらず、対象ドメインを跨いでも緩和の難しさの本質(実行時しか結果が観測できない多段計画)が共通することを示す。(Source: [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]], [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - **緩和策が障害の現れ方を別カテゴリへ転換する**: 緩和は障害を消すだけでなく、現れ方を別カテゴリへ移す場合がある。[[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] の dual-ToR 設計はリンク障害でのタスククラッシュを防ぐが、帯域半減で障害を「性能劣化ケース」へ移す。これは GPU 故障管理の段階的緩和([[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] の可逆・軽量な早期措置)が「不可逆な切り離しを遅らせて様子を見る」設計と表裏で、可用性を保つ緩和がクラッシュ障害を fail-slow/性能劣化へ転換する——緩和の選択が後段の診断対象を fail-stop から fail-slow へ移すことを示す。(Source: [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) - **GPU クラスタの故障管理も「緩和の段階化」に独立に収束している——深刻度に応じた多段アクションで過剰対応を避ける**: SRE/マイクロサービスの緩和とは別ドメインの GPU 訓練/HPC 運用でも、緩和の設計は深刻度ベースの多段エスカレーションへ収れんする。[[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](Aurora)の **multi-strike ポリシー**は、障害の種類と頻度(ストライク数)に応じてリセット → 特定 GPU のみの分離 → ノード切り離しへとアクションを段階的にエスカレーションし、単純なノードドレインに比べて過剰排除を抑えつつ真の故障を特定する。[[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](Amazon)の**段階的緩和**は異常スコアで 3 段に分ける——10% 未満は「検証保留」として監視継続、10–20% は次のチェックポイント到達まで待ってからリセット/再起動、20% 以上は即時に正常プールから除外して代替ノードで再起動。両者に共通するのは、可逆・軽量な早期措置(監視継続・検証保留)を先に置き、不可逆で重い措置(ノード切り離し・再起動)を深刻度が確証されるまで遅らせる順序設計である。これは SRE 側の「安全に巻き戻せる反復が鍵」「過剰対応を避ける」(上記)と同じ設計原理が、ハードウェア故障管理でも独立に現れたものと読める。Guard は早期緩和が軽量・可逆ゆえ偽陽性率 12.4% でも運用コストが限定的と明言し、軽量な早期措置を先に置く価値を裏づける。(Source: [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]], [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]]) - **三大クラウドの実証データが「リプレースメント最多・自己回復最少・ロールバック最速・フィックス最遅」という緩和手段の構造を定量化した**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](Li+ 2022)は 354 件のポストモーテムから 9 種類の緩和手段を分類し、リプレースメント(32%)が最多・自己回復(7.6%)が最少であることを示した(Table VIII)。時間軸では、ロールバックが TTM 中央値 91 分で最速、フィックスが 220 分で最遅。この実証データは、[[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が GenAI クラウドでアドホック修正 22.4%・自己回復 19.7%・ロールバック 15.2% と報告した分類と比較可能な基盤を提供する。クラウドサービス種別(汎用 IaaS/PaaS vs. GenAI)で緩和手段の分布が変化する可能性が示唆される。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **根本原因と緩和手段の強相関は「自動推薦が効く領域」と「均一分散で効かない領域」を峻別する**: Li+ 2022 の Fig.7/8 は、設定ミスにはロールバック(51 件)・リプレースメント(48 件)が集中し、ハードウェア障害にはフィックス(54 件)・リプレースメント(29 件)が多い一方、リソース競合・例外ハンドリング・コンポーネント削除は複数の緩和手段が均一に分散して「正解の推薦が難しい」ことを示す(Finding 10)。自動緩和推薦器([[障害緩和]] サーベイ Lv4)は「強相関ゾーン」では実装可能な近傍問題だが、「均一ゾーン」ではコンテキスト固有の推論が必要になる。本 wiki の障害緩和エージェント評価([[AIOpsLab]]・[[SREGym]])が扱う障害種別がどちらのゾーンに属するかを確認する必要がある。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) ## 未解決の問い - 緩和性能を押し上げるのはリフレクション(反省)かプローブ(情報収集)か。[[MicroRemed]] はリフレクション優位かつ過剰なプロービングが害になり得ると示すが、これはモデルの文脈推論能力に依存する暫定的な結論。モデルが賢くなればプローブの価値は回復するか。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - 反復リフレクションの精度向上は逓減する($T_{max}$ を増やしても頭打ち)。トークン/レイテンシのコストは ThinkRemed で 100K 超まで膨らむ。適応的なプロービング・動的なタイムアウト・選択的なリフレクションで精度を保ちつつコストを抑えるオーケストレーションは設計できるか。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - Configuration Error 緩和は観測可能なリソース異常でなく振る舞いの微妙な不整合として現れ、記号推論とデプロイの意味理解を要する。リフレクションを持つ ThinkRemed でも 60% を超えにくい。設定レベルの推論のボトルネックをどう破るか。ネットワーク系(Loss/Delay)が全モデルで最難な理由(時間依存・サービス間通信グラフの推論)も同根か。(Source: [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]]) - script-based 緩和(Ansible playbook 生成)と plan-based 緩和(rule/policy 駆動の recovery plan)の使い分けはどうあるべきか。[[MicroRemed]] は前者に焦点を絞るが、ソースコードや過去の緩和記録を併用すると更に改善し得ると示唆する。 - 「正しく理解して直す」と「症状のパターン照合でたまたま直る」をどう区別して報酬設計するか([[agentic SRE]]・[[SRE Benchmark]] の報酬ハッキングの問いと共有)。安全制約 [[Transactional No-Regression]] が緩和の誠実性を担保し得るか。 - サーベイの自動化 5 段は単調な梯子(下位を経て上位へ)なのか、それとも対象障害ごとに最適な段が違うのか。例えば設定誤りは script generation(Lv4)が、外部依存の輻輳は assisted questioning(Lv1)止まりが妥当、というように障害クラスと適切な自動化レベルの対応はあるか。([[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]]) - 本番で自己回復が 19.7% を占めるが、緩和エージェントは「何もしないのが最適」というケースを判別できるか。不要な介入はサービスへの副作用を招く。「介入すべきか否か」の判断はエージェント評価の設計対象に含めるべきか。([[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - マイクロサービス緩和の安全制約([[Transactional No-Regression]]・安全な巻き戻しと再試行)を、[[強化ファインチューニング]] の訓練介入(checkpoint ロールバック・ハイパーパラメータ調整)へ持ち込めば、RFT-FM の one-shot 介入の不安定性(Median Severity Change -5.84%)を抑えられるか。緩和対象がサービス状態か最適化ダイナミクスかで、「悪化させない」保証の形はどう変わるか。([[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]]) - 段階的緩和のしきい/ストライク数は最適に設計できるか。[[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] の 10%/20% の異常スコア閾やトリアージ閾(1 週間に 3 回入れば恒久不良)、[[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] の multi-strike のストライク数は、いずれも経験則で最適性の理論的裏付けがない。偽陽性(過剰排除)と偽陰性(劣化の見逃し)、緩和の可逆性/コストを入力に、しきい・ストライク数を原理的に最適化する枠組みはあるか。SRE 側のリフレクション回数 $T_{max}$ の頭打ち(上記)と同根の問題か。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]]) - 「可逆・軽量な早期措置を先に置く」段階化が成立するのは、早期措置のコストが本当に低い場合に限る。[[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] は早期緩和が軽量・可逆ゆえ偽陽性 12.4% でも許容と論じるが、緩和措置自体が不可逆/高コストな障害クラス(persistent fault・設定誤り)では段階化の前提が崩れる。SRE 側で [[Stratus]] が pod 再起動を persistent fault に効かないと明言したのと同じ限界が、GPU 故障管理の段階的緩和にも当てはまるか。(Source: [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]], [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]]) - 性能劣化に転じた障害を、クラッシュ障害と同等の優先度・精度で扱う統合的な診断フロー。([[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]]) ## 関連 - ソース: [[@2024__OSR__LLexus - an AI agent system for incident management]] / [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]] / [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]] / [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] / [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]] / [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] / [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]] / [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]] / [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]] / [[@2025__NSDI__Evolution of Aegis - Fault Diagnosis for AI Model Training Service in Production]] - 概念: [[AIOps]] / [[agentic SRE]] / [[SRE Benchmark]] / [[Transactional No-Regression]] / [[障害予測]] / [[根本原因分析]] / [[インシデント管理]] / [[強化ファインチューニング]] / [[GPUクラスタ運用]] / [[GPUレジリエンス]] / [[ストラグラー]] - エンティティ: [[MicroRemed]] / [[ThinkRemed]] / [[Ansible]] / [[Stratus]] / [[ChaosMesh]] / [[RFT-FM]] / [[Aurora]] / [[Guard]] - 関連 MOC: [[LLM4SRE - MOC]] / [[SRE - MOC]] / [[Project AI4SRE - MOC]] ## 出典 - [[@2024__OSR__LLexus - an AI agent system for incident management]]（§3 設計原理・計画前置の根拠、§4 マルチステップ計画生成・ツール選択・検証、§6.4 コスト分析・図10 オンライン方式との比較） - [[@2025__arXiv__MicroRemed - Benchmarking LLMs in Microservices Remediation]](Abstract, §1, §3, §4, §5, Appendix B.3/F/I/J) - [[@2025__CSUR__A Survey of AIOps in the Era of Large Language Models]](§4.3 Assisted Remediation, Fig.9, §6.1.3 Execution Task Metrics) - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]](Table 1, §3.6) - [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]](§3 TNR, §5 Table 2/3, 付録 C: ITBench pod-restart 分析) - [[@2026__arXiv__SREGym - A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios]](§1, §2) - [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]](§VII Mitigation taxonomy, Figure 8–9, §VIII-A Lessons Learned) - [[@2026__arXiv__Towards Robust LLM Post-Training - Automatic Failure Management for Reinforcement Fine-Tuning]](§V-C Agentic Training Intervention, §VI-F Auto Remediation, Table V) - [[@2025__SC__Fine-grained Automated Failure Management for Extreme-Scale GPU Accelerated Systems]](multi-strike 修復ポリシー:ストライク数に応じたリセット/分離/切り離しのエスカレーション) - [[@2026__MLSys2026__Guard - Scalable Straggler Detection and Node Health Management for Large-Scale Training]](§4.2 段階的緩和:10%=監視継続/中程度=次CPまで待機/20%=即時除外+再起動、偽陽性 12.4% でも軽量・可逆ゆえ許容)