告警能力中台设计与实践（三）—

告警能力中台设计与实践（三）——告警通知

一、告警消息与告警通知

正如笔者在最开始所写的那样，第三方服务通过调用能力中台的OpenAPI实现告警发起，并且每一次的告警请求都会创建、归档为一条告警消息（AlarmMsg）。

这样的消息是无状态的，并且对应的消息会外键关联到对应的告警原子事件（AlarmEvent）。

当告警请求送达并处理后，如果满足告警实际发送条件（例如第一次或不在收敛周期内），此时中台会根据对应的告警策略执行告警通知动作，并根据通知类型的不同，生成

这样的通知同样是无状态的，并且会外键关联到对应的告警消息（AlarmMsg）。

（1）基本逻辑
对于企业而言，会使用工作IM软件来进行工作内容的沟通。这类IM软件大部分都会提供OpenAPI，以实现类似AI聊天机器人等功能。

因此，平台通过调用此类OpenAPI，实现了告警信息及时推送到相应的IM群组中。

（2）群组分层分级
对于服务的告警而言，本身就是有等级的，不同的等级划分关注度自然也是不同，这点在告警IM消息的发送上也是一样。

一般来说，对于特别紧急、生死攸关的问题，都会直接拉起Warroom群，这类告警肯定需要第一时间响应。
而很多提示、轻微的告警如果也发送到这样的Warroom群，肯定会引起不必要的紧张。

基于上述需求，笔者按照告警的阶段、等级，提供了灵活的群组配置方法：

综上，笔者一共提供了十六个配置的选择，服务可批量配置、也可以单个自主调节群号。

（1）基本逻辑
工单也是企业对于问题处理的必要手段，可以规范的进行提交、接受、处理和闭环。

该部分总体逻辑比较简单直接：

（1）基本逻辑
打电话与发短信本质上都是通过电话号码实现的消息通知。通知内容会进行一定的自然语言处理，方便接收者能够快随了解问题所在。

具体打电话/发短息的方法也很简单，同样是使用了公司层级的电话通知服务所提供的OpenAPI。

（2）OnCall机制
对于应该通知给谁，这一点很重要，毕竟人也不可能是连轴转的，OnCall也是人，需要轮换。

因此，笔者提供了OnCall的配置机制，除了保底的SRE作为OnCall外，还会提供对应的班次、周期等，提供批量配置、导入导出等手段，方便快速配置电话短信接收人。

随着第三方告警请求接入数量越来越多，平台处理请求、发起告警的压力也会越来越多大，性能风险也越来越高。
针对这个问题，笔者主要提出了以下几个解决办法：

确保告警接口访问可控
- 告警OpenAPI仅支持通过网关授权的方式调用；
- 不接受其他一切形式的调用请求；
限流
- 针对每个授权的APPID进行分钟、小时、天级限流；
- 针对接口本身进行分钟、小时、天级限流；
- 系统底层通过组件的方式监控基础指标、提供限流能力；
三方调用原则约束
- 公告三方服务避免过度频繁调用接口致使限流，导致重要告警未能发送出后果自负；
异步执行
- 所有告警请求均通过异步任务的方式分配到CeleryWorker执行，避免同步堆积；
提升服务性能与监控水平
- 提升整体集群性能与吞吐量；
  - 提高集群CPU与内存；
  - 提高RDS（数据库）参数；
  - 增加告警相关的Celery队列Worker数量；
- 积极监控自身服务各项指标，利用运维平台自身告警能力进行监控；

在上面的问题中，虽然笔者解决了高请求量性能问题，但异步任务带来的高并发又可能会带来数据的一致性问题。

例如极短时间内接受到两条相同告警，由于集群与异步带来的函数执行问题，最后极端情况下可能会生成两颗几乎一模一样的事件树。
针对这个问题，笔者的解决方法是：

对于整个部门而言，会有专属的Warroom群组，生产环境的致命告警均会发送到该群中，方便各服务、SRE快速响应、定位问题。

一般情况下群组的消息数量是比较少的，但是当较大规模批量故障产生时，Warroom群会被海量的消息淹没。
针对这个问题，笔者提出两个措施：

针对Warroom发送的消息有数量限制，同一个Region下一段时间内（15分钟）只能发送5条消息；
- 超过5条后，Warroom群组通知操作会被取消；
每10分钟会根据当前仍未恢复的生产致命告警事件，进行Warroom通报；
- 一方面避免可能的致命告警消息遗漏；
- 另一方面也让相关人员了解目前故障的处理进展；

由于本身这类致命告警会有其他通知手段（电话、短信、提单、服务群组），因此这样的收敛也不会让服务漏通知，仅仅为了提升公共Warroom群组的体验。