一张图说清告警值班 Oncall 全概念

OnCall 不是单纯的排班表，而是一套围绕告警事件的响应系统。它把监控工具、告警事件、责任人、通知渠道、认领动作、升级路线和数据统计串起来，让故障在发生后能被快速发现、明确分派、持续跟进。

核心要点

• 告警 OnCall 平台的核心对象是“告警事件”，不是某一个监控系统。
• 告警集成、标签增强、聚合降噪和告警抑制，解决的是事件质量问题。
• 值班排班、认领、升级、转派和协同，解决的是人员响应问题。
• 通知和移动端处理体验，决定工程师是否能在真实故障中快速行动。
• MTTA、MTTR、告警压缩率和认领比例，是衡量 OnCall 体系有效性的关键指标。

一张图里的 OnCall 全流程

1. 告警集成

告警集成的目标，是在一个 OnCall 平台上处理所有告警。常见监控工具通常具备 webhook 能力，因此 OnCall 平台可以为不同监控工具提供接口适配，降低用户配置成本。

对于不够开放的监控工具，如果只支持邮件通知，OnCall 平台能够接收邮件并解析内容，也可以作为兜底的告警集成方式。

2. 标签增强

告警信息中的标签越丰富，工程师接收到告警后处理起来越高效。现实情况中，很多监控工具发送出来的告警只有有限字段，例如机器名、监控项、阈值。

如果能对接外部元数据，例如 CMDB，对告警字段进行扩充，就可以利用扩充后的标签自动分派告警。工程师也能更快判断影响面和严重程度。

3. 聚合降噪

对相似告警进行聚合、对频发告警进行收敛，可以显著降低告警数量，减少对工程师的无效打扰。基于规则、基于语义相似度都是可行的聚合方式。

告警聚合可以跨监控数据来源。例如来源于 Zabbix 的告警和来源于 Prometheus 的告警，如果描述的是同一类问题，就可以聚合到同一个事件视图中。

4. 告警抑制

告警抑制可以是高级别告警抑制低级别告警，也可以是底层基础设施告警抑制上层模块告警。它的本质是引入某种依赖关系。

需要注意的是，依赖关系的维护成本较高，也不容易解释。因此，告警抑制适合在关系明确、收益明显的场景使用，不建议在大规模场景里重度依赖。

5. 值班排班

值班排班的目的，是避免整个团队被经常性打断。日常值班、节假日值班、临时调班、公平轮换，都是排班时要考虑的因素。

值班轮换交接时要有清晰通知机制。值班人也要有角色概念，例如主值班人和备值班人，用来区分第一响应和兜底响应。

6. 认领

理论上，所有有效告警都需要被认领。如果一个告警发送出来后没有人认领，也没有产生任何不良后果，那这个告警很可能是无意义的，就不应该发送出来。

通常可以用 MTTA 量化告警认领的效率和效果。MTTA 越短，说明告警从触发到有人接手的链路越顺畅。

7. 升级与转派

针对不同等级的告警提前建立清晰升级路线，可以降低 OnCall 工程师的心理压力，也有助于快速、准确地解决问题。

告警升级可以是手动升级，也可以是自动升级。例如某个告警超过 30 分钟未被处理且未恢复，就自动升级到主管或者备份人员，确保问题最终得到及时处理。

8. 协同

在告警处理过程中，可以随时引入相关人员协同。添加协同人时，需要准确、及时地通知对方，并把告警处理过程和时间线清晰保留下来，供协作方快速了解全貌。

9. 通知

国外 Slack 可以连接大量周边生态，很多协同工作在 Slack 中完成。国内则主要围绕微信/企业微信、飞书、钉钉展开。

这些 IM 支持开发应用。在 IM 内置应用中接收告警、认领、关闭、转派和处理，是提升 OnCall 体验的关键方法。

10. 数据统计

告警压缩率、MTTA、MTTR、告警认领比例、告警数量，是衡量 OnCall 效率的关键指标。按业务、团队、个人等维度分析这些指标，可以推动告警优化和治理，让 OnCall 更有效率。

OnCall 能力速查表

常见问题

Q1：OnCall 平台和监控系统是什么关系？ A：监控系统负责发现异常并产生告警，OnCall 平台负责告警事件后的分派、通知、认领、升级、协同和统计。

Q2：为什么不能把所有告警都发到群里？ A：群通知看似简单，但责任不明确，容易出现“大家都看见了，但没人接手”的情况。OnCall 机制强调当前责任人和认领动作。

Q3：告警降噪是不是只做聚合就够了？ A：不够。聚合只解决重复告警问题，标签增强、抑制、分派、值班和升级共同决定告警是否真正可处理。