背景
在业务的质量保障过程中，主动预警是较为重要的一项，可以帮助我们提前发现问题，尤其是权益过期，库存耗尽，资源位过期等问题，等到监控发现时再恢复，再快也快不过提前预警，因此，我们探索在业务各个方面实现主动预警监控的能力。
▐ 预警范围
预警第一步，是要先搞清楚，在我们项目质量保障过程中，需要主动预警的项到底有哪些，这是一种探索发现的过程，最初我们遇到最多的问题，就是活动配置过期，红包库存不足，但随着深入了解业务，我们发现有更多需要预警的点，我们对配置划分以下几类：
第一类是活动/资源位配置过期，不同业务域可能用到了不同的配置后台，有淘宝特价版自建的运营后台，也有集团的各种活动配置、资源位配置平台，这些地方都会存在配置过期的问题。
第二类是权益，权益包含集团统一权益，也有自建运营平台权益，还有其他资格券权益等，权益类主要是库存不足，权益过期问题。
第三类是开发常用的配置平台，有些开发会将一些时间配置在这些平台上，这里的配置过期也会导致业务异常。
第四类是实验，人群这类过期，也会导致业务异常。
第五类是舆情类，包括淘宝特价版和手淘的舆情。
▐ 预警流程
在确定了预警范围后，我们需要确定预警及接手处理的流程。这块我们借鉴了集团技术风险平台的风险预警机制，并结合自己的业务实践，最终确认以下的流程：
![]()
其中，预警告警，群内通知，预警升级，预警接手处理结单这部分流程，风险平台已经有了成熟的能力，可以基于我们直接复用了这块能力，剩下的事，就是如何将需要预警的内容接入进来了。
我们基于此搭建了预警数据采集能力，对接各个平台数据，制定适合业务的预警规则，逐步根据我们先制定优先级，对资金相关的，前台资源位等项进行高优先级的覆盖，实现整套主动预警体系。
![]()
核心解决方案
在预警能力建设中，遇到的主要问题如下：
针对这些问题，给出了一些通用的解决方案来实现
▐ 解决方案
在建设各项预警能力中，不同的预警类型有不同特点，因此我们建设了不同的能力来解决不同的问题。
平台类配置预警方案
平台类配置预警，遇到最大的问题，是平台较多，各个平台获取的数据来源不同，因此，平台需要支持多种数据源获取方式，并定义一个通用的数据模型，来清洗获取到的数据。
平台的接口、离线数据表、消息等获取平台配置数据，在平台上自定义预警规则，根据规则发送告警，利用风险平台的预警接手机制来跟进问题。
权益类预警方案
权益类预警是我们最关注的预警，也是最复杂的场景，里面主要有几个问题：
第一个问题，我们从我们的资金监控脚本中找到了灵感，资金监控的离线表是整体业务维度每天的发放的红包，因此，我们只要从这个表中获取全部的权益code，就可以覆盖到线上生效中的全部权益。
第二个问题，在通过接口获取到权益的库存后，通过历史采集的数据，来预测当前的库存够用多少时间，以此来判断是否需要预警，在发出预警工单后，让运营来接手处理。
我们通过实验了多个预警规则来查看问题处理率：
过期预警规则
-
工作日24小时内过期预警
-
周五3天内过期预警
-
自定义日期筛选过期（节假日、大促）
库存预警规则，我们在探索多个预警方式
-
低于固定数值后告警
-
总量低于10%后告警
-
根据流速告警
流速计算公式：
库存剩余可用时间 = 今日x点的剩余库存/( (今日x点的剩余库存-昨日x点剩余库存)/24)
库存剩余可用时间<24，触发告警
预警流程如下：
通过实践发现，24小时级别的流速预警在实际使用过程中接手率最高，误报率最低。
不过，我们发现如果在权益在短时间内消耗特别快，还是无法预警到，这块后续会建设分钟级的极速消耗预警方案。
配置预警方案
部分开发在配置平台中配置了时间字段，因此时间过期也是需要预警的问题，这个核心解法是通过全量扫描制定应用的配置平台配置中的关键字，如time，date等，发现配置的Key和value中存在此字段，就解析对应的值，来检查是否满足过期告警时间。
![]()
实验预警
实验平台本身自带了较完善的告警能力，但是随着人员流动较频繁，因此不少实验的owner离职转岗后，告警无法告到对应负责的同学，因此，我们通过扫码本业务实验的离线数据表，找到过期的实验，如果负责人无法预警到，就通知到指定同学。
舆情预警方案
舆情预警，主要是通过算法聚类与场景打标的方式来实现，这个是用了体验引擎现有能力，告警到淘宝特价版的舆情预警群内。
![]()
