# TTXメトリクス ## 定義 TTX メトリクスとは、インシデントのライフサイクルを複数のフェーズに分解し、各フェーズの経過時間を個別に計測する指標群の総称である。MTTR（Mean Time To Recovery）の単一値では変動性が高く改善評価に使えないという問題に対し、改善対象フェーズを特定して細粒度で計測することで変動性を抑える。(Source: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) ### インシデントのマイルストーン（フェーズ境界） SRE 関連ベストプラクティス（SRE Book・SRE の探求・Incident Management for Operations・Establishing SRE Foundations）を統合すると、以下のマイルストーンが定義できる。 - **Triggered**（発生） - **Detected**（検知） - **Acknowledged**（認知） - **Engaged**（チームの構成） - **Identified**（解決策の特定） - **Mitigated**（緩和） - **Recovered**（復旧） - **Resolved**（解決） - **Closed**（完了） ### TTX 指標一覧（Waroom 定義） | 指標 | 測定範囲 | 用途 | |---|---|---| | TTDetect | 発生 → 検知 | モニタリング品質の評価 | | TTAcknowledge | 検知 → 認知 | アラートレスポンスの評価 | | TTEngage | 発生 → チーム構成 | オンコール体制の評価 | | TTInvestigate | 認知 → 解決策特定 | 調査効率の評価 | | TTIdentify | 発生 → 解決策特定 | 総合的な特定速度 | | TTMitigated | 発生 → 緩和 | サービス影響軽減速度 | | TTFix(Repair) | 解決策特定 → 復旧 | 修復実施効率 | | TTRecovery | 発生 → 復旧 | いわゆる TTR | | Response Time | 検知 → 復旧 | 組織が割込業務に費やした時間 | | Time Between Failure | 復旧 → 次の発生 | 信頼性・障害発生頻度 | | Time Between Service Incidents | 発生 → 次の発生 | インシデント発生間隔 | (Source: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]] p.40) ### MTTRとの関係 MTTR（Mean Time To Recovery）は DORA の 4 指標のひとつであり、プロセス効率の代表指標として広く使われてきた。しかしモンテカルロシミュレーション（インターネット大手 3 社の実データ、10 万回）により、各インシデントの修復時間を 10% 短縮してもMTTR が 10% 以上改善されるのは 49%・50%・64% のケースのみと判明した。インシデント期間の分布がべき乗則に近く、外れ値（ブラックスワンイベント）1 件で平均が大きく動くためである。→ **MTTR は改善評価指標としては不適切**。(Source: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) この批判は [[@2021__OReilly__Incident Metrics in SRE]]（[[Štěpán Davidovič]] / Google）でも同様に提起されている。Davidovič はモンテカルロシミュレーション（10 万回）に加え、中央値・幾何平均・95 パーセンタイルなど代替統計でも問題が解決しないことを示し、さらに Google 内部の大規模データセットでも年単位で 5.3% の改善しか検出できないことを実証した。 ### 実践的な TTX 定義の 3 条件（Waroom 観点） 1. **網羅的**：フェーズを漏れなくカバーする 2. **粒度が細かい**：改善対象を特定できるレベルに分解する 3. **収集が現実的**：対応中に人間が手動打刻するのは非現実的。自動収集が必須（Slack イベント連携等） ### 活用の原則：目的・指標・データ分析の整合 データ分析（仮説検証型）の流れは「目的設定 → 仮説構築 → データ分析」であり、各ステップの整合性が重要。MTTR を使う場合は「昨年と同様の障害が起きる」という強い前提が暗黙に含まれるが、実際はデータセット次第で MTTR は改善にも悪化にもなる。改善箇所を明確にして対応するフェーズの TTX だけを分析することで、仮説と指標が噛み合う。(Source: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) ## 横断的知見 - **MTTR 批判は 3 つの異なる立場から一致して登場する**: (1) [[Štěpán Davidovič]]（Google SRE、[[@2021__OReilly__Incident Metrics in SRE]]）は定量的モンテカルロシミュレーションで実証。(2) [[Narimichi Takamura]]（[[Topotal]]）は同じアプローチを SRE Kaigi 2025 で日本語圏に展開し TTX 代替指標を体系化。(3) [[Courtney Nash]]（[[Verica]]、[[@2023__SREcon23Americas__Far from the Shallows]]）は「shallow data」として定性的・哲学的に批判しインシデントストーリーへの転換を主張。共通の問題意識を持ちながらアプローチが異なる。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]], [[@2023__SREcon23Americas__Far from the Shallows]]) - **「問いに合わせたメトリクス」の考え方は SRE 実践の異なる層で展開する**: Davidovič は「製品が改善する特定フェーズを特定し、そのフェーズだけを計測する」と提案（TTX の先駆け）。Takamura はこれを Waroom での自動収集実装として具体化した。両者は同じ原則の理論版と実装版として読める。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) - **大規模データセットは問題を解決しない**: Davidovič は Google の大規模内部データ（数万件規模）でも MTTR の信頼区間が広く実用性が低いことを示した。「件数を増やせばよい」という直感的解決策が機能しないことが実証されている。これはインシデント件数を増やすこと自体が信頼性工学の目標に反するという根本的な矛盾も指摘している。(Source: [[@2021__OReilly__Incident Metrics in SRE]]) - ANZx の PIR² プロセス（Tom Partington、SREcon22 APAC）は MTTR をインシデントレビューから意図的に除外する。TTX の「計測は継続しつつ改善評価指標としては使わない」というアプローチと異なるが、問題意識は共通する。(Source: [[@2022__SREcon22APAC__A Post Incident Review Review]]) - DORA の 4 指標に MTTR が含まれる（[[DORA]] 参照）ため、組織によっては MTTR からの移行に摩擦が生じる可能性がある。 ## 未解決の問い - TTX 収集のための Slack 連携以外の実装パターン（PagerDuty・Jira 等）はどう設計するか？ - TTX の「想定値」（例: TTAcknowledge は 10 分以内）はどう設定・組織間比較するか？ - Learning Metrics・Improvement Metrics などサービス復旧以外の指標の収集・分析は実際にどう自動化するか？ - MTTR に代わる単一サマリー指標として何が使えるか？（Davidovič は「シルバーバレット」は存在しないと結論づけている） - SLI/SLO は MTTR の代替として分析に耐えうるか？ Davidovič はこれを「将来の研究」として留保している。 - 中央値・幾何平均など代替統計も根本的な問題（分散の高さ）を解決しないことが示された。では「インシデントの分散そのもの」を指標化（例: 標準偏差や IQR）することは有用か？（Davidovič が将来の可能性として言及） ## 関連 - [[インシデント管理]] — TTX の位置づけ - [[DORA]] — MTTR は DORA の一指標（批判対象） - [[Waroom]] — TTX 自動収集の実装例 - [[変更起因インシデント]] — TTDetect に関連（検知遅延の文脈） - [[クラウドモニタリング]] — TTDetect 改善の手段 - [[structures/AIOps - Fault Localization - MOC]] ## 出典 - [[@2021__OReilly__Incident Metrics in SRE]] — MTTR の統計的限界をモンテカルロシミュレーションと Google 内部データで実証した一次ソース - [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]] - [[@2023__SREcon23Americas__Far from the Shallows]]（MTTR 批判の比較参照） - [[@2022__SREcon22APAC__A Post Incident Review Review]]（MTTR 除外の別アプローチ）