1. 告警确认机制概述
告警确认机制是 On-Call 流程中用于标记“告警已被人工关注并正在处理”的显式操作。它并非简单的“已读”标记，而是 SRE 团队在告警风暴、值班交接、升级策略中维持事件处理秩序的核心手段。
1.1 什么是告警确认
告警确认（Alert Acknowledgment）是指值班工程师在收到告警通知后，通过监控平台或协作工具执行的一次显式操作，表明该告警已由特定人员接管，系统应停止向该人员重复发送通知，并进入后续处理或升级流程。
| 维度 | 说明 |
|---|---|
| 操作主体 | 值班工程师（Primary / Secondary On-Call） |
| 操作对象 | 一条或多条告警（支持批量确认） |
| 系统行为变化 | 停止重复通知、启动升级计时、记录确认时间戳 |
| 与“已读”的区别 | 确认是显式承诺处理；已读仅表示通知送达 |
关键认知： 确认 ≠ 解决。确认只表示“有人正在看”，不表示问题已修复。确认后告警仍可能升级，但升级对象会从当前确认人转向更高层级。
1.2 为什么需要确认机制
在无确认机制的告警系统中，每一条告警都会持续向所有值班人员发送通知，导致以下典型问题：
- 通知疲劳： 同一告警每分钟重复推送，值班人员被迫关闭通知或产生“告警麻木”。
- 责任模糊： 多人同时收到告警，但无人明确认领，事件在“我以为别人在处理”中延误。
- 升级失效： 系统无法判断告警是否已被关注，升级策略只能基于时间，无法结合人工状态。
- 审计缺失： 事后复盘时无法确定谁在什么时间点开始处理，MTTA（平均确认时间）无法统计。
引入确认机制后，上述问题得到系统性解决：
| 问题 | 确认机制提供的解决 |
|---|---|
| 通知疲劳 | 确认后停止向确认人重复推送，仅保留升级通道 |
| 责任模糊 | 确认操作绑定人员身份，形成明确的“当前处理人” |
| 升级失效 | 确认后启动升级计时，超时未解决则自动升级 |
| 审计缺失 | 记录确认时间戳，MTTA 成为可量化指标 |
1.3 确认机制在 On-Call 流程中的位置
确认机制位于告警生命周期中“通知”与“处理”之间的关键衔接点。下图展示了告警从产生到关闭的完整流程，其中确认阶段是区分“系统通知”与“人工处理”的分水岭。
实践要点： 确认机制的有效性高度依赖阈值策略的合理性。如果阈值设置过低，大量噪音告警涌入，值班人员会因疲劳而延迟确认甚至忽略确认操作；如果阈值过高，真实故障可能在确认前已造成业务影响。阈值调优的目标是让“值得确认的告警”恰好进入确认流程。
1.4 确认机制的核心指标
引入确认机制后，SRE 团队应建立以下可量化指标来评估告警流程的健康度：
| 指标 | 定义 | 典型目标 |
|---|---|---|
| MTTA | Mean Time to Acknowledge，从告警产生到首次确认的平均时间 | < 5 分钟（P0/P1） |
| 确认率 | 被确认的告警数 / 总告警数 × 100% | > 95% |
| 确认超时率 | 超时未确认导致升级的告警数 / 总告警数 × 100% | < 2% |
| 误确认率 | 确认后 5 分钟内又自动恢复或确认为误报的告警数 / 总确认数 × 100% | < 10% |
常见陷阱： 不要将确认率作为唯一考核指标。团队可能为了达成确认率目标而“一键确认所有告警”，导致确认机制失去筛选价值。应同时关注 MTTA 和误确认率，形成组合评估。