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

【51CTO.com原创稿件】DataPipeline Head of AI 王睿在51CTO大咖来了公开课上作了题为《业务异常实时自动化检测 — 基于人工智能的系统实战》的分享，本文根据分享内容整理而成。

图片来自 Pexels

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

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

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

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

DataPipeline 的算法实现思路

DataPipeline 的系统架构

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

①无(半)监督机器学习算法为主

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

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

②算法跟业务解耦

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

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

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

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

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

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

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

④算法的扩展性和实时性

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

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

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

DataPipeline 的算法实现思路

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

①接入数据

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

②正常表现的建模

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

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

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!