# インシデントメトリクス Navigation: [[index]] | [[インシデント管理]] | [[グッドハートの法則]] ## 定義 インシデントメトリクスとは、インシデント管理プロセスの健全さ・有効性を定量的・定性的に評価するための指標群である。インシデントは低頻度かつ複雑な社会技術的イベントであるため、単純な平均値ベースの指標(MTTR・インシデント件数など)は統計的に不堅牢であり、かつ[[グッドハートの法則]]的な逆インセンティブを誘発する。有効な指標設計には、まず「インシデント管理プロセスの成功とは何か」を目標レベルで定義し、そこから逆算して複数の視点から指標を選ぶサイクルが必要である。(Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]) ## なぜ MTTR・インシデント件数が機能しないか - **MTTR の統計的問題**: インシデント件数が少なく標準偏差が大きい場合、MTTR の変化のほぼすべてが統計的ノイズになる。[[Štěpán Davidovič]] が *Incident Metrics in SRE*([[wiki/entities/Incident Metrics in SRE|Incident Metrics in SRE]])で統計分析により明示した。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]) - 具体的には、全インシデントを実際に 10% 短縮しても MTTR の差がゼロ以下になる試行が 3 社で 38%・40%・20% を占め、15 分以上の改善が見える確率は 49%・50%・64% にとどまる。逆にインシデントを一切変えていなくても 30 分以上の「改善」が 19%・23%・10% の確率で観測される。標準偏差が平均の 2 倍前後(例: 平均 2h 26m に対し標準偏差 5h 16m)であることがこの結果を規定する。(Source: [[@2021__OReilly__Incident Metrics in SRE]]) - **代替統計への逃げ道も塞がれている**: 中央値・95 パーセンタイル・幾何平均・継続時間の合計のいずれでも、実用的な件数では信頼区間が 10% の変化を包含する。95 パーセンタイルは最も稀で最悪のインシデントに引きずられるためむしろ悪化する(N=1,000 でも ±3〜5 時間)。(Source: [[@2021__OReilly__Incident Metrics in SRE]]) - **MTTx が機能する条件**: 量が確保でき分散が低い場合(Backblaze が公開するモデル単位で数万台規模のハードディスク信頼性統計、配信システムの平均レイテンシ)、および継続時間が従来の 20% になるような劇的な変化。ただし後者は他の手段でも明らかであり、MTTx を使う理由にはならない。(Source: [[@2021__OReilly__Incident Metrics in SRE]]) - **MTTR の逆インセンティブ**: MTTR を下げる最も簡単な方法は「同じインシデントを繰り返して素早く修正する」こと。深い根本原因の修正は MTTR を上昇させる。 - **インシデント件数の問題**: 「件数を減らせ」というプレッシャーは、低重大度インシデントを「スパイシーなバグ」として申告外しするインセンティブを生む。重大度指標の逆インセンティブとも連動し、本当の重大度ランクで申告することへの躊躇を増やす。 - **逆説的帰結**: インシデント管理が成熟すると、本当の修正により系は複雑になる。したがって MTTR が上昇することが「学習している」証拠でありうる。(Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]) ## 推奨される測定カテゴリ インシデント管理プロセスを「目標ごと」に分解して指標を当てる: | 目標 | 測定例 | |---|---| | オンコールツールの健全さ | ツール操作ミス率・使いにくさ起因の誤通報数 | | オンコール持続可能性 | 深夜ページ数、シフト長、フェアネス知覚サーベイ | | インシデントが真剣に扱われる | ステートマシン完走率、自発的ポストモーテム率、IC 不在率 | | インシデント対応の質 | 役割使用率、感情分析(自信・準備感) | | 顧客コミュニケーション | 高重大度通知タイムライン、顧客フィードバック | | 事後学習と改善 | アクションアイテム速度、繰り返しインシデント率、複雑度指標 | | エグゼクティブ透明性 | サマリー閲覧数、四半期レビューフィードバック | 顧客信頼性はこのリストに含まれない——それは SLO で直接測定すべき別の問題である。 ## 横断的知見 - **VOID の実データ（1,856 件・610 組織）が示す持続時間分布は、Heroku・Google・Honeycomb・Slack・全組織の集計において一貫して右歪み**: 1〜4 時間にピークがあり 72 時間超まで長い裾を引く。Davidovič の理論的予測（標本が少なく分散が大きい → MTTR は統計的ノイズに埋もれる）を、業界横断の実分布が独立して裏付けている。(Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]], [[@2021__OReilly__Incident Metrics in SRE]]) - **持続時間と深刻度の無相関を実データで証明**: Honeycomb の公開データでは「23 時間 11 分・顧客影響ゼロ」と「21 分・Critical 顧客影響」が共存する。「長い障害ほど悪い」という直感が VOID データで否定される。John Allspaw の表現で言えば「同じ長さの 2 つの障害は、人々がどう状況を理解したかの驚きと不確実性の点で劇的に異なりうる」。(Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]]) - **[[Štěpán Davidovič]] と [[Jamie Luck]]・[[Laura de Vesine]] は「MTTR は不適切」という結論で一致するが、Davidovič が統計的論拠(分布の歪み・ノイズ比)に重点を置くのに対し、Luck/de Vesine は逆インセンティブと組織的動機付けの側面をより強調する。両方の論拠が独立して「MTTR の廃棄」を支持する。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SREcon25Americas__Incident Management Metrics that Matter]])** - **MTTR と DORA の関係**: DORA の最新版では MTTR が削除され「bad rollout を remediate する時間」に置き換えられた。これは「デプロイ起因のロールバック時間」という測定しやすい sub-case に絞ったものであり、一般的な MTTR 批判と整合する。(Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]]) - **業務ケースの文脈ではMTTD/MTTRが依然として「わかりやすいROI指標」として素朴に使われる緊張関係**: 本ページの他ソースはMTTRが統計的ノイズに埋もれやすく逆インセンティブを生むと論じるが、[[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]] は運用ループの業務ケースを説明する際、「faster mean time to detect (MTTD) and mean time to repair (MTTR)」を他の指標(クエリ応答速度・ボトルネック特定速度・オンコール時間削減・ロールバック件数削減)と並べて「コスト削減」の一項目として素朴に列挙するにとどまり、本ページが蓄積してきたMTTRの統計的欠陥・逆インセンティブへの言及はない。同一書籍内でも読者(経営層向けの業務ケース章)によって指標の扱いの精度が変わりうることを示す例であり、財務・経営層向けの業務ケース提示では「わかりやすさ」が「統計的健全性」より優先される場面がありうるという実務上の緊張を浮かび上がらせる。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SREcon25Americas__Incident Management Metrics that Matter]], [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]]) - **Hidalgo は「インシデントの固有性」という、Davidovič の統計的批判とは独立の定性的論拠を MTTX 批判に追加する**: 『SLO サービスレベル目標』17章は、MTTX(平均認識時間・平均復旧時間など多数の派生指標の総称)が破綻する理由を、Davidovič の統計的論拠(件数が少なく分散が大きいためノイズに埋もれる)とは別に、「インシデントはそれぞれ固有であり、同じバケットに投げ入れて平均をとる前提(等価性)自体が成り立たない」という定性的論拠で補強する。同種の DDoS 攻撃でも攻撃者の技術・トラフィックパターン・対応するエンジニアの経験や状況が毎回異なる例を挙げ、母集団の等価性という MTTX の暗黙の前提を突き崩す。統計的論拠(分布の歪み)と定性的論拠(母集団の非等価性)は、独立の角度から同じ「MTTX の廃棄」という結論を支持する (Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] §17.1.3.1)。 - **「20件×20分 対 1件×3時間」という具体例は、VOID データの「持続時間と深刻度の無相関」を四半期比較の文脈で再現する**: Hidalgo(17章)は、20分のインシデントが20件(合計6時間40分)発生した四半期と、3時間のインシデントが1件だけ発生した四半期を比較すると、MTTRは前者が20分・後者が3時間となり後者のほうが悪化して見えるが、ユーザーが実際に体験した信頼性欠如の合計時間は前者のほうが長いと示した。これは、VOID の実データが示す「23時間11分・顧客影響ゼロ」と「21分・Critical顧客影響」の共存(既出)と同型の逆転現象を、実データではなく最小構成の思考実験として提示したものであり、平均ベースの指標がユーザー体験を覆い隠すという同じ結論に、経験的分析と理論的反例という異なる経路から到達している (Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] §17.1.3.2)。 - **エラーバジェットは、本ページが列挙してきた代替指標フレームワーク(推奨される測定カテゴリの表)とは異なる系統の解として、MTTX・深刻度レベル・インシデント件数のすべてを単一の計算に置き換える**: 本ページの「推奨される測定カテゴリ」(Datadog, SREcon25Americas)は、インシデント管理プロセスを目標ごとに分解して複数の指標を当てる多元的アプローチだが、Hidalgo(17章)は SLI/SLO に基づくエラーバジェットという単一の指標に、DDoS 攻撃の2波を合算(3分+30分=33分の消費)して片付ける一元的アプローチを示す。両者は「MTTR・インシデント件数・深刻度レベルは機能しない」という診断を共有しつつ、処方箋が「指標を増やして多面的に見る」か「SLIを介して単一の指標に統合する」かで分岐しており、目的(組織診断 vs ユーザー影響の一次表現)の違いに対応する可能性がある (Source: [[@2025__SREcon25Americas__Incident Management Metrics that Matter]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] §17.1.4.1)。 - **Anatomy 本の TTR は「緩和完了」を終点に定義することで、Davidovič らが批判する MTTR の逆インセンティブの一部を構造的に回避するが、統計的ノイズの問題には手を付けない**: [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]] は「TTR(修復までの時間)の終点はコードの修正でなく、応答者が顧客影響を緩和した時点である」と明記する。本ページが蓄積した批判のうち「MTTR の逆インセンティブ(深い根本原因の修正は MTTR を上昇させる)」は、MTTR が根本原因の完全な修正までを測定範囲に含めることに起因する。Anatomy 本の TTR は測定終点を緩和(症状の停止)に限定し、根本原因修正はポストモーテムのアクションアイテムという別の追跡対象へ切り出すため、この逆インセンティブの発生源そのものを構造的に取り除いている。ただし Davidovič が指摘するもう一つの問題(インシデント件数が少なく分散が大きいため MTTR/TTR の平均値は統計的ノイズに埋もれる)には Anatomy 本は言及しておらず、逆インセンティブの回避と統計的頑健性の確保は別問題として残る。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]]) - **不信頼性の式(TTD+TTR)/TBF×Impact は、本ページが批判してきた「単純な平均値ベースの指標」そのものの構造を持つ——実務書と学術批判の間に未解消の緊張がある**: 本ページの定義節が要約する中心テーゼ(単純な平均値ベースの指標は統計的に不堅牢で逆インセンティブを誘発する)に照らすと、Anatomy 本が提示する不信頼性の式は TTD・TTR という時間指標の合計を TBF(頻度の逆数)で割るという、まさに平均値ベースの単純な集計である。VOID の実データ(1〜4時間ピークの右歪み分布)や Hidalgo の「インシデントの固有性」論拠は、この種の単純化された式が個々のインシデントの質的差異を覆い隠す危険性を示唆するが、Anatomy 本自身はこの式の統計的頑健性(サンプルサイズ・分散)を検討していない。[[クラウド障害ライフサイクル]] で論じた通り、Anatomy 本の式は実務家向けの簡略化されたメンタルモデルとして評価すべきであり、本ページが蓄積してきた学術的批判をそのまま適用する場合は注意が必要。(Source: [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]], [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]]) - **本ページが集めた 3 つの処方箋は「指標を増やす」「指標を統合する」「指標を検定する」という異なる層にある**: Datadog(SREcon25 Americas)の測定カテゴリ表は目標ごとに指標を分解する多元的処方、Hidalgo(17 章)のエラーバジェットは SLI を介して単一指標へ統合する一元的処方であり、既出の横断的知見はこの 2 分岐を扱ってきた。Davidovič はそのどちらでもなく、「汎用の代替指標(シルバーバレット)は見つからなかった」と明言したうえで、**採用しようとしている指標を自分のデータでモンテカルロシミュレーションにかけ、自分にとって意味のある変化の水準を決めたうえでそれを検出できるか確かめる**という手続きを処方する。前 2 者が「何を測るか」への答えであるのに対し、これは「測る前に何を確かめるか」というメタ層の答えであり、Datadog の測定カテゴリにも Hidalgo のエラーバジェットにもそのまま適用できる。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SREcon25Americas__Incident Management Metrics that Matter]], [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]]) - **「代替統計を使えばよい」という一般的な反論を系統的に潰したのは Davidovič だけである**: 本ページの他ソースは MTTR・インシデント件数・重大度レベルを名指しで批判するが、「平均が外れ値に弱いなら中央値を使えばよい」という自然な次手について、中央値・95 パーセンタイル・幾何平均・合計継続時間のそれぞれをシミュレーションで検証したのは [[@2021__OReilly__Incident Metrics in SRE]] のみである。この検証があるため、本ページの批判は「算術平均への批判」ではなく「低頻度・高分散の集計統計一般への批判」として成立する。VOID の実分布(1〜4 時間ピークの右歪み)はこの一般化の経験的裏づけを与える。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]]) - **企業規模による解決も否定されている**: Davidovič は Google の内部データ(全重要インシデントは最深刻インシデントの約 15 倍規模)でも、1 年分で MTTR の 90% 信頼区間が ±5.3%、中央値で ±10% にとどまることを示した。数学的には信頼区間が縮むが、これほど広範なインシデント群に対しその規模の削減を約束する施策は実在しないため実務的な意味はない。しかも件数を増やすこと自体が信頼性工学の目的に反する。「大企業なら統計が効く」という直感的な逃げ道も、[[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]] の業界横断データ(610 組織)と同じ結論に至る。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]]) - **Azure の TTD/TTE/TTF/TTM は本ページが集めた「何を計測すべきか」の議論に、統計的批判(Davidovič)とは独立の「代理メトリクスによる組織的アクション化」という処方を加える**: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] は、TTD(検出時間)・TTE(エンゲージ時間)・TTF(修正時間)を合計した TTM(軽減時間)をダッシュボードで追跡する一方、データがまばら・分散が大きい・外れ値を含む場合には**パーセンタイルを適用して正規化**した(§4.2)。これは Davidovič がシミュレーションで示した「MTTR は分布が右歪みで分散が大きいため統計的ノイズに埋もれる」という問題(既出)に、統計的検定ではなく実務的な正規化手法で対処する動きとして読める。さらに Azure は主要指標の改善を促すために「DRI Hops」「% Outages autodetected」という**代理メトリクス**(具体的で対応しやすいが単体では成功を示さない従属指標)を追加し、これをエンジニアリングマネージャーへの具体的アクションアイテムに変換する。本ページが集める他ソース(Datadog の測定カテゴリ表、Hidalgo のエラーバジェット)が「何を測るべきか」の設計論であるのに対し、Azure の代理メトリクスは「測った指標をどう組織的アクションに変換するか」という実装レベルの処方を加える。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]], [[@2021__OReilly__Incident Metrics in SRE]]) - **「修復負債」「仮想修復負債」は、本ページが集めてきたどの処方（多元的・一元的・検定的）とも異なる第4の層——指標を組織のバックログ運用に接続する仕組み——を提示する**: Azure の修復負債は、インシデントレビューで見つかったバグ・改善機会を「修復（repair）」として標準バックログと区別してログに記録・追跡する仕組みであり、仮想修復負債はさらに「RCA が不十分で修復アイテム自体が作成されなかった」欠落を可視化する。本ページが既出で扱ってきた処方はいずれも「どの指標を採用するか」の設計論だが、修復負債は採用した指標(TTD/TTE/TTM の目標欠落)を**確実にバックログのアクションアイテムへ変換する運用プロセス**を提供する点で異質であり、「指標を測っても改善につながらない」というインシデントメトリクス一般の実装上の失敗モードに対する処方として位置づけられる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]]) ## 未解決の問い - Azure のパーセンタイル正規化(§4.2)は、Davidovič がシミュレーションで示した MTTR の統計的ノイズ問題を実際にどこまで緩和するか。本ページは両者を並置したのみで、正規化後のTTMがDavidovičの検定手続き(採用前にモンテカルロシミュレーションで検出力を確認する)に耐えるかどうかは未検証。 - 仮想修復負債(欠落した修復アイテムの可視化)は、RCA完了率の低さという症状を捉えるが、根本原因(なぜRCAが不徹底になるのか)には踏み込んでいない。組織的インセンティブやオンコール負荷との関係はどう分析できるか。 - Hidalgo が提示するエラーバジェット消費量による一元的処方は、Davidovič の統計的批判を免れるのか。Davidovič 自身は「SLI/SLO が理想に近くても、年間のエラーバジェット消費量の総和のような集計統計で分析できるとは限らない」と述べ、この領域の分析は行わず将来の課題として明示的に留保している。本ページが記録した「多元的 対 一元的」の分岐は、一元的側の統計的頑健性が未検証のまま残っている。 - Davidovič 自身が結論で挙げた「インシデント継続時間の分散そのものを指標にする(対応能力の一貫性を示すかもしれない)」という案は、その後どのソースでも検討されていない。VOID の公開データで検証可能か。 - 「繰り返しインシデント」の検出は現在「人間がパターンを認識する」手動作業に依存しており、LLM は不得意だとされる。どのような定式化でこれを自動化できるか。 - インシデント対応のコンピテンシー感情を survey でなく行動指標(例: IC がいつ escalate を呼ぶか)で測る方法はあるか。 - SLO とインシデント指標の間の「橋渡し」——インシデントが SLO burn rate に与えた寄与を帰属する指標設計はどうあるべきか。 - Anatomy 本の TTR(緩和完了を終点とする定義)は逆インセンティブを回避するが統計的ノイズには対処しない。TTR の測定範囲を緩和限定にしたうえで、Davidovič の統計的批判(サンプルサイズ・分散)にも同時に対応する指標設計はどう組み立てられるか。 ## 関連 - 上位概念: [[インシデント管理]] - 隣接概念: [[インシデント重大度評価]] / [[グッドハートの法則]] / [[サービスレベル目標]] / [[エラーバジェット]] / [[DORA]] / [[ポストモーテム]] / [[クラウド障害ライフサイクル]] / [[統計的有意性]] / [[TTXメトリクス]] / [[修復負債]] - 書籍: [[wiki/entities/Incident Metrics in SRE|Incident Metrics in SRE]] — MTTx 批判の一次統計文献 - 章: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] / 著者: [[Martin Check]] - 関連 MOC: [[Incident Management - MOC]] / [[SRE - MOC]] - 関連 structures: [[structures/sre/Incident Management - MOC.md]] ## 出典 - [[@2022__SREcon22Americas__Tales from the VOID - The Scary Truth About Incident Metrics]] — VOID データによる MTTR・持続時間・RCA の実証的批判 - [[@2021__OReilly__Incident Metrics in SRE]] — Štěpán Davidovič による MTTR の統計的批判 - [[@2025__SREcon25Americas__Incident Management Metrics that Matter]] — Datadog の実践に基づく代替指標フレームワーク - [[@2026__OReilly__Observability Engineering 2E - Chapter 26 The Business Case for Observability]] — 業務ケースにおけるMTTD/MTTRの素朴な使用例 - [[@2023__OReillyJapan__SLO サービスレベル目標 - Chapter 17 信頼性のレポート]] — インシデントの固有性という定性的論拠、20件×20分対1件×3時間の反例、エラーバジェットによる一元的な代替 - [[@2022__OReilly__Anatomy of an Incident - Chapter 4 Mitigation and Recovery]] — TTR を「緩和完了」で終点定義することによる逆インセンティブ回避、不信頼性の式の単純化された集計構造 - [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] — Microsoft Azure における TTD/TTE/TTF/TTM の実践的定義、代理メトリクス、修復負債・仮想修復負債による組織的アクション化