# 障害傾向分析 Navigation: [[index]] | [[インシデント管理]] | [[根本原因分析]] ## 定義 障害傾向分析（Outage Trend Analysis）とは、複数のプロダクション障害・インシデントデータを横断収集・整理・分析し、システム的な傾向（根本原因の分布・タイムライン特性・インパクト規模）を把握することで、システム・プロセス・ツールの改善を計画的に実施するアプローチである。単発のポストモーテムが個々の障害から学ぶのに対し、傾向分析は多数の障害から統計的・構造的なパターンを抽出して組織全体の信頼性向上につなげる。 [[Sue Lueder]]（[[Google]] SRE Program Manager）は 2014 年にこのアプローチを Google 全プロダクトへ展開し、GQM（Goal Question Metric）フィードバックモデルを適用してプログラムを設計・運用した（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）。 ## GQMフィードバックモデル 障害傾向分析のサイクル骨格として、次の5段を採用する: 1. **Goal Question Metric（GQM）** — 測定目標（例:「インシデント解決時間でベストインクラスになる」）を設定し、それを問いとメトリクスに分解する。GQM の設計はプログラム初期に最大工数を要する。 2. **Collect** — 内部コミュニケーション（メール/IRC）・バグトラッカー・インシデント管理ツール・ポストモーテム・カスタマーレポート・ソーシャルメディア・報道記事など多様なソースからデータを収集する。 3. **Organize** — 収集データを Technical Impact / Financial Impact / User Impact / Timeline / Root Causes / Communications の次元で整理し、分析可能な構造化データにする。 4. **Analyze** — タイムライン特性・根本原因頻度・重大度分布などを分析し傾向を把握する。 5. **Socialize** — 分析結果を関係ステークホルダーに継続的に届け（Socialize Early and Often）、改善施策の立案・実行・測定につなげる。プログラム成熟後は Socialize が最大の継続工数になる。 ## 統計的トレンド判定(ソフトウェア信頼性工学の視点) Google の GQM モデルおよび FaultProfIT は、複数の障害・インシデントを横断集計して**根本原因やインパクトのカテゴリ分布**の傾向を追う。これに対して、より古典的なソフトウェア信頼性工学(SRE = software reliability engineering、SRE = site reliability engineering とは別系統の学術分野)は、**単一システムの故障発生率という時系列そのもの**が統計的に見て増加・減少・定常のいずれであるかを検定する手法を発展させてきた。 [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 10 Trend Analysis]](Kanoun and Laprie, 1996)は、この時系列トレンド判定を「劣加法性(subadditive property)」という数学的性質として定義する。累積故障数関数 $H(t)$ が区間 $[0,T]$ 上で劣加法的($H(t_1)+H(t_2)\ge H(t_1+t_2)$)であれば区間全体で信頼性成長、超加法的であれば劣化とみなし、その差分(劣加法性因子 $A_H(t)$)の局所的な増減から**局所トレンド変化点**を特定する。実務上最も使われる **Laplace検定**は、統計量 $u(k)$ の分子が実は劣加法性因子 $A_H(k)$ そのものであることが数学的に示され(Source: ch.10 §10.3.1.3)、$u<0$ なら成長・$u>0$ なら劣化・$-2$〜$+2$ なら定常という単純な符号判定で運用できる。5システムへの適用例では、開発フェーズの移行・テスト種別の変更・仕様変更・新規ユーザーの追加が局所トレンド変化の典型的な原因として実証されている。 ## 横断的知見 - **障害パターン分類の自動化は傾向分析の対象インシデントを量的に拡大する**: Google の GQM モデル（SREcon 2015）では分析対象インシデントのサンプリングが人的リソースの制約で深刻度上位に偏っていたが、FaultProfIT（ICSE-SEIP 2024）による Huawei Cloud での実装では全 10,000 件超を自動プロファイリングし、軽微インシデント（S4/S5）の傾向も週次で可視化できるようになった。手動 GQM サイクルが「Organize」コストを Socialize の前提とするのに対し、自動分類は Organize を大幅に自動化してサイクル全体を加速する。(Source: [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]], [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]) - Socialize フェーズへの投資は、SRE だけでなく開発・製品・法務など広範なステークホルダーを巻き込むことで初めて組織全体の改善に結びつく。SRE 視点だけに限定することが失敗パターンの一つである（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）。 - データスキーマは最初から柔軟に設計・維持することが重要で、「分かると思っていたものが違う」という発見のためにデータに耳を傾ける余白が必要だとされる（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）。 - **「傾向分析」という同じ語が指す対象が、SRE(site reliability)実務とソフトウェア信頼性工学の学術系譜とで全く異なる粒度にある**: Google の GQM モデル・FaultProfIT はいずれも「多数の障害イベントを横断して根本原因・インパクトのカテゴリ分布がどう推移するか」を問う——分析単位はインシデントの**集団**であり、時系列上のどのカテゴリが増減しているかという離散的な分類問題に近い。一方 Handbook ch.10 が扱うトレンド解析は「単一システムの故障発生率という連続的な時系列が、統計的に見て有意な増加・減少トレンドを持つか」を問う——分析単位は故障の**発生時刻そのもの**であり、Laplace検定・劣加法性因子という数理統計の道具を使う。前者は「何が起きているか(カテゴリ)」、後者は「起きている頻度がどう変化しているか(レート)」を問うており、両者は補完関係にある。GQM モデルの「Analyze」フェーズにレート変化の検定を組み込めば、カテゴリ別のトレンドをより厳密に判定できる可能性がある。(Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 10 Trend Analysis]] §10.2–10.3) - **Handbook ch.10 の「局所トレンド変化」概念は、GQM モデルの Socialize フェーズが暗黙に前提とする「原因ごとの継続的モニタリング」に、統計的な裏付けを与えうる**: GQM モデルは Socialize フェーズで分析結果を継続的にステークホルダーに届けることを重視するが、いつ・どの変化が「報告に値するシグナル」で、いつが単なるノイズかを判定する統計的基準は示さない。Handbook ch.10 が区別する「局所トレンド変化(local trend change、$A_h(T_L)=0$ の点)」と「過渡的・一時的挙動(transient/temporary behavior、ノイズに起因し劣加法性因子の符号には現れない変動)」という2分法は、まさにこの「報告すべき変化」と「無視してよい揺らぎ」を区別する数理的基準を提供する。SRE 実務の傾向分析プログラムが誤検知(過剰な Socialize)や見逃し(過少な Socialize)を減らすうえで、応用可能性のある橋渡しである。(Source: [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]], [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 10 Trend Analysis]] §10.2.3–10.2.5) ## 未解決の問い - 障害パターン自動分類（FaultProfIT 等）が産業規模で定着した場合、GQM フィードバックモデルの「Organize」フェーズはどのように変化するか。Socialize フェーズへの投資比率はさらに高まるか。 - 収集すべきデータソースの選定と負荷管理: 多様なソースを統合する際の自動化コストとデータ品質のトレードオフはどう最適化するか。 - 根本原因カテゴリの組織間一貫性: チーム・プロダクトをまたいで同じカテゴリ定義を維持するための仕組みは何か。 - 傾向分析の定量的効果検証: 分析による改善施策の効果をどう測定し、分析プログラム自体の価値を示すか。 - Handbook ch.10 のLaplace検定・劣加法性因子のような数理統計的なレート変化検定は、GQM モデルの Analyze フェーズに実装可能か。カテゴリ別インシデント数の時系列に対して局所トレンド変化点を自動検出できれば、Socialize すべきタイミングの客観的な基準になりうるが、本ページのソースだけでは実装例が確認できない。 - Handbook ch.10 の劣加法性因子は単一システムの故障発生時刻という連続時系列を前提とするが、SRE 実務のインシデントデータは離散的なカテゴリラベル(根本原因・重大度)を伴う。カテゴリ別に時系列を分けて劣加法性因子を計算する場合、カテゴリごとのデータ数が少なくなることで検定の検出力がどう低下するかは未検討。 ## 関連 - [[インシデント管理]] — 傾向分析の入力となるインシデント管理ライフサイクル - [[根本原因分析]] — 傾向分析内の中心的分析軸 - [[ポストモーテム]] — 個別障害からの学習（傾向分析の補完） - [[インシデント重大度評価]] — 傾向分析内の重大度フラグ・スコアリング - [[変更起因インシデント]] — 根本原因カテゴリ「Deployment Planning」として登場 - [[ソフトウェア信頼性成長モデル]] — 統計的トレンド判定の先の「成長モデルの当てはめ」を扱う隣接概念 - [[信頼性成長]] — 劣加法性因子が判定対象とする現象そのもの - [[structures/AIOps - Fault Localization - MOC]] — AIOps 文脈での障害分析との関連 ## 出典 - [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]] - [[@2024__ICSE-SEIP__FaultProfIT - Hierarchical Fault Profiling of Incident Tickets in Large-scale Cloud Systems]] - [[@1996__McGrawHill__Handbook of Software Reliability Engineering - Chapter 10 Trend Analysis]](§10.2–10.3、劣加法性とLaplace検定)