# プロアクティブ障害管理 ## 定義 プロアクティブ障害管理(proactive fault management, PFM)は、障害(failure)が発生する前にその予兆を捉え、対策を事前に打つことで可用性を向上させる運用枠組みである。古典的フォールトトレランス(発生後の冗長化・復旧)では成長するシステム複雑性・動的性に追従できないという問題意識から、autonomic computing・recovery-oriented computing・self-*properties などの研究と並走して提示された(Source: [[A Survey of Online Failure Prediction Methods]] §1.2)。 [[A Survey of Online Failure Prediction Methods]] の Figure 2 によれば、PFM は次の **4 段階**から成る: 1. **オンライン障害予測**(online failure prediction): runtime monitoring から「将来の failure 発生確率」を二値判定または連続スコアで出力する。本連鎖の入口で、本 wiki の [[障害予測]] の主題。 2. **診断**(diagnosis): 予測が示した「障害の可能性」に対し、必要なら追加で原因コンポーネントや fault の種類を特定する。チェックポインティング等は予測の二値出力だけで起動できるが、コストの高い対策はこの診断結果が要る。 3. **アクションスケジューリング**(action scheduling): 採用すべき対策(microreboot・rejuvenation・rollback・rerouting 等)と実行タイミングを決める。Candea+ 2004 は「短い restart 時間ほど許容できる偽陽性率が高い」関係を定量化した(本論文 §1.2 で引用)。 4. **アクション実行**(action execution): 分散環境でのオンライン再構成・データ同期など、実装上の挑戦が多い段階。 > [!note] スコープの注意 > [[A Survey of Online Failure Prediction Methods]] 自身はこの 4 段階のうち **1.オンライン障害予測のみ**を扱うサーベイで、残り 3 段階(診断・スケジューリング・実行)はそれぞれ独立の研究領域として明示的にスコープ外とする(§1.2)。本 concept はこの 4 段階を一望する索引役として置く。 ## 横断的知見 - **「予測 → 診断 → 対策決定 → 実行」の 4 段階は、AIOps の「検知 → 箇所特定 → RCA → 緩和」と部分的に対応するが順序と動機が違う**: AIOpsLab/SREGym の reactive ループ([[AIOps]])は「障害発生後」に検知から動き始めるのに対し、PFM のループは「障害発生前」に予測から動き始める。診断は PFM では予測結果のサニティチェック+対策選択のための入力という従属的役割だが、AIOps では Mean Time To Recovery を支配する主役。「予測の品質はモデルだけで決まらず、後段のスケジューリング・実行で許容できる偽陽性率の関数になる」という Candea+ 2004 の関係は、AIOps の緩和エージェントが偽陽性に弱い(STRATUS・Bits AI SRE 系)という近年の観察とも整合する。(Source: [[A Survey of Online Failure Prediction Methods]] §1.2, [[A Survey of AIOps Methods for Failure Management]] §4) - **「prevention 10.6% / remediation 2.5%」という研究密度の偏りは PFM のうち予測以外の 3 段階の手薄さに対応する**: Notaro et al. 2021 が 1,086 件中 100 件で定量化した failure management 領域の研究密度は detection 33.7% / RCA 26.7% / online prediction 26.4% に対し prevention 10.6% / remediation 2.5%。Salfner+ 2010 の PFM 4 段階で言えば「予測」のみが厚く、「診断〜実行」の側はそもそも研究が薄い。15 年経っても 4 段階を統合した end-to-end の PFM システムが希少なのは、論文・産業ともに「予測」段で止まる構造が継続しているため。(Source: [[A Survey of Online Failure Prediction Methods]] §1.2, [[A Survey of AIOps Methods for Failure Management]] §5.1) - **PFM の現代的具現化は単一エージェントではなく複数経路の組合せになりつつある**: [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]] が「予測 → 説明」の経路を作る一方、Google の **Adaptive Progressive Rollouts** は「予測なしでデプロイ前検証によって障害発生確率を下げる」経路、[[Detectr]] は「障害発生後だがテレメトリより早い user feedback で検知」経路をそれぞれ作る。Salfner+ 2010 の 4 段階のうち「予測」自体を回避する経路(rollout 検証・早期検知)も含めて、現代の PFM は複数の前倒し戦略の合成として現れる。(Source: [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]], [[A Survey of Online Failure Prediction Methods]] §1.2) - **AI インフラの PFM は「予測なしの定期検証」と「予測ありの選択的検証」のハイブリッドに着地する**: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] の SuperBench は Cox-Time モデルでノードのインシデント確率を予測しつつ、確率が閾値超のときだけベンチマーク部分集合を選んで stress テストを走らせる(§3.3)。これは Salfner+ 2010 の 4 段階のうち「予測 → アクションスケジューリング(検証部分集合の選択)→ 実行(ベンチマーク走行)」を一本化した実装例で、Adaptive Progressive Rollouts(予測なし検証)と PAGER(予測のみ)の中間に位置する。Azure シミュレーションでフルセット検証比 MTBI 1.11×・検証時間 92.07% 削減と、予測ありの選択的検証が予測なしの全検証を **MTBI でも上回る**ことを示した点が、PFM の経済合理性に関する新しいデータポイント。(Source: [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]], [[A Survey of Online Failure Prediction Methods]] §1.2) - **「本番前のテストによる潜在バグ検知」は Salfner+ 2010 の 4 段階が扱わない、もう一つのプロアクティブ経路である**: [[A Survey of Online Failure Prediction Methods]] の PFM 4 段階(予測→診断→スケジューリング→実行)はいずれも**本番稼働中**のオンライン監視を前提とするが、[[Rainmaker]]([[Agentic Failure Management of Cloud Systems]]第2章)は**本番投入前**の開発・テスト段階で、クラウドサービスとの REST API 呼び出しに一時的障害を注入し、まだ発生していない障害を静的に検知する。これは「オンライン障害予測」と対になる「オフライン障害予防」の経路であり、同論文の thesis statement は明示的に PFM を二極化する: 本番前は体系的テストで failure surface を縮小し(Rainmaker)、本番中は安全ガードレール付き AI で自律管理する([[Stratus]])。Adaptive Progressive Rollouts(予測なしのデプロイ前検証)や [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]](予測ありの選択的検証)がインフラのハードウェア健全性を対象とするのに対し、Rainmaker はアプリケーションコードのエラー処理ロジックを対象とする点で、同じ「予測を経由しないプロアクティブ経路」の中でも対象レイヤーが異なる。(Source: [[Agentic Failure Management of Cloud Systems]], [[A Survey of Online Failure Prediction Methods]] §1.2) - **「本番前テストによるオフライン予防」は、対象を1回のAPI呼び出しに限定することで初めて push-button 化を達成できた——スコープの限定自体がプロアクティブ経路の実用性の前提になっている**: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]](Rainmaker、[[@2023__NSDI__Push-Button Reliability Testing for Cloud-Backed Applications with Rainmaker]] と数値照合済みで矛盾なし)は、1回の REST API 呼び出しインタラクション(とその SDK リトライ)に閉じた障害モデルだからこそ、わずか4種のポリシー P1–P4 と2種の汎用オラクル(Exception/Assertion)だけで taxonomy 全体を網羅でき、11 アプリケーション・73 件のバグを誤検知率 1.96% で検出する push-button 性を実現した。著者ら自身、複数の相関する API 呼び出しにまたがるバグは「actively investigating」と述べるにとどめ、対象外としている(§2.9)。これは Salfner+ 2010 の PFM 4 段階が「オンライン障害予測」1段階に意図的にスコープを絞ることで実用的なサーベイたり得ているのと同型の設計判断であり、**プロアクティブ経路が実用段階に達するには、対象範囲を狭めて自動化の完全性を優先する必要がある**という共通パターンが、本番前テスト(Rainmaker)と本番中予測(Salfner+ 2010)という異なる時間軸のプロアクティブ経路の両方で観測される。(Source: [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]] §2.9, [[A Survey of Online Failure Prediction Methods]] §1.2) - **RouterOPS の「大胆に予測し、慎重に復旧する」原則は、Salfner+ 2010 の PFM 4 段階(予測→診断→対策決定→実行)をネットワークルーティング層で 1 エージェントに畳み込んだ具体例であり、Candea+ 2004 の偽陽性率と復旧アクション破壊性のトレードオフに対する明示的な設計解を提供する**: [[@2026__SIGCOMM Posters and Demos__Predict Boldly, Recover Cautiously : Fast On-Router Route Anomaly Prediction and Recovery|RouterOPS]] の self-checking/neighbor-checking(EWMA + 残差集約によるオンライン障害予測)→ decision guard(ヒステリシスによる持続性確認 + 対象 next hop/prefix の特定という診断的サニティチェック)→ ローカル復旧アクション(loop-free バックアップ next hop への切り替え、対策スケジューリングと実行の一体化)という設計は、PFM の 4 段階を単一のルーターエージェント内に統合した実例である。decision guard が「異常状態がヒステリシス後も持続」することを復旧発動の必要条件とする設計は、Candea+ 2004 が定量化した「復旧アクションが短時間・低コストであるほど許容できる偽陽性率が高い」という関係の裏返し——ルート切り替えという相対的に破壊的な復旧アクションだからこそ、閾値超過の瞬間ではなく持続性まで要求する保守的設計——として読める。本 concept が未解決の問いとして挙げてきた「診断・スケジューリング・実行を 1 つのエージェントに畳めるか」に対し、RouterOPS はネットワークルーティングという限定ドメインでの肯定的な実例を提供する。(Source: [[A Survey of Online Failure Prediction Methods]] §1.2, [[@2026__SIGCOMM Posters and Demos__Predict Boldly, Recover Cautiously : Fast On-Router Route Anomaly Prediction and Recovery]]) - **Notaro et al. 2021 の 5 カテゴリ分類では「予測」に加え「予防」という、Salfner+ 2010 の 4 段階モデルが扱わない予測非依存の proactive 経路が独立カテゴリとして存在する**: [[A Survey of Online Failure Prediction Methods]] の PFM 4 段階は「予測」を起点とするが、[[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] の failure avoidance(予測的回避)は online failure prediction(第4.2章、177 件・26.4%)と failure prevention(第4.1章、71 件・10.6%)を対等な姉妹カテゴリとして置く。failure prevention のサブカテゴリのうち software defect prediction (SDP) は「将来の障害確率」でなく「現在のコードの欠陥密度」を推定するため予測(prediction)を経由せず、fault injection はシステムを能動的にストレステストして脆弱性を発見する点で予測とは無関係である。これは本 concept が既に記録した「予測を経由しないプロアクティブ経路」(Adaptive Progressive Rollouts・Rainmaker)の存在を、Notaro et al. の taxonomy が独立に「failure prevention」という正式カテゴリとして体系化していたことを示す——2010 年の Salfner+ サーベイの段階では明示的にスコープ外とされていた領域が、2021 年の Notaro et al. では FM 5 カテゴリの一つとして定量化されている。ただし checkpointing・software rejuvenation は resource exhaustion prediction のような予測モデルを内部で使う場合があり(§4.1.3–4.1.4)、「予測非依存」が failure prevention 全体の性質ではなく SDP・fault injection に限られる点には注意が要る。(Source: [[A Survey of Online Failure Prediction Methods]] §1.2, [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] §4, §4.1.1–4.1.2) - 1997年のプロアクティブ監視システム(Hood & Ji, RPIネットワーク)は、SNMPで収集したMIB変数をAR(2)特徴量へ変換し、ベイジアンネットワークでNetwork/IF/IP/UDPの階層に統合することで、障害の具体的仕様を持たずにファイルサーバ無応答の約12分前に異常を検知した。障害の事前モデルなしで未知障害を検知するという設計目標は、現代のAIOps文献が繰り返し掲げる目標と同一である。(Source: [[@1997__IM__Automated Proactive Anomaly Detection]]) ## 未解決の問い - **failure prevention(71 件・10.6%)と online failure prediction(177 件・26.4%)という Notaro et al. 2021 の研究密度の非対称は、「予測」への研究投資が「予防」より 2.5 倍以上厚いことを意味するが、この非対称は Salfner+ 2010 の PFM 4 段階のどこに位置づくか未整理である**: PFM の 4 段階(予測→診断→対策決定→実行)は online failure prediction のみを直接対応させるが、failure prevention の SDP・fault injection・rejuvenation・checkpointing は「予測」段の外側にある独立の予防的介入であり、PFM の 4 段階モデルに追加の「予防(prevention)」段階を導入すべきか、それとも別軸の分類体系として並置すべきかは未解決。(Source: [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] §4) - **RouterOPS の「1 エージェント統合」は、ネットワークルーティングという形式的不変条件が明確なドメイン([[NetOps]] が指摘する到達可能性・隔離・ループ自由等)だからこそ成立している可能性がある**: 同様の予測→診断→対策決定→実行の統合は、不変条件が明確でないマイクロサービス/クラウド層の AIOps でも成立するか、それともドメイン固有の安全制約(loop-free backup next hop、ルーティングポリシー)が無ければ危険な設計になるか。([[@2026__SIGCOMM Posters and Demos__Predict Boldly, Recover Cautiously : Fast On-Router Route Anomaly Prediction and Recovery]]) - 「予測 → 診断 → 対策決定 → 実行」を end-to-end で 1 つの自律ループにする実装は 2026 年時点でもまれである。AIOps の reactive ループに対し PFM ループはなぜスケールしないのか。予測モデルの偽陽性率の閾値を「対策コスト × 復旧時間」と動的に連動させる action scheduling は、ML モデルだけでは設計しにくく業務・意思決定の側の知識を要するためか。 - 「予測の lead time `t_l` は対策に必要な warning time `t_w` より長くなければならない」という Salfner+ 2010 の制約(§2.2)は、microreboot のような対策が `t_w` 自体を圧縮することで予測の有効性そのものを拡張するという循環関係にある。`t_w` を最小化する recovery 設計と `t_l` を最大化する予測モデルのどちらに投資すべきかの定量的判断基準は確立していない。 - Notaro et al. 2021 が指摘する「prevention 10.6%」の研究の薄さは、LLM エージェントの登場で逆転するのか。LLM が PFM のスケジューリング段(対策と実行タイミングの決定)を担えるなら、Salfner+ 2010 が「3 つの別領域」とした診断・スケジューリング・実行は 1 つのエージェントに畳めるはずだが、現状の [[PAGER]] や [[Bian Que]] は予測層・説明層・実行層を別モジュールに分けている。(Source: [[A Survey of AIOps Methods for Failure Management]] §5.1) ## 関連 - 上位 concept: [[ディペンダビリティ]] - 子・隣接 concept: [[障害予測]] / [[障害緩和]] / [[ソフトウェアエイジング]] / [[AIOps]] / [[agentic SRE]] / [[プロアクティブ検証]] / [[グレイ障害]] / [[障害注入]] / [[NetOps]] - ソース: [[A Survey of Online Failure Prediction Methods]] / [[A Survey of AIOps Methods for Failure Management]] / [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]] / [[@2024__USENIX ATC__SuperBench - Improving Cloud AI Infrastructure Reliability with Proactive Validation]] / [[Agentic Failure Management of Cloud Systems]] / [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]] / [[@2026__SIGCOMM Posters and Demos__Predict Boldly, Recover Cautiously : Fast On-Router Route Anomaly Prediction and Recovery]] / [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]] / [[@1997__IM__Automated Proactive Anomaly Detection]] - 関連 entity: [[Felix Salfner]] / [[Miroslaw Malek]] / [[Humboldt University of Berlin]] - 関連 MOC: [[structures/AIOps - Failure Detection - MOC]](該当 MOC があれば人間が承認時に手動で逆リンク追加) ## 出典 - [[A Survey of Online Failure Prediction Methods]] §1.2(PFM の 4 段階・Figure 2、Candea+ 2004 の偽陽性率と restart 時間のトレードオフ引用) - [[A Survey of AIOps Methods for Failure Management]] §4・§5.1(prevention/remediation の研究密度の薄さ) - [[@2026__AAAI__PAGER - Proactive Monitoring Agent for Enterprise AI Assistant]](Introduction、System Overview: 予測本体と説明層の分離) - [[@2026__SIGCOMM Posters and Demos__Predict Boldly, Recover Cautiously : Fast On-Router Route Anomaly Prediction and Recovery]](RouterOPS — self-checking/neighbor-checking + decision guard による PFM 4 段階の 1 エージェント統合) - [[@2026__PhD__Agentic Failure Management of Cloud Systems - Chapter 2 Reliability Testing for Cloud-Backed Applications]](Rainmaker — §2.9 単一REST呼び出しへのスコープ限定がpush-button化を可能にしたと明言) - [[@2021__TIST__A Survey of AIOps Methods for Failure Management - Chapter 4.1 Failure Prevention]](§4 failure avoidance の 2 分類=online failure prediction/failure prevention と研究密度、§4.1.1–4.1.2 SDP・fault injection が予測を経由しない予防経路である点)