关于告警，要想做好，从这些方面着手

各类监控系统都会产生告警事件，于是，就产生了 FlashDuty、PagerDuty、Opsgenie 这类产品，做告警事件的收敛降噪、排班认领升级等。如果你想增强自己公司的告警事件处理能力，参考（chao xi）这些产品的功能就可以了 😎。

• 告警集成：目标是在一个 Oncall 平台上处理所有告警，一般常见的监控工具，都有对接 webhook 的能力，因此 Oncall 平台可以对不同监控工具进行接口适配，提供一个相应的 webhook，对用户来说配置成本最低。还有一些不那么开放的监控工具，可能只对外提供了发邮件通知的方式，如果 Oncall 平台能够接受这些邮件并对内容进行解析的话，也是一种兜底的告警集成方式。

• 标签增强：告警信息中的标签越丰富，工程师在接收到告警的时候处理起来就更高效。现实情况中很多监控工具发送出来的告警只有光秃秃的有限的几个字段，比如机器名、监控项、阈值，如果能对接外部元数据（比如 CMDB），对告警的字段进行扩充，那就可以利用扩充出来的字段，更自动化的分发告警，以及在处理故障的时候，让工程师能快速判断告警的影响面和严重程度。

• 聚合降噪：对相似的告警进行聚合、对频发的告警进行收敛，能够显著降低告警数量，减少对工程师的无效打扰。基于规则、基于语义相似度都是可行的聚合方式。告警的聚合，可以跨监控数据来源，比如来源于 Zabbix 的告警和来源于 Prometheus 的告警，如果“相似”，就可以聚合。

• 告警抑制：可以是高级别的告警抑制低级别的告警，也可是底层基础设施的告警抑制上层模块的告警，总而言之是引入了“某种依赖关系”。这些依赖关系的维护成本较高，且不容易解释，不推荐大规模场景重度使用。

• 值班排班：目的是避免整个团队被经常性打断。日常值班、节假日值班、临时调班、公平轮换都是排班时要考虑的因素，值班轮换交接时，要有清晰的通知机制。值班人也要有角色的概念，比如主备值班人。

• 认领：理论上来说，所有的告警都需要被认领。如果一个告警发送出来后，没有人认领，也没有产生任何不良的后果，那这个告警是无意义的，就不应该发送出来。通常会用 MTTA 量化告警认领的效率和效果。

• 升级/转派：针对不同等级的告警，提前建立清晰的升级路线，会降低 Oncall 工程师心理压力，有助于快速、准确的解决问题。告警升级可以是手动升级，也可以是自动升级，比如当某个告警超过 30 分钟未被处理，且未恢复，那么就自动升级到主管或者备份人员，确保问题最终得到及时的处理。

• 协同：在告警处理的过程中，可以随时把相关的人员拉进来协同（通常，把相关人员拉齐，问题就解决了一半，如果能自动创建 warroom 就更好了），添加协同人时需要准确及时的通知到对方，并把告警处理的过程和时间线，清晰的保留下来，供协作方快速了解全貌。

• 通知：国外 Slack 可以连接巨大的周边生态，很多协同工作是在 Slack 中完成的，说是协同领域的操作系统也不夸张；在国内那就是企微、飞书、钉钉三足鼎立了，这些 IM 支持开发应用，在这些内置应用中接收告警、认领、关闭、转派、处理，是提升 Oncall 体验的关键方法。移动办公的体验感，用过都说好。

• 统计分析运营：告警压缩率、MTTA、MTTR、告警认领比例、告警数量是衡量 Oncall 效率的关键指标，通过按业务、按团队、按个人等维度分析以上指标，能够有效的推动告警的优化和治理工作，让 Oncall 更有效率。

这类产品缺少开源项目，可能是随着越来越多的开源作者养家糊口都困难，没人愿意用爱发电了。如果有预算，建议上 FlashDuty，我觉得这是东半球最好用的 OnCall 产品。