告别运维焦虑！Flashduty - 重新定义智能告警与值班管理的行业标杆

快猫运营团队 2025-03-03 10:28:27

Google SRE 那本书讲到，OnCall 是 SRE 工作中极为关键的一环。毕竟，SRE 是要负责生产环境的稳定性，而 OnCall 则是保障生产环境稳定性的重要手段。国外非常重视告警 OnCall，有 PagerDuty 这样的专门的产品，很多公司都在使用，感觉已经是行业标配了，甚至连 NetFlix 都在用。

国内使用 PagerDuty 不太方便，一个是网络问题，另一个是全英文界面和 Support，对于国内的运维人员来说，使用起来有一定的障碍。另外就是 PagerDuty 和国内的 IM 接驳的不好，比如钉钉、飞书、企微等。但告警 OnCall 响应这个需求是很重度的一个需求，所以国内其实也有替代品，比如 Flashduty，就是比 PagerDuty 更轻量、更懂中国团队的告警协作平台。

为什么告警 OnCall 这么重要？

PagerDuty 是市值 20 亿美元的公司，妥妥的独角兽了。PagerDuty 只做一件事，就是告警 OnCall，为啥这个方向值得投入呢？显然是因为这个方向有痛点，而且天花板不低，SRE 或参与 OnCall 的 DEV 通常会有如何痛苦：

告警事件散落各处。一般公司都会有多套监控系统，指标的、日志的、云上的、自建的、开源的、商业的，告警事件散落各处，这导致规则也散落各处，人员信息重复维护，很不方便，如果想统一分析处理，就更难了。
告警风暴。某个底层基础设施或者服务故障，可能会引发告警风暴，产生大范围的告警，手机可能会响个不停，如果还有语音告警，那电话基本是不可用的状态，让处理人员很痛苦。
告警漏处理。告警 OnCall 的人可能会因为某些原因收不到告警，比如手机没电、手机没信号、手机静音、手机丢了、手机被抢了、手机被摔坏了、手机被泡水了、手机被狗叼走了等等，或者就是晚上睡死了，各种奇怪的原因，导致告警漏处理。

为了解决以上问题，PagerDuty 这样的产品应运而生，Flashduty 也是这样的产品，专注于告警 OnCall，不被告警轰炸、不遗漏告警，让告警响应更轻松、从容。下面我们以 Flashduty 举例，看看 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 的告警处理流程：