智能运维

 运维要做的是保障业务能够可靠高速高效安全的运转，因为它会直接影响到业务的收益和成本。目前已有运维方法的主要难点是突发故障的发现、止损、修复和规避，也是我们要解决的关键问题。

 当前运维所大量依赖的人力决策已经无法应对当前运维所面临的挑战。随着互联网、移动互联网迅猛发展，用户越来越挑剔、对应用软件的用户体验要求越来越高。应用软件都是建立在一个庞大、复杂、跨协议层的大型分布式系统之上的，而这个分布式系统的技术、软件、配置通常会不断快速地演变; 其软硬件难以避免会发生故障、Bug, 变更，用户流量会发生不可预知的变化，甚至会发生安全攻击事件， 而上述趋势有愈演愈烈之势。

 尽管各类运维监控工具使得系统运行状态的可见度有较大提升，但是当遇到运维故障时，面对海量监控数据和庞大负责分布式系统，仍依赖运维人员在高压下人力做出迅速、准确的运维决策，这显然是不现实的。

 解决上述核心矛盾的思路就是逐渐减少人力在运维决策中所占的比例，逐渐增加人工智能在运维决策中的比例，最终实现无人运维。

 运维已经从最早的人力运维发展到了一定程度上的自动化运维（但是还需要大量人力盯屏决策），最终我们希望基于人工智能的运维工具能够更多自主决策，只需很少人力、甚至不再需要人力参与决策，这就是我们运维行业的长远的目标：基于 AIOps 无人运维。

无人运维是目标，智能运维AIOps（AI for IT Operations） 是工具、手段。

智能运维是指在互联网中的大型分布式系统不断处理海量用户体验、性能、稳定性、安全事件，从而达到如下效果：
能够准确的复现并诊断过去发生的事件；
能够及时准确的检测、诊断当前正在发生的事件，并确定最适合的应对方案；
能够相对准确地规划和预测将来可能发生的事件。
因此可以看出智能运维是人工智能（机器学习）、互联网运维领域知识、工程开发的交叉领域，三者缺一不可。

智能运维是人工智能（机器学习）、互联网领域知识、工程的交叉领域。互联网领域技术和工程开发技术在此不赘述。智能运维常用到的机器学习技术包括相关性分析、回归、关联分析、聚类、决策树、随机森林、支持向量机、隐氏马尔科夫、卷积神经网络、LSTM（Long Short Term Memory) 等等。这些算法在各种（开源或闭源的）工具集中都有现成的代码实现。智能运维的一个主要挑战是根据具体需求评判应用哪些机器学习算法，并适配或改造。智能运维正在经历由“基于人为指定规则”到“基于机器学习”的转变

基于如上机器学习技术的具体智能运维技术包括：
面向历史事件的： 批量根因分析、瓶颈分析、热点分析等；
面向实时事件的： KPI异常检测、日志异常监测、事件关联关系挖掘、报警聚合、快速止损、故障根因分析、止损建议分析；
面向未来的：配置管理、容量预测、趋势预测、故障预测、热点预测等。

基于机器学习的智能运维技术是APM（应用性能监控），操作系统性能监控，数据库监控，网络监控等技术的底层基础技术

未来几年的运维领域的技术发展的期望：
1.一些智能运维的关键技术会逐渐通过工业界和学术界的密切合作被突破，比如异常检测、异常定位、异常事件关联等。
2.更多的预测型的智能运维技术会被提出并实际应用，比如故障预测、热点预测、容量预测等。

容器和微服务的不断落地，也会使得一些过去可行的技术（比如基于人工置顶规则的根因分析）遇到瓶颈，需要新的智能运维技术来适应容器和微服务等底层技术的更新

故障识别也叫故障根因分析（Root Cause Analysis） ，是智能运维领域非常有挑战性的一个工作，主要在于三个原因：
1.对各类事件的监控要全面，少了数据不行，实践中很难一下就全面监控各类事件；
2.对各类事件的监控要准确，但是很多事件的监控是依赖于异常检测的准确度的，而这个问题还没有在实践中很好解决，往往还是基于原始的静态阈值；
3.由于微服务的兴起，模块的更新变化变得很快，模块监控项之间的故障传播关系也在不断变化，导致无法通过先验知识建立静态的故障传播链。

实验室的主要工作重点在问题二和问题三：
1.通过集成学习方法实现算法与参数的智能筛选，使得异常检测在实践中不必再手动调算法、调参数，实用性大大提升，使得实践监控变得准确；
2.通过关联关系挖掘和随机森林自动挖掘微服务模块间的故障传播链关系。
以上都有相应的论文发表，我们还在尝试用最新的机器学习算法来进一步提升相应解决方案的性能。

提出的无人运维量化评级方法，不包含主观因素、不需要人主观打分。按照这种方法，每个单位都可以与其它单位、自己以往进行客观地比较，有效衡量本单位无人运维（或智能运维）在行业内的相对水平及自身进展。

一、 无人运维评级

希望能够量化、综合评估运维的生产力。因此，在设计具体指标的时候，我们考虑了如下因素：

1）直观上来讲，为了达到同等的稳定性、可靠性SLA，如果依赖人力的决策越多，其无人运维评级水平就相对低一些

2）希望这个评估指标能够与以下因素脱钩：行业、业务类型、业务规模、架构、技术、加班程度、外包情况等等

3）运维人力计入负责运维服务器、存储、网络、中间件、数据库、应用的所有人力

4）运维人力计入人力查看监控数据、排除故障、运维规划，盯屏幕、值班闲置的事件，但是不计入运维人员用于开发运维工具的时间

可以利用这种评级方法对同一行业的不同机构、不同行业的机构之间进行进行横向的量化比较，也可以对同一家机构不同时期进行纵向的量化比较。 CPO和无人运维评级可以给大家提供一个量化的依据，大家可以看到自己处于什么水准，同行处于什么水准，促进大家更好地朝着最终的无人运维目标前进。

二、通过AIOps实现无人运维

无人运维是我们的终极目标，AIOps是我们通往这个目标的手段。

AIOps的组成部分：

左侧是监控系统，相当于“眼睛”，采集各类运维监控数据（抓包、埋点、拨测、日志、流程等）， 全面感知系统状态；

中间部分是“大脑”，就是AIOps，它以眼睛感知到的数据作为输入，做出实时的运维决策，从而驱动“手”执行一些自动化的操作。此外，大脑还负责把监测的历史数据梳理成高水平的知识（即运维知识图谱），从而可以被算法模块调用、同时也可以供人查询

右边相当于“手”， 是基于确定逻辑的自动化工具，负责一些比如重启、回滚、流量调度、扩缩容、跨机房迁移等操作；

AIOps运维大脑主要包含两大部分：

1.运维知识图谱

定义：线下挖掘运维历史数据、建立各种画像，梳理出各类高水平的知识

这些知识有两类基本用途：

(1)可以通过查询工具（比如人机对话机器人）被运维人员消费

(2)动态决策利用实时监控数据和已经挖掘好的运维知识图谱进行实时决策

2.动态决策

定义：包括故障发现、故障定位、故障处置、故障规避等大场景

（1）故障发现
包含单指标异常检测、多指标异常检测、文本日志异常检测、交易链条日常检测等等

AIOps要解决的是“系统+算法”问题，而不是简单的算法问题。这是因为我们的运维对象是个庞大、复杂、跨协议层的系统，它里面的大量逻辑是程序员写的代码和各种网络协议和应用协议。因此，AIOps运维大脑中的每一个模块都相当复杂，所以我们不要期望把运维数据灌进一个通用AI算法就能完成该模块的功能。

解决任何一个AIOps中的模块或场景，都需要有“AIOps架构师”把复杂的场景和需求拆解成具体的功能模块： “眼”、“手”、“脑”。

“眼”解决那些通过采集数据全面感知系统运行状态就能解决的问题

“手”解决那些基于固定逻辑就能解决的问题；

“脑”又细分为两类模块：

（1）通过挖掘历史数据总结出来各种画像和知识；

（2）通过动态决策算法来处理各种具体运维场景。 “脑”里面的两个模块必须能被当前AI技术所解决（要求数据丰富、信息完整、清楚定义、单领域）

运维领域有很多问题当前AI技术没有办法直接整体解决，在这种情况下我们就继续把该问题拆解成更细的模块以期能够被当前AI技术解决

AIOps运维大脑的各个模块采用的通用AI算法差异非常大，有些模块还需要若干通用AI算法的组合才能良好解决

三、 智能故障发现

智能故障发现包括故障发现和故障定位

单指标异常检测的最新进展：

1）我们IMC2015工作是有监督的异常检测，解决了之前朴素异常检测算法无法普适的问题

2）后来我们在推广这个技术的过程中，发现有监督异常检测算法的应用场景是有限的，所以后来我们在WWW2018发明了一种无监督的异常检测算法

3）随着在实践中对该WWW2018算法的使用，发现它也存在一些不足。比如，当存在违反周期性的异常时，使用该算法效果不好，因此我们加入了时间信息解决了这个问题

4）WWW2018算法在处理非高斯噪声的指标时也存在不足，我们就实现了一个基于对抗生成网络的算法把这个问题解决了

5）此外，我们通过聚类算法和迁移学习，实现了对于百万级指标进行异常检测

6）对于游戏等生命周期很短的应用通过半监督学习快速进行异常检测

7）通过参数自动迁移，在指标模式漂移后自动适配异常检测算法。最后这些算法整合成了我们非常智能的单指标异常检测算法

在单指标异常检测的基础上，我们还实现了多指标异常检测、面向文本日志的异常检测、对交易链条的异常检测、异常机器定位、异常多维定位、变更故障定位、交易链条定位等。这些AIOps最终被整合在一起，形成我们的“智能故障发现”系统。

智能故障发现系统：一线运维人员无需关注背后的种种算法：当有故障发生时，系统直接告诉运维人员哪里出了什么样的故障，以及该故障的原因是什么。系统不是将海量的监控都推给运维人员让他自己搞清楚问题是什么，而是已经汇总好，直接给出问题所在。

例如：某一个具体日志时间，发生故障时第三个参数取值的分布在故障之前和故障之后有显著变化，这样就给运维人员提供了非常清晰的提示和参考，指导人员下一步该怎么做。同时系统还会提示本次故障和历史上某次故障症状上非常相似或有某种关系，进而建议运维人员现在可采取什么样的处置方案应对当前故障。

四、运维知识图谱

构建运维知识图谱是指从运维数据中自动挖掘：

1.各类运维主体

2.运维主体的各类特性画像和规律

3.运维主体之间的关系

运维主体包括系统软件、硬件及其运行状态

软件是指服务、微服务、中间件、存储服务、数据库等等；

硬件是指机房、机群、机架、服务器、虚拟机、容器、硬盘、路由器、交换机等等；

各类监控数据，包括指标、日志事件、Trace、变更、流程等等。

运维知识图谱与传统的运维专家知识又有什么区别呢？

第一，知识图谱是中心化的，而传统专家知识是分布在运维专家头脑中的，是去中心化的。

第二，知识图谱是连在一起的“一幅大图”；而专家知识是割裂的，所以，想要实时地把分布在专家头脑中的知识以及静态CMDB数据关联在一起，解决实时问题显然是不可行的。

第三，知识图谱可被快速查询，专家知识需要人力关联，所以缓慢易错。

第四，知识图谱可自动更新，而专家知识需要手动更新。

第五，可以自动生成知识图谱的变化报表，而利用专家知识要靠手动撰写报告。因此，建立运维知识图谱的优势是非常明显的。

运维知识图谱与CMDB的区别是什么呢？

运维知识图谱包含基于人工智能的、模糊的、自动化挖掘的知识，而CMDB是确定的、手工配置的知识或基于确定逻辑自动配置的知识。

五.智能运维的发展历程

在运维发展的过程中，最早出现的是手工运维，在大量的自动化脚本产生后，就有了自动化的运维，后来又出现了DevOps和智能运维

在运维的过程中，涉及到的步骤可以概括为：产生海量的监测日志，进行分析决策，并通过自动化的脚本进行控制

运维的发展过程，主要是分析决策步骤发生了变化：起初，由人工决策分析；后来，在采集数据的基础上，使用自动化的脚本进行决策分析；最后，用机器学习方法做决策分析

很多故障都是突发的，在处理突发故障时，我们主要关心三个问题：发生了什么，怎么解决，多长时间能解决。由人力来回答这些问题效率低、不准确、不及时。因为我们要对付的这个系统实在是太复杂了。AIOps提高运维生产力的一种方式就是把处理突发故障时的人力分析尽可能的都替换成机器来做。

我们现在有非常多的监控工具，采集存储了海量的、价值极高的各种监控数据。我们希望当遇到突发事件的时候，能够基于这些数据快速准确做出决策。而处理海量、高速、多样的数据并产生高价值，正是机器学习的专长。也就是说，采用机器学习技术是运维的一个必然的走向。

1、智能运维科研门槛高

智能运维需要三方面的知识：

第一，我们要熟悉应用的行业，比如说互联网、电信或者相对传统的行业，如金融、电力等等。
第二，我们要熟悉运维相关的场景，包括异常检测、故障预测、瓶颈分析、容量预测等。
第三，虽然工业界熟悉运维行业和场景，熟悉生产实践中的挑战，也有数据。但是，工业界并不熟悉整个智能运维中最重要的部分——如何把实际问题转化为算法问题（后面会讲到如何把实践中的难题分解成多个算法并逐个解决）。同时，工业界也不太熟悉查阅科研文献，特别是跨行业的文献。因此，智能运维是一个需要三方面领域知识结合的高门槛领域。

2.AIOps拥有广泛的AI算法，要具体问题具体分析

AIOps领域的算法种类多种多样,不同的场景下使用的人工智能方法也有所不同。只有针对具体问题进行具体分析，足够聚焦，才有可能通过人工智能的方式解决问题。

3.尽量减少数据标注

 运维领域算法如果能不用数据标注就尽量不用数据标注，这一点与计算机视觉领域有强烈的对比。比如，在计算机视觉领域，物理识别应用要求有数据标注，对标注质量要求也比较高，在没有标注的情况下可以通过众包解决。通常，一个普通人就能完成标注，质量也能有保证。不同的是，运维领域的数据标注无法通过众包来解决，因为只有运维领域专家才能有效、准确地进行标注。然而，运维领域专家因工作忙碌抽不出时间，也不愿意进行标注。

 因此，我们做智能运维算法时，首选能使用无监督方法就使用无监督方法，在无监督方法效果不理想时，再加入主动学习，让人工对效果不理想的部分做进一步反馈，用于指导、调整无监督算法里面的参数；其次，使用半监督学习方法，比如有监督学习+迁移学习、无监督学习+迁移学习等；最后，使用有监督学习方法，不过由于标注很少且很难获得标注，整体效果并不好。

4.尽可能使用多模态数据

解决真实事件问题，不能只看指标、日志或者调用链，而是尽量使用多模态数据，因为数据特征越丰富，智能运维的结果就会越明显。在这个过程中，需要根据“知识+数据”双轮驱动中的“知识”对多模态数据进行有效关联，实现“上帝视角”，避免“盲人摸象”的效果。这里说的“知识”可能来自一部分数据，比如拓扑、调用链；也可能来自于经验，基于IT 架构挖掘出来的因果关系。

5.智能运维将来的愿景

现有监控提供数据采集，AIOps的引擎做出决策建议，少数运维专家最终决策，执行自动化脚本进行故障止损、修复、规避等操作

具体而言，AIOps引擎 中的“异常检测”模块在检测到异常之后可以将报警第一时间报给运维人员，达到“故障发现”的效果；“异常定位”模块达到“故障止损”的效果，它会给出一些止损的建议，运维专家看到这个定位之后也许他不知道根因，但是他知道怎么去根据已有的预案来进行止损，然后再执行自动化的脚本。

如果是软件上线导致的问题我们回卷，如果业务不允许回卷就赶紧发布更新版本；如果是容量不够了，那我们动态扩容；如果部分软硬件出问题了，我们切换一下流量等等。AIOps引擎中的“根因分析”模块会找出故障的根因，从而对其进行修复。

如果根因是硬件出了问题，像慢性病一样的问题，那我们可以让我们的运维人员去修复。同时，AIOps 引擎中的“异常预测模块”能够提前预测性能瓶颈、容量不足、故障等，从而实现“故障规避”。比如，如果我们预测出来了设备故障的话，那么可以更新设备；如果说我们发现性能上的瓶颈是代码导致的，那就交给研发人员去修改。

上图是展望的AIOps大概的体系结构

核心的AIOps的引擎会积累一个知识库，从里边不断的学习。也就是说监控数据会给AIOps提供训练数据的基础，然后专家会反馈一部分专家知识。这里面关键的一点是，我们还是离不开运维专家的。最终的止损、规避的决策、软件的代码修复以及设备的更换还是要靠人来做的，但是机器把绝大部分工作都做了，包括异常检测、异常定位、根因分析、异常预测。