# TTXメトリクス ## 定義 TTX メトリクスとは、インシデントのライフサイクルを複数のフェーズに分解し、各フェーズの経過時間を個別に計測する指標群の総称である。MTTR（Mean Time To Recovery）の単一値では変動性が高く改善評価に使えないという問題に対し、改善対象フェーズを特定して細粒度で計測することで変動性を抑える。(Source: [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) ### インシデントのマイルストーン（フェーズ境界） SRE 関連ベストプラクティス（SRE Book・[[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善|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 内部の大規模データセットでも年単位で MTTR の ±5.3% までしか信頼区間を狭められないことを実証した。 > [!contradiction] 49%・50%・64% という数値の条件が食い違う > 上記の SRE Kaigi 2025 発表は「各インシデントの修復時間を 10% 短縮しても **MTTR が 10% 以上改善される**のは 49%・50%・64% のケースのみ」と紹介するが、一次ソースである [[@2021__OReilly__Incident Metrics in SRE]] の本文では、この 3 つの数値は「**15 分以上の改善**（絶対変化）が観測される確率」として提示されている（Source: [[@2021__OReilly__Incident Metrics in SRE]] ch.1 §Scenario simulation and evaluation）。同じ図5 に関する別の数値として、一次ソースは「MTTR の差がゼロ以下に落ちた（＝改善がまったく見えない）試行が 38%・40%・20%」も示す。数値の出所は同一のシミュレーションだが、閾値の定義（相対 10% 対 絶対 15 分）が異なるため、引用時は条件を明示する必要がある。 ### 実践的な 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 の信頼区間が広く実用性が低いことを示した。1 年分の全重要インシデント（最深刻インシデント集合の約 15 倍規模。著者は実数を公開できないとしつつ「先の検定で用いた 1,000 件より多い」と述べる）で 90% 信頼区間が MTTR の ±5.3%、中央値でも ±10% にとどまる。数学的には確かに縮むが、これほど広範なインシデント群（ユーザー向け配信障害から処理パイプライン・ネットワーク設定・社内端末のソフトウェア導入まで）に対しその規模の削減を約束する施策は実在しないため、実務的な意味は薄い。「件数を増やせばよい」という直感的解決策が機能しないことが実証されている。これはインシデント件数を増やすこと自体が信頼性工学の目標に反するという根本的な矛盾も指摘している。(Source: [[@2021__OReilly__Incident Metrics in SRE]]) - **フェーズ分解という TTX の処方は、Davidovič の処方の一部分にすぎない**: Davidovič が「問いに合わせて指標を絞る」節で挙げる手段は 2 つあり、改善対象フェーズだけを測る（＝ TTX の考え方）に加えて、**選んだ少数のインシデントに対するユーザースタディ**を並置する。後者を置く理由は「個々のインシデントを逐一詳細に分析するのは現実的でない（人手のメタデータ入力に依存できず、すべてを密に観測できない）」からであり、これは TTX が前提とする自動収集（Slack イベント連携等）で解消される制約と正面から対立する。自動収集が十分に効く環境では TTX 側の前提が成り立ち、効かない環境ではユーザースタディ側に倒れる、という条件分岐として読める。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) - **TTX に分解しても統計的問題そのものは残る**: Davidovič は「検知までの時間など他の多くのインシデント指標も、同様の分布特性とサンプルサイズに従う限り同じ問題を抱える」と明示する。フェーズを絞ることで改善対象以外のノイズは減らせるが、件数の少なさと分散の高さという根因は各フェーズにも引き継がれる。TTX が有効なのは「改善対象フェーズの効果量が、そのフェーズ固有の分散に対して十分大きいとき」に限られ、その確認には Davidovič 自身が処方する検定手続き（採用前に自分のデータでシミュレーションする）が必要になる。(Source: [[@2021__OReilly__Incident Metrics in SRE]], [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) - ANZx の PIR² プロセス（Tom Partington、SREcon22 APAC）は MTTR をインシデントレビューから意図的に除外する。TTX の「計測は継続しつつ改善評価指標としては使わない」というアプローチと異なるが、問題意識は共通する。(Source: [[@2022__SREcon22APAC__A Post Incident Review Review]]) - **Microsoft Azure の TTD/TTE/TTF/TTM は、Waroom の TTX 一覧より粗い4分解だが、本ページのTTX一覧より早い時期に本番運用された実例である**: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]]（原書 2018 年）は、検出時間（TTD）・エンゲージ時間（TTE）・修正時間（TTF）の3分解とその合計である軽減時間（TTM）を定義し、これをダッシュボードで追跡した。Waroom の11指標一覧（TTDetect/TTAcknowledge/TTEngage/TTInvestigate/TTIdentify/TTMitigated/TTFix/TTRecovery等）と比べるとフェーズの粒度は粗いが、「MTTRのような単一の合計指標ではなくフェーズに分解して計測する」という設計原則は同一であり、TTXという用語が定着する以前から同種のフェーズ分解が実務で行われていたことを示す一次資料である。Azure はさらに、フェーズ分解に加えて「DRI Hops」「% Outages autodetected」という代理メトリクス（従属メトリクス）を併用し、主要指標の改善を具体的なアクションアイテムに変換する運用を先取りしていた。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]], [[@2025__SRE Kaigi 2025__インシデントキーメトリクスによるインシデント対応の改善]]) - **Azure のパーセンタイル正規化は、TTX に分解してもなお残る統計的問題（Davidovič の指摘）への実務的な対処法の一例になりうる**: 本ページは「TTX に分解しても各フェーズが同じ分布特性・サンプルサイズの問題を引き継ぐ」と記録しているが、Azure はデータがまばら・分散が大きい・外れ値を含む場合に**パーセンタイルを適用して正規化**することで対処した（§4.2）。これは Davidovič が処方する「採用前にモンテカルロシミュレーションで検出力を確認する」という統計的検定手続きとは異なる、実務側からの簡便な代替アプローチであり、両者の関係（正規化が検定に代わりうるか）は未検証のまま両ソースに残る。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]], [[@2021__OReilly__Incident Metrics in SRE]]) - DORA の 4 指標に MTTR が含まれる（[[DORA]] 参照）ため、組織によっては MTTR からの移行に摩擦が生じる可能性がある。 ## 未解決の問い - TTX 収集のための Slack 連携以外の実装パターン（PagerDuty・Jira 等）はどう設計するか？ - TTX の「想定値」（例: TTAcknowledge は 10 分以内）はどう設定・組織間比較するか？ - Learning Metrics・Improvement Metrics などサービス復旧以外の指標の収集・分析は実際にどう自動化するか？ - MTTR に代わる単一サマリー指標として何が使えるか？（Davidovič は「シルバーバレット」は存在しないと結論づけている） - SLI/SLO は MTTR の代替として分析に耐えうるか？ Davidovič はこれを「将来の研究」として留保している。 - 中央値・幾何平均など代替統計も根本的な問題（分散の高さ）を解決しないことが示された。では「インシデントの分散そのもの」を指標化（例: 標準偏差や IQR）することは有用か？（Davidovič が将来の可能性として言及） - Azure のパーセンタイル正規化は、Davidovič が処方する検定手続き（採用前にモンテカルロシミュレーションで検出力を確認する）の代わりになりうるか、それとも両方が必要か。 ## 関連 - [[インシデント管理]] — TTX の位置づけ - [[インシデントメトリクス]] — MTTR 批判と代替指標フレームワークの集約 - [[wiki/entities/Incident Metrics in SRE|Incident Metrics in SRE]] — MTTR 批判の一次統計文献（書籍 entity） - [[DORA]] — MTTR は DORA の一指標（批判対象） - [[Waroom]] — TTX 自動収集の実装例 - [[変更起因インシデント]] — TTDetect に関連（検知遅延の文脈） - [[クラウドモニタリング]] — TTDetect 改善の手段 - [[修復負債]] — Azure が TTD/TTE/TTM の目標欠落を修復アイテムの追跡プロセスに接続する仕組み - 章: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] / 著者: [[Martin Check]]（[[Microsoft Azure]]） - [[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 除外の別アプローチ） - [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] — TTD/TTE/TTF/TTM という早期の実務的フェーズ分解、代理メトリクス、パーセンタイル正規化