# 障害傾向分析 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 モデル（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]]）。 ## 未解決の問い - 障害パターン自動分類（FaultProfIT 等）が産業規模で定着した場合、GQM フィードバックモデルの「Organize」フェーズはどのように変化するか。Socialize フェーズへの投資比率はさらに高まるか。 - 収集すべきデータソースの選定と負荷管理: 多様なソースを統合する際の自動化コストとデータ品質のトレードオフはどう最適化するか。 - 根本原因カテゴリの組織間一貫性: チーム・プロダクトをまたいで同じカテゴリ定義を維持するための仕組みは何か。 - 傾向分析の定量的効果検証: 分析による改善施策の効果をどう測定し、分析プログラム自体の価値を示すか。 ## 関連 - [[インシデント管理]] — 傾向分析の入力となるインシデント管理ライフサイクル - [[根本原因分析]] — 傾向分析内の中心的分析軸 - [[ポストモーテム]] — 個別障害からの学習（傾向分析の補完） - [[インシデント重大度評価]] — 傾向分析内の重大度フラグ・スコアリング - [[変更起因インシデント]] — 根本原因カテゴリ「Deployment Planning」として登場 - [[structures/AIOps - Fault Localization - MOC]] — AIOps 文脈での障害分析との関連 ## 出典 - [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]