作为一线 OnCall 人员，晚上被告警吵醒绝对是最痛苦的经历之一。这里的一线 OnCall 人员通常是运维人员；如果运维团队人少，各业务线研发也会参与 OnCall。
OnCall 产品不能让线上故障消失，也不能保证永远不用半夜起床。它真正能解决的是：减少无效告警、让真正重要的告警找到正确的人、避免全组被无差别打扰，并把响应过程管理起来。
本文给出一些优化举措，目标很朴素：尽可能让 OnCall 人员睡个好觉。
核心要点
- 夜间被频繁吵醒，根因往往不是通知方式，而是告警规则、排班机制和响应流程没有治理好。
- OnCall 文化需要管理层认可，否则一线人员的痛苦很难变成组织改进动作。
- 告警规则要尽量 actionable，即发出来以后能对应明确止损动作或 SOP。
- 收敛降噪、灵活分发和运营治理，是降低无效打扰、减少漏处理的关键能力。
文化和认知上重视
文化和认知永远是第一位的。
一线 OnCall 人员很痛苦，但如果老板、老板的老板不在意，大家沟通时就无法处在同一个频道。这个问题解决不好，再多工具也只是局部缓解。
解决好 OnCall 体验，可以极大提升员工幸福感，有时比加薪还管用。国内公司对员工值班体验的重视程度通常不够，有时也不是老板故意忽视，而是关注点在别的地方，没有看到这里的损耗。尝试跟老板沟通，大概率可以引起重视。
原文提到一个现象：海外有些运维人员面试时，会问公司是否使用 PagerDuty 这类产品；如果不使用，可能直接不去。背后的逻辑是，没有引入这类产品，往往意味着组织对 OnCall 工程师的工作负担不够重视。
轮班处理
OnCall 的确可以让工程师成长，因为它能让人直接面对生产环境问题。但它不能长期由固定几个人持续承担。
这类事情相对琐碎，而且晚上经常起夜，长期持续干会损耗身体和状态。
所以 OnCall 这个事，通常需要排班轮值，比如一周一拨人，下一周换另一波人，像 PagerDuty、Flashduty 这些专注 OnCall 的产品，都可以配置排班表，支持调班，支持对接国家法定节假日，支持临时调班等机制。
有些工程师其实是愿意 OnCall 的，因为 OnCall 可以双倍工资或调休，但是所有人都 OnCall 公司就受不了了，得支持巨大的成本，所以排班轮值，某种程度来看，是节省公司成本的办法，毕竟通过排班轮值可以让 OnCall 的人变少，公司支付的成本自然就变少。
什么？你们公司参与 OnCall 没有额外补贴？想个办法旁敲侧击一下让老板改革改革，如果老板装傻，那也没办法了。
优化告警规则
业内对于告警规则的配置，是有一些最佳实践的。典型的比如：
- 每个告警都是要 actionable 的，即对应止损动作对应 SOP 的
- 对结果类指标告警而不是对原因类指标告警，可参考这个文章
很多公司都是只要有故障，做复盘，第一个问题就是告警规则全不全，把员工搞得，宁愿多加告警规则，也不愿意被怼，管他合不合理呢。长期下来，会积累特别多的有用的没用的告警规则。痛苦不堪，痛苦到一定程度就离职或转岗，新人来了受不了，也会离职或转岗，长线来看，对团队对公司都是不好的。
每个告警都应该是 actionable 的，即对应止损动作和 SOP。如果告警发出来只是一个提醒，不需要对应止损动作，通常这个告警规则就是多余的。
如果你很担心漏掉某些信息，可以让这类告警自动创建 ticket，定期看一眼就完事了，不要电话、短信、邮件、钉钉一起轰炸。
对结果类指标告警而不是对原因类指标告警，看完上面的文章就了解了。简而言之，结果类指标是从上层使用方来衡量你这个服务是否健康。比如你对外提供一个 HTTP 服务，接口的成功率、延迟就是典型的结果类指标，是最应该关注的。至于这个服务的 CPU 利用率，通常就是原因类指标，原因类指标通常放到大盘里可观测就行了，不需要配成告警，因为原因类指标有问题，结果类指标通常也有问题，如果结果类指标没问题，那说明原因类指标通常尚未影响业务。顶多创建个 ticket，定期去看一眼就完事了。
| 告警类型 | 是否适合夜间强通知 | 处理建议 |
|---|---|---|
| 影响用户体验的结果类指标 | 适合 | 电话、短信或强提醒，并关联 SOP |
| 尚未影响业务的原因类指标 | 通常不适合 | 放入大盘观察，或自动创建 ticket |
| 只用于提醒的信息类事件 | 不适合 | 汇总到工单或日报，避免打扰值班人 |
收敛降噪
这是 PagerDuty、Flashduty 这类 OnCall 产品的核心功能之一。为了减少告警打扰，同时触发的 N 条告警可以归类成有限的几条 incident，仅以 incident 颗粒度做通知，不至于把你的手机打爆，反而影响了故障处理的效率。
当然，除了大规模实例告警，还有一些其他的可收敛场景，比如那种一会触发一会恢复一会又触发一会又恢复的告警，也可以通过 OnCall 产品收敛，或者自定义某些标签，具备相同标签的告警可以收敛为一个 incident，大幅降低告警频率。
灵活分发
监控系统通常侧重于监控数据采集、存储、可视化、告警，对于告警产生之后的处理、分发，通常做的比较简单。而 OnCall 类产品则会做的非常灵活，可以定义不同的告警不同的发送方式，哪些要 at 人哪些不 at 人，可以分时段定义不同的规则，甚至可以和工作日历集成，不同的告警可以定义不同的模板，定义不同的循环通知策略、升级策略等等。
大家如果体验过 Flashduty，就会发现，OnCall 产品还可以和钉钉、企微、飞书、Slack、Teams 等良好集成，实现移动办公，有时告警发生，睡意朦胧，对于一些短期不用处理的告警，掏出手机点几下就好，省得爬起来开电脑，也会大幅提升员工的幸福感。
运营治理
从公司全局来看，所有的告警接入一个 OnCall 平台来处理，就更容易分不同维度来统计 MTTR 等指标，进而优化薄弱点做优化；也可以看到哪些告警规则频繁触发，可能意味着规则本身不合理，既浪费了电话、短信费用，员工又不开心，服务的稳定性还没啥改观。
无数据不决策，对于那些走的比较靠前的公司，运营治理是一定要重点投入的。另外每周再发个周报啥的，让老板看到你们团队的付出和成绩，也是很重要的。
落地检查清单
| 检查项 | 判断标准 |
|---|---|
| 是否有明确排班 | 值班人、备份人、交接时间清楚 |
| 告警是否 actionable | 每条强通知告警都有止损动作或 SOP |
| 是否区分结果类和原因类指标 | 结果类指标优先强通知，原因类指标更多用于观察 |
| 是否做收敛降噪 | 同类告警能聚合为 incident，抖动告警能减少重复打扰 |
| 是否有升级机制 | 未认领或未恢复时能通知备份人员或负责人 |
| 是否做运营分析 | 能看到 MTTR、频繁告警、通知成本等治理线索 |
FAQ
Q1：用了 OnCall 平台就不会半夜起床了吗？ A：不能这么理解。OnCall 平台降低的是无效打扰和漏处理概率，真正影响业务的故障仍然需要有人响应。
Q2：哪些告警应该电话或短信强通知？ A：优先是影响用户体验或业务结果的告警，例如接口成功率、延迟、核心链路可用性。只用于提醒的信息类告警不适合夜间强通知。
Q3：告警太多时应该先做什么？ A：先审查告警是否 actionable，再按结果类指标优先、原因类指标观察的思路做规则治理，随后再配置收敛、抑制和升级策略。
参考资料
- PagerDuty 官网：https://www.pagerduty.com/
- Flashduty 介绍：https://www.flashduty.com
