作者简介

王肇刚
阿里巴巴全球运行指挥中心高级技术专家

智能监控是智能运维的子领域，我们说的监控，探讨的更多是在监控策略，因为可能从数据采集、日志收集、包括计算等等产生数据，再设定一些判断的规则和策略，发送报警，这些都属于监控。

我和我的团队在阿里内部的分工是横向去看阿里巴巴业务指标的监控，我们就以这个话题展开。

分享分为五个环节，从阿里巴巴不同的业态，特别是新的业态带来的挑战讲起。对于我们之前已有的基于机器学习算法这样一个算法工程架构，我们做了哪些增强应对这些挑战。

我们的监控也从单一指标监控延展到多个指标一起监控。监控完了之后，我们可能要分析定位，这时系统又能帮运维工程师做什么，这是第四方面的话题。最后是对智能运维整个领域做一些展望。

一、新业态给业务监控带来的挑战

上图是阿里巴巴不同的业态，有比较传统的电商业态，右上角是国际电商，蚂蚁金服还有阿里云。最近这段时间阿里在收购各种各样的公司，也是商业的布局，我们会看到优酷、钉钉等等。

我们团队在阿里巴巴内部是负责横向的业务指标监控，这个有什么差异？

技术层面也是通过日志的采集流程计算看一个指标下跌还是上涨，区别在于只要业务发生了不可用或者发生问题，我们希望都能够发现，而不是说阿里巴巴本身的系统出问题了。

举个例子，如果阿里巴巴一点异常都没有，但是电信可能有问题，这个时候我们希望知道。

它是从对于业务数据量实时的监控。因为阿里巴巴本身的业态是很丰富的，有这么多的业态，我们看到的数据也很丰富。

上边这个图，大家可能看到的这些 Logo，看到购物或云计算的一些业务，但是团队做智能运维算法的同学，看到的就是右边这种奇形怪状的曲线。

我们团队在阿里内部是横向团队，第一环节就是需要能够精确、及时的发现业务是否有异常。

为了达到这个目标，我们引入了称之为智能基线的系统，这个系统可以在网上搜索到。

这个系统效果还是不错的，能够在没有任何阈值或者规则输入的情况下，自觉做预测。同时有些业务发展比较迅速，我们可以比较好地在历史的长期趋势和短期的业务沟通之间，做出一个相对较优的折中。

业务变化之后，假设你以前配了阈值还要改，智能基线不需要改。阿里巴巴几千项业务指标，通过人工的检查验收之后的准确率是在80%以上，这个数字每周都不一样。

而对比传统的工程师通过传统的静态分段阈值或者环比的方式，准确率可能只有 40% 左右。

大家可能也会看到特别对于业务量监控，可能 10 条报警里面，4 条真的觉得有问题已经不容易了。

阿里有很多不同的业态，所以一套系统解决所有问题还是挺难的，因为不同业态之间的差异还是非常大，数量级、波动、周期均有差异，包括现在有新零售业务，它是把线上线下的业务结合起来，而且非常强调线下。

比如盒马鲜生有几百家门店，这是个商业的尝试，对于做运维监控的同学也带来很多挑战。

比如淘宝和天猫的某些交易量在分钟级别是万或十万或更高的数量级，这个可能就是百或几百，波动的量级和原始量级在一个量级上，这个就比较难处理。

包括周期性，对于一般的在线服务，是7X24小时提供服务，每天什么时间流量最低？国内业务凌晨四点钟最低，这个会受门店的开关门影响，因为零售是有时间的。

我们如果线上刷淘宝下单点一下就行，线下不一样，一对一排队结账。而且在量小的情况下，很多时候不能看单一指标，许多指标要一起看，所以就给我们之前的算法提出非常大的挑战，我们需要做新的算法演进。

大家可能会问为什么整这么复杂的算法。配监控，配规则不就可以了吗？

其实是可以的，但业务太复杂。作为一个横向团队，算法工程师可能只有三四人，七八个人要面对阿里巴巴集团成千上万的业务监控指标，不可能了解每个指标的所有细节，这个时候是没有办法用人，我们要用机器学习的方法去做。

二、增强版的时间序列异常检测实战

接下来讲讲怎么用机器算法解决问题，这是一年半以前我们采取的架构，我们能从业界很多文章上看到类似的架构。

我们希望做一个基线拟合，这个曲线应该是什么样，我们说异常这两个字就是异于平常。

我们第一步想知道正常的曲线是什么样子，所以我们做基线拟合，我们用STL做这样的方法，我们用比较传统的 N-sigma 做调整。这种架构其实能解决 60% 左右的问题，但是有些极端的情况解决不了，所以我们就把架构做了演进。

我们第二代的架构做数据预处理，然后又做了比较简单的滑动平均，数据有时候会缺点，不管是采集侧的一些不稳定因素，还是计算一侧出现了问题，导致你希望一分钟出一个数据点，但是最后还没有算出来。

这种情况应该从工程上解决，所以我们会在算法层面做一些脑部的算法策略，就是即使缺了能补回来，但是不能长时间缺数据。

下面的逻辑就走了机器学习的思路，我们对曲线做特征工程。我们之前的基线拟合的这种预测只是我们特征工程中一部分，对于重要的部分，我们也会把一些统计特征编码进去，当然也会把一些时间特征编码进去。

因为我们知道很多电商的业务是有定期促销的习惯，比如淘宝的交易量每天早晨十点一定会有阶峰，大家不知道在抢什么东西。

算法层面怎么解决？我们把每天的这个时刻第几小时第几分钟，通过热度编码的方式做到里面去，就可以让算法学到这个时间点这样一下可能是正常的。

我们后面采取了不同类型的统计学的判断和做法，最后做成集成策略，大家可以理解为简单的投票策略。

它其实给我们带来了比较好的一些算法的效果，比如说基线拟合会更准，对于不同类型的异常进行判定。很多时候曲线有不一样的异常，如果用 N-sigma 的方式，你的刻画表现能力是不够的。

即使是这样，对于遇到的新零售业态，我们觉得还是不够。因为你看刚才的算法能解决一般性的问题，但是对于曲线问题差异很大的时候，之前的预处理就需要增强，量级从十万左右到几百万，你的预处理策略需要变化。很多曲线不具备周期性，或者周期性非常零乱。

比如我们有一个业务比较奇怪，大家在淘宝上有没有充话费？这个是天、周、月三重周期，天的话基本没有问题，周的话工作日和周末是有差异的，月这个周期，因为大部分人是在月末报警了或者月初充。

最后一个线下的业务对这种异常很敏感，在这种情况下我们用一套算法策略是解决不了不同问题的，所以我们做了第三次优化。我们先引入了一层算法路由，希望能够通过机器学习的方式，把不同的曲线归到不同的算法路由里面去，这样的话不同的曲线走不同的处理路径，那么效果会很好。

我举三个例子，比较周期性、非周期性、百分比的指标等等，这些不同类型的指标方法都不一样。在这些不同的方法之后，我们还是觉得算法也许解决不了所有的问题，因为算法对于大多数运维工程师来讲，不见得那么方便去调参数，所以我们也开放了三个参数，我们会看它不同的抑制时间、发布策略和敏感度。

分开来看，算法路由，这个工作的目的就是说让算法自动把数据分类，这一块也不一定非得用算法，用人就可以，但是因为量太大，所以人工的成本很高。

这里我们用了深度学习的算法，上面那个图是网络的图，我们使用了孪生网络，两边都是LSTM，所以我们用了双向的网络结构去把我们标记为一样和不一样的，最终能够区分开。

在这个基础上，我们做了一个分类模型。这块从技术层面来讲，不用特别复杂的算法，我们用这个算法就是想探索一下，实际大家真正做的好的话，比如你用一般的分类方法，用我们最直接方法也可以达到类似的效果，但是我们这里尝试了一下。

分好之后有个工程架构，以前是说不同的算法场景走的处理逻辑都是一样的，里面的参数可以不一样，后面不同的处理逻辑像插件一样可以去做组合，这个组合的变化频度不会太快，但是一般变化成本都很低。

这样以前是三条通路，我把插件的参数和顺序和有没有插件做一个变化。有了这个之后，对于阿里巴巴成千上万条，但都是到万这个级别，不会再多。

大家会想这个东西可能是从业务角度监控的，从惯性思维来看，我们可能会是想监控 CPU 或者某个接口调用的超时，这些也是可以的。

我们也探索了在系统级指标或者非应用级指标做这个尝试。它的周期性不太明显，第二个这个指标的变化跟业务行为关系不那么大，运维的决策对它的曲线影响大于业务的影响。最后一个就是标准不统一，你觉得这个可能需要报警，别人可能觉得不需要报警。

我们采取了一种轻量级的方式去做检测，可以做到自动学习。

它跟上面那套算法相比在于它比较轻，可以做成一个包的形式，嵌到监控系统中去做监测。它的效果如上图右边显示，我们内存中有奇形怪状的异常，这个算法逻辑还是比较简单的，不用太在意算法本身的框架，因为这些算法你可以替换成其他的算法，但可能需要考虑在数据进来之前做比较好的预处理。

第二个可能你需要基于统计特征和那些曲线本身的特征，影响你的特征工程。最后孤立森林不是说基于用户的标注去做的，因为实际场景中我们不可能像做人脸识别这样给我们标注。

什么参数微调？第一个是说抑制报警的时间，这个很容易理解。第二个防抖动策略，这个也很容易理解，就跟过去 N 分钟有 N 条报警是一样的，所以我们概括成N/M。

最后一个是报警灵敏度。这个在我们市场环境中测试的效果大于70%，现在这个数字可能稍微好一些。

最终怎么评价算法？还是要看人标的。比如说我们有十几位同学评判，他们的标准也不统一。甚至一个人今天说这个点标的对，第二天忘了再看一遍就说标的不对。

所以说以上是我们介绍的关于单个指标，不管是系统级的还是业务级的指标，怎么通过机器学习的方法，做不用任何监控阈值配置和维护成本的智能监控。

三、多指标关联分析的探索

刚才也提到了在新业态下，很多时候我们只看一个指标是没有办法判定业务有没有异常，或者我们发现指标和指标之间是有关联的，这个在实践当中也会遇到。有时候两个指标都出了问题，这时这个信息能不能被利用，我们也做了探索。

这个东西有一个业务背景，就是我们刚才提到的看一个指标不够，我们经常在一些业态里看到会监控某一个业务的成功量、成功率、失败的错误请求数几个指标相关变化。

有时候会发现指标有异常传播，这个传播有几种方向传播。比如说在不同的业务之间传播，比如因为两个程序之间有关联关系，A坏了B也影响了。

还有就是混合部署的情况，同一个集群布两个业务，A被打爆，B也被压死了，也有这样的情况。

我们怎么做这个事情？分为两步。第一步我们希望发现和维护相关的指标，就是哪些指标应该有关联的，发现之后要维护。一旦我们掌握这个信息之后就可以做两个事情。

第一种我们能够把这些相关指标放在一起判定业务是不是异常，而不是只看一个指标。

第二种我们单指标能看的很准，但这时候我想知道为什么会下跌，虽然给不出因果，但是可以给出相关。

业务指标之间的相关性其实有不同的类型，比如上下游之间有监控项，比如我们在阿里做过一个实际情况，大家看淘宝搜商品，如果出现异常大家就搜不了东西，我们的淘宝详情页的浏览量和下单量都会下降。不是说搜索的程序或者应用服务掉了那个服务，它们之间没有关联，但是很多用户习惯了搜而买。一但搜挂了，很多用户不知道怎么买了。

所以这样的关联靠系统内部是拿不到的。包括业务不同分量的监控，比如河南省播放成功率和河北省播放成功率之间的关联。

这种关联我们怎么发现？一定是靠人工梳理，但是对于阿里的体量，一个是梳理不过来，第二个梳理以后过两天又变了。阿里集团可能每天的业务发布的频次是千级别的，那怎么办？还有第三种方式。

第一种利用 CMDB，我们通过CMDB看到哪些应用之间可能相关。

第二个通过 时间序列相关性 发现了方法，这个跟刚才提到的卵生网络的方法是类似的。但从实际来看，一般是在第一个检测的基础上，再在局部做第二个，而不是全局的检测。

第三个我们利用关联规则挖掘看哪些项经常关联报警。

我们可以通过算法发现这些关系，这三个方案其实是互补的方案。所以有了这三个方案后，就可以把很多相关的指标放在一起监控，方案取得了较好的效果。

在盒马鲜生，基于我们上面做的新的算法，单指标架构和多指标关联架构，能够把监控发现率和误报量做非常好的提升，这就是我们在新业态下通过单个指标的算法和多个指标的算法取得关联效果。

四、故障影响面和根因分析的探索

之前都是关于监控的部分，监控是为了发现问题，但是发现完了问题，很多时候是需要想怎么能够解决问题的。我们在故障根因的推荐层面做过一些探索，但这个也只能是探索，供大家参考借鉴。

首先我们看一下故障原因分析问题的范围和边界，我也跟很多工程师交流过，凡是做运维系统的工程师都有一个梦想，就是我想做一套系统，一旦我的业务出问题，告诉我问题原因在哪，这个非常理想化。

但在实际过程中，这个事情是非常难解决的，探索来说在阿里内部也解决地不好。虽然解决的不好，我们也做了一些探索。

为了避免我们做的事情不符合我们老板或者客户的预期，我们需要先把能做什么说清楚。我们很难做到淘宝交易量下跌了，我告诉你哪个代码有bug，这个做不到，但是我们能做到缩小影响范围。

这个为什么有价值？因为阿里巴巴有两到三万名工程师，半夜两点出了问题，我打电话叫起来就是一个非常复杂的技术问题。

首先要从阿里巴巴几万个应用程序里，先要看这个业务故障到底跟哪几个应用相关，这个都是非常典型的问题。

我们的目标是能够从站点、产品线和业务功能指标出现问题的时候，能够定位到应用服务层，包括数据库这层。这个架构就是能够锁定这个范围，然后之后的事情可能需要更细致的方式解决。

另外一个好处，我们可以对故障做一个结构化的快照，除了阿里巴巴，我看到很多公司也会对故障做复盘做改进措施，但是没有形成很好的流程。

但是在阿里我看到过去大大小小非常严谨的复盘和故障记录，包括非常多的细分的环节和字段，这个非常好，因为以后的故障可以从中学些东西。但是有个遗憾，这些东西全是用汉语写成的，长篇大论几千字。

人可以去读，但是比如阿里有另外一个工作叫全链度压测，我们要对去年的业务优先进行测试，这个时候我们要挖掘到底哪些有问题。挖不出来，为什么？都是汉字写的。

汉字写的话，它的表述、格式，都是很难被机器理解的。如果做的这件事情以后出故障，我们尽可能地把故障做一个结构，这个不仅对这次故障的本身，对以后故障的防范都有非常大的价值。

怎么做？如上图所示，我们会有一个主的抽象流程，当我们的前面算法发现问题之后，我们会尝试找到跟这个业务指标相关的应用和它的中间件以及数据库，以及相关的网络服务器IDC。

我们建立了一个囊括阿里主流的所有运维相关事件的这样一个数据仓库，阿里内部可能有自己的这种事件存储的机制。

这个数据仓库能够告诉我们在哪些运维的对象上发生了什么事情，最后我们对这个事情做一个排序和筛选，把可疑的挑出来。逻辑还是比较清晰的，但是真正做的时候发现有很多具体的环节需要考虑。

比如你怎么找到监控项关联应用，淘宝交易下跌了，你怎么知道是阿里的几万个应用中哪个应用造成的问题？这个其实也是比较难的问题，我们也没有解决太好，但是可以看到思路。

最直接来讲，我们通过监控系统本身的配置来得到。我们的业务指标能画成一张趋势图，能做监控，因为背后有逻辑计算，有日志的采集等等。这些系统的工作，是因为加监控的同学已经把监控怎么采集配置进去了。但是它有失效的时候，比如说两种情况。

一种发现业务环境非常强，ABC三个程序不断做处理，最后把结果打到第四个程序上去了。所以你通过这个，能得到第四个应用的名字，前三个应用其实跟这个业务非常相关，但是你从这里读不到，所以这是我们要解决的。

第二个有一些应用本身是用来监控的，比如阿里的客户端，它会上报到某一些监控系统，这时候监控系统画出来的曲线，其实跟监控系统本身相关的，而不是跟产生监控数据的应用相关的。

这种情况下，这个方案就失效了。这个时候就需要通过人工配置的方式解决，目前是这两种方式结合在用。

刚才说的第一个问题，我们也可以通过阿里巴巴的中间做的系统去解决这个问题，包括我们也可以通过算法，对于报警做平台挖掘，可以挖掘出来像刚才搜索框下跌，导致交易量下跌的关系等等都可以挖掘出来，这个东西也是补充的方式。但是最核心的不是算法，最核心的是CMDB如果维护得好，比什么都好。

通过刚才那个思路，能够把我们的业务指标跟应用结合起来，但是很多时候应用经常是无状态的，状态存储在数据库集群里面，这个时候还是经常通过CMDB解决这个问题。

还有比较难的问题，就是网络跟应用程序的关系，有一个机房出问题了，经常我们是混合部署的，所以这个时候问题其实是一个非常散的关联，这个问题上我们解决的也不好，所以我们只能把这个信息当成一个缺少的信息推荐出来，供大家去决策。

比如说不管阿里什么业务出了问题，我们都会把网络最近出的一些异常点或者事情推送出来，提醒大家是不是这个问题，但是这块很难做到精细的管理。

我们知道了哪些运维实体跟业务有关联之后，还要知道这些运维实体上、程序上、集群上、网络上发生了什么事情？那这个事情我们怎么知道？我们会建立一个在线的数据仓库，它能够不断地抓取来自于各个运维平台和系统中的不同格式的事件。

这个抓取之后不是简单放一块存，还要建立关联索引。阿里有很多不同的横向纵向的系统，他们的数据格式的字段都不一样。

我们尝试做一个翻译，在当中找到了两三个大家都能看懂的词。比如钉钉应用，这在阿里内部非常稳定的。第二个IP地址，这个也是很稳定的。

但是这两个之外，格式语言是不一样的。我们把数据仓库建好之后，输入开始时间、结束时间和应用列表三个关键词，就可以查到这段时间内实体发生了什么事情。我把事情都推荐出来是不是就解决了？还不够。

我给大家分享一个数字，在阿里巴巴内部，像这样的事情一分钟发生四千到六千次，也就是说一个故障如果持续了十分钟，就是几万个事件，所以我们还要再做筛选。

这个时候就会通过一些方式做筛选，我们会根据哪些运维实际上发生了报警，把这些实体的信息优先放在前面。怎么知道有跳变？我们会对怀疑的对象做系统级指标的扫描，扫描出来跳变就排到前面去，所以有了这个之后就可以相对精确地缩小范围，当阿里巴巴淘宝天猫有异常的时候，我就可以知道。

我们能够从上面看到，最上面这个环节是同一个时间内有多少业务的多少点在报警，红颜色的时候，可能就是某些业务出现短暂的异常了。

我们会感觉 CMDB 加平台化算法对报警压缩合并，看到了集中在优酷、集团客户体验、菜鸟这三个业务功能上。

这个其实就是刚才讲的多指标关联分析的作用，这时候我也不知道是不是因为它导致的，但是他们之间是相关的，这个可以帮助我们定位。

最后我们能够根据刚才说的逻辑，把跟这个事情相关的前五个或者前十个应用程序推荐给你。为什么推荐给你？要么它发生了一些骤变，要么发生了一些大的业务操作。

很多时候可能百分之五六十的业务故障，都是发布新功能或者改配置改错导致的。做的比较好的地方，可能能够做到70%以上的推荐准确率。但是也有做的不好的，百分之三四十的准确率。

因为阿里业务很复杂，每个环节每个业务都有不一样的方式。但是这个方法，我认为还是一个值得推广和借鉴的大逻辑上的思路，这个就是我们介绍的监控发现问题之后，我们在根因分析层面有哪些探索和思考。

五、智能运维在故障治理领域的未来规划

最后希望能够和大家一起探讨一下在智能运维领域现在与未来可以做什么事情。

运维本质上是解决在线服务运行中的质量、成本和效率三方面，运维不是从上到下的思路，包括我也参与了白皮书的工作，我们也跟其他业界的同事探讨这个问题，不是说有一个顶层规划要怎么做，实际是在这些点所处的具体环节上，很多工程师开始尝试用算法的方式解决问题，逐步汇集成一个数。

我们现在在上图左边那条路做了一些探索，已经在业务中用起来了。最早的探索，其实在阿里内部已经稳定运行了接近两年时间，也是效果在不断演化演进。

最近我们也在探索右边这条路，就是无人值守相关的东西。出问题的时候很多人问淘宝的故障恢复了没有，支付宝有没有受影响。靠自然语言提出的问题，是不是可以通过机器人回答你，这个也是我们探索的。

当然现在还不敢做全自动，还是我们列出来你再确认一下，但已经比你调出系统然后跟很多人沟通半天决策要方便一些。所以其实不仅是在质量领域我们做智能化的监控，智能化的根因分析，其实在节省人效率层面，也可以做一些探索。

中间这块跟成本相关，这块在阿里巴巴有很多团队做这样的事情，也可以通过智能化的调度能够做容量预测，优化包括硬件采购的周期，预测你服务器增长怎么样。或者在实施的时候，通过自动化的调度策略，节省服务器的资源。

所以其实智能运维这个概念，在今天已经不是个概念，它已经在我们企业实际工作中，有非常多落地的点。希望今天我的分享，能给大家有一些借鉴和参考，我们一起建设智能运维美好的明天。

说明：以上内容为阿里高级技术专家王肇刚在 GOPS 2018 · 上海站的分享。

原文发布时间为：2018-12-12
本文作者： 王肇刚
本文来自云栖社区合作伙伴“高效运维”， 了解相关信息可以关注“高效运维”。