# インシデントキーメトリクスによるインシデント対応の改善 [[Narimichi Takamura]]（[[Topotal]] CEO / SRE）による SRE Kaigi 2025（2025-01-26）の発表。TTX メトリクスの実践的定義と活用方法を体系的に論じた資料。 ## 概要 MTTR（平均復旧時間）がインシデント改善の評価指標として統計的に機能しないことをモンテカルロシミュレーションで実証し、代替として TTX メトリクス（インシデントの各フェーズに分解した経過時間指標）の網羅的定義と活用方法を提示する。[[Waroom]]（Topotal の SaaS）における自動収集の実装例も含む。 YouTube: https://www.youtube.com/watch?v=4myF9kw-ZDA ## 主要メッセージ 1. **MTTR は改善評価に役立たない** — インシデント期間のばらつきが大きく、修復時間を 10% 短縮してもMTTR が改善されるのは半分程度（p.18 シミュレーション）。 2. **目的・指標・データ分析の整合性が重要** — 抽象的な目的のまま指標を選ぶと仮説検証ロジックが崩れる（p.24）。 3. **細粒度 TTX で変動性を抑える** — 改善したいステップを特定し、そのステップのみを計測する（pp.25–26）。 4. **網羅的 TTX 定義** — ベストプラクティス（SRE Book・Incident Management for Operations 等）をベースに 10 種類の TTX を定義（p.40）。 5. **サービス復旧以外のメトリクス** — 顧客対応・学習・改善実施状況まで対象を広げることで組織全体の対応改善につながる（p.53）。 ## 視覚的に重要な図表 **p.7 インシデントマネジメントサイクル** ![[_attachments/sre-kaigi-2025/page-007.png]] 復旧対応がメインのサイクル（破線、完結しない）から、改善フィードバックが高速に循環するサイクル（実線、Waroom アイコン中心）への転換を示す。 **p.18 シミュレーション結果** ![[_attachments/sre-kaigi-2025/page-018.png]] 各インシデントの修復時間を 10% 短縮したとき MTTR が 10% 以上改善される比率は Company A=49%、Company B=50%、Company C=64%。グラフ横軸: Relative change in incident duration（正方向が改善）、縦軸: Number of simulations（10 万回）。山の中心が 0% 付近にあり、修復時間の短縮が MTTR に反映されない。 **p.25–26 解決策フロー** ![[_attachments/sre-kaigi-2025/page-025.png]] 目的設定「改善による復旧時間の短縮を可視化したい」→ 改善箇所の明確化「復旧着手までの時間を短縮する」→ 仮説構築「発生から着手までの時間が全体的に短縮されるはず」→ データ分析「TTDetect と TTAck の傾向を分析する」 **p.40 TTX メトリクス体系図** ![[_attachments/sre-kaigi-2025/page-040.png]] インシデントのタイムライン（Triggered → Detected → Acknowledged → Engaged → Identified → Mitigated → Recovered → Resolved → Closed → Next Triggered）上に TTX を重ねた図。TTDetect・TTAcknowledge・TTEngage・TTInvestigate・TTIdentify・TTMitigated・TTFix(Repair)・TTRecovery・Response Time・Time Between Failure・Time Between Service Incidents の 11 種類を定義。 **p.46 メトリクスと改善施策の対応表** ![[_attachments/sre-kaigi-2025/page-046.png]] TTDetect → モニタリングの改善、TTEngage → シフト・役割明確化・オンコール制度、TTInvestigate → Runbook ダッシュボード整備、TTFix → ロールバック高速化。 **p.53 発展的なメトリクス体系** ![[_attachments/sre-kaigi-2025/page-053.png]] Incident Response Metrics（Engineer 向け、純粋な復旧課題特定）/ Customer Reliability Metrics（Sales・CRE 向け、顧客対応課題）/ Learning Metrics（Manager・Engineer 向け、組織学習トラッキング）/ Improvement Metrics（Manager・Engineer 向け、根本対策実施状況分析）の 4 カテゴリ。 ## 口頭説明・補足 transcript（YouTube 自動字幕）より補足。 - **Waroom の自動収集ロジック** — 対応中の Slack イベントをトリガーにタイムスタンプを自動記録（p.42）。Acknowledged はチャンネル作成・インシデント起票、Identified は Runbook のフェーズ分け（Precheck/Resolution）、Recovered は Slack のやり取りから AI が判断する。 - **TTR 分布の活用** — MTTR（平均値）ではなく分布比較が課題発見の糸口になる。即時復旧障害の減少は「自動復旧成果か、検知仕組みの不具合か」を区別する手がかりになる（p.27）。 - **データセット出典** — シミュレーションのデータセットは The VOID Report 掲載の有名インターネット企業 3 社のインシデントステータスダッシュボードから取得（p.15 脚注）。 ## 概念・実体への接続 - [[TTXメトリクス]] — 本資料が定義する中心概念 - [[インシデント管理]] — TTX 体系の位置づけ - [[DORA]] — MTTR は DORA の 4 指標のひとつだが本資料は改善指標としての限界を実証 - [[Narimichi Takamura]] / [[Topotal]] / [[Waroom]] ## 限界・不確実点 - transcript は YouTube 自動字幕（機械精度）のため、発言の細部は不確実。 - シミュレーション結果（49%/50%/64%）はスライド画像（p.18）で裏取り済み。グラフ軸ラベルは英語で正確に読み取れる。 - The VOID Report のデータセット詳細（収集期間・企業名）はスライドに明示なし。 ---