# インシデント重大度評価 Navigation: [[index]] | [[インシデント管理]] | [[障害傾向分析]] ## 定義 インシデント重大度評価（Incident Severity Assessment）とは、発生したインシデントが組織・サービス・ユーザーにどの程度の影響をもたらすかを定量的・多次元的に評価するプロセスである。単一の「重大度レベル（Critical / Major / Minor）」だけでなく、影響の性質（法的・財務・ユーザー信頼・インフラ波及）を複数のフラグで表現し、パースペクティブ別（財務 / 広報 / 品質）に重み付け加算スコアを算出することで、組織内の異なるステークホルダーが同じデータから各自の観点で優先課題を読み取れるようにする。 [[Sue Lueder]]（[[Google]]）の SREcon 2015 発表が、フラグベース・スコアリング方式の具体的実装例として公開した（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）。 ## Severity Flags の4次元 Google の実装では以下の4次元でフラグを設定する: | 次元 | フラグ例 | |---|---| | **法的・コンプライアンス** | プライバシー侵害、セキュリティリスク/侵害 | | **ユーザー影響** | ユーザー信頼失墜、ユーザーが先に発見、ユーザー可視、有料顧客影響、悪報道 | | **財務** | 売上減少（Revenue > $）、売上損失（Revenue > 0） | | **サービス種別** | 基盤サービス、高トラフィックサービス、戦略サービス、生命維持サービス | 各フラグに重みを乗じて合算することで、Finance / Public Relations / Quality の3パースペクティブ別スコアを生成し、担当者・部門が自分の関心軸でトップ課題を把握できる。 ## 重大度測定の課題 - **チーム間の正規化**: 同じ障害でもチームによって重大度の評価基準が異なり、横断比較が困難。 - **シグナル対ノイズ比**: 大量インシデントのなかで本当に重要なものを埋もれさせないようにする必要がある。 - **リソース制約**: 重大度評価に費やせる時間とリソースが限られるため、評価プロセス自体も軽量化が必要。 - **Boiling Frog Problem（茹でガエル問題）**: 少しずつ悪化する指標が「正常」に見えてしまう認知バイアス。長期トレンドを可視化して対処する。 - **Squeaky Wheels（うるさいホイール問題）**: 声の大きいユーザーや特定チームの障害が過大評価され、静かに影響が大きい障害が見落とされるリスク。 ## 横断的知見 - VOCE（FASE 2025）はアラートインシデント分析において system layer / impact scope / severity の3因子で 93-95% 一致を達成しており、severity フラグがアラート分析でも有効な信号であることを示す（Source: [[アラートインシデント分析]]、[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）。 - **Severity は交渉可能な変数プロキシであり、Duration と相関しない**: [[Courtney Nash]]（[[@2023__SREcon23Americas__Far from the Shallows]]）は The Void データベース（1 万件超の公開インシデントレポート）の分析から、複数社の Severity 別インシデント Duration を比較し「Severity と Duration は相関しない」ことをグラフで示した。Severity の構成要素として顧客影響・修正コスト・緊急度の変数プロキシ、自動化されることも主観的に割り当てられることもあると整理し、[[John Allspaw]] の「評点(ratings)のようなもの—いかに過度な単純化か」という言葉を引用して Severity が測定値ではなく社交的調整物であることを強調した。Google の 4 次元フラグ × 重み付けスコア方式（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）は Severity の多次元化によってこの問題を部分的に緩和するが、Allspaw・Nash の批判は単一数値化されたレベル（Sev1/Sev2 等）に向けられており、フラグスコアリングでも「各フラグの主観的割り当て」の問題は残る。(Source: [[@2023__SREcon23Americas__Far from the Shallows]] p.013, p.021) - **単一レベル方式の Severity にも「意図的な過大分類」という緩和策があり、メトリクスゲーミング問題を 2016 年時点で明示的に警告していた**: [[Gareth Eason]]（[[Facebook]]、[[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]]）は、単純な SEV1/2/3 レベル方式を採りながらも「リスクがあれば SEV1 に倒し、後から格下げする」という運用ポリシーで過小分類を防いでいる。さらに「SEV 数を減らすことを成功指標にすると、エンジニアが SEV1 を SEV2/SEV3 に過小分類したり報告自体をしなくなったりするインセンティブを生む」と明示的に警告した。この警告は、Nash・Allspaw が指摘する「Severity は社交的調整物であり交渉可能」という問題を、Facebook が 2016 年の実務者視点から先取りして認識していたことを示す一次証言であり、Severity を単一 KPI 化することの危険性についての最古級の明文化された警告として本 wiki に位置づけられる。(Source: [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]]) - **可用性ベースの重大度評価は「正しさ（correctness）」を見落とし、Google の財務・法務フラグとは異なる第5の軸を示唆する**: [[Niall McCarthy]]（[[Afterpay]]、[[@2023__SREcon23EMEA__The Incident Is The Way - Using Your Incidents to Win Reliability Investment]]）は、エラー率ゼロ・応答時間良好であっても「請求書は期限どおりだが金額が誤り」「ページはロードされるが古いオファーを表示」「ジョブはエラーなく完了するが6時間遅延」という3例が実害のあるインシデントの定義を満たすと指摘した。Google の4次元フラグ（法的・ユーザー影響・財務・サービス種別、[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）は障害の「影響先」を分類するが、McCarthy の correctness 軸は障害の「性質」（可用性でなく正しさの毀損）を問う点で異なる次元であり、既存のフラグ体系に「正しさフラグ」を追加する余地を示唆する。(Source: [[@2023__SREcon23EMEA__The Incident Is The Way - Using Your Incidents to Win Reliability Investment]]) - **「Severity は社交的調整物であり交渉可能」という Nash・Allspaw の批判に対し、McCarthy は評価の重心を「意図」から「結果（ユーザーへの実害）」へ移すことで交渉可能性を減らす具体策を提示する**: Nash（[[@2023__SREcon23Americas__Far from the Shallows]]）が Severity を「測定値ではなく社交的調整物」と批判したのに対し、McCarthy は「意図と結果はソフトウェアにおいて相関しない」ため重大度判断は結果ベースであるべきだと主張し、「6,000人のユーザーが1日半ログインできなかったという事実は組織内の文脈が何であれ同じように真実だ」という具体例を挙げた。これは Eason の「意図的な過大分類ポリシー」（過小評価を防ぐ運用的対策）とは異なり、評価基準そのものを「エンジニアの意図」という交渉可能な変数から切り離す構造的対策である点で、Nash が指摘した問題への直接的な処方箋として位置づけられる。(Source: [[@2023__SREcon23EMEA__The Incident Is The Way - Using Your Incidents to Win Reliability Investment]], [[@2023__SREcon23Americas__Far from the Shallows]] p.021) - **Severity を「測定値」から「組織的問題のカナリア」へ読み替える視点は、Nash の「社交的調整物」論をさらに一歩進め、severity の対立自体を診断シグナルとして活用する運用論を提示する**: [[Emily Ruppe]]（[[Jeli]]、[[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]]）は、severity を巡る議論の長期化は severity 設計そのものの欠陥ではなく、過小評価(underleveling)・過大評価(overleveling)・ステークホルダーへの説明不足・組織の未成熟さといった組織的問題(sociotechnical issue)の兆候であり、「severity はそれらの問題を歌うカナリアだ」と位置づけた。Nash・Allspaw の「Severity は社交的調整物であり交渉可能」という批判が severity の測定不能性を指摘する静的な分析であるのに対し、Ruppe は「severity を巡る摩擦そのものを定期的に振り返り、組織課題を特定する材料として使う」という動的な運用手法を提示しており、両者は「severity の主観性」という同じ現象を診断(Nash)と治療(Ruppe)として補完する関係にある。また Ruppe は Google・Facebook 型の複雑な多次元マトリクス化（"incident math"）を明確に否定しており、これは Google の4次元フラグ×重み付けスコア方式（[[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]]）が抱える複雑性への対抗案とも読める。(Source: [[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]]) - **実験的証拠が「severity 分類に費やした時間」と「解決時間」の負の関係を示す**: [[Hamed Silatani]]（[[Uptime Labs]]、[[@2024__SREcon24EMEA__Incident Groundhog Day]]）の20名参加のステージドワールド実験では、全員が同じシナリオを体験した結果、SEV1 と分類した参加者（約8名）と SEV2 と分類した参加者（約8名）で解決時間に有意差はなかった。一方、重大度を巡る議論に時間を費やした参加者は実際のインシデント解決に使える時間が短くなった。Silatani は「SEV2 の参加者の方が SEV1 より速く解決した」と述べ、Ruppe の SREcon 発表を直接引用している。これは Ruppe の「severity を巡る摩擦は組織的問題のカナリア」という運用論に対する、**実験的インシデントシミュレーションからの実証的補強**として位置づけられる——ただしシナリオが1件かつ参加者数が20名と少ないため統計的結論は限定的。(Source: [[@2024__SREcon24EMEA__Incident Groundhog Day]]) ## 未解決の問い - 重み付けの設定方法: Finance / PR / Quality の各重みはどのように決定・更新するか。 - 重大度とインシデント解決優先度の連動: Boiling Frog を検出したとき、自動的に優先度を上げる仕組みはどうあるべきか。 - AIOps との統合: LLM ベースの自動分類と人間によるフラグ設定をどう組み合わせるか。 - McCarthy の correctness 軸（正しさの毀損）は Google の4次元フラグや VOCE の3因子（system layer / impact scope / severity）とどう統合できるか。既存の severity スコアリングに「correctness フラグ」を第5の次元として追加すべきか、それとも別の評価軸として並置すべきか。 ## 関連 - [[インシデント管理]] — 重大度評価はインシデント管理の上流工程 - [[障害傾向分析]] — 重大度スコアを用いたトップ課題の優先順位付け - [[アラートインシデント分析]] — アラートレベルでの severity 計算との接点 - [[アラートランキング]] — severity から actionability への目的関数の拡張（TraceArk） - [[クロスインシデント分析]] — 「数値はコンテキストなしでは意味がない」というメトリクスゲーミング警告の系譜 - [[Gareth Eason]] — SEV1/2/3 の意図的過大分類バイアスとメトリクスゲーミング警告を提示 - [[Emily Ruppe]] — severity を組織的問題のカナリアとして読み解く運用論を提示 - [[Jeli]] — [[PagerDuty]] 傘下でインシデント分析製品を提供する企業 - [[Hamed Silatani]]、[[Uptime Labs]] — staged world 実験による実証的補強 - [[インシデントシミュレーション]] — Silatani の実験設計と結果の詳細 ## 出典 - [[@2015__SREcon15__What Brought Us Down - Outage Trend Analysis at Google]] - [[@2016__SREcon16__Incident Response @ FB, Facebook's SEV Process]] - [[@2023__SREcon23EMEA__The Incident Is The Way - Using Your Incidents to Win Reliability Investment]] - [[@2024__SREcon24 Americas__What Is Incident Severity, but a Lie Agreed Upon?]] - [[@2024__SREcon24EMEA__Incident Groundhog Day]]