事件指標

1）為什麼要測量事件

事件指標將混亂事件轉變為受控過程：幫助減少響應和恢復時間，減少原因的可重復性，證明SLO/合同的執行並找到自動化點。一組好的指標涵蓋了整個周期：檢測→分類→升級→聯想活動→恢復→分析CAPA →。

2）基本定義和公式

事件間隔

MTTD （Mean Time To Detect）=從T0（實際影響開始）到第一個信號/檢測的平均時間。
MTTA（指向認知時間）=從第一個信號到呼叫ack的平均時間。
MTTM （Mean Time To Mitigate）=將影響降低到SLO閾值以下的平均時間（通常=解決方法/UX降解之前的時間）。
MTTR （Mean Time To Recover）=目標SLI完全恢復之前的平均時間。
MTBF（遇險時間之間）=相關事件之間的平均間隔。

運營時間

時間到決定-從T0到正式宣布SEV級別/事件。
時間到Comms-從公告到SLA的第一個公共/內部升級。
狀態時間-每個階段的持續時間（triage/diag/fix/verify）。

頻率和分數

事件計數-在此期間發生的事件數量。
事件率-在1k/10k/100k成功交易或查詢（正常化）上。
SEV Mix-重量分布（SEV-0…… SEV-3）。
SLA Breach Count/Rate-違反外部SLA的數量/比例。
Change Failure Rate是更改引起的事件（版本/configi/遷移）的百分比。

信號和過程的質量

可操作頁的百分比是導致有意義的花花公子行動的頁面的比例。
假正值（Pages）-假陽性的比例。
Detection Coverage-自動檢測到的事件比例（不是客戶/支持）。
Reopen Rate-重復發生與≤90天相同的根原因的事件的比例。
CAPA Completion-按時關閉的糾正/警告行動的百分比。
Comms SLA Adherence是按所需頻率發布的升級的比例。

3）事件階段的度量圖

階段	關鍵指標	一個問題
檢測到	MTTD, Detection Coverage, Source Mix (monitoring vs users)	問題發現的速度有多快？
反應	MTTA, Time to Declare, Page-to-Ack %, Escalation Latency	團隊動員並分配SEV的速度有多快？
Mitiging	MTTM, Workaround Success %, Change Freeze Latency	影響降低到安全水平的速度有多快?
恢復	MTTR, SLO Burn Stopped Time, Residual Risk Window	服務何時完全恢復正常？
Comms	Time to Comms, Comms SLA Adherence, Sentiment/Complaints	通訊員的質量和時間是多少？
培訓	Postmortem Lead Time, CAPA Completion/Overdue, Reopen Rate	我們學習並關閉改進循環嗎?

4）規範化和細分

將計數器歸一化（流量、成功操作、活動用戶）。
按區域/tenant、提供商（PSP/KYC/CDN）、更改類型（代碼/config/infra）、白天時間（日/夜）、檢測源（synthetic/RUM/infra/support）進行細分。
業務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小時（Tier-1）。
檢測覆蓋：≥ 85%自動化。

% Actionable Pages: ≥ 80–90%;FP Pages: ≤ 5%.

Reopen Rate (90д): ≤ 5–10%.

CAPA Completion（按時）：≥ 85%。

6）原因歸因和變化的影響

為每個事件分配一個主要原因（Code/Config/Infra/Provider/Security/Data/Capacity）和trigger（發布ID、config更改、遷移、外部因素）。
運行更改鏈接的MTTR/Count-發行版和configs的貢獻程度（門戶/金絲雀政策的基礎）。
單獨考慮提供者輔助事件（PSP/KYC/CDN/Cloud）來管理路線和合同。

7）通信和客戶影響

第一次公共更新和更新學分的時間（例如，每15/30分鐘）。
Complaint Rate-關於1起事件的滴答聲/投訴，趨勢。
Status Accuracy-未退回的公共升級比例。
後事件NPS（按關鍵客戶計算）是SEV-1/0後的短暫推動。

8）事件周圍的Alerting質量度量

Page Storm Index是事件發生時每通話一個分頁數/小時（中位數/p95）。
Dedup Efficiency-被抑制重復的百分比。
Quorum Confirmation Rate是觸發法定探測器（≥2獨立來源）的事件比例。
Shadow→Canary→Prod新規則的轉換（警報作為代碼）。

9）Dashbords（最低設置）

1.Executive （28天）：事件數量,SEV分發,MTTR/MTTM, SLA breaches, Reopen, CAPA。

2.SRE Operations: MTTD/MTTA по часам/сменам, Page Storm, Actionable %, Detection Coverage, Time to Declare/Comms.

3.Change Impact：與發布/config相關的事件百分比，用於更改事件的MTTR，服務窗口vs事件。
4.Providers：供應商事件、降級時間、路線切換、合同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想法）

期間的MTTR（中位）：

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');

Detection Coverage:

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';

Change Failure Rate （28天）：

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燃燒分鐘是事件的主要的「重量」。
按總燃燒量和SEV重量而不按事件數量對CAPA進行優先排序。
將burn與財務沖擊縫合（例如：$/分鐘停機或$/丟失的交易）。

13）過程成熟度度量（程序級別）

Postmortem Lead Time：從事件結束到發布報告的中位數。
事件完整性：具有時間線、SLI圖表、日誌、公關/通用鏈接的報告比例。
警報Hygiene得分：按可操作/FP/dedup/定額計算的復合索引。
Handover Defects：活動事件上下文丟失的班次比例。
培訓覆蓋率：本季度通過模擬的呼叫百分比。

14）指標實施清單

已定義單一時間標簽（UTC）和事件事件合同。
采用了SEV字典，原因（root cause taxonomy）和檢測源。
將度量標準化為體積（流量/成功操作）。
準備好3個dashboard： Executive, Operations, Change Impact。
警報作為代碼：每個頁面規則都有花花公子和所有者。
SLA後太平間（例如草稿≤72ch，結尾≤5奴隸。天數）。
CAPA使用KPI效果和D+14/D+30日期進行跟蹤。
每周事件評論：趨勢，頂級原因，CAPA狀態。

15）反模式

僅計算沒有MTTD/MTTA/MTTM的MTTR →早期階段的可控性喪失。
在數量上不正常化→大型服務「似乎」更糟。
隨意的SEV →事件的不可比性。
缺少Evidence →爭議而不是改進。
專註於事件數量而不是burn/SLO影響。
忽視Reopen和CAPA →永恒的復發。
「在Excel中」不自動從遙測/ITSM卸載。

16）迷你模板

事件卡（縮寫。）


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

Executive報告（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：時間標簽/字段標準，SEV/原因詞典；基本事件展示。
2.奈德。2：MTTD/MTTA/MTTM/MTTR計算，正常化和SEV-dashbord。
3.奈德。3：與發布/configs、Detection Coverage和Alert Hygiene捆綁在一起。
4.奈德。4：執行報告，後太平間的SLA，CAPA跟蹤器。
5.奈德。5-6：提供者報告，財務模型burn→$，季度目標和季度事件評論。

18）結果

事件指標不僅僅是數字，而是操作可靠性的故事板。當你測量整個流程（從檢測到CAPA），規範指標，將它們與SLO和更改相關聯，並定期進行審核時，組織可以預測地降低響應時間，成本和事件重復性-用戶可以看到穩定的服務。

事件指標

事件間隔

運營時間

頻率和分數

信號和過程的質量

Detection Coverage:

事件卡（縮寫。）

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案