# 運用障害分析 ## 定義 運用障害分析（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層の障害分類体系」を必要とし、従来のクラウド障害分類とは分類軸そのものが異なる**: [[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: [[A Survey on Failure Analysis and Fault Injection in AI Systems]]) - **開発時点の欠陥分類(ODC)は、本番障害の多次元分類が1990年代に既に体系化していた設計原理を、より早い段階から経験的必要十分条件つきで確立していた**: Oppenheimer 2003・Ghosh 2022 の多次元相関分析(「検知失敗×根本原因」「根本原因×緩和戦略」)は、単一次元の集計統計では見えないactionableな洞察を導く点で運用障害分析の方法論的発展として位置づけられる(既出)。[[直交欠陥分類]](ODC、Chillarege 1996)は同じ発想——複数の直交した属性の掛け合わせで初めて実務に効くフィードバックが得られる——を、開発時点の欠陥データに対して先行して体系化しており、しかも属性が「直交性(独立性)・工程間一貫性・製品間均一性」という経験的必要十分条件を満たすかを明示的に検証する枠組みを持つ。運用障害分析側の各分類スキーム(cause×location、root-cause×mitigation、6層障害分類など)はこの水準での属性設計の妥当性検証を行っておらず、ODCの必要十分条件を本番障害分類に輸入できるかは開かれた問いである。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]], [[@2022__SoCC__How to Fight Production Incidents]]) - **「計測ベース解析」対「ポストモーテムのナラティブ分析」という、データの出どころそのものが異なる2つの運用障害分析系譜が1990年代から並存する**: Oppenheimer 2003・Ghosh 2022・Li+ 2022 はいずれも人間が事後に作成したポストモーテム文書(ナラティブ・自由記述)を一次データとし、カテゴリ分類は分析者による事後的な読み込みで行う。これに対し [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]](Iyer & Lee 1996)は、システムに組み込まれたオンライン計装(GUARDIANのイベントログ・MVSのSYS1.LOGREC・VAX/VMSのbugcheckレポート)を主データとし、これを分析者によるダンプ解析つきの技術報告(TPR)で補う「計測ベース解析(measurement-based analysis)」という別系譜を1980〜90年代から確立していた。計測ベース系譜は前処理段階でエラーログの**合体(coalescing、ΔT時間窓内の同種エラーを1事象へ統合)**という、ナラティブ分析には存在しない固有の技術的難所を持つ——1件の障害が短時間に大量の重複ログを生む機械生成データ特有の問題であり、現代のログ収集基盤におけるアラート重複排除・イベント相関の起源にあたる。ポストモーテムのナラティブ分析はこの種の重複除去を意識しなくてよい代わりに、記述の不正確さ(オペレータのナラティブとフォーム入力の矛盾)という別の前処理課題を抱える。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - **計測ベース解析は「再発(recurrence)」を主要な障害構造として定量化する点で、ポストモーテム系譜の障害分類とは異なる軸を持つ**: Oppenheimer 2003・Ghosh 2022・Li+ 2022 の分類スキーム(cause×location、root-cause×mitigation、内部/外部原因)はいずれも個々のインシデントを独立事象として扱い、同一の根本原因が繰り返し障害を起こす「再発」を主要な分析軸に据えていない。Iyer & Lee 1996 は Tandem GUARDIAN の153件のTPRが100件の一意な障害に帰着し、その約72%(110件)が既知障害の再発だったことを示し、「障害の識別数を減らす」ことと「障害の発生回数を減らす」ことが別の改善問題であると論じる。これは、運用障害分析が「原因は何か」だけでなく「同じ原因がなぜ何度も表面化するか」を問うべきだという、ポストモーテム系譜にはあまり明示的でない視点を提供する。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]]) - **「出荷後の現場データの特性とその扱い」という第三の系譜が、計測ベース解析・ポストモーテムのナラティブ分析のいずれとも異なる形でデータ品質問題に向き合う**: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]](Jones & Vouk 1996)は、Iyer & Lee(第8章)のシステム内部計装ログでも、Oppenheimer 2003・Ghosh 2022のポストモーテム文書でもなく、**顧客・フィールド支援要員・問題スクリーナ・保守要員など多様な人間の発生源から集約される問題報告**(Table 11.1に例示される多数のフィールドを持つレコード)を主データとする。この系譜に固有のデータ品質課題は、機械生成ログの重複(第8章のcoalescing問題)でもポストモーテムのナラティブと自由記述の矛盾(Oppenheimer 2003)でもなく、**サイトコード・追跡番号の組織間不一致**(顧客サービス組織とマーケティング/エンジニアリング組織で異なるコード体系を使うと故障とサイトの対応付けが崩れる)、**履歴データの誤破棄**(現在値のみを保持し過去のソフトウェアロード情報を追跡不能にする設計)、**リリースへの故障の誤帰属**(次リリース効果により、旧リリース由来の欠陥が新リリースの出荷を機に発見される)という、時間軸をまたぐ追跡可能性(traceability)の問題である。さらに、稼働の「量」(exposure)を正しく測れないという固有の困難——広域配布ソフトウェアでは稼働時間の直接計測ができず、暦時間で代替すると新リリース導入台数のランピング効果により信頼性の描像そのものが歪む(暦時間ベースでは劣化、稼働時間ベースでは継続的改善という正反対の結論になりうる)——を持つ。これは第8章・第11章のいずれの系譜にも共通する「稼働をどう定量化するか」という論点(第8章はワークロード変数、第11章はカレンダー時間/稼働時間の選択)を、より広い視点で結びつける観察でもある。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]], [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]]) - **フィールドデータ解析の「再発(recurrence)」に相当する構造が、次リリース効果(next-release effect)という異なる形で現れる**: 第8章はTandemの153件のTPRが100件の一意な障害に帰着し約72%が既知障害の再発だったことを示した(既出)。第11章は同種の「同じ根本原因が繰り返し表面化する」現象を、単一リリース内の再発としてではなく、**リリース間をまたぐ現象**として捉える——新リリースの出荷が、旧リリースに潜在していた未発見の欠陥の発見を刺激する「次リリース効果」であり、複数リリースの問題報告頻度分布に、後続リリースの出荷時期に対応した複数のピークが現れる(NASAスペースシャトル搭載飛行ソフトウェアでも同型の現象がドットプロットで確認された)。両者はともに「障害の識別数」と「障害の発生・表面化回数」を区別すべきだという教訓を独立に導いており、運用障害分析における時間軸(単一システムの再発、複数リリースをまたぐ再発)の重要性を補強する。(Source: [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] §11.5.1, §11.7.2) - **オペレータエラーの「実験的再現」という第三の方法論が、ポストモーテムのナラティブ分析とは異なる粒度の知見を生む**: Oppenheimer 2003・Ghosh 2022・Li+ 2022 はいずれも実運用で自然発生したインシデントの事後記録(ポストモーテム)を一次データとするのに対し、[[@2004__OSDI__Understanding and Dealing with Operator Mistakes in Internet Services]](Nagaraja+ OSDI 2004)は21人のボランティアオペレータに三層オークションサービスの保守・診断タスクを実際に行わせ、43回のライブ実験から42件のミスを直接観測する**制御された実験的手法**を取る。これにより、Oppenheimer 2003 が集計レベルで示した「オペレータエラーが支配的原因」という知見の**内訳**(設定ミス24件・誤ったソフトウェア再起動14件、うち19件が即座のスループット低下を招く)を、個々のミスの発生プロセス・原因(誤診断・情報不足・時間切迫)まで踏み込んで記述できる。ポストモーテム系譜が「何が起きたか」を大量サンプルで統計化するのに対し、実験的再現系譜は「なぜそれが起きたか」を少数サンプルで深く追跡する、相補的な方法論であるといえる。(Source: [[@2004__OSDI__Understanding and Dealing with Operator Mistakes in Internet Services]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) - **「エキスパートでもミスを犯す」という実験的知見が、運用障害分析における属人的対策の限界を裏付ける**: Nagaraja+ 2004 は、被験者をnovice/intermediate/expertに分類したところ、**エキスパートも local misconfiguration・start of wrong SW version で無視できない割合のミスを犯した**ことを実験で直接示した(実験数で正規化した発生率、Figure 2)。著者らはこれを「最難関の実験の多くをエキスパートが担当したため」と説明しているが、いずれにせよ「経験を積んだオペレータならミスをしない」という暗黙の前提が実験的に反証された点は、運用障害分析全体における「トレーニング・スキル向上だけでは運用ミスを解消できず、検証(validation)やオフラインテストのようなシステム側の防御機構が必要」という設計方針を裏付ける一次的証拠になる。(Source: [[@2004__OSDI__Understanding and Dealing with Operator Mistakes in Internet Services]]) - **「検証(validation)」は運用障害分析が示す原因分布に対する予防的介入として、緩和(mitigation)や根本原因分析(RCA)とは異なる第三の対応段階を占める**: [[障害緩和]]が扱う対応(ロールバック・インフラ変更等)は障害が顕在化した後の是正行動であるのに対し、Nagaraja+ 2004 が提案する検証基盤は、オペレータのアクションを**本番へ反映する前に**現実的なワークロードで妥当性確認し、ミスの影響を未然に遮断する。プロトタイプは観測ミスの66%(28/42件)を検知でき、offline testing(40%)を明確に上回った。これは、運用障害分析が明らかにした原因分布(設定ミスが支配的)を踏まえた**事前予防アーキテクチャ**の具体例であり、事後対応の緩和戦略研究([[@2022__SoCC__How to Fight Production Incidents]])と組み合わせることで、障害ライフサイクル全体([[クラウド障害ライフサイクル]])をカバーする視点を提供する。(Source: [[@2004__OSDI__Understanding and Dealing with Operator Mistakes in Internet Services]]) - **FA(Failure Analysis)の手続きを「インシデントレポートを入力として fault パターンを要約する工程」と明示的に定式化した点は、本 concept が蓄積してきたポストモーテムベースの運用障害分析と同じデータ源(事後インシデント記録)に依拠する**: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 2 Background and Definitions]] の図3は、Fault が活性化し Failure が検知される(①)→ エンジニアが観測された挙動に基づき緩和し発生時刻・影響・緩和策を含むインシデントレポートを作成する(②)→ FA がこのインシデントレポートを入力として再発する種別・箇所などの fault パターンを要約する(③)、という 3 段階の手続きを示す。これは本 concept が [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] や [[@2022__SoCC__How to Fight Production Incidents]] で確認してきた「事後インシデント文書を一次データとして原因分布を体系化する」という運用障害分析の方法論的骨格と同型であり、AI システムに固有の分類軸(§4〜9 の6層)を持ち込みつつも、FA そのものの手続き(インシデント記録 → パターン要約)はクラウドシステムの運用障害分析と共通することを示す。(Source: [[@2025__TOSEM__A Survey on Failure Analysis and Fault Injection in AI Systems - Chapter 2 Background and Definitions]], [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]]) ## 未解決の問い - 計測ベース解析(オンラインログ主体)とポストモーテムのナラティブ分析(人間の事後記述主体)は、同一システムに対して適用した場合にどの程度異なる障害分布・原因分布を導くか。両者を同一システムで突き合わせた実証研究は本 wiki には未収載である。 - カレンダー時間ベースの障害率と稼働時間ベースの障害率が正反対の信頼性描像を与える(第11章 図11.8)という現象は、web スケールサービスの「デプロイ頻度あたりの障害率」対「リクエスト数あたりの障害率」という現代的な指標選択にどう対応づけられるか。 - Iyer & Lee 1996 が定量化した「72%が再発」という構造は、Oppenheimer 2003・Ghosh 2022・Li+ 2022 が扱う web スケールサービスのポストモーテムでも同程度に成立するか。現代の障害追跡システム(Jira・PagerDuty等)は根本原因の再発をどの程度追跡可能な形で記録しているか。 - ODCの「直交性・工程間一貫性・製品間均一性」という経験的必要十分条件は、本番障害の多次元分類スキーム(Oppenheimer 2003のcause×location、Ghosh 2022のroot-cause×mitigation)にそのまま輸入できるか。輸入できるとすれば、どの既存分類軸が条件を満たしておらず再設計が必要か。 - 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 アプリケーションの失敗モードをポストモーテムに記録する場合、幻覚・コンテキスト喪失・ツール呼び出しエラー・コスト起因劣化のような意味的/設計的カテゴリを、従来のインシデント原因カテゴリ（コード、設定、依存、インフラ）とどう二重符号化するか。 - Nagaraja+ 2004 の検証(validation)アプローチはノード粒度の仮想ネットワーク隔離(Mendosus)を前提とする。コンテナ・Kubernetesが普及した現代のクラウドネイティブ環境では、より細粒度なサービスメッシュレベルのシャント・トラフィックシャドウイング(例: カナリアデプロイのトラフィックミラーリング)によって同種の「本番反映前検証」がどこまで一般化・自動化されているか。現代のAIOps研究(本 wiki の[[障害緩和]]・[[カナリアテスト]])との接続は未収載。 - Nagaraja+ 2004 は「意図通りに実行されたが不要だった操作」(不要な再起動・不要なハードウェア交換)を検証原理上検出できないと認めている。これらは Oppenheimer 2003 やGhosh 2022 が分類する原因カテゴリのどこに位置づけられるか、また LLM エージェントによる自動運用(本 wiki の[[エージェント運用安全性]])において同種の「無害に見えるが不要な操作」をどう検知できるか。 ## 関連 - [[インシデント管理]] — 障害のライフサイクル全体（検知→トリアージ→診断→緩和）を扱うプロセス。運用障害分析はその事後的な知見蓄積に相当する。 - [[根本原因分析]] — 個々の障害の根本原因を特定する技法。運用障害分析は RCA の結果を集約して統計的傾向を導出する。 - [[障害注入]] — 運用障害分析で特定された障害パターンは、障害注入ベンチマークの障害モデルの根拠となる。 - [[障害緩和]] — 運用障害分析は緩和技法の有効性を事後評価する枠組みを提供する。 - [[LLMアプリケーション信頼性]] — LLM アプリケーション固有の失敗モードを、運用障害分析の分類軸へ接続する概念。 - [[直交欠陥分類]] — 開発時点の欠陥を多次元・直交属性で分類するODC。運用障害分析の多次元分類スキームと同型の設計原理を、経験的必要十分条件つきで先行して体系化した。 - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]] — オンライン計装(イベントログ)とダンプ解析つき技術報告(TPR)を主データとする「計測ベース解析」という、ポストモーテムのナラティブ分析とはデータの出どころが異なる運用障害分析の系譜。エラーログ合体(coalescing)・再発(recurrence)の定量化を特徴とする。 - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]] — 顧客・フィールド支援要員経由で人手集約される問題報告を主データとする「フィールドデータ解析」の系譜。サイトコード不一致・履歴データ誤破棄・次リリース効果というデータ品質課題と、カレンダー時間/稼働時間の選択が信頼性の描像を左右する問題を特徴とする。 - [[フィールドデータ解析]] — 本概念の一部(フィールドデータの収集・エクスポージャー測定に焦点を当てた下位概念)を切り出した専用ページ。 - [[@2004__OSDI__Understanding and Dealing with Operator Mistakes in Internet Services]] — Oppenheimer 2003 が示したオペレータエラーの支配的原因を、21人の被験者による43回のライブ実験で個々のミスの発生プロセスまで実験的に再現・特性化し、本番反映前に検証する validation 基盤を提案した論文。 ## 出典 - [[@2003__USITS__Why Do Internet Services Fail and What Can Be Done About It]] - [[@2004__OSDI__Understanding and Dealing with Operator Mistakes in Internet Services]](21人の被験者オペレータによる43回のライブ実験、42件のミスの実験的特性化、本番反映前検証(validation)基盤の提案、66%のミス検知率) - [[@2022__SoCC__How to Fight Production Incidents]] - [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] - [[A Survey on Failure Analysis and Fault Injection in AI Systems]](AI システム6層の障害分類体系化、142 本のサーベイ、各層の FA/FI ギャップテーブル) - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 9 Orthogonal Defect Classification]](開発時点の欠陥に対する多次元直交分類、ODCの必要十分条件) - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 8 Measurement-Based Analysis of Software Reliability]](稼働システムのオンラインログ・TPRを用いた計測ベース解析、データ合体、再発の定量化、Tandem/MVS/VMSの実測) - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 11 Field Data Analysis]](顧客・フィールド支援要員経由の問題報告を用いたフィールドデータ解析、次リリース効果、カレンダー時間/稼働時間の対比、IBM/Hitachi/NASAの実測)