一个Bug损失200亿!如何搭建业务异常检测系统?( 二 )


这就是为什么我们需要搭建基于人工智能算法的业务异常检测系统的原因 。
搭建该系统的挑战和设计理念
人工智能算法在异常检测领域已经被研究了几十年,但是搭建这样的系统却并非易事 。主要的挑战有以下几点:
第一,对于异常的定义较为模糊且各种数据指标的表现形式千差万别 。
比如 IT 的 CPU 异常与销售额异常不同,因此试图用一种通用的算法检测不同类型指标的异常往往准确率很低 。
因为某一类数据的异常表现形式放在另一类数据指标中可能就不会被认为是异常 。另外,在未来发生的异常很多时候是过去并未见过的 。
这直接导致了第二个难点,即很难获取标注数据 。
不仅很难标注一个数据的变化是否是异常,且异常出现的频率较低,很难像传统机器学习问题那样获得很多正负样本 。
第三,对该算法和系统的实时性和可扩展性要求很高 。
如果不能实时监控大量指标,发现异常并告警,这个系统将失去其意义 。
为解决上述痛点,同时考虑到种种挑战,DataPipeline 在设计该系统前确定了几点设计原则:
①无(半)监督机器学习算法为主
虽然目标是将数据分类为正常或异常,但由于异常的定义模糊,很难获取标注数据,我们主要采取无监督的机器学习算法 。
当然,对于给用户发送的告警,系统需要可以收集用户的反馈,然后用在提升算法的准确性上 。综合来讲,这是一种半监督学习的方法 。
②算法跟业务解耦
人工智能算法的优势在于解放人工,做到自动化,因此算法需要跟业务尽可能解耦 。
算法可以通过对于指标历史数据本身模式(如周期性)的学习来建模 。而不同业务指标数据的表现形式各异,总体上时序数据的表现类型是有限的,因此我们需要算法具备根据不同表现形式选择不同模型的能力 。
③异常相关性学习和根因分析
上面讲到的一个很大的痛点是告警洪流 。当业务出现问题时,业务人员往往被淹没在大量告警中,很难快速准确地定位问题 。
因此我们需要学习监控指标之间的相关性,当业务出现问题时给用户一个汇总的告警,这样不仅能避免告警洪流,还能让用户一目了然地看到反映问题的相关指标,从而更快找到问题根因 。
从产品角度而言,这也是一个成熟的业务异常检测系统中很重要的组成部分,即根因分析 。
我们不仅希望及时地反应业务问题,也希望能缩小发现问题到解决问题的时间和成本 。
④算法的扩展性和实时性
算法和整个系统需要做到对亿级数据指标的秒级实时响应 。因此我们主要考虑应用轻量级并且支持线上学习(Online Learning)的算法模型 。
近些年深度学习在异常检测领域的应用逐渐成熟,其相较于传统的统计模型算法具有更强的泛化能力 。
但这些算法的训练成本较大,因此需要对实时性要求更高的指标系统进行取舍 。
DataPipeline 的算法实现思路
基于以上设计原则,DataPipeline 提出了解决问题的几个步骤:
①接入数据
首先利用 DataPipeline 自身的数据集成能力,从不同数据源中接入实时的数据流或批式的数据集并进行预处理,形成多个指标的时序数据 。
②正常表现的建模
进而对每个单一的指标时序数据学习其正常表现模式,拟合模型,并自动生成置信区间 。
如下图,深蓝色部分为数据本身,浅蓝色部分为自动生成的置信区间,红色部分为异常 。

一个Bug损失200亿!如何搭建业务异常检测系统?

文章插图
 
③异常的检测和过滤
对于新的数据点,一旦其跨过置信区间系统便认定为异常 。接着对于每个识别出的异常进行打分和过滤 。
④关联多个异常并自动报警
对检测出的多个异常,算法自动进行相关性学习,将其关联起来 。最后生成一个汇总的告警,发送给用户 。
下面重点解释对单一数据的正常表现建模,异常检测和关联多个指标异常的具体技术实现 。
单一数据的正常表现建模
【一个Bug损失200亿!如何搭建业务异常检测系统?】在过去数十年里,许多不同类型的算法被研究和开发来尝试解决这一问题 。
其中有较为传统的基于统计模型的算法,也有许多基于时序数据的分析方法,而近年来大热的深度学习模型也被证明在时序数据预测和异常检测上有较高的准确性 。
这些算法一般遵循这样一个步骤:先对历史数据进行建模,学习数据正常表现的规律 。


推荐阅读