Google SRE 那本书讲到，OnCall 是 SRE 工作中极为关键的一环。毕竟，SRE 是要负责生产环境的稳定性，而 OnCall 则是保障生产环境稳定性的重要手段。国外非常重视告警 OnCall，有 PagerDuty 这样的专门的产品，很多公司都在使用，感觉已经是行业标配了，甚至连 NetFlix 都在用。
国内使用 PagerDuty 不太方便，一个是网络问题，另一个是全英文界面和 Support，对于国内的运维人员来说，使用起来有一定的障碍。另外就是 PagerDuty 和国内的 IM 接驳的不好，比如钉钉、飞书、企微等。但告警 OnCall 响应这个需求是很重度的一个需求，所以国内其实也有替代品，比如 Flashduty，就是比 PagerDuty 更轻量、更懂中国团队的告警协作平台。
核心要点
- 告警 OnCall 不是简单通知工具，而是把告警集成、降噪、认领、升级、协同和统计分析串成闭环。
- Flashduty 的核心价值在于统一接收多套监控系统的告警事件，再通过 Pipeline 做过滤、屏蔽、增强、聚合和分派。
- 对一线值班人员来说，关键能力是避免告警风暴、减少漏处理，并支持移动端快速响应。
- 对管理者来说，故障列表、排班和统计分析能帮助量化响应效率和治理效果。
为什么告警 OnCall 这么重要？
PagerDuty 是市值 20 亿美元的公司，妥妥的独角兽了。PagerDuty 只做一件事，就是告警 OnCall，为啥这个方向值得投入呢？显然是因为这个方向有痛点，而且天花板不低，SRE 或参与 OnCall 的 DEV 通常会有如何痛苦：
- 告警事件散落各处。一般公司都会有多套监控系统，指标的、日志的、云上的、自建的、开源的、商业的，告警事件散落各处，这导致规则也散落各处，人员信息重复维护，很不方便，如果想统一分析处理，就更难了。
- 告警风暴。某个底层基础设施或者服务故障，可能会引发告警风暴，产生大范围的告警，手机可能会响个不停，如果还有语音告警，那电话基本是不可用的状态，让处理人员很痛苦。
- 告警漏处理。告警 OnCall 的人可能会因为手机没电、没信号、静音、设备损坏，或者夜间深睡等原因收不到告警，最终导致告警漏处理。
为了解决以上问题，PagerDuty 这样的产品应运而生，Flashduty 也是这样的产品，专注于告警 OnCall，不被告警轰炸、不遗漏告警，让告警响应更轻松、从容。下面我们以 Flashduty 举例，看看 Flashduty 是如何解决这些问题的。
告警集成
Flashduty 支持与各种类型的监控系统集成，这些监控系统产生告警事件之后，统一发送给 Flashduty，Flashduty 做后续处理：
一般监控系统都会提供 Webhook 的方式和第三方系统集成，Flashduty 也是通过 Webhook 的方式接收告警事件，于是就可以协同在一起了。但是不同的监控系统产生的告警事件格式各异，需要一个统一格式化的过程，这是个脏活累活，需要 Flashduty 针对每个事件源做适配。
有些监控系统比较挫，不提供 Webhook 的方式，但是至少会提供邮件告警，此时 Flashduty 会生成一个专属的邮箱地址，监控系统配置告警邮件发送到这个邮箱地址，Flashduty 会解析邮件内容，生成告警事件。这种集成方式比较挫，但是 Flashduty 也能应对。
告警统一处理
告警事件进入 Flashduty 之后，会经过一个 Pipeline 来处理，比如：
- 告警过滤。把不需要的告警 Drop 掉。
- 告警屏蔽。根据一定的规则，把某些告警屏蔽掉，虽然还是会持久化但是不会通知。
- 再丰富。通常称为 Enrichment。告警事件中会有各种标签，通常要支持对这些标签做 relabel 的操作，而且还要和内部 CMDB 的数据打通，比如机器告警了，根据机器的 IP 自动获取机器的其他信息，比如机器的所属团队、机器的负责人等，把这些额外的信息附加到告警事件中。
- 持久化。把告警事件持久化到数据库中，方便后续查询。
- 收敛聚合。把相同的告警事件聚合在一起，通常称之为 incident，避免告警风暴，用户认领的时候可以以 incident 颗粒度认领，相当于一下子认领了一批告警。
- 认领、升级。用户可以认领故障，如果故障没有被认领，可以继续走升级流程，发给 Backup 的人员，直到有人认领为止，避免告警遗漏。
- 告警协同。大家可以对 incident 发表评论、关闭 incident，关闭 incident 的时候还可以写处理方法、经验总结，方便后续查看。
- 移动端支持。告警响应是个及时性很强的事情，所以 Flashduty 也有移动端 App，方便用户随时随地处理告警。
- 等等等等。
把这些动作串起来看，Flashduty 处理的不是单条消息，而是一条告警响应流水线：
| 阶段 | 解决的问题 |
|---|---|
| 接入与格式化 | 不同监控系统的事件格式不一致 |
| 过滤与屏蔽 | 不需要通知的告警不打扰值班人 |
| 再丰富 | 补充团队、负责人、业务、CMDB 等上下文 |
| 聚合与收敛 | 把大量相似告警合并成可处理的 incident |
| 认领与升级 | 明确谁负责，没人处理时继续升级 |
| 协同与沉淀 | 记录处理过程、评论、关闭原因和经验总结 |
下面这个图展示了 Flashduty 的告警处理流程：
上面都是一些逻辑性讲解，下面我们来看看 Flashduty 的界面，让大家有个感性的认识。
Flashduty 界面
首先看一个最常用的页面，即故障（告警的集合）汇总页面：
告警事件响应平台，是践行的 OnCall 文化，读过 Google SRE 那本书的朋友对这个概念应该很熟悉，没有 OnCall 排班不可能有 SRE 的落地，排班需要有个灵活的工具，下面就是 Flashduty 的排班页面：
作为管理者，希望能够量化告警、故障处理效率，作为一线员工，也希望能把工作量化，方便年终汇报，所以统计分析也是必不可少：
晚上朦朦胧胧接到告警电话，起床开电脑、连 VPN、打开监控系统，这样经历肯定很痛苦，一款事件 OnCall 的 App，移动办公，会提升很多幸福感，Flashduty 也提供了手机 App：
实际上，Flashduty 不止可以接收告警事件，也提供了告警引擎能力，可以直接对接时序库等各类存储，做告警判定，总之，跟告警相关的事情，Flashduty 都可以干，下面是告警规则管理页面：
适合优先接入的场景
| 场景 | 为什么适合先接入 |
|---|---|
| 公司有多套监控系统 | 先统一告警事件，减少人员和规则重复维护 |
| 经常出现告警风暴 | 用聚合、收敛和屏蔽降低无效通知 |
| 夜间告警容易漏处理 | 用排班、升级和多渠道通知提高触达确定性 |
| 故障处理缺少过程记录 | 用 incident 评论、关闭说明和统计分析沉淀处理过程 |
| 需要移动端响应 | 在手机 App 或 IM 中处理部分轻量动作，减少必须开电脑的场景 |
关于试用
Flashduty 产品介绍和试用地址如下：
FAQ
Q1：Flashduty 和监控系统是什么关系？ A：监控系统负责采集、存储、可视化和产生告警；Flashduty 负责把不同来源的告警统一处理、分派、降噪、认领、升级和协同。
Q2：只有 Webhook 才能接入 Flashduty 吗？ A：不是。原文场景中提到，部分监控系统如果只能发送邮件，Flashduty 也可以通过专属邮箱解析邮件并生成告警事件。
Q3：为什么要把多套监控的告警统一到一个平台？ A：因为告警分散会导致人员信息重复维护、事件难以统一分析、通知和升级策略不一致。统一平台可以把响应流程标准化。
结语
真正的运维革命，不是让工程师 24 小时待命，而是让系统替你时刻清醒。
