# Agentic Failure Management of Cloud Systems - Chapter 1: Introduction > 次: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]] | 全体: [[Agentic Failure Management of Cloud Systems]] ## 要約 第 1 章は本論文全体の導入章であり、個別の手法・実験は持たない。クラウドシステムの信頼性問題を人手中心(human-centric)な運用慣行として位置づけ、これを自律化するための 4 つの課題を提示し、その課題それぞれに対応する 4 つの貢献(Rainmaker・RCACopilot・STRATUS・AIOpsLab)をクラウドインシデントライフサイクルに沿って配置する(§1)。 ## 問題設定 現代クラウドシステムの信頼性は死活的であり、数分の停止でも大きなユーザー影響と金銭的損失を招く[1][2]。多大なエンジニアリング・研究努力にもかかわらず[3]–[6]、クラウドシステムは障害を未然に防ぐことにも、発生後に検知・箇所特定・緩和を迅速に行うことにも依然として苦戦している[7]。 その中心的な理由は、信頼性エンジニアリングが今なお人手中心であることだ[8][9]。クラウドインシデントは典型的に「検知 → トリアージ → 診断 → 緩和」というライフサイクルを進行し[10]–[13]、ほぼすべての段階で人間が深く関与する。開発者は許容・対処すべき一過性障害(transient failure)を手作業で見積もるが、テストは一過性障害の空間を網羅しきれない。インシデントが本番に到達すると、オンコールエンジニア(OCE)はノイズの多いテレメトリを精査し、どのアラートに対応すべきか、どのツールを使うべきか、どの緩和経路を辿るべきかを判断しなければならない。障害がクラウドシステムの常態である以上、この human-in-the-loop な実務は障害の発生速度に追いつけない。 本論文はここから、クラウド障害管理はインシデントライフサイクル全体――本番到達前の潜在バグ予防から、本番で発生した障害の安全な緩和まで[14][15]――で自律化されるべきであり、かつその進展は測定可能でなければならない、と主張する。この目標の達成には、以下の 4 つの課題を解く必要がある。 1. **予防(pre-incident)**: AWS S3・Azure Storage・CosmosDB のようなクラウドサービスへの依存が深まる「クラウドネイティブ」な実務は、従来のソフトウェア障害を超えた信頼性上の課題をもたらす。HTTP リクエストは経路上のどの地点でも失敗しうるうえ、一過性エラーは SDK 側で不透明に再試行され、アプリケーションからは単一の API 呼び出しに見えても同じ論理操作が複数回実行されることがある。この結果、エラー処理経路は巨大かつ深くネストした空間を形成するが、開発・テスト中に稀にしか発生しない障害下でしか行使されず、潜在バグが本番に紛れ込み、大規模化した一過性エラーがそれを引き起こして停止に至る。障害注入(fault injection)とカオスエンジニアリングはこうしたバグを事前に暴く自然な手段だが[16]–[21]、既存ツールの多くはクラウドサービス自体を対象とし、アプリケーション側は対象にしない。粗い境界での障害注入(サービス全体を落とすなど)か、テスト側に多大な障害注入用の配線を要求するかのいずれかであり、結果としてアプリケーションは現実的な一過性障害モデルの下でほとんどテストされていない。 2. **診断(diagnosis)**: 障害発生後の最初の作業は、数百のマイクロサービスにまたがる分散トレース・ミリ秒粒度のメトリクス・トラフィック規模で増大するログという大量のノイズを含むテレメトリの中から根本原因を見つけることである。診断は今日なお大部分が手作業・場当たり的であり、個人の経験、品質にばらつきのあるランブック、世代・サービスをまたいで伝わりにくい暗黙知(tribal knowledge)に依存する。LLM は有望な進路を提供する――大量データを解析し、関連信号を見分け、簡潔な説明を生成でき、新規・進化するインシデントにも適応できる[22][23]。インシデント診断への応用は増えつつあるが[24]–[26]、既存システムは典型的に単一の情報チャネルしか扱えず、経験豊富な OCE のように複数情報源の証拠を統合する構造を欠く。また全テレメトリを素朴に LLM に投入すると、無関係なデータのロングテールでコンテキスト予算を使い果たす一方、モデルはクラウドインシデント管理特有のドメイン知識も欠いている。 3. **緩和(mitigation)**: 診断は何が問題かを特定するが、サービスを復旧しない。緩和はシステム状態を(しばしば不可逆に)変更するため、診断より安全性の確保が根本的に難しい。誤った緩和アクションは、既に劣化したシステムをさらに深い障害や完全な停止へ追い込みうる。近年の LLM ベースエージェントは自律的な緩和に着手し始めているが[27]–[30]、安全性に焦点を当てるものは少なく、エージェントがライブシステムに何をしてよいか、システム状態がアクションの下でどう変化するかについての形式的保証を提供しない。 4. **評価(evaluation)**: AI エージェントの急速な台頭は、それを評価する能力を追い越してしまった。既存の AIOps ベンチマークは、範囲が狭い(静的な事前収集データ上の異常検知など単一タスク)か、特定のアプリケーションドメインに限定されるかのいずれかが多く、大半はエージェントが複数ステップにわたって計画・行動するために必要なライブかつインタラクティブな設定を欠く。動的に推論・行動する LLM ベースエージェントは、それを試験するハーネスの能力を上回ってしまっている。 これら 4 つの課題が本論文全体の構成を規定する(§1)。 ## 提案手法(本論文の構成と 4 システムの位置づけ) **Thesis statement(§1.1)**: 現代クラウドシステムの自律的トラブルシューティングは、インシデント管理ライフサイクルの両端における体系的な改善によって実用化できる。すなわち (1) 本番前は、体系的テストで潜在バグを検知することで障害面(failure surface)を縮小し、(2) 本番中は、安全ガードレール付きの AI によって自律的障害管理を可能にする。 4 つの貢献(§1.2)は、この主張に沿ってクラウドインシデントライフサイクルの各段階に配置される。 1. **[[Rainmaker]](予防段階)**: クラウドベースの障害モデルの下でエラー処理がどう破綻するかを調査し、「エラー処理なし」「無関係な例外送出」「無言の意味論的違反(silent semantic violation)」「状態分岐(state divergence)」の 4 パターンからなるバグ taxonomy に蒸留する。この taxonomy を基に、HTTP 層で現実的な一過性クラウド障害を注入する push-button 型信頼性テストツール Rainmaker を提示する。Rainmaker は既存のテストスイートにコード変更なしで組み込め、taxonomy 化したバグパターンをカバーする 4 種の障害注入ポリシーを用い、クラウドサービス API の一意な呼び出し箇所のみを選択的に対象としてテストを扱いやすく保つ。11 個の広く使われる .NET アプリケーション全体で新規バグ 73 件を発見し、うち 55 件が確認、51 件が上流開発者によって修正され、誤検知率は 1.96% だった。 2. **[[RCACopilot]](診断段階)**: 本番インシデントの根本原因を突き止めるため、LLM の推論をクラウドインシデント管理に適応させた AI 拡張の根本原因分析システム。アラート種別ごとの受信インシデントハンドラを、スコープ切替・クエリ・緩和という 3 種の再利用可能アクションから合成して多源(multi-source)診断データを収集し、プロンプト予算に収まるよう LLM でデータを要約したうえで、過去インシデントに対する最近傍検索により自動 chain-of-thought プロンプティングを駆動して根本原因カテゴリを予測し説明を生成する。実運用インシデントデータセット上で micro-F1 スコア 0.766 を達成し、古典的機械学習ベースラインや素朴な LLM アプローチを大きく上回りつつ、オンコールの時間的制約下でも使える速度を維持する。 3. **[[Stratus|STRATUS]](緩和段階)**: 自律 SRE のための LLM ベースマルチエージェントシステム。検知・診断・緩和・巻き戻し(undo)の 4 種の専門エージェントを決定的な状態機械で編成し、クラウドを Agent-Cloud Interface を通じてエージェントに露出する。中核は [[Transactional No-Regression]](TNR)であり、古典的トランザクション意味論に基づく形式的安全仕様である。TNR は、失敗した緩和は必ず巻き戻せること、システムの外部から見える深刻度が障害検知時点のベースラインを超えて悪化しないことを保証する。writer-exclusivity スケジューリング・Kubernetes の状態収束原理上に構築したスタックベースの undo 機構・トランザクションごとの有界なリスクウィンドウで TNR を実装する。TNR は agentic SRE を「うまくいくことを願うだけの試み」から「安全な探索ループ」へと変える。2 つのベンチマークの緩和問題で STRATUS はそれぞれ 69.2%(9/13)・50.0%(9/18)を解決し、複数の LLM バックエンドにわたり SOTA の agentic ベースラインを少なくとも 1.5 倍上回る。 4. **[[AIOpsLab]](評価基盤)**: LLM ベース SRE エージェントを評価する共通かつ厳密なベンチマークとして、検知・箇所特定・根本原因分析・緩和というクラウドインシデントライフサイクル全体にわたり LLM ベースエージェントを評価する初の end-to-end ベンチマークスイート。各評価シナリオを形式化し、現実的なマイクロサービスデプロイメント、表層症状にとどまらない障害ライブラリ、クラウドの複雑さをエージェントから抽象化する Agent-Cloud Interface(ACI)、問題の提示・実行・評価方法を標準化する Orchestrator を提供する。場当たり的だった SRE エージェント評価を再現可能・比較可能な実験に変え、STRATUS と上記ベースラインを評価するハーネスとして機能する。 章構成(§1 末尾)は、第 2 章 Rainmaker、第 3 章 RCACopilot、第 4 章 STRATUS、第 5 章 AIOpsLab(STRATUS とベースラインの評価に用いたベンチマーク)、第 6 章 結論と今後の課題、の順である。 ## 考察・限界 第 1 章自体は導入章であり著者自身の実験結果は持たないが、本文の記述からは本論文のスコープ設定に関わる論点が読み取れる。ライフサイクルの記述では「検知 → トリアージ → 診断 → 緩和」の 4 段階を挙げる一方、4 つの貢献は「予防・診断・緩和・評価」の軸で構成されており、**トリアージと本番検知(detection)は独立した貢献としては立てられず、AIOpsLab のベンチマークタスク(detection・localization を含む)の中に評価対象として折り込まれる**にとどまる(§1、§1.2 の AIOpsLab 節)。また、4 つの課題の記述はいずれも「既存手法の限界」として述べられており(障害注入ツールの粗さ、診断システムの単一チャネル依存、緩和エージェントの安全性保証の欠如、ベンチマークの静的・単一タスク性)、これら自体は第 1 章の主張の根拠であって、後続各章の実験による限界の記述ではない。 ## 関連 - [[Agentic Failure Management of Cloud Systems]] — 本論文のハブ entity。 - [[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]] — 第 2 章 Rainmaker の出版論文版。 - [[@2024__EuroSys__Automatic Root Cause Analysis via Large Language Models for Cloud Incidents]] — 第 3 章 RCACopilot の出版論文版。 - [[@2025__NeurIPS2025__STRATUS - A Multi-agent System for Autonomous Reliability Engineering of Modern Clouds]] — 第 4 章 STRATUS の出版論文版。 - [[@2025__MLSys2025__AIOpsLab - A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds]] — 第 5 章 AIOpsLab の出版論文版。 - [[クラウド障害ライフサイクル]] — 本章が組み立てるインシデントライフサイクル(検知・トリアージ・診断・緩和)の概念的土台。 - [[AIOps]] / [[agentic SRE]] / [[根本原因分析]] / [[障害注入]] / [[障害緩和]] — 各章が本格的に深掘りする概念。本章はこれらを 1 本のライフサイクルとして接続する俯瞰的立場を取るにとどめる。 ## 出典 - .raw/theses/phd-chen-2026-agentic-failure-management/chapters/ch-01.txt(PDF p11–15、§1・§1.1・§1.2)