我们观察到，绝大部分公司都不止一套监控系统，比如同时使用了 Cacti、Zabbix、Prometheus、Open-Falcon、Nightingale、ElastAlert、Grafana 中的一款或多款，还用了阿里云（阿里云有3套监控：云监控、Arms、SLS）、腾讯云、华为云、AWS 等云厂商监控产品，通常会有以下痛点：

• 💥 告警事件散落在各处，没法在一个统一的地方统计、分析、协同
• 💥 监控系统重点是搞定数据采集、可视化、告警事件产生，事件的后续处理关注较少，比如缺少告警聚合、告警升级等能力，即使有些监控系统把这些能力也做了，但是是自闭环的，无法把能力共享给其他监控系统
• 💥 人员信息散落在各处，要改个手机号需要去多个系统同步修改
• 💥 没法和IM（飞书、钉钉、企微）良好打通，比如没法在IM里完成告警认领、屏蔽等逻辑，没有手机App或H5，不方便移动办公
• 💥 事件的处理分析通常是缺失的，比如发了多少事件，消耗了多少手机、短信费用，平均认领/响应时间，平均恢复时间等相关统计分析是缺失的
• 💥 缺少灵活的排班机制，落地SRE实践首先得做好排班，非OnCall的人就可以心无旁骛的干一些长线的工作

这些烦恼，我们懂！从创业第一天，我们就规划了这个产品，取名 FlashDuty（👈 点击快速体验），经过一年的打磨，是时候公开了！下面为大家分享一下我们的设计思路。

多事件源支持

告警事件散落各处，那就统一收集到一个中心，大部分监控系统都提供Webhook能力，通过Webhook的方式对接起来，FlashDuty目前支持了常见的事件源，当然，您也可以通过自定义事件推送接口直接推送。

订阅分组能力

这么多系统都对接进来，事件五花八门，都混在一起太混乱了，可以利用订阅规则把不同的事件分组到不同的协作空间。比如云平台的告警，分到云平台协作空间，由相关的研发和运维去处理，支付中台的告警，分到支付中台的专属协作空间，由相关的研发和运维去处理，各个团队的告警都类似的方式去处理。

当然，也可以为协作空间创建专属集成，让某个些事件进来就直接进入特定的协作空间，无需订阅规则。两种路由方式的详细区别可以参考这篇文章：FlashDuty协作空间的设计逻辑和路由逻辑

灵活的通知策略

针对不同的告警，可以设置不同的通知策略，比如高级别的告警使用电话通知，低级别的告警只使用邮件和IM通知：

我们点开某个通知策略，看看支持哪些配置：