FlashDuty 简介

FlashDuty 告警响应平台 - 图1

说它小而美，是因为它确实非常专注，只解决一个问题，就是运维领域的告警响应问题。可以看做是 PagerDuty 的国内平替。 理论上，好产品一定是经过深度打磨的，打磨是需要大量人力的，所以摊子铺得越大投入就越大，专注在一个细分领域的产品反而更容易取得成功。 FlashDuty 具体解决哪些痛点需求呢？大概可以归为如下几点：
  • 告警统一收集的需求，解决「监控系统多，告警事件分散，配置分散，人员信息重复维护在多个地方」等问题。
  • 告警统一响应的需求，在一个地方查看、处理所有监控系统的告警，统一做告警聚合降噪、排班、告警升级、分派。还要提供 App、和 IM 打通等移动办公手段。
  • 告警统一分析的需求，告警统一到一个地方，统一结构化、再丰富，进而可以统一分析，不但可以分析 MTTA、MTTR 等常规指标，也可以喂给 AI，往智能化方向探索。
为啥这些需求不能直接在监控系统中搞定呢？核心原因有二。一是监控系统的侧重点就不在这，监控系统侧重在数据采集、存储、分析、生成告警事件，对事件的后续处理流程关注较少；二是监控系统有方向侧重，比如 Zabbix 侧重在设备、Cacti 侧重网络、Prometheus 侧重微服务、云监控侧重云上资源，所以监控系统来做这摊事，也只能处理自身生成的告警事件，不够全面。 那 FlashDuty 是如何解决这些需求的呢？或者说，其产品主要思路是？

FlashDuty 产品思路

几乎所有监控系统都支持通过 Webhook 的方式把告警推送给第三方，所以首先 FlashDuty 就要基于这个机制去对接各类监控系统，这是个脏活累活，不过对接的越多竞争力越大。

FlashDuty 告警响应平台 - 图2

上图是 FlashDuty 已经对接的监控系统，还在持续增加中… 事件进入 FlashDuty 之后，会走一个 Pipeline，对事件进行规整、过滤、再丰富、持久化、聚合、分派等一系列逻辑，最终递达通知媒介，其逻辑就类似下面这个图：

FlashDuty 告警响应平台 - 图3

当然了，魔鬼在细节，即便是一个细分领域的产品，也有很多需要打磨的点，下面走马观花，简单看一些系统截图。

FlashDuty 产品截图

首先看一个最常用的页面，即故障（告警的集合）汇总页面：

FlashDuty 告警响应平台 - 图4

告警事件响应平台，是践行的 OnCall 文化，读过 Google SRE 那本书的朋友对这个概念应该很熟悉，没有 OnCall 排班不可能有 SRE 的落地，排班需要有个灵活的工具，下面就是 FlashDuty 的排班页面：

FlashDuty 告警响应平台 - 图5

作为管理者，希望能够量化告警、故障处理效率，作为一线员工，也希望能把工作量化，方便年终汇报，所以统计分析也是必不可少：

FlashDuty 告警响应平台 - 图6

晚上朦朦胧胧接到告警电话，起床开电脑、连 VPN、打开监控系统，这样经历肯定很痛苦，一款事件 OnCall 的 App，移动办公，会提升很多幸福感，FlashDuty 也提供了手机 App：

FlashDuty 告警响应平台 - 图7

实际上，FlashDuty 不止可以接收告警事件，也提供了告警引擎能力，可以直接对接时序库等各类存储，做告警判定，总之，跟告警相关的事情，FlashDuty 都可以干，下面是告警规则管理页面：

FlashDuty 告警响应平台 - 图8

关于试用

FlashDuty 产品介绍和试用地址如下： 通过他们的产品介绍页面可以看到，有不少企业用了 FlashDuty，比如海底捞、吉野家、益丰、海大、保时捷、地平线、紫光云 等，看起来还是比较靠谱的。