告警事件 OnCall 平台，如何选型
研发、运维人员在告警处理的时候，可能会经历如下困扰：
- 告警风暴，手机不停地响，打电话都打不出去
- 告警分散在多个平台，因为一个公司通常不止是一套监控系统，可能同时用了 Zabbix、Prometheus、Nightingale、云监控、Grafana、ElastAlert、还有各类商业产品自带的监控等等
- 没法协同，一个重要故障可能需要很多人协作解决，大家可能会拉个群，但是群里的消息很多，很零散，看起来很乱
- 移动办公不方便，告警可能是通过短信、邮件、钉钉机器人消息发出的，如果想评论、认领等，还需要打开电脑、登录 VPN、登录平台，操作起来很麻烦
- 告警容易遗漏，比如晚上睡着了没有听见，或者信号不好，或者手机静音了
这时候，一个好的告警事件 OnCall 平台很有必要，这里我介绍三个方案，两个开源方案一个商业方案，供大家参考。
方案一：Zabbix
Zabbix 内置的 PROBLEM 管理其实挺丝滑的，完成度很高，不但支持告警根据条件做分派、方便管理各类通知媒介，还支持 PROBLEM Update、PROBLEM 多环节升级，整体设计还是挺不错的。比如下面这个图，是 Zabbix 的分派规则：
在 Zabbix 里称为 Trigger Action，可以根据告警事件的属性做各种条件过滤，即不同的事件发给不同的人（通过不同的通知媒介），甚至还可以做多环节的升级、认领。如果你们公司就只有 Zabbix 这么一套监控系统，就使用 Zabbix 内置的 PROBLEM 管理也能解决大部分问题了。
但是，Zabbix 体系相对封闭，没法接入其他监控系统的事件，Zabbix 的设计初衷如此，没有办法。所以如果你们公司有多套监控系统，就需要考虑其他方案了。
方案二：Alertmanager
Alertmanager 一开始的设计就不止是针对 Prometheus 的，它就是提供了一个统一的告警事件接收的接口，不同的监控系统都可以把事件推给 Alertmanager，Alertmanager 做统一的告警屏蔽、抑制、分组、分派。即：对事件本身的处理做的比较到位，但是事件的发送设计的比较粗糙，Alertmanager 里没有人员信息，没法做排班、认领、升级、协同评论这类跟人有关的操作。
Alertmanager 更像是一个中间组件，各种的监控系统把告警事件发给 Alertmanager，Alertmanager 做一个初步处理，再投递给 PagerDuty 这样的组件。但是要把 Alertmanager 作为公司级统一的 OnCall 平台，还是不太够。但是开源社区基本也找不到其他方案了，Alertmanager 算是唯一一个稍微有那么点意思的项目了。
方案三：FlashDuty
FlashDuty 是 SaaS 产品，有免费套餐，专门做告警事件 OnCall 的统一平台，类似国外的 PagerDuty，因为 FlashDuty 是面向国内用户的，所以和国内的各类云监控、国内的 IM（比如钉钉、企业微信、飞书等）等都有很好的适配。作为一款统一的 OnCall 平台，FlashDuty 主要干了下面这些事：
- 对接各类监控系统，把告警事件统一接收
- 对事件做处理，比如过滤、Enrichment、Relabel 等
- 对事件做分派，支持按照各自条件做分派
- 支持排班管理
- 支持权限管理
- 支持协同评论
- 支持移动办公，不但可以和 IM 对接，还有 APP，可以在手机上处理告警事件
- 支持告警事件的统计、分析
- 支持认领、升级、转派、关闭等操作
- 支持告警降噪
- 支持和外部事件管理系统对接，比如 jira 等
毕竟，FlashDuty 就是专职做 OnCall 的，比 Zabbix、Alertmanager 更完善，当然了，主要是定位问题，Zabbix 的定位主要还是一个监控系统，Alertmanager 的定位，主要是一个告警事件的聚合平台，而 FlashDuty 的定位，就是一个专业的 OnCall 平台。
总结
告警事件 OnCall 平台是一个很重要的产品，Google SRE 就有 OnCall 文化，OnCall 文化的落地需要一个 OnCall 平台的支撑。本文列举了社区的两个方案以及一个商业方案，供大家参考。希望你们公司至少是有排班机制的，比每个人都要被告警吵醒，这就太让人崩溃了。
