一张图说清告警值班 Oncall 的流程

[laiwei]

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

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

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

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

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

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

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

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

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

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

原文链接： https://flashcat.cloud/blog/oncall-concept/

[hxndg]

写得不错。。。不过有个问题，这流程没啥用。。。。

比方说“告警集成”，“标签增强”这都是如果有故障出现就会自然而然具有的，适配日常的消息流
而“聚合降噪”，“告警抑制”这个是防止噪声出现，被 annoy 自然就会有
“值班轮班”，“认领”，“协同”是因为人手不足或者专业性不足
“升级”，这个是直接根据故障登记和灾备能力决定的

感觉也就“数据统计”有些用。。。。

总之是先有的自然而然的流程，才有的纸面的流程。。。。

[laiwei]

@hxndg 你可以看看国外的 PagerDuty 案例，国内的 Flashduty 的案例。oncall 是一个现实问题，有标准解法。

[hxndg]

@laiwei 我并不否认 oncall 是现实问题，有标准解法。
我想表达的是：信息化的前提是必须是现实先标准/信息化，电子化只是流程的最终结果。

我原先有几年做 infra ，写过流程信息化的代码，也做过流程自动化的内容。最麻烦的往往不是聚合或者认领，分诊啥的。而是第一步的可流程和可采集。