OnCall 文化值得落地，晚上被告警吵醒的概率确实大大降低了

被告警折磨的SRE 2024-07-08 00:06:10

作为一线 OnCall 人员（通常是运维人员，如果运维人员较少，各个业务线的研发也会参与 OnCall），晚上被告警吵醒绝对是最痛苦的经历之一。本文给出一些优化举措，尽可能让 OnCall 人员睡个好觉。

文化和认知上重视

文化和认知永远是第一位的，你作为一线 OnCall 人员，你挺痛苦，但是你的老板、老板的老板根本不在意，沟通时无法处于同一个频道，鸡同鸭讲，那就没辙了。其实解决好这个问题，是可以极大提升员工幸福感的，有时比加薪还管用。国内公司对员工的重视程度通常不太够，有时也不是老板故意而为之，实际是他的关注点在别的地方，没关注到这里，尝试跟老板沟通一下，大概率可以引起老板的重视。据说海外有些运维人员去面试，会问公司是否使用 PagerDuty 这样的产品，如果不使用，直接就不去了，因为没有引入这类产品，本质上就是对 OnCall 工程师的忽视。

轮班处理

OnCall 这个事，的确可以让工程师成长，但是不能长期持续干，这类事情相对琐碎，而且晚上经常起夜，长期持续干，身体就废了。

所以 OnCall 这个事，通常需要排班轮值，比如一周一拨人，下一周换另一波人，像 PagerDuty、FlashDuty 这些专注 OnCall 的产品，都可以配置排班表，支持调班，支持对接国家法定节假日，支持临时调班等机制。

有些工程师其实是愿意 OnCall 的，因为 OnCall 可以双倍工资或调休，但是所有人都 OnCall 公司就受不了了，得支持巨大的成本，所以排班轮值，某种程度来看，是节省公司成本的办法，毕竟通过排班轮值可以让 OnCall 的人变少，公司支付的成本自然就变少。

什么？你们公司参与 OnCall 没有额外补贴？想个办法旁敲侧击一下让老板改革改革，如果老板装傻，那也没办法了。

优化告警规则

业内对于告警规则的配置，是有一些最佳实践的。典型的比如：

每个告警都是要 actionable 的，即对应止损动作对应 SOP 的
对结果类指标告警而不是对原因类指标告警，可参考这个文章

很多公司都是只要有故障，做复盘，第一个问题就是告警规则全不全，把员工搞得，宁愿多加告警规则，也不愿意被怼，管他合不合理呢。长期下来，会积累特别多的有用的没用的告警规则。痛苦不堪，痛苦到一定程度就离职或转岗，新人来了受不了，也会离职或转岗，长线来看，对团队对公司都是不好的。

每个告警都是要 actionable 的，即对应止损动作对应 SOP 的。如果告警发出来只是一个提醒，不需要对应止损动作，通常这个告警规则都是多余的，如果你很担心漏了什么天大的事情，那就让这类告警自动创建 ticket，定期去看一眼就完事了，不要打电话、发短信、发邮件、发钉钉的。

对结果类指标告警而不是对原因类指标告警，看完上面的文章就了解了。简而言之，结果类指标是从上层使用方来衡量你这个服务是否健康。比如你对外提供一个 HTTP 服务，接口的成功率、延迟就是典型的结果类指标，是最应该关注的。至于这个服务的 CPU 利用率，通常就是原因类指标，原因类指标通常放到大盘里可观测就行了，不需要配成告警，因为原因类指标有问题，结果类指标通常也有问题，如果结果类指标没问题，那说明原因类指标通常尚未影响业务。顶多创建个 ticket，定期去看一眼就完事了。

收敛降噪

这是 PagerDuty、FlashDuty 这类 OnCall 产品的核心功能之一。为了减少告警打扰，同时触发的 N 条告警可以归类成有限的几条 incident，仅以 incident 颗粒度做通知，不至于把你的手机打爆，反而影响了故障处理的效率。

当然，除了大规模实例告警，还有一些其他的可收敛场景，比如那种一会触发一会恢复一会又触发一会又恢复的告警，也可以通过 OnCall 产品收敛，或者自定义某些标签，具备相同标签的告警可以收敛为一个 incident，大幅降低告警频率。

灵活分发

监控系统通常侧重于监控数据采集、存储、可视化、告警，对于告警产生之后的处理、分发，通常做的比较简单。而 OnCall 类产品则会做的非常灵活，可以定义不同的告警不同的发送方式，哪些要 at 人哪些不 at 人，可以分时段定义不同的规则，甚至可以和工作日历集成，不同的告警可以定义不同的模板，定义不同的循环通知策略、升级策略等等。

大家如果体验过 FlashDuty，就会发现，OnCall 产品还可以和钉钉、企微、飞书、Slack、Teams 等良好集成，实现移动办公，有时告警发生，睡意朦胧，对于一些短期不用处理的告警，掏出手机点几下就好，省得爬起来开电脑，也会大幅提升员工的幸福感。