| 编辑推荐: |
本文主要包含“无人运维评级”、“智能故障发现”，“运维知识图谱”三个主要内容,希望对您的学习有所帮助。
本文来自于高维在线，由火龙果软件Delores编辑、推荐。 |
|
我们生活在一个数字化的社会中，而运维则是这个数字社会的一个基础设施级别的技术。
运维做得不好，各行各业，无论是金融、电信、能源、工业制造、互联网、物联网， 都不能高效、稳定、可靠地运转。
既然运维这么重要，为什么还常出现各种各样的、甚至影响非常大的故障呢？（见下图）。
本质原因是我们现在遇到了一个非常大的矛盾。
这个矛盾就是当前运维所大量依赖的人力决策已经无法应对当前运维所面临的挑战（见下图）。
随着互联网、移动互联网迅猛发展，用户越来越挑剔、对应用软件的用户体验要求越来越高。 而我们知道，应用软件都是建立在一个庞大、复杂、跨协议层的大型分布式系统之上的。
而这个分布式系统的技术、软件、配置通常会不断快速地演变; 其软硬件难以避免会发生故障、Bug, 变更；
用户流量会发生不可预知的变化，甚至会发生安全攻击事件， 而上述趋势有愈演愈烈之势。
尽管各类运维监控工具使得系统运行状态的可见度有较大提升，但是当遇到运维故障时，面对海量监控数据和庞大负责分布式系统，仍依赖运维人员在高压下人力做出迅速、准确的运维决策。这显然是不现实的。
也即人力运维决策已经无法应对当前的运维挑战。
这导致我们的运维人员的工作生活可以说是处于水深火热之中， “人少、事多，救火、背锅”，7*24小时时刻准备救火。
有运维人员自己做的打油诗为证（见下图）。
而我们解决上述核心矛盾的思路就是逐渐减少人力在运维决策中所占的比例，逐渐增加人工智能在运维决策中的比例，最终实现无人运维 (见下图)。
这就像交通工具所经历的变革一样：
起初交通工具要靠人力驱动，之后能够做到自动驱动，但还需要做大量的人力决策（每公里驾驶需要人力决策100次以上），最终我们希望能够做到无人驾驶——你坐在车上面，车自动带你去目的地。
运维已经从最早的人力运维发展到了一定程度上的自动化运维（但是还需要大量人力盯屏决策），最终我们希望基于人工智能的运维工具能够更多自主决策，只需很少人力、甚至不再需要人力参与决策。
这就是我们运维行业的长远的目标：基于 AIOps 无人运维。
无人运维是目标，AIOps（AI for IT Operations） 是工具、手段。
无人运维这个目标不可能一蹴而就，需要我们一步步脚踏实地、不断探索去实现。因此我们必须有一种客观的、量化的手段能够对无人运维（或智能运维）水平进行度量。
我们下面提出的无人运维量化评级方法，不包含主观因素、不需要人主观打分。
按照这种方法，每个单位都可以与其它单位、自己以往进行客观地比较，有效衡量本单位无人运维（或智能运维）在行业内的相对水平及自身进展。
一、 无人运维评级
如前所述，我们希望能够量化、综合评估运维的生产力。
因此，在设计具体指标的时候，我们考虑了如下因素：
1）直观上来讲，为了达到同等的稳定性、可靠性SLA，如果依赖人力的决策越多，其无人运维评级水平就相对低一些。
2）希望这个评估指标能够与以下因素脱钩：行业、业务类型、业务规模、架构、技术、加班程度、外包情况等等。
3）运维人力计入负责运维服务器、存储、网络、中间件、数据库、应用的所有人力。
4）运维人力计入人力查看监控数据、排除故障、运维规划，盯屏幕、值班闲置的事件，但是不计入运维人员用于开发运维工具的时间 （见下图）。
基于如上考虑，我们提出的指标是Cores per Op (CPO), 即每个运维人员OP（每周平均工作40小时）平均管理的X86 CPU核数，而评级可以对照下表直接换算。
在我之前访谈的若干家机构中， 传统行业的CPO大致在几百（对应Level 0），基于公有云中小型互联网公司的CPO大致几千（对应Level 1），大型互联网公司CPO 在几万（对应Level 2）。
下面通过举几个虚构的例子来进一步说明如何通过CPO和无人运维评级进行横向和纵向的比较。
某互联网公司A（见下图） 有X86架构的服务器100万台，其中12核的50万台、24核的50万台；人力共有400人、每人每周工作60小时，其中200人50%的时间用在人力运维，另200人80%的时间用在人力运维。
按照上述方法核算下来是390 Op，再用总核数（1300万）除以390OP，是3.3万核每OP，对应Level 2。
互联网公司B（见下图）运维水准要比A高一些: 总核数同样是1300万，但是总人力核算下来只有130 Op，用相同方法计算下来是Level 3, 比A高一级，表示其智能化程度更高。
从前两个例子里可以看出，同一类型的不同公司之间可以通过CPO和无人运维评级进行量化的横向比较。
再举一个传统行业的例子（见下图）。
某大型银行C的CPU核数核算下来有18万核，各种运维人力（其中包括外包运维人力200人）核算下来有495 Op。CPO为363，相当于Level 0。水平远低于互联网公司A、B。
这里面有行业原因，因为银行对稳定性、可靠性的优先级更高，所以银行C为保证稳定性和可靠性只好依赖大量的人力来补足运维工具的不足。 这里是不同行业的机构之间的横向比较。
由于银行C基于互联网的业务增长迅猛，银行C 计划3年内把X86的服务器从1万台增长到10万台，因此总核数预计增长为126万核。
如果保持运维水准不变（即每个运维人力管理363个核），则需要人力增加10倍，达到3000多人；但如果人力只能保持300多，这就必须提升自动化运维的水平，无人运维评级相应需要从0级升为1级。这是同一个机构通过CPO和无人运维评级进行自我纵向比较和规划的例子。
以上几个例子可以给大家一个比较直观的感受： 我们可以利用这种评级方法对同一行业的不同机构、不同行业的机构之间进行进行横向的量化比较，也可以对同一家机构不同时期进行纵向的量化比较。
CPO和无人运维评级可以给大家提供一个量化的依据，大家可以看到自己处于什么水准，同行处于什么水准，促进大家更好地朝着最终的无人运维目标前进。
我们相信上述CPO和无人运维评级在“基于AIOps的无人运维”发展中讲起到重要的促进作用。
二、通过AIOps实现无人运维
无人运维是我们的终极目标，AIOps是我们通往这个目标的手段。
如下图所示，AIOps有两个相关部分：
左侧是监控系统，相当于“眼睛”，采集各类运维监控数据（抓包、埋点、拨测、日志、流程等）， 全面感知系统状态；
右边相当于“手”， 是基于确定逻辑的自动化工具，负责一些比如重启、回滚、流量调度、扩缩容、跨机房迁移等操作；
中间部分是“大脑”，就是AIOps，它以眼睛感知到的数据作为输入，做出实时的运维决策，从而驱动“手”执行一些自动化的操作。
此外，大脑还负责把监测的历史数据梳理成高水平的知识（即运维知识图谱），从而可以被算法模块调用、同时也可以供人查询。
AIOps 运维大脑主要包含两大部分：“运维知识图谱”和“动态决策”。（见下图） 运维知识图谱就是线下挖掘运维历史数据、建立各种画像，梳理出各类高水平的知识。
这些知识有两类基本用途：
1） 可以通过查询工具（比如人机对话机器人）被运维人员消费；
2） 动态决策利用实时监控数据和已经挖掘好的运维知识图谱进行实时决策。“动态决策” 包括故障发现、故障定位、故障处置、故障规避等大场景。
每一个大场景还包含若干个小场景，比如故障发现包含单指标异常检测、多指标异常检测、文本日志异常检测、交易链条日常检测等等。
每一个场景都是运维行业几十年发展积累下来的难题，都需要投入大量AIOps算法人力和精力去攻关。
比如我在清华的实验室在去年一年投入了10个博士生分工合作研究单指标异常检测，才把这个难题攻克了。
此外， AIOps要解决的是“系统+算法”问题，而不是简单的算法问题。这是因为我们的运维对象是个庞大、复杂、跨协议层的系统，它里面的大量逻辑是程序员写的代码和各种网络协议和应用协议。
因此，AIOps运维大脑中的每一个模块都相当复杂，所以我们不要期望把运维数据灌进一个通用AI算法就能完成该模块的功能。
解决任何一个AIOps中的模块或场景，都需要有“AIOps架构师”把复杂的场景和需求拆解成具体的功能模块： “眼”、“手”、“脑”。（如下图）。
“眼”解决那些通过采集数据全面感知系统运行状态就能解决的问题；“手”解决那些基于固定逻辑就能解决的问题；
“脑”又细分为两类模块：
1）通过挖掘历史数据总结出来各种画像和知识；
2）通过动态决策算法来处理各种具体运维场景。 “脑”里面的两个模块必须能被当前AI技术所解决（要求数据丰富、信息完整、清楚定义、单领域）。
运维领域有很多问题当前AI技术没有办法直接整体解决，在这种情况下我们就继续把该问题拆解成更细的模块以期能够被当前AI技术解决。
为了更好地支持上述观点， 我们在下图中给出了我在清华的实验室在AIOps运维大脑的各个模块中使用过的并行之有效的通用AI算法。
可以看到不同的模块采用的通用AI算法差异非常大，有些模块还需要若干通用AI算法的组合才能良好解决。这张图充分说明了AIOps的架构挑战。
三、 智能故障发现
这一部分介绍一下我们实验室在“智能故障发现”方向的进展。智能故障发现包括故障发现和故障定位。
首先介绍我们在单指标异常检测的最新进展。我们实验室在这一领域的科研成果在世界范围内处于领先的地位。（见下图）
1）我们IMC2015工作是有监督的异常检测，解决了之前朴素异常检测算法无法普适的问题；
2）后来我们在推广这个技术的过程中，发现有监督异常检测算法的应用场景是有限的，所以后来我们在WWW2018发明了一种无监督的异常检测算法；
3）随着在实践中对该WWW2018算法的使用，发现它也存在一些不足。比如，当存在违反周期性的异常时，使用该算法效果不好，因此我们加入了时间信息解决了这个问题；
4）WWW2018算法在处理非高斯噪声的指标时也存在不足，我们就实现了一个基于对抗生成网络的算法把这个问题解决了；
5）此外，我们通过聚类算法和迁移学习，实现了对于百万级指标进行异常检测；
6）对于游戏等生命周期很短的应用通过半监督学习快速进行异常检测；
7）通过参数自动迁移，在指标模式漂移后自动适配异常检测算法。最后这些算法整合成了我们非常智能的单指标异常检测算法。
这个单指标异常检测的例子很好地说明了我们实验室的研究思路：
“从实践中来” （从实践中总结提炼出科研问题，从根儿上解决问题，而不是通过简单工程方法治标不治本）、“到实践中去”（不断实践、不断迭代认知、不断完善，而不是发表一篇论文就做别的去了）。
上述算法2)-7)在我2017年下半年的演讲中还是处于展望阶段，现在我比较自豪的说去年展望的技术百分之八九十都已经实现了。
这离不开实验室博士生们的艰辛攻关，也离不开我们的专注投入（ 世界上没有第二个机构会在这一领域像我们一样投入超过十个博士生）。 所以我们在这个细分领域能走到世界领先的位置也就不足为怪了。
在单指标异常检测的基础上，我们还实现了多指标异常检测、面向文本日志的异常检测、对交易链条的异常检测、异常机器定位、异常多维定位、变更故障定位、交易链条定位等 （见下图）。
这些AIOps最终被整合在一起，形成我们的“智能故障发现”系统。
一线运维人员无需关注背后的种种算法：当有故障发生时，系统直接告诉运维人员哪里出了什么样的故障，以及该故障的原因是什么。
系统不是将海量的监控都推给运维人员让他自己搞清楚问题是什么，而是已经汇总好，直接给出问题所在。
上图展示5台机器4项指标出了问题，采用人力排查的话需要看上万台机器、每台各100多个指标，而我们的系统则可以把这个结果快速呈现出来：
某一个具体日志时间，发生故障时第三个参数取值的分布在故障之前和故障之后有显著变化，这样就给运维人员提供了非常清晰的提示和参考，指导人员下一步该怎么做。
同时系统还会提示本次故障和历史上某次故障症状上非常相似或有某种关系，进而建议运维人员现在可采取什么样的处置方案应对当前故障。
以上“智能故障发现”AIOps算法朝着无人运维的终极目标迈进了一大步。
四、运维知识图谱
本部分简要介绍运维知识图谱的构建和使用（见下图）。构建运维知识图谱是指从运维数据中自动挖掘：
1）各类运维主体；
2）运维主体的各类特性画像和规律；
3）运维主体之间的关系。
运维主体包括系统软、硬件及其运行状态：
软件是指服务、微服务、中间件、存储服务、数据库等等；硬件是指机房、机群、机架、服务器、虚拟机、容器、硬盘、路由器、交换机等等；各类监控数据，包括指标、日志事件、Trace、变更、流程等等。
（见上图）那么运维知识图谱与CMDB的区别是什么呢？
运维知识图谱包含基于人工智能的、模糊的、自动化挖掘的知识，而CMDB是确定的、手工配置的知识或基于确定逻辑自动配置的知识。
运维知识图谱与传统的运维专家知识又有什么区别呢？
第一，知识图谱是中心化的，而传统专家知识是分布在运维专家头脑中的，是去中心化的。
第二，知识图谱是连在一起的“一幅大图”；而专家知识是割裂的，所以，想要实时地把分布在专家头脑中的知识以及静态CMDB数据关联在一起，解决实时问题显然是不可行的。
第三，知识图谱可被快速查询，专家知识需要人力关联，所以缓慢易错。
第四，知识图谱可自动更新，而专家知识需要手动更新。
第五，可以自动生成知识图谱的变化报表，而利用专家知识要靠手动撰写报告。因此，建立运维知识图谱的优势是非常明显的。下面我们通过两个例子来详细说明一下
上图给出了各类硬件主体之间的关系。
容器1属于容器类型1， 而容器类型1的配置细节（CPU、内存、存储类型、存储空间）都是能够由配置信息基于固定逻辑自动构建出来的，属于静态属性。
同时，通过挖掘学习出一些动态属性（白底红字），比如容器类型1 的资源使用限制（内存使用率最多能到多少），这些信息很难靠人力准确总结或推测，得靠挖掘历史数据获得。
我们再看软件主体和硬件主体之间关系，以及软件主体之间的关系（见上图）。
服务1调用微服务1、微服务1部署在容器1上面。这样，软硬件主体在图中就通过边连接起来了。
这种关系也是通过确定逻辑基于配置信息自动构建的（橙色的边属性）。那么，容器类型1可以支持微服务1每秒钟多少次的交易呢（容器类型1与微服务1之间的边的红色属性）？这个属性需要通过历史数据、压测数据构建动态的画像。
（见上图）我们再看一下软件主体与监控指标主体之间的关系，以及监控指标之间的关系。
服务1的一个监控指标是总流量，而这个总流量又可以按照省份属性细分，监控指标“服务1.流量”与监控指标“服务1.流量.北京市”是包含的关系， 而“服务1.流量.北京市”与“服务1.流量.北京市.联通”又是包含关系。
当今的监控数据中虽然可能有几百万监控指标，但是他们之间往往有类似上述“包含”关系的某种关系。
而此类关系是遵循固定逻辑的，是可以通过配置信息自动构建出来，最终可以作为边添加在这幅图谱中。
因此我们可以想象这个图谱就形成了一个无所不包的大型数据结构，供我们在其上为各类运维场景开发动态决策算法。
上图中还展示了“服务1.流量”的动态画像（白底红字）：增长趋势、季节性、高峰时段、特殊日、最佳的变更时段等等。
这些信息在运维人员脑子里面或多或少有一些，但是并不能被随时随地准确快速地查询。我们的方法是，在专家的指导下，通过机器学习方法自动把这些知识挖掘出来，可以被自动更新和随时查询。
（见上图）“微服务1.响应时间” 的影响因素有n个, 而它们之间的关系是通过一个函数f(x1,x2,…,xn)来刻画的，而这个函数可能是通过一个神经网络来拟合的。
这个例子清晰的说明运维知识图谱与传统基于确定逻辑的CMDB的区别。
在这个例子里，我们用有限的一页PPT， 展示了一个很大的知识图谱中很小的一个切面。
可以想象上万台机器，上百万指标，全都串在一起会形成如何的一幅大图！幸运的是，现在有不少相对成熟的图计算系统和算法可以处理如此规模的图。
上述例子的一个应用场景是：以往为了应对每个月的大促，需要拍脑袋人工预测所需计算资源；有了运维知识图谱，通过查询图谱以及算法计算就可以给出准确的预测结果。
下面介绍最后一个例子，运维知识图谱的另一个切面—故障传播图。
有了这个故障传播图，就可以快速回答如下问题：
1）当前服务故障的根因是什么？
2）对当前故障有何处置建议？
3）当前底层的故障对上层服务有何具体影响？
（见上图）故障传播图可以长成什么样子，又是如何构建的呢？我们通过举例来说明。服务1调用了微服务1.1和微服务1.2，而微服务1.2部署在容器1.2.1上。它们有共同的KPI A。
因此，KPI A报警在这三个主体之前就自然形成了故障传播关系，而这种故障传播关系是可以通过配置信息通过固定逻辑自动生成的（见上图中蓝色的边属性）。
（见上图中橙色的边属性）有些故障传播关系是要靠机器学习算法自动挖掘的。
比如系统存储日志事件Y导致数据库日志事件X；数据库日志事件X导致微服务1.1 的KPI A 报警。
同时，交换机日志事件U也会导致微服务1.1.的KPI A 报警；而微服务1.2 KPI A 与微服务1.3的KPI C故障传播关系体现为具有波动相关性。上图中边的属性为橙色的都是自动挖掘出的故障传播关系。
（见上图）有些故障传播关系（比如那些由网络协议导致的）很难被自动挖掘出来，也不在静态配置中体现，而是存在于行业标准中（如网络协议）。
因此我们可以根据网络协议中固定的规则人工指定故障传播关系（上图中绿色的边属性），如物理层故障导致链路层故障。
最后，另外还有一些自动挖掘出来的画像信息（上图中红色六边形），比如厂商手册中关于交换机日志事件V有一些相关知识，事件V为什么发生、该如何处置。我们可以自动把手册里面的规则挖掘出来变成知识。
综上，由算法专家和运维专家配合，采用合适的算法，我们可以把所有运维相关的经验知识转化故障传播关系，进而形成故障传播图。
这样，运维最大的痛点故障根因分析也就不难解决了。
|
