基于AIOps的无人运维

白凡

我今天分享主题基于AIOps无人运维，总结过去三到六个月里面新的思考，还有我们在清华实验室最近一段时间的进展。
我们知道运维是当代社会一个基础设施级别行业，各行各业都是建立在数字化软硬件基础上，没有运维，不管各行各业，不管什么行业，金融、电信、互联网、物联网都不能有效、高效、稳定、可靠运转，既然运维这么重要为什么出现各种各样故障？本质上因为现在遇到的矛盾，这个矛盾是什么？人力决策已经无法应对我们运维所面临的挑战，我们非常复杂介入网络数据中心和应用拓扑，非常庞大、复杂、跨协议层，它里面基础、软件、配置随着时间推移，不断高速在演变，这样一个复杂的分布式系统，它里面软硬件会发生故障，不管软硬件都有BUG，大量的变更，各种各样用户流量变化，还有安全方面的攻击。

与此同时，我们用户随着移动互联网发展越来越挑剔，对移动体验要求越来越高，我们对系统运行状态有更多了解，部署海量监控数据，有海量监控数据。遇到运维故障时候，在高压情况下做准确的人力运维决策，这个趋势愈演愈烈，需要人力做大量决策，面临系统这么庞大复杂，这么多监控数据，靠人做不现实的，我们遇到这样挑战，我们运维人员处在水深火热之中，我们运维人员自己做的打油诗，我不多念了，人少事多，救火背锅。

解决思路是什么呢，我们希望逐渐减少人力决策在运维中所占的比例，就像我们交通工具所经历的变革一样。交通工具人力驱动，后边能够做到自动驱动，我还需要做大量的人力决策，最终我们希望能够做到无人驾驶，你坐在车上面，车自动带你去目的地，这个发展有过程，为什么有无人驾驶分级。

对于运维希望做到这一点，最早人力运维到我们自动化的运维，但是有大量的人力投入到盯屏或者人力决策，我们希望做到自主决策，我们开发运维工具能够自主决策做各种运维方面的决定，而不是需要我们人力在里面进行决策。

这是我们的目标，也就是基于AIOps无人运维，无人运维咱们的目标，咱们一步步的去。AIOps是什么，它是工具，是我们的手段。我们看一看具体会怎么做，讲具体怎么做之前，受无人车的评级启发，我们希望能给一些评级的方式，各种不同的白皮书也都提到了评级的方式，我这边学术角度提出一个比较量化评级，没有太多主观因素，不需要靠人主观打分，每个人给自己所在单位评出一个级来，大家处于不同行业能够横向比较，还能够纵向比较，今年什么水平，明年什么水平，能看到自己的进展。

1. 无人运维评级

我们希望达到效果是什么，讲具体怎么设计之前，希望达到效果是什么？我们希望能够量化评估，并且综合评估运维的生产力，希望最终设计出来之后跟这个同等重要。我们假设各个机构依赖已有运维技术和已有人力满足一定可靠性和稳定性，大家组织优类似这个需求，为了达到同等SLA，人力越多，两个同样行业组织，人力越多依赖人力决策越多，依赖人力运维越多，相对水平低一些，希望留下的因素有这些，这些人力都计算在内，并且记录人力运维查看监控数据时间、排除故障时间、运维规划时间，以及值班运维人员盯屏幕闲置时间等等，运维人员把时间花在工具开发时间不计在里面，我们定义这样一个指标，每个OP平均管理X86的CPU核数，我们以这样方式计算，每个OP一周工作40小时，通过这样一个定义采访的几家机构，传统行业在几百的级别，基于公有云中小型互联网公司几千，大型互联网公司几万。

举几个例子，这些虚构例子，不要对号入座。互联网公司硬件资源X86架构，这么多服务器，每12核、24核服务器，总台数这么多，中间有这么多人，他们各自用于人力运维时间按一定比例计算下来，核算下来390OP，这个数据1300万核除以390是3.3万核，对应是处于2级别。

互联网公司B，运维水准相对高一些，没有达到无人运维。它运维同样架构，类似的业务，它运维人员有这些，最后核算下来130人，这么一除是10万核，这样一算它的水准是高一层。B比A高，是智能化程度高。真正做到无人运维还远着呢，但是我们步步往前去。

传统行业，大型银行，比如它有X86服务器1万台，每台12核有小机，核算每台小机多少核，大机多少核，核数18万核，各种运维人力，包括外包运维人力200人，最后核算下来490运维人力，这样一算属于水准多少，远低于A、B，这里面有行业原因，包括银行对稳定性、可靠性，这是它的最高优先级，稳定压大一切。其他方面的因素，因为稳定压倒一切，我们运维技术没有发展真正无人运维水平，保证稳定性和可靠性依赖大量人力补足，希望能够提升可靠性。

另外一家银行，X85的服务器1万台增长到10万台，保持运维水准不变，每个运维人力管理363个核，需要多少人，需要300多人。如果人力保持这么多人不变，你需要把水准，CPU的值增长10倍，从0级变成1级，无人运维评级增加一些，时间发生在三年之内，实实在在需要三年内把它的X86服务器增加10倍。

我们举几个例子给大家直观感受，不同行业横向比较，自己和自己纵向可以比较。虽然这个东西相对草稿级别，但是给大家提供一个量化的依据，大家可以私底下交流一下，看自己处于什么水准，同行处于什么水准，促进大家更好共同朝着最终无人运维目标去前进。

2. 实现无人运维

说到这样的目标，如果从0进展到1、2，刚才说过AIOps基于人工智能的运维。我们经常讲到，在这里面AIOps有两个相关部分，一个是全面感知系统状态，我们常说的监控系统。还有我们自动化运维，自动化运维里面怎么定义自动化和AI，程序里面它的逻辑是固定逻辑，那么基本上可以认为是偏自动化一些。如果你的逻辑通过数据，由算法自动总结出来的逻辑，虽然代码执行相对确定，但是总结出来由算法根据数据总结出来，这是AI。其中两大部分，由数据到决策是什么，实时数据到决策是智能决策算法、动态决策所发。动态到执行，我们基于海量监控数据挖掘出来、总结出来这样的知识，像我们大脑里面一样有处理事情算法，我们有根据历史实践学习出来各种知识。

我们刚才说的大脑中间的AIOps部分，它大概包含哪些成分呢，各自经验背景不一样，总结出来不一样，根据大概20年左右运维经验总结出来，现象监控数据，统计数据平台，中间两大部分，运维知识图谱，我们运维的大脑，运维知识图谱就是我说的线下挖掘运维历史数据，建立各种画像，类似于这些，这些可以被我们人自动在工具上面查询，可以被我们上面动态决策模块调用，动态决策利用实时监控数据和已经挖掘好的运维知识图谱进行实时决策。比如我们常见故障发现、故障处置和故障规避等等。这些里面每一个大方向，可能里面包含若干模块，比如我们常说故障发现，单指标异常检测、多指标异常检测等等，这里面时间关系不一个个念了，每一个大的模块里面有小模块，每一个小模块投入大量人力和精力去做。去年时候这块是重点，投入10个博士生全部研究这方面工作，每个人负责一小块，整体把这个点给突破。

在这边特别强调一点，前面说的大脑，它里面的每一个模块都是蛮复杂，你要想办法解决它的时候，你不要觉得拿一个AI的通用算法，各种工具拿一些算法把运维数据倒进去能解决。刚才提到它是非常庞大复杂跨协议层的系统，它里面大量逻辑是程序员写的代码和各种网络协议和应用协议，我们首先AIOps什么问题？系统问题，不是简单的算法问题。

任何一个系统问题，我们建立一个电商网站一样，我们首先有架构师把复杂的场景和需求，把它拆解成具体的功能模块。对于我们来说拆解成眼睛，全面感知系统运营状态采集数据能解决，我们把它拆解成基于固定逻辑能做的东西，剩下的两块，我们详细拆解成通过挖掘历史数据总结出来各种画像和知识，我们通过发明的动态决策，基于这个算法来和这些具体运维场景。
这边特别强调，这两个模块被当前AI技术所能解决，为什么这么说，当前AI发展属于非常早期阶段，功能非常有限，知道AI有算法能做，我们运维场景里面很多问题AI没有直接算法能做，你的解决思路希望把它拆成更细模块能够被AI解决。

举下例子，刚才画图分很多模块，清华实验室每个模块尝试过行之有效的算法，我用不同颜色编码机器学习大致类型，具体算法在这儿。这里面很多细节，不是想给大家展现细节，即使对于里面的小模块，尝试海量算法里面去选择，跟其他不同模块算法不一样，拆解成AI能解决，AIOps算法海量非常多的。

3. AIOps算法进展举例

最后一部分，介绍一下我们这段时间取得的进展，通过两个主要方向的例子，一个决策算法，一个是知识图谱。

3.1 决策算法

我们举大家最熟悉的单指标异常检测为例，在过去若干年中取得一些进展，两年前我开始分享是这样，主要分享这个案例，监督异常检测，解决之前朴素的异常检测算法，基于统计算法普世性问题。今年初，2018年发表一篇完全无监督的异常检测算法，它又可以改进地方，当违反周期性异常发生时候，我们又做了一个基于对抗生成网络算法，对于违反周期性的异常，我们加入了时间信息在里面，利用零星标签让系统举一反三，对于百万级曲线，游戏生命周期很短，一上线监控数据起来，没有多少历史数据监控起来，对于海量百万级曲线模型和参数迁移，对于已有的可能发生变化，如何自动检测和自动系统适配。

如果大家熟悉我去年做的演讲，这个去年我展望过，这里面比较自豪和大家说一声去年展望的，吹过的牛百分之八九十实现了，过程非常艰辛，里面每一个方块，每一个博士生辛辛苦苦没日没夜做出来，这个过程很艰辛。这样艰辛工作基础上，我们整合成非常智能单指标异常检测算法。单指标异常检测基础上有多指标异常检测，基于文本日志异常检测，不是文本简单提取KPI指标检测，像自然语言处理对它进行检测，包括交易链条异常检测，这是文本异常检测和交易链条异常检测，我们对部署新代码、新配置带来故障可能的检测，多维指标检测，还有对故障机器的定位，最终达到的效果是什么呢？我们希望当业务出故障时候，业务出故障不仅迅速发现它是否出问题，准确发现出问题，并且告诉我们运维人员问题到底在哪儿。

我们看一下把这些算法集中在一起会怎样，一线运维人员不会关注后面算法，就看功能。这个东西，运维的业务，上面发生时间线体现在这里，下面具体分项监控，包括业务的主要指标，包括日志和调用链条这些监控，点击会有日志里面模板，这里面很多细节，不多说，时间关系。

包括参数取值范围和取值分布，这边出现问题，横轴表示故障持续时间，点一下事件，把跟它相关聚合好的所有监控报警事件，聚合在一起，不是海量的监控都堆给我们运维人员让他自己搞清楚问题是什么。是我们已经汇总好，点击完跟这个事件相关主要报警是哪些，下面会有具体监控自动分析出来发生故障的计算资源到底是谁，这些计算资源上面哪些指标出了问题。

这里面展示5台机器4项指标出问题，我们人要看的上万台机器各自的100个指标，我们已经把这个结果呈现出来了，在日志旁边如果有结果，某一个具体日志模板和日志实践，发生时候第三个参数，取这两个值时候，故障之前和故障之后有显著变化，这样给我们运维人员非常清晰下一步怎么做的指示。
所有故障相关事件通过后面算法智能发现、智能定位了，还可以做得更进一步，我们通过可视化、层次化战时，把所有结果串起来，更直观呈现给具体的运维人员，包括本次故障和之前发生的，一天前、两个月之前发生哪个事件，它症状上几乎一样，那里面处置方式会对现在故障有显著帮助。

这是我们决策算法给了一个例子，我们做了很多的。一个算法，根据海量监控数据，所有监控数据都汇总在一起，告诉运维人员业务有没有出问题，出问题到底发生在哪儿，给我结果告诉实际人工后面做什么事情，这不是无人运维，但是朝着无人运维方向进了一大步。

人日常过程中处理非常大数据，像大家听报告一样，你吸收各个讲者信息，你会梳理出自己的知识，不是他讲每一句话、每一个字、讲的PPT。我们自动运维数据终挖掘各类运维主体各类特性和规律，我们先说一下主体，运维主体是系统软硬件，机器运行状态，软件是我们的服务、微服务、中间件、存储服务等等。硬件是机房、虚拟机、硬盘、路由器等等。第三类，上面各类监控数据，不一定全，列出四大类，指标，日志数据等等，这些都是主体。最终希望所有主体在一张硕大无比的图上面，节点它们之间的关系。它与CMDB什么区别，手动配置或者固定逻辑的自动挖掘，我们这边实际基于统计数据，基于人工智能和神经网络进行挖掘，最关键的区别，这里面挖掘出来的什么东西，它主要确定，这边相对模糊，是经验的。

3.2 知识图谱

相对传统专家知识，我们知识图谱中心化。去中心化，这些专家知识分布在运维专家头脑中，经验丰富可能多一点，经验不丰富可能少一些。这个好处是什么，直接调用去查，不是现场值班和状态如何。

知识图谱是连接，刚才我说所有放一幅图，这个所有割裂，实时把分布专家头脑中的知识，它的静态CMDB数据，把它关联在一起解决实时问题显然不可行。知识图谱可被快速查询，基于我们算法拿历史数据自动更新，这个需要手动更新，不宜维护。生成图谱变化报表，系统升级前、升级后，系统知识图谱有没有发生变化，要靠手动撰写报告，这里面显著的区别。

举两个例子，看一下这幅图，上面大家非常熟悉的硬件方面，可能CMDB都有了，容器、物理机、交换机、机房，物理主体之间的关系。这是硬件主题，我们看对于这样一个容器有硬件细节，CPU、内存、存储类型、存储空间等等，这些可以认为配置信息能够自动构建出来的静态属性。我们挖掘学习出来的数据，比如我们这个容器这样配置情况下，内存达到多少，有什么限制等等，这些限制很难靠人，得靠挖掘出来。

我们刚才看物理这些硬件关系，我们看软件和硬件关系，以及软件和软件关系，服务1调用微服务1，微服务1部署在容器1上面，这是我们说软硬件主体之间在图中连起来了。
看一下还需要挖掘的东西，容器类型1，它有这样的配置，它要支持微服务1，这个要靠专家经验了。我们希望做到什么？根据历史数据，包括压测数据，我们把这个东西画像给它画出来，我们说的挖掘出的关系。
再往上更高级别指标，服务1有流量，按省份拆分，再按运营商拆分，是包含关系。今天说几百万曲线、几百万指标，这些之间都是有关系，这个关系可以写成固定逻辑，编码已有工具里面，也可以在这幅图里面，在这个图上面再开发算法。
我们再看一下流量这边，它有什么可以画像，增长趋势、季节性、高峰时段、特殊日，有没有最佳的变更时段。这些信息在运维人员脑子里面多多少少有一些，不是希望用到时候运维人员脑子里面抓出来，这些运维人员，把他们专家知识，在没有发生事情时候通过我们算法，在历史数据中形成自动学习方法，我们专家指导这些算法把这些画像给画出来，不是他的脑子里面知识弄出来。
这些指标之间的关系等等，我们看一下最后的例子，我们微服务1可能部署多个容器，响应时间指标，容器1响应时间和容器2响应时间，他们同质同构，响应时间就应该长成一样，形成一个聚类。容器3和别人不聚在一类，说明容器3多半出了点问题，我们对它能够进行画像，检测出来容器3所在机器可能有一些问题，或者负载均衡不均衡等等，我只是在有限的一幅图、一页PPT里面展示很大知识图谱的切面，可以想象我们上万台机器，上面上千万指标，这些东西串在一起形成大图。你说这幅图不是给人看，本来就是给机器看的。

假设下个月大促支持2万笔每秒交易，我们有这个信息，这个事情变得很显然，变成查询，不担心弄到弄低。
故障传播图，解决我们最痛苦的一点，故障根因分析，底层硬件发生故障，对上层有没有影响，对我们核心业务有没有影响，有故障传播图可以很好做这个事情。故障传播图可以长成什么样子呢，比如服务1下面调用了微服务1.1和微服务1.2，他们有共同的KPI，这个边什么关系，KPI直接包含关系，下面两个聚合上面，这个依据配制自动生成。数据库日志发生事件影响到这个，这里发生事件导致它发生故障，这个根据历史数据挖掘出来，具体的算法之前也聊过。
还有一些，根据部署的信息能够自动配置，比如容器1.2.1，上面部署微服务1.2，容器报警自然上面微服务有可能故障传播关系，所以这也是根据配置信息自动生成的关系。两个都有包茎，有波动相关，自动挖掘出关系，故障传播关系。可能数据里面没有那么多，我们知道网络协议写死是有标准，我们根据网络协议，根据我们专家把写死这些规则也能写出来，交换机、日志实践，比如物理层故障导致链路层故障，不用挖掘，自然知道，这是写死。还有一些自动挖掘出来的画像信息，比如厂商手册中关于日志事件V有一些相关知识，为什么发生，处置方法是什么，自动把手册里面东西挖掘出来变成我们知识，把历史事件V相关处置方案，你的系统下如何变成我们的画像和知识。最后发现说的所有运维相关历史经验知识，可以从运维专家脑子里面通过算法转变成处理的东西，形成故障传播图。我们最大的痛点故障根因分析听起来也就可解了，这方面我们投入大量人力，超过10个人。

4. 总结和展望

这是算法进展，知识图谱里面，大的架构上面怎么进行设计，后面一步步怎么去解决。这里面一些信息，包括智能运维前沿的公众号，包括清华开设课的课件这些。大家非常看好AIOps方向，同时这条路不是非常轻松，需要付出大量的努力，包括在座各位在内共同努力。我们不断地努力，不断地探索，能给我们所在的各行各业逐渐带来革命性影响。2018年初说AIOps今年落地的元年，根据我收集到信息的确落地的元年。
我们提出这样一个量化评估指标，希望给在座各位提供横向和纵向比较的基础。AIOps我们实现无人运维的重要手段，这个手段通过我们监控、自动化、基于AI知识图谱画像，包括基于AI智能决策算法，我们不断地取得了一些实质性进展，这些进展付出了巨大的努力，包括我们决策算法距离，这是智能故障发现和知识图谱，基于AIOps无人运维，我们这个时代赋予中国运维人的基于和长期目标，我们其实有机会让中国无人运维站在世界最高水平上，我们局部一些点上，单指标和KPI异常检测取得世界前沿成果，大家共同努力和共同推进，我们中国整体运维水平有机会站在世界最高水平。
不光技术方面意义，而且我们社会意义上也是非常重要，前面说了我们运维人员处于水深火热之中，如果把我们无人运维水平从零级提升到一级、二级，我们实在改变千万运维人生活工作和生活质量，让我们大家一起努力推动中国无人运维方向的进展，谢谢大家。