# 運用障害分析 ## 定義 運用障害分析（operational failure study / failure data analysis）は、本番システムの障害事後報告や障害追跡データベースを体系的に収集・分類し、障害原因の分布・修復時間・緩和技法の有効性を実証的に明らかにする取り組みである。Gray (1986) の Tandem システム障害研究が嚆矢であり、[[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] がインターネットサービスに拡張した。障害を原因種別（ハードウェア・ソフトウェア・オペレータエラー・ネットワーク・環境等）と場所（フロントエンド・バックエンド・ネットワーク等）の 2 次元で分類し、コンポーネント障害からサービス障害への伝搬率や修復時間 (TTR) を定量化する。目的は、研究・設計の労力をどこに集中すべきかを実データで示すことにある。(Source: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) ## 横断的知見 - **「非コード系根本原因が過半数」という発見は 2003 年の知見を web スケールで更新・拡張する**: [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] はオペレータエラーを最大カテゴリ（Online 33%、Content 36%）とし設定ミスが主体と報告した。[[@2022__SoCC__How to Fight Production Incidents]] は Microsoft Teams の 152 件で同様に**コードバグ 27% に対して非コード系 60%** を示す——デプロイエラー 13.2%・インフラ問題 15.8%・依存障害 16.4% は 2003 年の「オペレータエラー」の細分化に対応する。「人間起因の障害が常に過半数」という構造的持続性が、web スケール・10 億人級サービスに対しても成立することを独立に確認した。(Source: [[@2022__SoCC__How to Fight Production Incidents]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - **「緩和の 90% がコード変更なし」は障害分析に「緩和戦略」という新次元を加える**: Oppenheimer (2003) は障害原因と TTR のみを扱い、緩和の種別分布を体系化しなかった。Ghosh et al. (2022) は初めて緩和戦略を 7 カテゴリに分類し、ロールバック(22.4%)・インフラ変更(21.1%)が 90% 超を占めてコード修正(7.9%)が少数であることを示す。「障害を直す」のではなく「障害の影響を速く止める」緩和行動の実態が、同種の実証研究としては初めて定量化された。(Source: [[@2022__SoCC__How to Fight Production Incidents]]) - **多次元相関分析が「単一次元では見えない洞察」を体系化するアプローチとして確立**: Gray (1986) と Oppenheimer (2003) は各軸を独立に集計する単一次元分析に留まった。Ghosh et al. は Chi-square 検定で独立因子を排除した上で「検知失敗 × 根本原因」「根本原因 × 緩和戦略」「緩和失敗 × 教訓」などの多次元相関を分析し、「コードバグの 70% は監視なし → テストが有効」「設定バグの 47% がロールバックで緩和 → 設定変更の多くはテスト可能」など **actionable な洞察**を導いた。この多次元設計は今後の障害データ分析の方法論的な発展として位置づけられる。(Source: [[@2022__SoCC__How to Fight Production Incidents]]) - **GenAI サービスの障害はプライバシー制約が診断速度を低下させるという新たな構造的課題を持つ**: [[Anthropic]] は 2025 年 8〜9 月のポストモーテム（[[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]）で、「内部評価はユーザーが体験した品質劣化をキャプチャできなかった」「プライバシー保護のためエンジニアが問題のあるインタラクションにアクセスできず診断が遅延した」という 2 つの構造的課題を明示した。これは [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が GenAI インシデントの緩和時間が非 GenAI 比 1.83 倍になると定量化した根本的理由の一つを、当事者視点から裏付ける一次資料である。従来の障害分析（Oppenheimer 2003、Ghosh 2022）が扱わなかった「プライバシー vs 可観測性のトレードオフ」が、GenAI サービスの障害管理における新たな設計次元として浮上している。(Source: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]]) - **LLM 本番障害の評価カバレッジ問題は従来のサービス監視とは異なる課題類型を生む**: 従来のサービス障害（応答時間の悪化・エラー率の上昇）は客観的メトリクスで自動検知できる。LLM の品質劣化（誤ったトークン選択・劣化した文章品質）は主観的・文脈依存的であり、統計的ベンチマークで捉えにくい。Anthropic 事例では内部評価がユーザー報告の品質劣化を事前にキャプチャできなかった。この「評価カバレッジ問題」は [[AIOps]] における自動検知の限界の GenAI 固有形態として位置づけられる。(Source: [[@2025__Anthropic Engineering Blog__A Postmortem of Three Recent Issues]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **LLM アプリケーションの失敗分析は、原因分布だけでなく「失敗がパイプラインのどこで発生するか」を記録する必要がある**: 従来の運用障害分析はハードウェア、ソフトウェア、設定、依存障害、オペレータエラーといった根本原因カテゴリを重視してきた。[[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] は、LLM アプリケーションでは推論内部、入力/コンテキスト境界、ツール/API/マルチエージェント通信、コスト制約というパイプライン上の発生位置が診断上重要だと示す。これは [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]] が扱う GenAI サービス本番インシデント分類を、アプリケーション設計レベルへ細分化する視点である。(Source: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]], [[@2026__ICSE__An Empirical Study of Production Incidents in Generative AI Cloud Services]]) - **全ライフサイクル視点(発生→検知→特定→緩和)を一貫して分析した最初の三大クラウド研究が TTM 支配という構造を明示した**: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]](Li+ 2022)は AWS・Azure・Google Cloud から 354 件のポストモーテム(2011〜2021 年)を収集し、先行研究の多くが一部フェーズのみを扱っていたのに対して初めて 4 段階全体を定量化した。MTTD=16.9 分・MTTI=77.8 分・MTTM=304.2 分・MTTR=572.8 分という実測値は、**緩和フェーズが TTR の 53% を占める**という構造を実証し、自動緩和への投資 ROI が最も高いことの根拠を与えた。設定ミスが最多内部原因(31.6%)、ハードウェア障害が最多外部原因(17.0%)という根本原因分布は、Oppenheimer 2003・Ghosh 2022 が「非コード系根本原因が過半数」と報告した構造を三大クラウドで再確認する。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **変更(アップグレード・メンテナンス)起因障害と通常運行障害で根本原因分布が逆転する**: Li+ 2022 は変更中の障害の 84.7% が内部原因(設定ミス主体)であるのに対し、通常運行中の障害の 56.3% が外部原因(ハードウェア障害・過剰フロー)であることを示す。この「変更中=内部原因支配、通常運行=外部原因支配」という非対称性は、Oppenheimer 2003 の「オペレータエラーが支配的」という知見を原因×運行状態の 2 次元に精緻化したものとして読める。Ghosh 2022 が Microsoft Teams でデプロイエラーを独立カテゴリとして設定(13.2%)したのも同じ非対称性の別表現である。(Source: [[@2022__ISSRE__Going through the Life Cycle of Faults in Clouds - Guidelines on Fault Handling]]) - **AI システムの障害分析は「6層の障害分類体系」を必要とし、従来のクラウド障害分類とは分類軸そのものが異なる**: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]]（Yu+ TOSEM 2025）は 142 本の論文から AI システムの障害を Service / Model / Framework / Toolkit / Platform / Infrastructure の6層に分解し、各層固有の障害種別（データ品質・概念ドリフト・ハイパーパラメータ障害・テンソル不整合・同期障害・NCCL 障害・ビットフリップ等）を分類体系化した。従来の運用障害分析（Oppenheimer 2003 の原因6分類、Ghosh 2022 の根本原因7分類、Li+ 2022 の内部/外部2分類）がサービスを単一の障害単位として扱うのに対し、AI システムでは「同じ設定ミスでも Framework 層か Platform 層かで障害の顕在化メカニズムが異なる」ことが定量的に示された。例えば AI Framework 層での環境設定障害はビルド/コンパイル失敗として顕在化するが、AI Platform 層での設定ミスはリソース競合やジョブスケジューリング障害として現れる。これはクラウド障害分析の分類軸を AI 固有の多層構造に拡張した最初の体系的試みである。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]]) ## 未解決の問い - Oppenheimer et al. (2003) が提唱した「業界横断の障害データリポジトリ」は、20 年以上経った現在も実現していない。クラウドプロバイダごとの障害報告は部分的に公開されるが、標準化されたスキーマによる横断比較は依然として困難である。航空業界の ASRS（Aviation Safety Reporting System）に相当する仕組みはインターネットサービス業界に成立し得るか。 - 2003 年時点でオペレータエラーが支配的であったが、Infrastructure as Code、GitOps、自動化の進展により、現代の大規模サービスでも同じ傾向が続くか。「人間のエラー」の形態が設定ミスからポリシー定義ミスや自動化スクリプトのバグに変容している可能性がある。 - 障害追跡データベースのフォーム入力の不正確さ（オペレータのナラティブとの矛盾）は、LLM による自動分類・構造化で解消し得るか。([[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - Ghosh et al. (2022) は完全なポストモーテムを持つインシデントのみを分析対象とし、約 35% を除外している。不完全なポストモーテムのインシデントに固有のパターン（例: 前例のない障害で記録が残りにくい）があるとすれば、分析結果にどのような偏りが生じるか。([[@2022__SoCC__How to Fight Production Incidents]]) - Ghosh et al. は Microsoft Teams というコミュニケーションサービス単社の知見を示す。データベース・AI 推論・ストリーミングなど異なる特性を持つクラウドサービスで同様の多次元分析を行えば、根本原因分布や多次元相関にどのような差異が現れるか。([[@2022__SoCC__How to Fight Production Incidents]]) - LLM アプリケーションの失敗モードをポストモーテムに記録する場合、幻覚・コンテキスト喪失・ツール呼び出しエラー・コスト起因劣化のような意味的/設計的カテゴリを、従来のインシデント原因カテゴリ（コード、設定、依存、インフラ）とどう二重符号化するか。 ## 関連 - [[インシデント管理]] — 障害のライフサイクル全体（検知→トリアージ→診断→緩和）を扱うプロセス。運用障害分析はその事後的な知見蓄積に相当する。 - [[根本原因分析]] — 個々の障害の根本原因を特定する技法。運用障害分析は RCA の結果を集約して統計的傾向を導出する。 - [[障害注入]] — 運用障害分析で特定された障害パターンは、障害注入ベンチマークの障害モデルの根拠となる。 - [[障害緩和]] — 運用障害分析は緩和技法の有効性を事後評価する枠組みを提供する。 - [[LLMアプリケーション信頼性]] — LLM アプリケーション固有の失敗モードを、運用障害分析の分類軸へ接続する概念。 ## 出典 - [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] - [[@2022__SoCC__How to Fight Production Incidents]] - [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] - [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems]](AI システム6層の障害分類体系化、142 本のサーベイ、各層の FA/FI ギャップテーブル)