事件指标

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:

事件卡（缩写。）

联系我们

快速联系

视频即将更新

我们目前正忙于各项项目