前言

AIOps概念火热，但如何落地？清华大学裴丹副教授在GOPS上海站的主题演讲中，通过庖丁解牛的方式给出了AIOps落地的技术路线图；同时提出AIOps落地战略路线图，通过AIOps Challenge网站，汇聚社区力量，共同推进AIOps落地。 以下是裴丹副教授的演讲稿。

概述

这两年随着人工智能大潮来临，基于人工智能的智能运维（AIOps）开始火爆起来了,得到了更广泛的关注，并且有一小部分人一往无前的投入到AIOps中去了。

但是还存在一个无法回避的问题：AIOps到底在自己的场景下怎么落地？所以今天不分享具体案例，而是分享AIOps落地应该遵循的路线图。既有技术路线图，也有战略路线图。这虽然不是唯一的一个路线图，但这是我今后十年会不断努力、专注和迭代的一个方向，希望为那些对AIOps感兴趣的朋友们提供一些借鉴意义。

1.运维的目标和意义

运维在人类未来的生产生活中的作用会越来越重要。预计到2020年全球将有500亿到1000亿的设备，这些设备会承载无数的服务，涵盖互联网、金融、物联网、智能制造、电信、电力网络、政府等等的生产生活的方方面面。这些硬件和软件都是人造出来的，都是不完美的。运维要做的是保障业务能够可靠高速高效安全的运转，因为它会直接影响到业务的收益和成本。目前已有运维方法的主要难点是突发故障的发现、止损、修复和规避，也是我们要解决的关键问题。这些难点导致我们运维人有很多痛点。

2.运维的痛点

我相信在座的各位都看到过这幅图，我们运维人是全年365天7×24小时的救火，我们压力山大。在过去的三个月里，我走访了大概几十家跟运维相关的单位，我经常听到的描述是我们的压力很大、我们在不停的背锅、我们的日子是如履薄冰、幸福指数低、不知道下一秒会发生什么、睡不了安稳觉，还有人略带夸张的说我们做运维就是把脑袋别在裤腰带上。但是从这些描述我们能体会到我们运维人目前的工具还不足，因此如果人工智能能帮助我们的话，运维的生产力将得到极大的提高。

最早先运维处于手工阶段时，可能每天需要“祈祷”不要发生故障。在实现自动化运维后，我们实现了不少自动化脚本，把很多已知任务像流水线一样串起来，就像特斯拉电动机车流水线一样。但是，很多故障都是突发的。在故障突发时，我们会把所有相关的人纠集到一个作战室，然后大家在一起拼命的想搞清楚问题的原因。我们的目标是两分钟就能搞定，实际上有可能需要一个半小时。在解决问题的过程中，每一分每一秒都在给业务带来持续损失。在处理突发故障时，我们主要关心三个问题（也是领导最关心的问题）：发生了什么，怎么解决，多长时间能解决。由人力来回答这些问题效率低、不准确、不及时。因为我们要对付的这个系统实在是太复杂了。AIOps提高运维生产力的一种方式就是把处理突发故障时的人力分析尽可能的都替换成机器来做。

3.痛点的来源

我们现在来看看复杂度的来源。下图展示的是对一个互联网公司来说最不可控的部分——越来越复杂接入网络。这是当时AT&T的一个网络拓扑图，左上角的iPhone连接到互联网的话，经历的这个网络设备的种类有十几种，数量几十个。

数据中心的系统也在不断的演进，其规模复杂度、变更频率非常大，技术更新也非常的快。网络中心的拓扑越来越庞大，像上图所示，微软Azure数据中心大概半年就会更新一次拓扑结构，然后底层会逐渐融入SDN、NFV这样的技术。

与此同时，软件的规模、调用关系、变更频率也在逐渐增大。上图是前两天腾讯视频的朋友提供的软件模块之间的调用，非常复杂。同时，由于持续集成、敏捷开发、DevOps，每一个模块随时都可能发生变化，随时都可能给我们带来故障，也就是说整个云计算也在不断地发生变化。容器、持续交付、软件架构、工程方法也在不断的演进，会不断的给我运维工作带来挑战。

所以说，这么庞大、复杂、多变的软硬件系统，它的软硬件故障的放生是不可能避免的，但是我们运维需要保障上层的业务可靠高速高效安全的运转。那遇到突发故障的时候我们怎么能准确快速的决策呢？如果要靠人力去维护一些规则，那是显然不可行的。

4.解决办法–AIOps

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

我们希望在将来会有一个自动决策的CPU，大大的提升我们运维的效率，要真正能做到不光是双11的时候我们能够喝茶来保证的运维，而是在日常365天7×24小时都能够喝着茶，把运维工作做好。那么将来的愿景是什么样子呢？现有监控提供数据采集，AIOps的引擎做出决策建议，少数运维专家最终决策，执行自动化脚本进行故障止损、修复、规避等操作。

具体而言，AIOps引擎 中的“异常检测”模块在检测到异常之后可以将报警第一时间报给运维人员，达到“故障发现”的效果；“异常定位”模块达到“故障止损”的效果，它会给出一些止损的建议，运维专家看到这个定位之后也许他不知道根因，但是他知道怎么去根据已有的预案来进行止损，然后再执行自动化的脚本。如果是软件上线导致的问题我们回卷，如果业务不允许回卷就赶紧发布更新版本；如果是容量不够了，那我们动态扩容；如果部分软硬件出问题了，我们切换一下流量等等。AIOps引擎中的“根因分析”模块会找出故障的根因，从而对其进行修复。 如果根因是硬件出了问题，像慢性病一样的问题，那我们可以让我们的运维人员去修复。同时，AIOps 引擎中的“异常预测模块”能够提前预测性能瓶颈、容量不足、故障等，从而实现“故障规避”。比如，如果我们预测出来了设备故障的话，那么可以更新设备；如果说我们发现性能上的瓶颈是代码导致的，那就交给研发人员去修改。

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

5.AIOps的落地情况

核心思路–庖丁解牛

那么AIOps中“异常检测”到底如何落地呢？很简单，我们的方法论就是庖丁解牛。

当你刚开始接触异常检测这一问题时，你看到的就是一头全牛。但是，当你深入了解了异常检测之后，你就会目无全牛。你看到的是它的经脉。然后，你就不用困扰于具体的技术细节，而是要根据它的经脉，闭着眼睛就可以根据脑海中的图把这个牛给解剖了。每一刀都能够切中要害，游刃有余。

其实我们做异常检测这个事情也是一样的，我们只需要把前面的挑战都逐一的分解开，个个击破。刚才我们那些问题混杂在一起，这东西听起来就搞不定，但是如果我们能够把它们分解开，每一个变成了AI善于解决的问题，让它封闭住让它well-defined，那异常检测就变得可解了。

上图中左上子图所示， 我们先做一个无监督的异常检测，为什么呢？因为刚才说了，标注数据很难大批量获得，那我们先用一个无监督的异常检测作为初筛，一旦有了这个无监督异常检测，那我们再提供一个非常友好的界面，然后在上面我们的运维人员可以零星的把他们碰到的case在上面标注一下，然后我们提供基于算法的工具自动搜索跟它标注出来的异常区间类似的，达到举一反百、甚至举一反千的效果，让它的标注工作能够被充分利用，让它的标注开销非常非常低，如右中子图所示。之后就可以采用已有的有监督的异常检测，解决算法和参数的普适性问题（左中子图）。同时，如果遇到右下子图的那个KPI曲线的模式的突变的话，我们首先判断新模式是否跟老模式属于同一类型，然后自动通过迁移学习自动调整算法参数。最后，如左下子图所示，为了对大量的KPI自动地分配检测算法， 我们先把海量的KPI进行分类。即使有几百万条曲线，其类别也不会太多。我们在每一类里面找到典型的算法，然后对同一类里的每根曲线进行微调。

那我们把这个稍微梳理一下，最底下的是机器学习算法，最上面的是我们要做的这样一个自适应的异常检测系统，中间我们有一些技术层就是前面那页具体要解决的问题，下面还有一个智能运维的算法层，，所以我通过这个小的实例来说明一下我的idea，就是说我们要把这个技术进行分解，把我们要解决的复杂问题庖丁解牛分解成实际上是AI善于解决的问题。

故障发现

通过上面这个例子，我们可以看到，一个在实践中看起来非常难的异常检测问题，通过刨丁解牛的方法，可以分解成一系列问题的时候，它每一个都变成用AI方法可解了。我们面对的不再是运维应用场景与标准机器学习算法之间巨大的鸿沟，而是在中间加入了AIOps基础算法层，和AIOps关键技术层。其中关键技术层解决的是前一幅图中的挑战，而基础算法层为关键技术层和最终的运维场景提供基础的算法支撑。如上图图所示。比如说刚才提到的我们需要对海量KPI进行异常检测的话，就需要对它进行聚类。KPI聚类的问题就是一个单独的问题。如果把这一问题拎出来，你会发现这个问题其实很抽象，输入是若干条曲线，输出是按照曲线形状的分类。这个问题对于做算法的人来说非常可解，非常well-defined，只要给了数据，人工智能肯定能搞定这个KPI聚类算法，并且AI算法专家并不需深入理解运维场景就能研究这个问题。图中的每个问题都是一个AI比较擅长解决的问题，但是他们之间还有一些先后依赖关系。也就是说，我们提供了一个落地AIOps中的“自适应异常检测”的一个技术路线图。

上图是AIOps的整体路线图。包含了异常检测、异常定位、根因分析和异常预测。原来实践AIOps遇到困难的原因是试图通过底层的标准机器学习算法解决最上层的运维应用，这种方法论解决不了实际问题很正常，因为这种方法是吧问题当做一整头牛来处理。后面我们对故障止损、故障修复、故障预测再简单做一下庖丁解牛。

故障止损

在故障报出来之后，我们希望它能够有一些定位功能。那定位到什么粒度呢？定位的粒度足以实施运维专家提前准备好的修复预案，从而可以执行自动化的脚本进行回卷、动态扩缩、切流量等等。如右上子图所示，如果是变更导致了业务的异常，那运维人员把这个变更回卷一下就好了，如果业务不允许回卷（如涉及到用户交易）那么就需要快速部署更新过的新版本。把这个问题定义分解出来，那我们的预期是很清楚的——智能运维的算法需要告诉运维人员哪个变更导致了这个业务的巨变。我们之前也和百度在这方面合作过一个案例。

再以左上子图的单指标多维度监控为例。例如，运维人员需要监控流量的异常，并需要在数据中心、运营商、用户类型、浏览器等各个维度进行监控。一旦总流量出现了异常，它可能在各个维度都会出现报警。我们需要快速定位到具体哪些维度的组合导致了总流量的异常。比如，如果我们定位到根因是某个数据中心的某个集群的流量出现了异常，那我们就可以把该数据中心的流量切换掉就可以解决问题。同理，在右中子图中，当业务指标发生剧烈波动时，我们找到该业务的哪些模块的哪些指标也同时发生了波动，并根据关联程度进行排序，给出最可能的根因位置，供运维人员进行定位。在左中子图中，一个不完善组粒度的故障树也能起到故障定位的效果。另外，还可以对故障进行最粗粒度的故障定界，确定是网络、服务器、存储、还是用户的问题，快速明确责任单位，便于止损，如右下子图所示。最后，还可以判断故障是否为容量不足导致，以便迅速做出动态扩容决策。以上都是来源于实际的各种故障止损需求。由于问题定义得相对清晰， 都可以通过AI来解决。

故障修复

根因分析的前提是报警（要求异常检测部分要报准），下一步就是构建故障树。由于软件模块之间的依赖关系太复杂，因此故障树的构建非常难。对所有的报警信息进行两两关联的计算量过大。一种思路是构建一个故障树的超集，通过模块调用链获得模块之间的逻辑调用关系，通过配置信息获得物理模块之间的物理关联，比如共享机器资源、网络资源等。这两部分一起构成一个可能的故障树，这棵树是真正故障树的一个超集。之后我们对这个超集中的每个边进行联动分析、联动分析，对这棵树进行剪枝，构成最终的故障传播关系。这种方法的覆盖面广，计算开销大大降低，并且是AI擅长解决的问题。当我们拥有了故障传播关系，并它比较全而且准的话，根因分析就变得可行了。当发生故障时，依据准确的报警， 顺着故障传播树就能找到根因，从而进行故障修复。

故障规避

性能瓶颈预测、容量预测、故障预测等异常预测是故障规避的经典场景，如上图所示。 性能瓶颈被预测出来后，比如发现哪个模块是整个系统性能的瓶颈，就可以对这部分进行代码优化，如果代码优化来不及的话，也可以选择定向扩容。容量预测之后，可以进行动态的扩缩容、资源预算等，比如当业务需要达到每秒三十万笔交易时，也许不用统一的全面的扩容，只需要把瓶颈部分的容量扩展。故障预测可以帮助进行动态的切流量、替换硬件等等。时间关系，不展开详述。

6.总结

以上就是AIOps落地的技术路线图，通过社区集合整个工业界的力量（因为他们熟悉运维场景、也有丰富的数据）同时集合算法界的力量（因为他们熟悉算法）。以往工业界和学术界的交流就是工业界和科学家的一对一进行交流合作。可能整个项目的一半时间都花在问题的定义和迭代上面，而且没有公认的benchmark数据和缺乏比较性。

后面会分享AIOPS更多这方面的内容，感兴趣的朋友可以关注下~