张戎：腾讯云智能运维(AIOps)项目实践

11月9日，腾讯云开发者社区技术沙龙“高效智能运维”圆满落幕。本期沙龙围绕运维展开了一场技术盛宴，从AIOps、Serverless DevOps、蓝鲸PaaS平台、K8S等分享关于业务运维的技术实践干货，同时带来腾讯海量业务自研上云实践，推动传统运维向云运维转型。下面是张戎老师关于机器学习算法在时间序列的异常检测，故障的根因分析，时间序列预测方面的应用的内容分享。

讲师介绍：张戎，腾讯云高级研究员，新加坡国立大学数学博士，毕业后加入腾讯从事机器学习相关工作。目前主要致力于智能运维方向的研究，包括时间序列异常检测，时间序列预测，根因分析，告警收敛等方向。

今天讲的内容主要是智能运维方面的一些应用和实践。主要包括智能运维场景描述、单维时间序列分析、多维时间系列分析、近期工作和未来的研究方向。

基于机器学习的智能运维分为几个方面，机器学习的运维分为几个地方，第一个是我们要发现问题，运维上面的问题有多种多样，第一有可能是业务出了问题，第二有可能是网络或者是设备、底层服务出了问题，如何在高效或者烦琐的业务中迅速定位到哪些地方出了问题，就是我们需要关注的地方。

第一，发现问题。发现问题包括时间序列的异常检测，时间序列包括网络流量、CPU、负载以及业务的请求量、成功数、失败率等。第二，我们会做一些日志分析异常的工作，比如说业务上报了各种各样的日志，在这种情况下我们是否能够分析出到底哪里出了问题呢？之后我们会做一些工作。第三我们会对服务器各方面的性能做一些评估，检测出一些明显效率不高的设备将它剔除掉。

第二，分析问题。你发现问题了并不代表解决了问题，中间其实还有一段分析问题的过程。比方说业务上报了各种各样的日志或者是一些数据上报到系统上，我们如何在发现问题之后精准地定位到哪些日志出了问题，那些接口出了问题，影响到了哪些大客户，哪些大客户在这些故障中受到了影响，以及他们的影响范围和影响面，这些就是我们在分析问题方面要做的工作，这也是我们下面会说的多维下端分析的工作。第三，关联的事件分析。通常来说，我们在收到一条告警之后，我们的业务还是比较关注一些和它相关的其他告警会有哪些。比如说你收到一条告警之后，你最希望的是点击某个关联的按纽，将相关的告警或者当前的属性情况给它精准地展示在系统上，或者在监控系统上面再次地去人工搜索这些东西，所以这些是关联事件分析的过程。后面也会做一些容量分析，比如说这个时刻，我们是否要进行一些扩容的操作。

第三，解决问题。我们明确定位到它某个返回码出现了问题，或者某个网页宕掉了，或者是某台机器出了故障，这个时候我们能否做到全自动或者智能解决这样的工具呢？这样过程中，我们整个智能运维就是将机器学习运用到运维领域，提升整个运维的质量、效率、成本三方面。

智能运维这一块一般来说会形成一个智能运维的学件库。学件库是指我们做一个异常检测的工具，或者是做一个训练好的模型，这个模型可以做一个重用，别的业务或者是企业也可以用，或者是一些公司、平台，其他也可以有重用这个模型的机会。比如说在我们的数据级上我们得了一个模型，那别人有了他们的数据级，那我们这个模型是否具有可演进或者可更新的功能呢？这个是我们需要关注的地方。第三个是我们需要了解，比如说机器模型是一个黑盒子，当你运维处理完一个故障或者是发现了一个问题之后，你最好的是用一个规则的形式告诉它你现在的系出现了问题，然后写出一个让人类能够理解的语言，让运维人员能够尽量地理解到当前的系统出夷入了什么问题。

仅仅是检测到异常这对于发现故障其实是不够的，如能够让机器产生一种或者是生成一种人类可以理解的语言或者是人类可以理解的模式，给用户或者运维甚至是产研的模式给它输出出来，这个也是我们需要关注的地方。

整个智能运维分为好几个阶段，第一个是我们刚刚开始机器学习的能力，而刚刚开始应用到你逐渐能够成熟落地其实这个是有很长的时间段的，通常来说是1-2年甚至是更长的时间。比如说我们有一个单点的应用，比如说时间序列分析，日常检测的功能，如何将他们串连起来，这个就是我们需要做的一些事情，就是从发现问题到分析问题的流程到底有多长，我们是否已经形成了一个比较串连或者是串起来的流程化的模式？比如说用户在看到告警的时候，它不仅仅是看到一条曲线异常了给大家展示出来，它甚至需要你告诉他我哪个接口出现了问题，影响了哪些客户，这个就是串联应用的内容，这个就是我们需要分析结果附着到告警信息里面，这个就是串联的应用。

第二个就是我们各个能力相对完备一点，比如说异常检测、分析、日志提取或者是模板分析的内容，做到相对完善的功能。然后这一块我们尽量做到尽量少的人工参与。比如说现在我们还需要开发人员或者是上网人去配置一些资源或者是策略。未来整个流程自动化之后，我们就可以把这些能力逐渐完善起来，让刚开始入门的人员，或者是对这个业务并不是很了解的人员，来尽量实现一个流程化的功能，然后之后会实现第三个终极的AIOps的阶段，最终有一个终输的流程的大脑，但是这个时间也会比较长。但是这个我们可以在效率、质量、成本三个方面达到一个相对均衡的状态，然后让我们的系统达到一个相对稳定的过程。

智能运维的流程体系分为几个方面，它从底部到上面需要有一个流程。最开始我们比较关注底下的东西，底下的我们需要关注数据上报的一些格式，那数据上报命名规范就是我们需要具备的，比如说我们有一些用户的自定义指标或者是用户的一些属性，包括成功率、请求数或者是一些调用数这样的东西，那么如何将这些日志上报到我们的监控系统上面，这个就是我们第二步需要考虑的东西，我们会在系统上或者是服务器上面部署我们的平台，然后通过日志采集这样的方式将日至汇聚到我们的监控系统上面来，形成各种各样的指标。比如说缓冲时间的卡顿，或者是一些耗时或者是一些平均消耗时间的东西。

数据采集或者是数据通道尽量完备了之后，就达到了我们上层的应用，这个包括我们会做一些特征工程的集训，甚至将我们的指标汇聚展示出来，再上层的话就是我们机器学习必备的离线计算或者是在线计算的工具。就是说我们在这上面的一个检测，训练好了检测之后，我们会做一个预测，就是预测这一段时间之内，哪些序列出现了异常，或者是当前序列的时间戳有没有出现异常。这个就是离线与再线的过程。离线与在线上面我们也会用各种的开源工具来做，但是各个机器学习的开源工具并不能够直接运用在我们的业务场景上面，这一块相对于是每一个业务线，每个工具甚至每个部门都有自己的业务诉求，它根据不同的业务诉求，需要你定植各种各样的策略，甚至开发各种各样独特的模型，甚至来定制一些特殊的规则。这一块就需要我们建立一个AI的算法平台，或者是一个算法库。然后很多人在上面开发各种各样的工具，再将公共的能力，或者说是通用的能力给它抽建出来，抽建出来就可以逐渐搭建我们AIOPS的算法工具。这个就是工具开发和运维开发的东西。

支撑到我们上层的话，其实就是运维这一块比较关注的地方。第一个是效率，你运维如果说一天到晚在处理故障，或者说你花了很多时间来语言沟通、定位各种各样的问题，甚至你去查BUG做很多的事情的话，其实你的时间消耗得很快的，但是其实在工作中会发现，很多事情都有一个重复性，或者是有某种模式在这个地方，运维功能所形成的经验，或者是模式，我们能否有一个机器学习的颁发把它抽象出来，把它抽象出来能否形成一个通用的模式，和后来的工程师来使用呢？这块就是我们效率提升的过程，在效率提升的过程中，通常来说，很多部门或者是工程师都会来问你同样的、类似的问题，这一块我们能否将同样的问题或者是类似的问题形成算法库或者是问答库或者是FAQ这样的东西，比如说只要有人录单了，或者是有人将数据录入到了算法库里面，模型或者是聊天机器人就可以自动识别学习这些聊天的技术，然后将这一块的回答给另外的人同样使用。

第二个是我们需要关注的质量的问题，质量是我们运维这一块最关注的问题，我个人觉得它比我们的效率和成本还要重要。因为你如果没有做好的话，整个系统都会有问题，整个系统有问题的话，监控平台可能就做得不是很好。监控平台这一块就是我们一直在发力的地方。要发力的地方，首先AI或者是机器学习在这一块能够做一些什么样的事情呢？第一个能够做的肯定是异常检测，我想几乎所有的运维公司或者说企业，或者说是个人，甚至到部门的话，只要做机器学习，AIOPS肯定就是从异常检测开始，后面可能会做一些预测、多维分析或者是其他的分析包括一些余型监控这样的东西，所以质量是非常重要的模块。

第三个成本，其实就是一个性能调优，如何在有效的资源情况下，达到效果最优的状态。再上层就是我们的串连运用，把我们的质量、效率、成本都做好，达到一个效率提升然后质量也达到保障，然后成本达到最低的工作。最后，我们会形成一个AIOPS的大脑，然后整个来调解效率、质量、成本三个方面。但在做成这些之前，我们首先需要将各个单点运用给它做好，包括异常检测、日志分析和告警分析和关联的工具。

而在整个AIOPS这一块，我们也和很多同行讨论过，在这个角色划分这一块，运维团队其实是一个比较复杂的团队，只有运维是不太够的，运维主要是了解业务场景的诉求，包括他想知道当前的业务出现了什么情况，他该如何处理这个故障，甚至他和开发，或者是跟外部的业务或者是产品如何沟通这些事情，这个是运维工程师在这一块需要做的很多的事情。但是运维工程师主要了解的是业务，可能也有一些不足，对机器学习开发就不是那么了解。所以这一块就需要其他的角色来参与，而在参与学习这一块，机器学习就需要有数据，而数据的构建、采集、收集或者是上报通道的构件开发这一块需要做的工作，所以我们会有一个运维开发工程师这样的角色，包括各种各样监控系统的开发，甚至各种各样数据平台的开发，包括各种模型的部署上线，发挥效果、甚至将效果达到最优。在构建好各种各样的数据平台之后，我们算法功能就有一个发挥的余地了，因为你数据采集得越规范，数据方提供的数据更加符合我们使用的模式的话，我们使用起来就会更加地方便。所以这一块我们就会用运维开发工程师提供的一些数据，和他们的监控平台，包括他们提供的各种算法平台，结合我们运维工程师提供的各种经验，并且他们对运维也有各种各样的诉求，包括一些业务的理解，其实他们是更胜任预算法工程师的。算法工程师就是结合运维平台结合他们的经验，将这些经验和数据形成一个又一个的模型，或者说是一个文件，甚至是一套源码和工具。在这个AIOPS过程中这一块是非常重要的，缺了它就很难做成，所以运维工程师、开发工程师和机器学习的工程师是互联辅助、互联扶持的关系。

下面我们来说一下单维时间序列分析。在时间序列这一块，我想做运维的应该都不是很陌生，因为运维这一块接触最多的是时间序列，或者是各种各样的指标。在时间序列分析这一块，单维时间序列分析第一个要做的是异常检测。这个应该是所有人做智能运维的第一步，其实我们这一块是海量的时间序列和场景，包括各种各样的服务器数据和各种各样的业务器数据。原来我们是采用一个配规则的模式，在这种模式下，因为我们的业务场景非常复杂，而业务的一些时间序列总是非常特殊化，或者是需要一些定制化的东西，如果说每次都需要配这样的规则或者是检测一些东西的话，其实不是很限制。那么如何能够将它继承下来，让我们整个系统达到一个自动化调优或者是机器学习减缓功能配置的工作。在整个业务指标上来之后，我们能否在他们不进行配置的情况下，自动给它进行一个检测和告警发送的东西呢？所以这一块我们需要找到一些通用的解决方案，来解决一些规则配置繁琐的过程。

在时间序列异常检测里面，原来我们拆用的各种各样的规则配置的比较简单，我们会设计一些告警，当前数据大于某某值，我们会有一个告警。比如说在左侧的第一幅图的话，无论你在4万还是6万，它在早高峰的话都没有办法告警，但是在晚高峰的话可能出现了一个故障，但是并没有设置到。第二个是，再生最小值的告警，它不同的曲线需要有不同的策略，不同的规则配置的话，可能这个人配置的是20%，另外一个人配置的是30%。在这种情况下很可能不同经验的人配置的策略是完全不同的，它配置规则的策略不同，会导致它检测逻辑整个都不一样，它检测逻辑的不一样会导致我们的算法和最后的告警质量堪忧。因为它的配置规则方面中，它这个时间的配置规则是基于当前时间序列的走势来看的，但是随着业务的发展，行业的变化整个时间序列是会发生变化的。比如说当前你使用的规则不一定适用于未来的情况。所以这里我们必须要采取其他的方案来解决现在的问题。

谈到机器学习这一块，其实一开始大家做异常检测的时候也会担心可能没有什么样本，这一块机器学习有没有什么办法能够解决呢？这一块其实是有方案的，在一些学者的研究报告里面，他们可以用一些深度学习或者是一些无监督算法来生成一些样本，或者是构建一些样本，甚至从时间序列监督库里面搜索一些样本。这个其实是时间序列检测的一些方案，就是它左侧输入的是一个时间序列的深度学习的自编码器，它输入的就等于它输出的，它是将中间过程进行了压缩，再进行了重塑的过程。比如说下面的这两行图，第一行是我们的时间序列，原始的值，比如说这样的时间序列，出现了一个异常，那么进行算法重构，预测了之后就形成了一个较为光滑的曲线，形成了这样的曲线之后，我们的时间序列这个点的异常就将它的误差抹掉了。比如说我们可以发现，当前重构了这个时间序列，如果和原始的时间序列误差或者是偏差比较大，我们就认为它其实就是一个异常的情况。比如说在一些正常的情况，它的误差或者偏差值相对较小，所以通过深度学习这样的重构的过程，我们可以有效地发现时间序列的一些异常情况，甚至可以将它的毛刺给尽量地排除掉，所以这里面其实是有一些无监督的算法来提一些异常检测的功能，或者是查找样本的功能。所以大概第一步的时候，我们可以用这样的一些算法来查找一些样本，来和我们后面来进行训练和学习。

第二，大家应该都比较熟悉3-Sigma，它就是当前减去均值大于三倍的方差。这一块我们可以采用这个方案进行一个异常的检测。当我们考虑历史上的一段时间序列，当前点如果偏离3倍的Sigma就当作一个异常，或者是认定为疑似异常的过程。但是同时Sigma有些时间也有一些不足，比如说这个时间序列并不是正态分布的情况，其实它是具有一个高低峰走势的，高低峰走势就是说可能它处于一个凌晨，或者是软高峰的情况，他在某个点突然出现了一个上涨，在这种情况下用Sigma是无法解决这样的情况的。这种情况下，我们可以采用刚刚所说的无监督深度学习的方案，或者说也可以采用多项式拟合的技术。所谓多项式拟合就是将这条时间序列进行一个拟合或者是平滑，只要拟合后的值距离实际的值偏差比较大，我们就认为它是一个异常的情况，这个也是无监督算法，也是我们日常检测中比较常用的工具。

刚刚提到了无监督的异常检测算法，是否有监督的异常算法呢？其实是可以做的。第一步就是我们之前需要做的，就是将无监督收集到的一些样本，或者是案例给它搜集起来，无论是采用深度学习方案，还是Sigma甚至一些多项式、拟合的一些技术，你都可以将各种各样的模型或者是样本给它搜集起来，搜集起来之后，就可以对异常和正常建立一个二分类的模型，建立模型之后，你还需要建立各种个眼的特征。特征就看你如何对这个时间序列进行一个描述，因为你在人工纂写规则的时候，你就对这个时间序列进行了一个描述和规则的填写。比如说你写了一个规则，当前值大于多少就认定为异常，那么当前值减去这个幅度就可以设定为一个特征，进入到我们有监督学习的过程中去。所以这一块我们是将时间序列这样的统计特征给收集进去了，包括一些最大值、最小值、偏差或者是便利系数这样的一些值，作为有监督模型的输入。另外的话，我们做拟合模型，包括移动平均算法，或者是一些其他的模型，或者是深度学习算法，然后来提炼他们内部的潜在的特征。另外我们也会做一些分类的特征，包括一些熵、值分布的信息，然后进行一些时间序列、特征提取的工作。

在我们做了时间序列提取的工作之后，我们就可以对时间序列做一些异常检测了。方案的话其实是有监督的方案，我们之前可以用无监督的方案收集到各种各样的样本和数据，我们现在可以通过有监督的方案，我们可以提升我们对检测的效率和质量。比如说在无监督学习里面很难对这两条时间序列进行一个判断和归属的采集。这种情况下，在无监督里对于这种情况会被判断为一个异常。在我们使用了有监督算法之后，在这种情况下实现了一个长期的抖动或者是毛刺，这种情况下我们就会认为它是一个正常的情况，所以其实有监督的方案我们都能够将这些问题给解决掉。

整体的流程或者说架构的话，我们就是这样来做的。第一个是数据层的采集，这个是监控平台提供的各种各样的数据，包括一些成功率、次数，甚至一些模块的失败数，这些就是模块的数据。第二个我们会采用一些统计上的算法，包括移动平均算法等等，甚至我们会采用一些深度学习的方案来提高模型的样本。第三个我们会采用无监督算法，比如说多项式，或者是一些其他的思路。像这些，只要输入了疑似异常我们就会采用有监督的方案，只要我们采用了有监督的算法实现了一个特征工程和离线训练和实时计算的话，我们就可以做到人工标注，从而达到告警的效果。

在这一块我们发现，如果只用无监督算法和统计算法的话，其实是不太够的，基于人工的反馈，运维人员认为这一块时间序列不太标准，或者他告出来的步态标准，他以后不想要了，这一块就可以采用标注的工具。标注完了之后，我们会将这一部分的时间序列的样本，拖到我们上一层有监督算法这一块，有监督算法这一块会重新训练。相当于说将运维人员的经验持续地附着到这个模型上面，让这个模型达到最优或者是持续调优的过程。但在人工标注这一块，实际上是有一些人力成本和资源的成本的，但是整个流程是有一些效果的。一开始有一些数据，后面是无监督和统一算法，第三个是有监督算法，最后是人工标注的过程。

打标工程，大概就是这样，比如说我们告出来的时间序列异常，比如说这个点我们认为它异常了，那么我们将它告警出来，然后我们将这一段的时间序列标注下来，如果说你标注了之后，它这个地方就会显示已标注为副样本，没有标记的话就会显示待标记。有时候我们也会有误操作，标注错误了也可以及时取消。在这些方面也可以形成一个数据库，然后形成了一个时间序列样本提取的工具。在整个闭环过程中，它不仅承担了一个告警的大盘展示的功能，其实也承担了一个时间序列异常检测标记的工具，这个就是大盘和告警，甚至和我们的数据库和数据平台打通的流程。

这个其实是我们之前也开源过一部分，就是将算法这一块全部开源，开源这一块主要是集中在时间序列异常检测，异常检测包括我们会提供一些量值，比如说成功量、失败量、调用次数和流量的流程。另外我们也提供了各种各样特征的提取工具，也提供了一个异常的查询和告警的接口。最后是一个模型管理、样本甚至人工标注的样本。这个是我们内部已经实现并且已经落地了，最后整体来看，就是如果有异常，我们就会进行标记，没有异常的话，或者是不标记的话，就作为一个展示，甚至大屏的功能。

你发现了异常之后，很可能你会做更多的事情。比如说你很想知道哪些接口出了问题，哪些平台出了问题，影响了哪些客户。在这种情况下，刚刚说的单维的时间序列系统。多维的时间序列系统主要包括几个流程。第一个是业务埋点，通过各种各种各样的客户平台采集数据，采集了数据之后形成的各种各样的指标，做了这样的东西或者是日志采集之后，我们需要将时间序列进行一个展示，比如说这是个播放成功率，那个是个总播放量，进行一个各种各样的指标展示，进行了指标展示之后，我们有一个维度的查询，比如说你的维度就是你的某个接口或者是你某个用户又怎么样的查询的功能。这一块相当于小的一块的智能应用。进行了检测之后，我们会将分析它的哪个元素、哪个维度进行一个分析，然后将这些元素和维度进行展示。就是我们在告警的时候有一个异常。然后我们也会将哪些维度和哪些值进行一个展示和聚合。在这种情况下，就是一个多维时间序列分析的流程，流程就是一个成功率，比如说这些成功率在时间点上出现了波动和下降，人工其实是要判断它是否出现了异常。人工还要判断它哪些元素出现了问题。在这些情况下，你用人工查找其实是相对较慢的。我们这一块其实是一个从发现问题到分析问题这样一个有机结合的过程。比如说我们同样采用一个正副样本的过程。那么正副样本加上就是我们所要定位的过程。定位的话主要就是看成功率，成功率下降了有可能是运营商、操作系统、客户端版本或者是其他方面出来了问题。在这种情况下，我们会做一些特征工程的离散化的工具，只要将特征工程离散化，处理成机器学习能理解的模式，这一块我们就会做效果的提升并且做规则的展示。

在进行规则的展示的过程中，也有很特定的机器学习模型可以做到。但是在这个过程中还要做一个人工理解的规则，人工理解的规则用深度学习就不是很好了，但是可以采用一个决策数的解决方案。决策树其实是通过正副样本来形成这样一棵树，通过之前我们所做的特征工程的工作，将某些维度、某些元素的值给它打印出来，在这种情况下，异常聚集的那些叶子节点到根节点的路径，就是我们输出的规则，所以说在这种情况下，其实我们最后做的就是一个以正副样本的收集，特征工程、离散化的构建以及离散组合的输出，然后形成我们离散序列多维分析的展示。我们告警的时候会将棵树给解析出来，将告警规则给它列在下面，就是你影响了哪些人，哪些客户，哪个接口出了问题，你是因为某个访问码引起的，还是因为某个产品引起的，所以这些的话就是我们在告警列表里面都可以做的这些事情。

后面的话，我们简单来说一下未来的研究方向和我们近期做的一些东西。我们近期做的一些东西，前面两个就是我们刚刚提到的单指标异常检测和多维分析和链路调用。这些是我们内部已经落地并且进行了实践，甚至在效果提升的过程了，最后形成了发现问题到分析问题这样流程化的问题。那除了异常检测，我们还会做其他的一些东西。

在告警收敛这一块，你出现了一个告警之后，我们希望有更多的一些告警或者是相关的告警给用户展示出来，比如说A告警是因为B事件引起的，或者是因为某个变更引起的或者是某个操作引起的，在这一期我们会做一个告警收敛，做一个事件与事件，时间序列与事件、指标和指标之间的关联分析的过程。所以告警收敛和告警平台的建设就是我们近期发力的点，也是我们的难点。所以运维这一块最关注的，前面只是一个基础，最后做的告警关联和告警收敛是整个运维平台的核心。告警太多了，大家都不关注，告警太少了，告的质量也不高，或者是漏告的情况也会出现。在这一块，如何保证高质量、高稳定性甚至高告警效率的情况下，我们也需要做很多事情，这就是告警收敛的工作。最后我们也会做一些日志模板提取和日志分析，比如说日志剧烈的工作，这些东西也是我们内部在使用的东西，包括异常检测、多维分析包括告警平台的建设，最后到日志分析的流程。