プロアクティブ障害管理 - yuuk1's Digital Garden

# プロアクティブ障害管理 ## 定義プロアクティブ障害管理(proactive fault management, PFM)は、障害(failure)が発生する前にその予兆を捉え、対策を事前に打つことで可用性を向上させる運用枠組みである。古典的フォールトトレランス(発生後の冗長化・復旧)では成長するシステム複雑性・動的性に追従できないという問題意識から、autonomic computing・recovery-oriented computing・self-*properties などの研究と並走して提示された(Source: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2)。 [[@2010__ACM CSUR__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] スコープの注意 > [[@2010__ACM CSUR__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: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2, [[@2021__TIST__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: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2, [[@2021__TIST__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]], [[@2010__ACM CSUR__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]], [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2) ## 未解決の問い - 「予測 → 診断 → 対策決定 → 実行」を 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: [[@2021__TIST__A Survey of AIOps Methods for Failure Management]] §5.1) ## 関連 - 上位 concept: [[ディペンダビリティ]] - 子・隣接 concept: [[障害予測]] / [[障害緩和]] / [[ソフトウェアエイジング]] / [[AIOps]] / [[agentic SRE]] / [[プロアクティブ検証]] / [[グレイ障害]] - ソース: [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] / [[@2021__TIST__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]] - 関連 entity: [[Felix Salfner]] / [[Miroslaw Malek]] / [[Humboldt University of Berlin]] - 関連 MOC: [[structures/AIOps - Failure Detection - MOC]](該当 MOC があれば人間が承認時に手動で逆リンク追加) ## 出典 - [[@2010__ACM CSUR__A Survey of Online Failure Prediction Methods]] §1.2(PFM の 4 段階・Figure 2、Candea+ 2004 の偽陽性率と restart 時間のトレードオフ引用) - [[@2021__TIST__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: 予測本体と説明層の分離)