インシデントメトリクス

1）インシデントを測定する理由

インシデントメトリクスは、カオスなイベントを管理可能なプロセスに変えます。応答とリカバリ時間の短縮、原因の再発の削減、SLO/契約の履行の証明、オートメーションポイントの検索に役立ちます。検出→分類→エスカレーション→アクションの軽減→回復→CAPA→解析という、優れたメトリクスがサイクル全体をカバーしています。

2）基本的な定義と数式

イベント間隔

MTTD （Mean Time To Detect）=T0（実際の影響の開始）から最初の信号/検出までの平均時間。
MTTA （Mean Time To Acknowledge）=最初の信号からackオンコールまでの平均時間。
MTTM （Mean Time To Mitigate）=SLOしきい値を下回るまでの平均時間（多くの場合=UXの回避/劣化までの時間）。
MTTR （Mean Time To Recover）=ターゲットSLIを完全に回復するための平均時間。
MTBF （Mean Time Between Failures）=関連するインシデント間の平均間隔。

営業時間（営業時間）

宣言する時間-T0からSEV/インシデントレベルの公式発表まで。
Commsへの時間-発表から最初の公開/内部SLAの更新まで。
ステート内の時間-各ステージでの持続時間（トリアージ/diag/fix/verify）。

頻度および僅か

インシデントカウント-期間ごとのインシデント数。
インシデントレート-1k/10k/100k成功したトランザクションまたは要求（正規化）。
SEVミックス-重症度による分布（SEV-0..。SEV-3）。
SLA違反カウント/レート-外部SLA違反の数/シェア。
Change Failure Rate-変更によるインシデントの％（リリース/configs/移行）。

信号とプロセスの品質

％Actionable Pages-意味のあるPlaybookアクションにつながったページの割合。
False Positive Rate （Pages）-偽陽性の割合。
検出カバレッジ-自動化によって検出されるインシデントの割合（クライアント/サポートではありません）。
再開率-同じ根本原因の繰り返しインシデントの割合≤ 90日です。
CAPA完了-修正/予防アクションの％が時間通りに終了しました。
Comms SLA Adherence-必要な周波数で発行される更新の割合。

3）インシデントステージ別のメトリックマップ

4）正規化とセグメンテーション

カウンタをボリューム（トラフィック、成功、アクティブユーザー）に正規化します。
セグメント別：地域/テナント、プロバイダ（PSP/KYC/CDN）、変更の種類（コード/config/infra）、日中（昼/夜）、検出ソース（合成/RUM/infra/サポート）。
ビジネスSLI（支払いの成功、登録、補充）は、ビジネスにとって重要です-インシデントメトリクスを劣化にリンクします。

5）しきい値の目標（ランドマーク、ドメインに適応）

MTTD： ≤のためのTier-0 5分、Tier-1のための≤ 10-15分。
MTTA： ≤ 5分（24/7）、 ≤ 10分（フォローザサン）。
MTTM： ≤ 15分（Tier-0）、 ≤ 30-60分（Tier-1）。
MTTR： ≤ 60分（Tier-0）、 ≤ 4 h （Tier-1）。
検出の適用範囲：≥ 85％のオートメーション。
％Actionableページ：≥ 80-90％；FPページ：≤ 5％。
再開率（90％）： ≤ 5-10％。
CAPAの完了（時間通り）：≥ 85％。

6）変更の原因と影響の帰属

主な原因（Code/Config/Infra/Provider/Security/Data/Capacity）とトリガー（release ID、 config change、 migration、 external factor）を各インシデントに割り当てます。
Change-linked MTTR/Count（変更連動MTTR/Count）-リリースと構成がどれだけ貢献するか（ゲート/カナリアポリシーの基本）。
別に、ルートと契約を管理するために、プロバイダによって引き起こされるインシデント（PSP/KYC/CDN/Cloud）を検討してください。

7）コミュニケーションと顧客への影響

最初の公開更新と更新の時間ケイデンス（例えば、15/30分ごと）。
苦情レート-チケット/苦情について1インシデント、トレンド。
ステータス精度-リトラクションなしの公開アップデートの共有。
事後NPS（主要顧客による）-SEV-1/0後の簡単なブースト。

8）インシデントに関する品質指標のアラート

Page Storm Index-インシデント中の1コールあたりのページ数/時間（p95の中央値）。
Dedup Efficiency-抑制された重複の割合。
Quorum Confirmation Rate（クォーラム確認率）-プローブのクォーラム（≥ 2独立したソース）がトリガーされたインシデントの割合。
Shadow→Canary→新しいルールのProd変換（Alert-as-Code）。

9）ダッシュボード（最小セット）

1.エグゼクティブ（28日）：インシデントの数、SEV分布、MTTR/MTTM、 SLA休憩、再オープン、CAPA。
2.SRE Operations： MTTD/MTTA、 Page Storm、 Actionable％、 Detection Coverage、 Time to Declare/Comms。
3.Change Impact：リリース/構成インシデントの共有、変更インシデントのMTTR、メンテナンスウィンドウとインシデント。
4.プロバイダ：プロバイダによるインシデント、劣化時間、ルートスイッチ、契約SLA。
5.サービス/地域別ヒートマップ：1kトランザクションあたりのインシデントとMTTR。

SLI/SLOグラフィックスとリリースアノテーションとSEVマークを組み合わせます。

10）インシデントデータ図（推奨）

incident_id, sev, state, service, region, tenant, provider?,
t0_actual, t_detected, t_ack, t_declared, t_mitigated, t_recovered,
source_detect (synthetic    rum    infra    support),
root_cause (code    config    infra    provider    security    data    capacity    other),
trigger_id (release_id    change_id    external_id),
slo_impact (availability    latency    success), burn_minutes,
sla_breach (bool), public_updates[], owners (IC/TL/Comms/Scribe),
postmortem_id, capa_ids[], reopened_within_90d (bool)

11）計算例（SQLアイデア）

sql
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_recovered - t0_actual))/60) AS mttr_min
FROM incidents
WHERE t0_actual >= '2025-10-01' AND t_recovered IS NOT NULL AND sev IN ('SEV-0','SEV-1','SEV-2');

sql
SELECT 100.0 SUM(CASE WHEN source_detect <> 'support' THEN 1 ELSE 0 END) / COUNT() AS detection_coverage_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

sql
SELECT 100.0 COUNT() FILTER (WHERE trigger_id IS NOT NULL) / NULLIF(COUNT(),0) AS change_failure_rate_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

12） SLOとエラー予算へのリンク

インシデントあたりの記録SLO書き込み分-これがイベントの主な「重み」です。
CAPAをインシデントカウントではなく、トータルバーンとSEV重量で優先順位付けします。
（例：ダウンタイムの$/minuteまたは$/lostトランザクション）。

13）プログラムレベルの指標

Postmortemリードタイム：インシデントの閉鎖から報告書の発行までの中央値。
証拠の完全性：タイムライン、SLIチャート、ログ、PR/commsへのリンクによるレポートの共有。
アラート衛生スコア：/FP/dedup/quorumによる複合インデックス。
ハンドオーバーの欠陥：アクティブなインシデントのコンテキストが失われたシフトの割合。
トレーニングカバレッジ：四半期にシミュレートされた％オンコール。

14）メトリクス実装チェックリスト

• ユニフォームタイムスタンプ（UTC）とインシデントイベント契約が定義されています。
• SEV、根本原因分類および検出源を採用。
• メトリックはボリューム（トラフィック/成功）に正規化されます。
• Ready 3ダッシュボード：エグゼクティブ、オペレーション、変更インパクト。
• Alert-as-Code：各ページルールにはプレイブックとオーナーがあります。
• SLA後死亡（例。ドラフト≤ 72chファイナル≤ 5スレーブ。日）。
• CAPAは効果KPIとD+14/D+30日付で追跡されます。
• ウィークリーインシデントレビュー：トレンド、トップの理由、CAPAステータス。

15）アンチパターン

MTTD/MTTA/MTTMのないMTTRのみを考慮してください。
ボリュームで正規化しない→大規模なサービスは「悪いように見える」。
システマティックでないSEV→異種インシデント。
改善の代わりに証拠→論争の欠如。
バーンインパクト/SLOインパクトの代わりにインシデントの数に焦点を当てます。
再オープンとCAPA→永遠の再発を無視します。
Telemetry/ITSMから自動アップロードせずにExcelのメトリクス。

16）ミニテンプレート

インシデントカード（abbr。）

INC: 2025-11-01-042 (SEV-1)
T0=12:04Z, Detected=12:07, Ack=12:09, Declared=12:11,
Mitigated=12:24, Recovered=12:48
Service: payments-api (EU)
SLI: success_ratio (-3.6% к SLO, burn=18 мин)
Root cause: provider (PSP-A), Trigger: status red
Comms: first 12:12Z, cadence 15m, SLA met
Links: dashboards, logs, traces, release notes

エグゼクティブレポート（28日、キーライン）

Incidents: 12 (SEV-0:1, SEV-1:3, SEV-2:6, SEV-3:2)
Median MTTR: 52 мин; Median MTTD: 4 мин; MTTA: 3 мин; MTTM: 17 мин
Detection Coverage: 88%; Actionable Pages: 86%; FP Pages: 3.2%
Change Failure Rate: 33% (4/12) — 3 связаны с конфигом
Reopen(90d): 1/12 (8.3%); CAPA Completion: 82% (2 просрочены)
Top Root Causes: provider(4), config(3), capacity(2)

17）ロードマップ（4-6週）

1.ネッド。1-Timestamp/field標準、SEV/reason辞書の基本的なインシデントのショーケース。
2.ネッド。2： MTTD/MTTA/MTTM/MTTRの計算、正規化およびSEVダッシュボード。
3.ネッド。3：リリース/コンフィギュレーション、検出カバレッジ、アラート衛生をバンドルします。
4.ネッド。4：エグゼクティブレポート、SLA死後、CAPAトラッカー。
5.ネッド。5-6：プロバイダーレポート、書き込み→$財務モデル、四半期ごとの目標、四半期ごとのインシデントレビュー。

18）ボトムライン

インシデントメトリクスは数字だけでなく、運用の信頼性のストーリーボードです。フロー全体（検出からCAPAまで）を測定し、メトリクスを正規化し、SLOや変更に関連付け、定期的にレビューすると、組織は予測的に応答時間、コスト、インシデント頻度を削減し、ユーザーは安定したサービスを見ることができます。