# Incident Management Metrics that Matter Navigation: [[index]] | [[@2025__SREcon25Americas__Incident Management Metrics that Matter]] ## 概要 [[Jamie Luck]] と [[Laura de Vesine]]([[Datadog]])が SREcon25 Americas(2025-03-27、サンタクララ)で発表した 35分の講演。ビジネスが「MTTR を下げよ」「インシデント件数を減らせ」という指標を使おうとする構造的圧力に対し、それらが統計的に不堅牢かつ逆インセンティブを生む理由を体系的に論じ、代わりに何を測るべきかを Datadog の実践から提示する。発表はロールプレイ形式(Laura が「新任エンジニアリングマネージャー」、Jamie が「メトリクス懐疑論者 SRE」)で進行する。 ## 主要メッセージ - **MTTR・インシデント件数・変更失敗率などは測るのは簡単だが価値が低い**: MTTR は分布の歪みと標準偏差の大きさゆえに変化のほぼすべてがノイズになる(Štěpán Davidovič の統計分析より p.7 スライド参照)。インシデント件数は「スパイシーなバグ」と称した未申告や低重大度の申告外しを促す。 - **インシデントは内部調整プロセスである**: 顧客信頼性(customer reliability)とインシデント管理プロセスの健全さは別物。前者は SLO で測り、後者はプロセス自体の質を直接測定する。 - **目標→指標のサイクル**: 01 Alignment(ステークホルダーが目標に合意)→ 02 Identifying Goals(何が重要か)→ 03 Identifying Metrics(複数の視点から指標を選ぶ)→ 04 Define and Expand(フィードバックで改善) という 4 ステップのサイクルを提案(p.35 フローチャート)。 - **MTTR は健全な組織では上昇するはず**: 本当の修正をすれば系が複雑になり、次のインシデントはより難解になる。MTTR が下がり続けるのは「同じインシデントを繰り返す」歪んだ最適化の証拠になりうる(p.36 "A wild learning appeared!" スライド)。 ## 視覚的に重要な図表 **p.44 Summary of things we're measuring(メトリクス一覧)** ![[_attachments/srecon25americas-de-vesine-incident-management-metrics/page-044.png]] Datadog が実際に計測しているメトリクスの全体マップ。左列がオンコール・インシデント運用系、右列がエスカレーション・ポストモーテム・実行・エグゼクティブ報告系に大別される。 **p.46 Executive-friendly flow chart(4ステップサイクル)** ![[_attachments/srecon25americas-de-vesine-incident-management-metrics/page-046.png]] 01 Alignment → 02 Identifying Goals → 03 Identifying Metrics → 04 Define and Expand の循環。「ステークホルダーが goal-based metrics を worthwhile と合意すること」が出発点であることを強調する。 **p.26 Are we... good at them?(時間を測れない代わりに何を測るか)** ![[_attachments/srecon25americas-de-vesine-incident-management-metrics/page-026.png]] 時間は測れないという前提から、「Do we feel competent and prepared?」を代理指標として使うことを提案。Focus on the problem / Not scared about attention(責任追及を恐れない)の 2 要素に分解する。 ## 測定カテゴリと具体例 ### オンコール健全性 - **ツール品質**: 誤った通報手段・ツールのミスによる操作エラーを測定 - **ページ負荷**: 1シフト当たりのページ数、深夜シフト数(連続・総量)、オンコール期間の長さ - **公平性**: シフト分布の均等性、週末・深夜シフトの偏り、エンジニアのサーベイ感情(数値化可能) ### インシデント管理品質 - **インシデントステートマシン完走率**: ミティゲーションで止まらず解決まで辿り着く割合 - **メタデータ記録率**: 重大度・担当者・原因などのメタデータが記録されているか - **インシデントコマンダー不在率**: 誰も主導者のいないインシデントの割合(「ロボットがインシデントを宣言する」ワークフローの検出も含む) - **自発的ポストモーテム率**: 必須でない低重大度事例でもチームが自主的に書くか - **チーム参加数の分布**: 参加チームが非常に少ない(問題を局所化してしまった)または非常に多い(本当の大規模障害)インシデントの割合 ### インシデント対応能力 - **役割の使用率**: Incident Commander や専門ローテーション(security lead 等)が高重大度インシデントで適切に招集されているか - **エスカレーション輪番のテナー・規模**: 自発ボランティア IC ローテーションの平均在籍期間(スイートスポット: 約 12〜18ヶ月)・ハンドオフの一貫性 - **コンピテンシー感情**: サーベイと LLM による incident chat / ポストモーテムの感情分析 ### 顧客コミュニケーション - **高重大度通知のタイムライン**: 最初の顧客向けコミュニケーションまでの所要時間 - **顧客フィードバック**: 投稿内容への定性フィードバック、専用 comms チームからのフィードバック ### 学習と改善 - **ポストモーテム長・完成度**: 複雑さの代理指標にもなる - **ポストモーテム読書会**: 実施有無 - **アクションアイテム進捗**: 「期限」を設けずに速度で測る。短期・長期に分けて追跡 - **繰り返しインシデント**: 「以前見たパターン」を人間が手動でラベル付けする(LLM は不得意) - **インシデント複雑度**: 参加人数・ロール数・ポストモーテム長・感情分析 ### エグゼクティブ向け - **月次インシデントサマリーの閲覧数**: エグゼクティブが実際に読んでいるかの代理指標 - **四半期レビュー**: 定性フィードバックの収集 - **SLO**: 顧客信頼性は別プロジェクトとして SLO で直接測定すること ## Štěpán Davidovič の統計的批判との接続 p.7 スライドで [[Štěpán Davidovič]] の著書 *Incident Metrics in SRE* を明示的に引用。インシデントのような低頻度事象では、計算する平均値の個数と標準偏差の大きさゆえ、MTTR の変化のほぼすべてが統計的ノイズになると指摘する。これは本 wiki の [[@2021__OReilly__Incident Metrics in SRE]] の核心主張と一致する。(Source: スライド p.7) ## DORA メトリクスについて(Q&A 補足) Q&A スライド(p.48)で Laura が補足: DORA メトリクスはエグゼクティブに見せるものが何もない場合のギャップを埋めるが、外部報告のために測定する指標を内部最適化目標に転用してはならない。また最新の DORA 指標は MTTR を含まず、「bad rollout の remediate にかかる時間」(= ロールバックにかかる時間)に置き換えられている。コンプライアンスフレームワークは特定の数値より「指標を持っていること自体」が組織成熟度の証拠として機能する場合がある。 ## 概念・実体への接続 - [[インシデントメトリクス]] — 本講演の中心概念 - [[インシデント管理]] — インシデント管理プロセスの文脈 - [[グッドハートの法則]] — MTTR・インシデント件数が逆インセンティブを生む理由の背景理論 - [[サービスレベル目標]] — 顧客信頼性の直接測定手段 - [[ポストモーテム]] — 学習・改善メトリクスの主要ターゲット - [[Štěpán Davidovič]] — MTTR の統計的批判の一次出典 - [[インシデント重大度評価]] — 重大度指標の逆インセンティブへの言及 ## 限界・不確実点 - transcript なし(Whisper 未実行)。スライドのスピーカーノート(PDF 埋め込み)が口頭説明の大部分を補完している。 - "Incident Groundhog Day" (Dublin = SREcon23 EMEA) の引用があるが、発表者名・タイトルの正確な表記はスライドに記載なく不確実。 - 内部 RFC が存在すると言及されているが未公開のため参照不可。