亿级用户百TB级数据的AIOps技术实践之路

毕宏飞

作者简介

周荣，华为消费者BG云运维部 AIOps 负责人，GOPS 2018 深圳站金牌讲师，07年加入华为，先后分别负责下一代智能网、中间件平台、运维工具等产品的研发与规划，在分布式系统、大数据分析处理、高并发连接、运维工具等场景有丰富的实践经验；15年初起负责运营商领域的软件运维工具平台、17年初起加入消费者BG云服务部，负责云运维部运维大数据的研发与规划，倡导数据化精准化智能化运维理念，目前着力于AIOps 能力的运维实践提升；

说明

本文整理自 GOPS 2018 深圳站现场记录，第一稿发布后，各方反馈积极，为了促进大家在AIOps领域业务与技术交流，本文作者在此加强版本中，特别补充了第一版中的部分缺图，展示了更多华为消费者 BG 云运维部 AIOps 实践的直观内容。

前言

今天我给大家带来的分享议题是《亿级用户百TB级数据的AIOps技术实践之路》，主要有以下五个点：

1、华为消费者业务介绍
2、云服务运维面临的挑战
3、AIOps 实践之路：数据价值（业务监控）
4、AIOps 实践之路：数据平台
5、AIOps 实践之路：数据智能

一、华为消费者业务介绍

首先介绍一下华为的消费者BG业务，华为有三个BG，运营商、消费者、企业。17年华为6036亿元总收入中，消费者BG 2372亿，占比39.3%，其中手机发货量1.53亿台，全球份额已突破10%。

[更新图 邮件PPT附件 P1页]

图中列出了华为消费者BG的主要产品：华为&荣耀手机、笔记本&平板、穿戴设备、智能家居、软件应用。其中软件应用包含了操作系统EMUI 和各种应用业务，我所在的云服务部门主要负责各类应用业务。

今天我分享的主题中有一个描述是亿级用户，我们来看下一组数据，在这张图里，我们能够看到这个用户规模以及所带来的业务量量级。

截止17年底，华为帐号，注册用户3.3亿，到今天这个用户数还在不断增长。随着业务量的增长，云存储、PUSH、运动健康等业务量也随之保持着持续高速增长。PUSH 的并发能够直观体现用户使用情况，华为主题的杂志锁屏相信很多华为手机用户朋友都很喜欢，另外运动健康，虽然用户数是4600万多，但是数据活跃度很高，运维大数据处理量上，有近1/8是这个业务贡献的。在本图中下方，还列举了其他业务，总的来算，云服务运维部负责的内外部业务，有100余个。

二、云服务运维面临的挑战

随着用户量和业务量的持续高增长，如何维系上面提到的100余款内外部业务，快速发展下，我们面临着严峻挑战。除了传统的业务上线变更，站点可靠性、业务运营保障工作外，我们还需要做好业务用户体验质量的日常保障工作。

综合来看，我们主要面临着三大挑战：

2.1 面临的三大挑战

2.1.1 业务多、形式多样

现在已有100余个内外业务，后续可以预见的是还会不断增加。而每个业务场景是不同的，比如帐号、应用市场、云相册、音乐、视频等。业务场景不同，带来的数据内容与格式都是多种多样的，这是我们面临的第一个实际挑战。

2.1.2 数据价值与数据成本间的平衡

第二个就是数据价值和数据成本之间的平衡，可以说这方面是数据团队一定要搞清楚的关键点，否则产品和团队都无法持续健康发展，这里我说下数据价值中的“熵”减问题。比如平时大家经常会碰到的成功率、转换率、到达率等指标，如果业务上报上来的数据就是这类“率”的指标，那么很不幸，熵减已经发生；比如想进一步看到业务版本分布、操作系统分布、地域分布等，比如以前想看到的是小时级数据，后续要提升到分钟级甚至秒级，是不是要重新做？这类数据变更成本要从源头来修改上报，成本是很高的。

另外，之前我们提到过用户体验保障工作，这里比如说，应用市场下载应用的时候，可能有一个总的下载成功率，但对于用户保障是远远不够的，比如总指标只降了0.5%不到，实际上对于某款应用上已经是10%等很高了；这也是所提到的监控指标的“煽”减问题。

随着大数据技术的发展，数据平台能力不断增强，这里必然会让我们在数据价值上做更多的事情，这背后就是技术变化带来理念和相关的变化。以前在采集端做统计的，一个数据的统计变更，意味着开发团队要出版本、运维要帮助上线，变更成本高、变现周期长，现在，这类变更落地在数据团队，其实已经是非常方便的。

2.1.3 数据规模大，增长速度快

这个挑战很好理解，业务增长速度快，运维数据价值变现程度高，那么带来的相关运维数据增长就会很快，比如去年底我们处理量已达到2000亿/天左右，现在一天处理数据量已增加到2600亿，而这这个增长只花费了三个月时间。17年3月开始做这套系统前，每天只有4T的数据，17年底已经是快120TB；不仅是对数据平台的处理能力要求越来越高，同时，随着数据的增加，这里还带来一个新的问题：以前数据量少，都是人去看数据的，随着数据越来越多，数据洪水带来的找价值数据成本也越来越高。这就是挑战三。

2.2 业界的趋势-AIPOps

“这是最坏的时代，也是最好的时代”，狄更斯描述工业革命发生后的一句话，在此借用下，我更换了下顺序。在面对这些挑战时，可以看到这个时代不是某个团队或者某个公司在战斗，而是整个行业。

Gartner 在16年发布的报告中首先提出了基于大数据及算法的IT运维概念。紧接着在17年，Gartner的 AIOps 概念已经从基于大数据及算法，扩充为基于人工智能。由此可见，AIOps的发展趋势之快。这页我借用了 AIOps 行业里三张比较有代表性的图：

第一张图展示了 AIOps 所处的发展阶段，应该说当前还是比较初级阶段，里面的机会和风险并存，我个人觉得这个行业的趋势方向上没有太大的问题，所以更多要看到的是，我们当前正处于浪头刚刚起来的时候；

第二张图描述了当前的 AIOps 主要是基于大数据和机器学习，来持续提升监控、服务台、自动化的效率；

第三章图描述了AIOps在数据处理的两个层级，从数据到信息的阶段，以及从信息到知识的阶段。

2.3 面对挑战的对策

回到刚才的困惑，我们已经说过这三个方面的挑战，面对这三个方面就是三板斧。

一是降低数据的接入成本，我们不能对业务部门提特别多的要求，如果你要想那么去做，你会发现要做成一件事情不知道要等到猴年马月，所以，一定要降低数据的接入成本。

二是围绕数据价值带来的数据处理诉求，构建数据处理平台能力。从4T到120T的速度，其实我们自己也被吓了一跳，当时我们发现有段时间怎么老是数据不稳定？这个时候我们看一下数据已经达到40多T，也是这个时候我们才开始监控每个业务每个数据源的处理量（一开始来不及做）。价值做好了，数据自然源源不绝，所以运维数据平台一定要高性能。在这里，我们还加入了低成本开发的限定，为什么低成本开发？虽然数据团队做数据计算变更是很方便的，但是也得有技术支撑它做到方便，所以开发成本一定要低，否则你把前端的成本挪到了后端，而后端被拖垮也是很悲催的事情。而且数据平台不做好，信息到知识这个阶段，会遇到更多的问题。

第三点，就是有了数据，大家很爽，以前看不到的能够看到了，接下来，发现数据太多了，就会提出能不能帮我们提升效率（加一句：“懒”促进了整个人类社会的进步）。这个时候，就需要我们根据应用场景构建起智能化的运维服务，这里我也提到“学件”这个词。这是南京大学周志华教授2016年针对当前机器学习环境适应低、数据共享难等局限提出的新概念。这里我也加入了自己的理解，以前我们在做软件1.0的时候，交互方式是接口名、参数名来定义，到了AI阶段我们发现搞不定，模型训练、算法的专业性很强，数据算法研究员的专业内容并不是运维开发工程师或者运维工程师能够完全清楚的（在AIOps白皮书团队角色描述里列举了三者之间的协同），大部分人能够懂的就是预测的曲线和异常跟实际情况相比对不对，阈值是高了还是低了，剩下的交给学件（软件2.0）来自动学习适配。因为专业性强，我认为反而让交互方式变简单了，打个点餐的比方，软件1.0阶段是，我要吃鱼香肉丝，我要吃辣的或是素一点的，根据清晰的接口上菜。而软件2.0阶段就是，我今天想吃开心一点的，然后菜就上来了。学件的提出，说明 AIOps 给大家带来的已经不再是枯燥的接口，而是变成很友好的用户交互来解决业务场景。
上面提了我们面对的挑战和对策后，接下来就为大家分享下我们的具体技术实践。

三、AIOps 实践之路:数据价值(业务监控)

3.1 从哪来，到哪去

这张图里结合了我们的业务，同时借鉴了其他团队的时间。图的左边是我们数据服务的目标对象，右边是数据的来源。通过源源不断的数据，给目标服务对象提供用户体验质量、产品内容服务质量、业务稳定、故障处理、成本管理与流程效率相关的数字化、可视化与智能化服务。

目标对象，是数据价值的直接变现点，比如平时工作中，除常用的DevOps团队成员外，主管、产品和运营都是重点对象。比如，去年某款产品直播发布，视频直播刚刚具备功能，实战经验不足，在实际使用中，由于产品关注人员较多，用户并发量高，直播卡顿等体验不好，公司某高层让我们回放了当天这个频道的直播相关数据，回放数据符合当时体验。产品也基于全景数据，针对性优化，可以说华为视频这半年的播放用户体验持续提升，刚过去的P20发布会，得到了很好的实际验证。这里提到的是主管层面非常想得到产品的数据，越客观反映产品质量的数据越受到欢迎。此外，产品经理关注渠道扩展情况、运营关注用户反馈是什么样的，这里有很多的数据已不是传统运维类的数据，但这些信息都可以很容易从设备产生的运维类数据中得到。

另外，产品提供给消费者内容，因此，运维数据业务一定要精确到内容粒度，比如应用市场中下载每一款应用，华为视频点播影片以及直播频道，在运维大数据提供的数据服务里，都可以看到上述每一个内容的质量数据监控，而不是泛泛的汇总数据。这对于前面我们提到运维还要保障业务用户体验质量是非常关键的。比如，去年出现一个问题，某某APP在应用市场推送时，误将穿戴型上传到手机场景里，导致该 APP 安装成功率立即出现异常，如果这类问题一旦大规模发生，所产生的舆情会非常迅速。还有不少案例，这些都说明，保障业务用户体验质量，离不开精细化监控。

3.2 核心价值与演进

这张图的内容，在 AIOps 白皮书时也在一起讨论过。从分类来看，分成了三块，质量保障、成本管理和流程效率；从阶段来看，覆盖了数据从感知到分析再到执行；其中打星的部分是本次分享要讲的，分别是质量保障里的业务监控和异常检测，质量保障的其余部分，我们也有部分实践，成本管理上也有涉及。分类的各个阶段，我不细念了，图上都有。

3.3 架构总览

这张图，展示了我们运维大数据的最上层架构，其中最左边列举了我们的数据来源，比如：服务器大家常用的zabbix、HCW（华为自研的采集）、业务侧数据（包括端侧和云侧的数据）还有第三方（如CDN厂商提供的边缘节点数据），这些数据源有实时采集推送，也有非实时的。右侧是运维大数据，一共分为 5层：

最下面是数据分析处理层，待会下面的章节我们会打开看，对应的技术选型也会列在其中，都是我们实践中沉淀下来的技术选型，经受住了考验，供大家参考；

第二层是数据资产层，数据模型以及大数据下的数据治理在这一层；数据治理对于数据平台的吞吐量与稳定性很重要；

第三层是数据开放服务层，这一层对于开发效率提升是很关键的，包括数据可视化、数据清洗以及算法库；

第四层是洞察应用层，这层是数据的服务能力层，包括业务监控、日志检索、异常检测、故障诊断等都是这层的能力；

最上面一层就是展示层，提供了PC/大屏以及移动端能力，一般运维朋友们7*24小时都带着笔记本，虽然手机侧做了，但是实际使用次数并不多；

3.4 业务监控

说了那么多，先给大家看一组我们的产品的实际效果与案例，帮助大家有一个直观认识。

图中列举了业务监控的实际效果。中间的图是全球运维中心大屏，在这里可以看到中国、欧洲、亚非拉等区域的机房运行情况。为满足对应国家的安全隐私政策，这些区域的运维都是分区域部署。我们不仅用了华为云，还使用了亚马逊云。

左上方和右上方是各个业务的监控大屏，除了大屏我们还提供内容精度的数据监控，如左下角；目前，每个业务的监控有大几十张实时监控图表，这些监控报表的使用访问都会被实时记录。

右下角这张图展示了应用来源，图里数据展示了来自于某某云的异常非法请求，都可以捕捉到。中间下方的图展示了运维部常会做的双云演练，以保障业务运行的稳定，比如，去年4月份，当时某运营商的南北主干网断网，我们的业务基本没出问题，很快切到容灾机房。

这张图（缺图）是帐号系统变更引入的问题，发现这个问题比较巧，正好是我们新版本上线的第一天，变更上线后1分钟触发告警。告警使用的异常诊断算法，通过指标间的下钻分析，很快定位出这次变更后的问题原因。业务团队通过对实际消费者的评估影响（消费者使用APP没有感觉，但会触发重复消息）后，安排了最新版本修复。有了这次事件的经验，我们增加了软件版本维度对比数据，灰度期间就会发现这类问题并及时止损。

这张图（缺图）是南北骨干网断网，断网后可以很快识别问题在运营商，从故障分布来看，是典型的骨干网断网，切换容灾机房恢复业务。这类问题虽然不常见，但是一定要快速响应，因为消费者不知道到底发生什么问题了，而且会影响到收入。

前面我们讲了内部的，也讲了运营商，这张图（缺图）是说的第三方优化案例，我们的应用市场等业务会使用到 CDN，CDN 厂商会将各个地区的用户调度到不同的边缘节点。这张图里呈现的就是异常调度数据，站在用户角度给出调度后的业务真实体验。因此，如果出现问题，我们不仅第一时间告诉你出问题了，还会告诉哪台设备出问题了，便于第三方快速响应，毕竟业务是我们兜底，大家一起优先解决业务问题。另外，我们有多家CDN服务商，每一家有自己的价格和服务质量，我们还会把数据提供给他，他来做持续的全网调度优化。其中，在我们的数据驱动下，某个厂商的指标前后提升了三四倍。

上面的案例，其实想展示的业务监控背后的理念：我们在做运维的时候，不仅是被动的解决问题，还可以要主动通过数据来识别问题帮助改进。另外，为了支撑好业务监控，数据的下钻粒度，比如一个上亿、上十亿深度的表，对数据平台的压力与上千万的深度，是完全不一样的，下面就给大家继续分享我们的数据平台实践。

四、AIOps 实践之路:数据平台

4.1 对策

刚才我们分享了业务监控里的数据价值，案例其实每天都层出不穷，那么有了业务场景价值，那么一定要有一个好的数据平台。其实这对于我们的数据平台小组是比较有挑战的。

继续回到现实挑战，前面提到的：

1、存量业务大、业务场景多，为了便于业务接入，只要数据有分隔符，不限定具体格式；

2、为了不让信息“熵”减，2600亿条/天的处理数据都是原始日志，而且还在不断增加。只要数据有价值，能在数据上面做的事情就越多。有的原始数据，50多个纬度，有10多项数据值，业务统统都想要。因为，业务很多时候会说，这些维度和数据值，现在还不想清楚要哪个，这背后其实就是多维的要求。

3、有了这样的数据量还要即时查询，以前我们复用的是BI可视化工具，由于数据量很大，查询一次要两三分钟，现在查询都是秒级（1~2秒）。

解决上述点，就会涉及数据清洗和入库，一般就要对日志进行格式化，还要进行计算，这里会带来一个问题：质量问题。因为这里要写代码，特别是统计计算，很多时候数据发现异常，最后发现是计算代码逻辑错了，很多时候都是非常简单的错误导致。因此，只要你团队的代码写的越多，伴随数据量的快速增长，运维大数据团队一定会被工作量以及背后带来的研发质量拖垮。所以，从数据接入、数据格式化、数据计算、数据存储、数据查询都要考虑清楚技术选型，在这里，我们分享了实践与经验，就是希望能帮助到大家。

首先，海量数据处理框架，我们选择了和大部分数据团队类似的Kafka、Spark、Hive、MPP DB 这类，不过面对海量数据的处理，还需要一个出色的调度和管理系统，这块是自研的，由于本次是第一次分享，时间与篇幅关系，调度和管理系统的分享放入后续分享中。这套任务管理调度系统，仅在3月份前20天就完成了近300万次，非常活跃。

其次，对实时可视化，我们采用的是Vue，采用 Vue 是因为其他大数据团队提前用的Vue，其实个人喜好来看 Angular 也很不错；而数据层这块，我们采用了OLAP数据引擎Druid，这也是我们效率提升的关键之一。 Druid 是很重要的东西，实时数据入库时只是清洗转换，并未有过多的计算统计，降低了大量的工作量（与质量问题隐患），就是他帮的忙。下面看下我们这套数据平台具体是什么样的。

4.2 数据分析

这张图就是我们的数据平台，从下到上，所有的运维数据先汇总到Kafka ，Spark完成数据清洗后，就进入到后置 Kafka 。我们这里放置后置Kafka，原因很简单，就是可靠性。数据团队一定要注意这个事情， 由于数据侧的变更非常频繁，很多人都说变更是运维的万恶之源，我们把 Kafka 放在这儿就是隔离，保证数据源不被轻易破坏，最坏的情况，数据也可以重入，不至于一个“猪队友”全盘通输（有时候自己也是个猪队友）。

从内置Kafka之后，接下来分为三支数据流：中间这条流就是进入Druid；右边的这条流是离线非实时处理，比如去重统计等；左边的流就是常见ELK 中的EK；

这里说下ELK，在问题分析场景可以为业务团队提供很大的灵活性，缺点就是成本太高太高，无法承受大量指标的实时计算与查询；而Druid是有限维度，查询上也不如Kibana的友好，但是Druid在数据入库的预聚合，以及运维场景的查询语句，在性能和灵活性上得到了很好的平衡。

说到Druid，要用好，数据租户管理、汇聚任务管理都需要做到位，数据路由、数据回补时非常常见的数据治理场景。

4.2.1 数据平台 - OLAP数据引擎

接下来，我们认识一下 Druid，它是一个开源实时大数据的分析引擎，是面向列存储、分片、Shared-nothing 架构、分布式、高效索引的OLAP数据引擎。网站上的图是老版本，我贴的是新版本，与官网的有些不同，不过Druid的官网还是非常不错的，大部分的文档已经足以帮助我们了解 Druid 系统。

简要的说，Druid 是由几个主要部件组成，历史节点、协调节点、实时节点（IndexService）、查询节点（Broker）、任务调度（Overload、MiddleManager、Peon），此外，还依赖几个外部部件，比如zookeeper、HDFS、MySQL。

Druid 对于数据处理是关键，运维的数据目前对我们而言都是时间序列的数据，对于每条数据，Druid将其分为时间戳、维度和度量三部分：时间戳（精度）定义了数据写入时的汇聚精度，比如秒级、分钟级、小时级；维度就是分析所需要的粒度，如版本、地域、网络类型等；度量就是数值，成功次数、失败次数、时延等；

Druid会自动将每条数据按照时间精度入库时进行汇聚计算，例如官网举的这个例子，对于维基百科的词条编辑，按照小时级粒度，可以查询哪些词条（如Justin Bieber）什么版本（英文）来自什么地区的编辑者做了增删的情况；

Druid 对于维度采用了稀疏矩阵进行存储，因此，索引速度快存储效率高。同时，Druid的查询语法中的TimeSeries、TOPN、GroupBy、Select类型以及Filter、Aggregation等算子，对应于运维数据场景非常适用。

4.2.2 数据平台 - 可视化

有了数据，就需要数据可视化，本图（缺图）展示了我们的整套可视化技术的选型，连构建方案都写在这里了，包括模块管理，使用得哪种语法格式，包括基础框架Vue、组件的状态管理，组件之间的通性。我们现有的数据监控大盘，页面可视化都是可以直接编辑拖拽、灵活开发，这也是我们数据开发效率提升的关键。

最后看下数据平台以及可视化效果，首先是全国总览图，在地图中点击广东省后，周边的数据图都会刷新成广东省的数据，周边的联动以及整个查询都是秒级。进一步还可以下钻到市级数据。这张小图展示的就是每个APP的应用下载质量，包括次数、成功率错误码等等。

[补图 邮件PPT附件 P2页]

这张图展示了页面编辑模式打开后的效果，比如说业务部门想调整下哪些页面上线哪些下线，哪些渠道数据要凸显，诉求提出后，很快数据可视化就调整好了；数据开发人员通过编辑模式界面可以直接查询到后台数据，这里展示了对于可视化图背后的数据宽表，这种数据schema的展示，也能帮助数据开发人员更好的熟悉数据，加速开发效率。一般而言，数据清洗完成后，页面开发是分分钟的事情，有一次我们一位兄弟，误删除了一个业务50来张监控表，3个小时就全部重新开发完毕了（这块后续做了数据备份，不会发生这样的"悲剧"了）。

[补图 邮件PPT附件 P3页]

五、 AIOps 实践之路:数据智能

上面我们看到，数据开发起来很快，数据可视化表越来越多，在定位问题时，多次下钻，一开始，DevOps团队觉得非常好，但是一段时间以后就提出来，能不能不看这些，直接把问题告诉我。人嘛，都是喜欢“偷懒”的，但这背后其实及时科技和技术不断进步的过程。说实在的，随着数据越来越多，信息量越来越大，靠人真的看不过来。
下图中，主要围绕质量保障场景，列出了我们随着主机数（物理机）、业务数、数据量增长之后，面临的问题与挑战；

这次，篇幅关系，重点介绍异常检测环节里的数据源异常干扰与异常检测两部分；

5.1 数据源异常检测

异常检测这部分，首先我们面临的就是数据源的异常干扰，这个数据源的干扰不去除，指标的异常检测就失去了基础。大家肯定很有疑问，数据源异常到底是什么，怎么引发的，怎么处理的；在这里，我举一个例子来说下背景：

[补图 邮件PPT附件 P4页]

这是华为视频的起播时延（缺图），当时我们刚拿到数据指标时，吓了一跳，平均时延居然位于10秒到70秒之间，只要使用华为视频APP，就知道这个数据有问题，这完蛋了，数据部门最怕这个东西，数据一旦失真，那么数据价值就无从谈起，这是一个非常严肃的问题。怎么失真的？在ELK中，很快看到了这个数据的分布，只有0.28%的异常数据，导致起播时间是10到20秒。而这0.28% 数据不正确，开发团队仔细定位后都能够发现新的问题，比如说锁屏的时候继续统计，上报一条几个小时的数据，对于一个平时都是1秒左右的指标，很容易干扰。业务部门在持续定位后，异常数据占比下降到0.13%，指标依然有异常波动，同时时间过去了，这是数据质量不可承受之重，一定要解决。因此，数据源异常检测上来了，我们一共用了2个算法，v0.8和 v1.0，其中v0.8算法现在已经废弃了；这里也说下，在指标异常检测时也是2个算法，想表达的是，算法既有优劣，也有共存，好用够用是关键。

5.1.1 Z-score算法

Z-score算法，如图所示，其实比较简单，就是每个点减去均价再除方差，衡量计算这个点与整体情况的偏离度，达到一定程度就标记为极度异常数据（不纳入指标统计）。

[更新图 邮件PPT附件 P5页]

算法表现这里，黄色是一刀切，这是我们上的最快方法，先没有高大上算法，用最简单的方法先过滤掉，但是实际过滤效果还会存在毛刺。蓝色部分是Z-score算法，在正常情况下，z-score能够帮助我们过滤掉更多的异常，而在真正出现故障时，可以减少对合理异常数据的过滤。

但是这个z-score算法，优点的计算简单，计算成本低，但是缺点是后期人工成本高；比如对于数据滑窗参数要手工调整，同时阈值也需要手工判断，成本较高。同时，算法本身对于异常点突出效果不明显的话，阈值难以取舍，该算法推广到帐号业务时就遇到了困难。接下来就是来了基于Boxplot箱线图的改良算法。

5.1.2 Boxplot算法

该算法核心是基于箱线图算法来改良的，在这个思想里，默认异常数据百分比是比较低且相对稳定的，不过，指标数据一般不是完美的正态分布，比如时延指标是有右偏（偏大）情况，会往高的时延方向偏移，因此，我们在原有的箱线图算法中加了一个重心偏移。同时，我们还发现时延数据不仅有重心偏移，还存在长尾效应，因此我们还加入了长尾修正参数，即：99分位数据减去中间值除上75分位与中间值来衡量这个长尾效应，这样，算法很好地解决了存在重心偏移以及长尾效应的异常数据过滤。

[更新图 邮件PPT附件 P6页]

最终，可以看到我们的数据，用一刀切的方法，存在的毛刺以及异常发生时过度标记异常的问题都得到了解决，数据处理非常平滑。

[补图 邮件PPT附件 P7页]

5.2 指标异常检测

数据源的异常检测解决好后，指标的异常检测就有了基础。指标异常检测的背景，大家可以从图中看到：数据断点、早晚高峰不同、同一指标不同维度又不同，比如帐号时延，在广东地区和新疆地区表现不同，CDN厂商的价格与服务质量也是不同的。这些不同，如果每个都靠人去观察，靠人去设置，已经是很不现实的问题了。

[补图 邮件PPT附件 P8页]

这次我们将分享2个指标异常检测的算法，不同于数据源的异常检测，指标异常检测2个算法各有优劣，都在使用。

5.2.1 时间序列分解算法

[更新图 邮件PPT附件 P9页]

这是大家经常用到异常检测方法的时间序列分解法，周期项、趋势项、残差项的计算都在其中。从算法表现图上来看，通过周期学习，趋势计算后，原始数据减去周期再减去趋势，就变成了白噪声。通过置信空间的计算，叠加原来计算的周期与趋势，就得到了指标的上下阈值。

时间序列分解算法的效率很高，没有太多的调参过程，也是很多异常检测中常用的算法，在帐号等业务中推行时很顺利，如图所示，开始挺爽的，但是真相却是下面这样。

[补图 邮件PPT附件 P10页]

这是云相册业务，如图所示的西藏联通数据，原始指标存在了剧烈抖动。这不是数据源异常，而是因为用户少，少量用户的异常失败就会导致整个指标下降30%甚至更多，而且每天发生这种下降的随机性很强。因此，时间序列分解算法的一个问题也就出来了，在数据量大指标结果整体表现稳定（正态分布）下，表现较好，而对于指标结果波动剧烈的，就难以适应了，产生了大量异常点，这个图里就多达10余个异常，真实情况最后验证却大部分都是个别用户引起。

我们遇到这个问题的时候，业务团队就跳起来，因为这个异常检测会自动触发告警，夜里造成了很大干扰。简单从数据来看，异常检测确实成功率下降了，但是是不是应该触发告警，其实这就是实际问题。业务部门直接找我们麻烦说做得不好，当时立马心塞了。

5.2.2 多工况检测算法

上面时间序列分解算法所不能适应的场景，就是多工况检测（MRCheck）算法的由来，这个算法外部用的很少，在此分享下，我们通过历史数据的特征进行贡献度识别，其实数据的波动和请求量还有时间是有关系的。因此，如图所示流程，会根据特征（请求量和时间），建立不同的工况（本质是聚类算法），如3~20种工况，然后通过各个点与聚类中心点的距离进行工况划分的评估，确定工况划分的合理性。

左下方图列出了业务各个维度的所有点按工况之后的划分情况，每个颜色都是归属一种工况。可以这么理解，以前时间序列是只有一种工况的特例，而现在我们通过变成多种工况，重新评估置信空间，最终实际效果就是如此图所示，异常检测阈值线根据工况变化随之发生变化，很好的解决了原来时间序列分解算法的问题。

[补图 邮件PPT附件 P11页]

六、结束语

今天我的分享到这里就告一段落了，在质量保障这块我们当前在故障诊断与故障预测上持续实践，同时运维大数据平台也随着数据量和数据处理方式，在不断生长。
以哥白尼的一句话来结束今天的分享：人的天职是勇于探索真理；不久的将来，我们将继续分享我们的探索实践之路。谢谢。

下面是我的微信，期待与大家在AIOps实践之路上，相互交流，相互学习。

说明：由于数据视图敏感关系，整理中，有少量视图未能得以展示，标示为“（缺图）”，敬请各位同学谅解。