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

图片来自 Pexels

王睿，之前在 Facebook/Instagram 担任 AI 技术负责人，现在 DataPipeline 任 Head of AI，负责研发企业级业务异常检测产品，旨在帮助企业一站式解决业务自动化监控和异常检测问题。

分享主要从以下四方面跟大家分享构建该产品的思路和实战：

• 为什么需要人工智能业务异常检测系统

• 搭建该系统的挑战和设计理念

• DataPipeline 的算法实现思路

• DataPipeline 的系统架构

为什么需要人工智能业务异常检测系统

企业会因为业务异常无法得到及时解决而遭受较大的损失，比如某知名互联网企业，将原价为 50 元的优惠券以 18 元卖出，导致用户在短时间内大量疯抢，损失惨重。

同样，在金融、零售、电商领域因为 IT 系统的 Bug 或人工原因导致的业务异常也给企业造成了不可估量的经济损失。

然而，在业务异常出现时，企业往往在几天甚至几个星期之后才会发现。 以某公司为例，其主营业务为线上借贷，有次放款率突然增加，此时距离出现问题已经过去十几个小时。

后果是将钱款借给了许多不具备借贷资质的人，导致回款率和营收大幅下降。

为此，随着企业业务的持续高速增长以及信息化的全面普及，业务人员需要对业务变化有一个全面实时地掌控。

这时，IT 运维人员会关心服务器和网络的运行； 产品负责人会关心用户访问，点击率和用户体验等； 业务负责人则关心业务的核心 KPI，如销售额。

这些指标犹如一个人的心跳、血压、体温，反映企业业务的健康状况。

如何能快速准确地从业务指标中识别异常，发现问题根因，并及时解决对企业而言就显得尤为重要。

目前针对这块，不同企业采取的方法各异。 传统的业务监控方法往往是手工生成报表每天查看，对于比较重要且实时性要求较高的指标，会人工设定阈值，当指标跨过阈值时报警。

对于已知周期性的指标一般会用类似同比环比的方法。随着企业业务量和业务种类的不断提升，人工的监控也随之增多。

而这种基于人工的方法则会显示出几大不足：

①大量业务指标没有被实时监控。 以电商为例，若只监控总销售额，采用人工方法很容易实现。

但是，一旦某些地区或品类的销售额出现异常，只看总销售额指标则很难发现问题。

例如某零售企业，其酸奶的销售额在某地区较之前有所下降，原因是酸奶的库存出现了周转问题。

由于一直售卖过期酸奶，导致接到大量用户举报。 针对该情况，若只监控总销售额很难发现问题，这时需要监控品类和地区两个维度更细粒度的指标。

而监控多个维度的指标，指标监控的数量会成倍增长，显然是人工无法胜任的。

②告警洪流。 当业务出现问题时，往往报警的接收人员会收到大量告警，使得他们被告警洪流淹没，很难精准定位问题根因。

除了告警的准确率低以外，还由于业务指标之间具有很强的相关性，主要体现在两个方面：

首先是指标之间的链路关系。 比如在电商零售领域，当服务器错误增高时导致用户访问下降，从而导致下游的订单减少。

另外是指标的多维度特性， 例如当订单下降时，往往多个产品线，多个地区订单量同时下降。

因此当业务出现问题时，往往是多个相关的指标一起告警，形成告警洪流。

③误报漏报。 作为业务负责人，既不想在业务出现问题的最后一刻才知道，也不想在凌晨三点被一个假警报叫醒。

而多次的误报会导致“狼来了”的效应，当真正的问题出现时，告警却往往容易被接收人员忽略掉。

④人工维护成本。 随着业务的不断变化，大量的告警阈值和规则需要人工调整，而这显然跟不上业务的变化速度和监控指标不断增多的节奏。

因此我们需要一套自动化的智能业务监控和异常检测系统，通过对指标变化规律的学习，自动掌握指标数据正常和异常的表现模式，从而全面，实时地监控企业业务不同层面，不同维度的各项指标。

这就是为什么我们需要搭建基于人工智能算法的业务异常检测系统的原因。

搭建该系统的挑战和设计理念

人工智能算法在异常检测领域已经被研究了几十年，但是搭建这样的系统却并非易事。 主要的挑战有以下几点：

第一，对于异常的定义较为模糊且各种数据指标的表现形式千差万别。

比如 IT 的 CPU 异常与销售额异常不同，因此试图用一种通用的算法检测不同类型指标的异常往往准确率很低。

因为某一类数据的异常表现形式放在另一类数据指标中可能就不会被认为是异常。 另外，在未来发生的异常很多时候是过去并未见过的。

这直接导致了第二个难点，即很难获取标注数据。

不仅很难标注一个数据的变化是否是异常，且异常出现的频率较低，很难像传统机器学习问题那样获得很多正负样本。

第三，对该算法和系统的实时性和可扩展性要求很高。

如果不能实时监控大量指标，发现异常并告警，这个系统将失去其意义。

为解决上述痛点，同时考虑到种种挑战，DataPipeline 在设计该系统前确定了几点设计原则：

①无（半）监督机器学习算法为主

虽然目标是将数据分类为正常或异常，但由于异常的定义模糊，很难获取标注数据，我们主要采取无监督的机器学习算法。

当然，对于给用户发送的告警，系统需要可以收集用户的反馈，然后用在提升算法的准确性上。 综合来讲，这是一种半监督学习的方法。

②算法跟业务解耦

人工智能算法的优势在于解放人工，做到自动化，因此算法需要跟业务尽可能解耦。

算法可以通过对于指标历史数据本身模式（如周期性）的学习来建模。 而不同业务指标数据的表现形式各异，总体上时序数据的表现类型是有限的，因此我们需要算法具备根据不同表现形式选择不同模型的能力。

③异常相关性学习和根因分析

上面讲到的一个很大的痛点是告警洪流。 当业务出现问题时，业务人员往往被淹没在大量告警中，很难快速准确地定位问题。

因此我们需要学习监控指标之间的相关性，当业务出现问题时给用户一个汇总的告警，这样不仅能避免告警洪流，还能让用户一目了然地看到反映问题的相关指标，从而更快找到问题根因。

从产品角度而言，这也是一个成熟的业务异常检测系统中很重要的组成部分，即根因分析。

我们不仅希望及时地反应业务问题，也希望能缩小发现问题到解决问题的时间和成本。

④算法的扩展性和实时性

算法和整个系统需要做到对亿级数据指标的秒级实时响应。 因此我们主要考虑应用轻量级并且支持线上学习（Online Learning）的算法模型。

近些年深度学习在异常检测领域的应用逐渐成熟，其相较于传统的统计模型算法具有更强的泛化能力。

但这些算法的训练成本较大，因此需要对实时性要求更高的指标系统进行取舍。

DataPipeline 的算法实现思路

基于以上设计原则，DataPipeline 提出了解决问题的几个步骤：

①接入数据

首先利用 DataPipeline 自身的数据集成能力，从不同数据源中接入实时的数据流或批式的数据集并进行预处理，形成多个指标的时序数据。

②正常表现的建模

进而对每个单一的指标时序数据学习其正常表现模式，拟合模型，并自动生成置信区间。

如下图，深蓝色部分为数据本身，浅蓝色部分为自动生成的置信区间，红色部分为异常。

③异常的检测和过滤

对于新的数据点，一旦其跨过置信区间系统便认定为异常。 接着对于每个识别出的异常进行打分和过滤。

④关联多个异常并自动报警

对检测出的多个异常，算法自动进行相关性学习，将其关联起来。 最后生成一个汇总的告警，发送给用户。

下面重点解释对单一数据的正常表现建模，异常检测和关联多个指标异常的具体技术实现。

单一数据的正常表现建模

在过去数十年里，许多不同类型的算法被研究和开发来尝试解决这一问题。

其中有较为传统的基于统计模型的算法，也有许多基于时序数据的分析方法，而近年来大热的深度学习模型也被证明在时序数据预测和异常检测上有较高的准确性。

这些算法一般遵循这样一个步骤： 先对历史数据进行建模，学习数据正常表现的规律。

对新来的数据点，根据数据点偏离正常表现模型的程度来判定是否为异常。

比如最简单的算法模型是高斯分布，假设该指标数据符合高斯分布，就可以通过历史数据点估计出高斯分布的 mea n和期望（均数）μ 和标准差 σ，进而对新的数据点判定。

如果偏离期望多于三个标准差则该数据点不能被模型解释的概率为 99.7%，我们就可以判定其为异常。

然而实际情况是，大部分数据都无法简单地表现为高斯分布。 因此，首先我们需要根据数据本身来自动选择最适合的算法模型。

这也是很多开源的异常检测算法直接被拿来使用往往得不到满意效果的一个原因。

因为他们一般假设数据的底层表现是平稳的（Stationary），并且数据是规则取样的（Regular Sampling），若使用不适合的算法模型对数据建模会得到非常不好的效果，甚至完全无法使用。

因此 DataPipeline 开发了一个算法，可以自动根据数据的表现形式选择最合适的算法进行拟合。 最常用的算法可以分为基于统计模型的算法和深度学习的算法。

统计模型算法： 除了上面提到的高斯分布，比较常用的模型有基于指数平滑（Exponential Smoothing）的模型，实际是对过去的数据进行平均来预测未来的数据，只是给时间上更靠近当下的数据点更大的权重。

比较经典的有 Holt-Winters，ARIMA 等，这些还可以将周期性的规律考虑进去。

深度学习算法： 对于不符合规则取样和不表现为 Staionary 的数据，深度学习算法的效果更好。

LSTM（Long Short-Term Memory）是最常用的算法，而当下许多最新的算法都是基于 LSTM 上的变种。

然而深度学习算法很难做到实时训练，即模型随新的数据点实时更新，而且当监控数据量大的时候非常耗费 CPU。

算法自动选择出最合适的模型后，系统便可根据历史数据拟合模型，估计出模型参数，进而针对每个数据点给出预测。

对于实际数据点和预测数据点的差异（error）我们可以用高斯分布来模拟，利用高斯模型计算出一个置信区间，当新数据的 error 偏离置信区间过大时将其判断为异常。

周期性学习

许多指标数据都表现出明显的周期性，而周期性学习对异常检测的准确性至关重要。

最常见的自动学习周期性方法是自相关学习（Autocorrelation）。 简言之，该算法是将数据向过去平移一个时间差（Lag），然后计算平移后的数据和原来数据的统计相关性。

如果某一个 Lag 平移后的数据和原数据相关性很大，则认为该 Lag 就是数据的周期性。 此算法的主要问题是计算量较大，因为要对多个 Lag 进行计算。

鉴于上面提到的实时性和可扩展要求，DataPipeline 对该算法用 Subsampling 的方法进行优化，降低了计算复杂度。

相关性学习

之前提到为解决告警洪流问题，我们需要一个算法可以自动化计算指标间的相关性，在多个异常同时出现时，可以将反映同个业务问题的异常关联在一起，给用户一个汇总的告警。

针对这类问题，一般传统的方法是采取多变量分析（Multivariate Analysis），即将所有时序数据当成互相有关联的多变量一起建模，然后在整体层面检测异常。

该方法的主要问题是很难规模化，且当出现异常时检测结果的解释性较差。

因此，在 DataPipeline，我们采用单变量分析对每个指标进行异常检测，然后利用大规模聚类算法将相关度较高的指标进行聚类（如上图）。

这样每个指标的机器学习和相关性学习两部分可以各自规模化，使得整个系统计算效率更高。

而聚类算法通过几类特征来进行计算：

异常表现的相似度： 简言之，如果两个指标多次、同时出现异常，则认为两者更相关。

我们可以生成一个异常表现的特征向量，若在某个时间点该指标表现正常便设置为 0，若表现异常则设置为异常的打分（算法根据异常的严重程度自动打分）。

统计模型的相似度： 即指标的数值是否有相似的模式。 其中计算两个时序数据数值相似度最常见的算法是 Pearson Correlation Coefficient。

元数据相似度和人工反馈： DataPipeline 还根据元数据的拓扑关系来判断相关性。

比如同一个指标的多个维度生成的多个子指标会被认为更相关。 此外，用户也可自己输入一些信息告诉系统哪些指标更相关。

DataPipeline 的系统架构

若构建一套企业级业务监控和异常检测系统应该具备哪些组成部分？ 下面为 DataPipeline 的一些思路。

①产品功能组成

从产品功能角度而言，该系统可以接入企业的各种业务系统（左边），包括核心业务系统和各种已有系统，诸如数据分析，监控系统等。

挑战是如何将多源异构的数据以一致的方式接入，且同时可以处理流式和批式数据。

DataPipeline 已有的数据融合产品可以很好地实现这点。 如果企业自己搭建，则需要根据具体情况确定实现方式。

另外，针对中间的系统内核，我们将其设计成了一个跟业务完全解耦的黑盒。

右边则是用户交互 UI，包括两部分：

• 告警系统， 可根据企业的报警需要接到企业交流 App 如钉钉、邮件，电话等。

• 监控看板，可以看到监控的指标数据，搜索不同指标和多维度展示。

另外，还可看到指标异常的汇总展示，根因展示等。 从看板上用户可以根据展示出的异常进行反馈，表明这是正确的异常还是误报，另外还可调整指标异常检测的敏感度。 这些反馈和调整会返回到系统中。

②核心系统架构

核心系统主要分为线上处理和线下模型训练两部分。 线上部分处理实时的数据指标最新数据流，从模型存储数据库中读入模型并存于内存中，对数据流中每一个数据指标进行实时的阈值计算、异常检测和打分。

之后多个数据指标的异常检测结果会被汇总到一个关联性处理器，进行异常的关联，最后将关联好的异常指标组汇总，生成并触发告警。

在处理实时指标数据时，处理器会将最新的指标数据和检测出的异常分别写入数据库为线下训练做准备。

线下部分会定时从数据指标的历史数据库中读取数据并进行线下的模型训练，这其中便包括上面提到的算法自动选择，周期性学习等。 也会定期利用用户返回的反馈对模型进行评估，计算出误报漏报率等。

总结

业务异常的不及时解决会给企业带来巨大的经济损失。

相对于传统的人工生成报表和人工阈值的监控方法，基于人工智能的业务异常检测系统可以更自动化，更全面地监控业务各项指标并给出准确率更高，更有帮助性的报警和业务洞见。

而搭建这样一套系统面临业务数据表现形式多样，告警过多准确率低下等挑战。

伴随着企业级人工智能业务异常检测系统的出现，企业可以更高效、及时全面的掌控业务，从而实现业务和经济效益的提升。

想观看完整视频，请点击“阅读原文 ” 查看回放