浙江移动私有云AIOps实践

彭小阳

作者：潘宇宏

今天演讲的主题分四部分：第一部分是运维转型背景，第二部分是NOCAIOps1.0，第三部分我们的AIOps2.0，第四部分是我们对AIOps展望和自己的认识和期望。

一、运维转型背景

我现在所在的部门是在浙江移动云计算中心，这个部门成立在2016年年底，确实给我们带来的很多收益，但是同时给运维带来很大挑战，运维挑战可以用一二三四形容。

一降，大家都熟悉了解，相比传统小机时代，单个网元稳定性急剧下降。
二少是相比现在互联网巨头，我们的积累和沉淀相对比较少，第二个少是投入IT投入相对营收占比少。
三多是网元数量多，相比传统竖井和小机时代，网元数量急剧膨胀，未来会翻三番增长，和互联网公司相比，数量还是小巫见大巫，但是我们技术栈也是非常多的，为了满足各种客户的需求，我们市面上产品、蓝本、配置都会存在。第三是应用系统多，浙江移动内部租户系统已经有几千个。
四变是基础架构动态调整，技术栈本身也是不断向前演进，应用现在是持续迭代更新，组织人员变动。我们自有员工还好，有不少是从当地的知名互联网公司流入的，但是我们合作伙伴也有不少流向当地知名互联网公司。总体带来的故障处理时间飙升和运维人员生活品质的下降。I

我们运维转型第一步做的是组织转型，相比传统的竖井时代，我们还是培养很多大侠，这个时候是问题的终结者，很多疑难杂症到了大侠都解决了。
我们成立了NOC，腾讯也有这个组织，但是腾讯角色不一样，我们希望将低价值重复性工作交给NOC处理，让大侠做高价值工作，7×24小时监控值班以及简单故障应急处理，这个时候都是NOC工作智者，大侠提供价格稳定性，不断给AIOps平台提供数据。第二个是源源不断提供数据。
在1.0时代，NOC还是服务于各个专业条线，各个专业条线有什么不愿意干的，有什么不想做的我帮你做，但是在NOC2.0时代不仅仅是服务于专业条线，而是要通过运维数据的沉淀、运维数据的分析促使各个专业条线提升整体运维质量。

成立NOC之后我们必然也会提一些要求，我们提炼了4个要求，耳聪、目明、心灵、手巧，耳聪就是要听得懂业务语言和平台语言的转换。目明就是用运维监控平台能及时发现故障。心灵就是指如果一旦出现问题，我能够快速诊断问题、分析问题。手巧是说通过自动化平台，做一些简单故障应急。
怎么实现呢？我们认为有两方面，第一方面是人员培养，我们也持续不断在做人员培养，但是这里有一个问题，一旦培养起来，可能就坐不住了，可能也就流失了，所以我们做得更多是在做工具赋能，就是通过整个工具平台，不断给NOC赋能，提升NOC运维水平。

二、NOC的AIOps1.0

接下来讲一下NOC的AIOps1.0，从耳聪、目明、心灵、手巧怎么样从现有数据平台达到这个目标。

首先问大家一个问题，有了AI以后，或者有了AIOps以后，到底还需不需要CMDB？业界确实有些声音，上午杨总讲到，他认为CMDB是非常必要的，但是业界也有另外声音，包括供应商产品基于一些概念因果模型可以做一些事件关联分析，并不那么依赖于CMDB。
但是NOC在实际工作中会碰到这样的问题，比如租户问你帮我看一下我的SOE数据库怎么样，我们NOC接到这样的请求以后往往一脸懵逼，SOE是什么东西？白皮书有句话讲得非常好，书通文指的是统一，运维事件也要统一。运维语言要一致，靠什么统一呢？我认为靠CMDB统一，可能以标记形式承载在大数据平台上。
CMDB不仅仅是人与人之间沟通的语言，更多是系统与系统沟通的语言，当CMDB作用不仅仅是这些，在耳聪这方面我认为更多是CMDB发挥作用。业界现在做CMDB每个企业都在做，失败的项目其实非常多，因为这个时代是太难了。

CMDB建设的困难和配置管理的挑战有哪些？有两点。
第一、数据不准，数据为什么不准呢？
其实我认为是人造成的，人是最不可靠的，或者人是最不稳定的，对于CMDB技术属性基本通过自动化手段做的。
这里有一个比较奇怪的是爬虫，为什么会有这个东西呢？一些传统商业平台并没有对外提供接口，但是自己管理平台上又有这些东西，这个时候我们就用一些我们自己的偏方，通过这样一些东西把我想要的东西采过来。第二个是自动集合稽核，可以设置一些稽核规则发现问题。第三个是数据消费，校准CMDB数据。
第二个我认为CMDB存在的挑战，传统更多管静态数据，静态数据对AIOps不一定够用，或者前面很多老师讲的根因分析、相关性分析这样一些场景不够用，所以我认为第二个问题是数据不活的问题。
主要两方面，第一个是动态关系，我们也是靠自动化手段预采集的，第二个是动态标签，也是参考大数据、用户画像一些方法和理论，我们给维护对象做一些画像，当有了画像之后，可以发现很多很有意思的现象，比如发现经常变更的设备与较少变更设备相比，故障率高了43，这是在我们环境下的数据。

前面是耳聪，主要靠CMDB实现的，目明是监控平台，监控必须要做到快，能够及时发现问题，能够减少误报，全是没有漏报。
从NOC使用者角度来讲，我们概括了一个字，“简”，大家看到我们PPT内容比较少，怎么做“简”，我们从两个方面做的，第一个是更高维度，第二个是减少误报。
我们一般看日志、看预警指标，看一些进程运行状态或者看一些运行情况，总共需要花几分钟时间。后来专家告诉我们，其实不用这么复杂，比如操作系统而言可以看很简单两个指标，关于系统存活的检测。
因为Oracle有AAS这套通过，我们可以做成ACS这几个指标，可以指平均等待时间，通过这样一些核心指标，大致能了解这样一些网元健康情况，其他不一一介绍，根据这些指标，我们把网元健康度做成一个分数。
对于NOC来说记那么多指标是不可能完成的，但是作为一个分数是很容易看懂的，比如90分以上代表这个系统活得挺好，60分以下性能有问题，10分以下基本快死了。
这里针对的是网元，云计算并不是单个网元对外提供服务，一般是多个网元组成一组对外提供服务。我们做成了一个服务的健康度，一方面基于底层网元指标做一个组合、做一个策略配制，另外服务有服务自身的指标，对于每个指标可以往下看历史趋势，可以和历史做一些对比，这是健康度的情况。

健康度的历程一开始是从一个网元看多个指标，到一个网元一个分数，这个时候NOC可以方便快捷了解，另外从一个网元一个分数到一个集群，或者一个云平台服务一个分数。
从Oracle开始做，到现在几乎所有技术栈都做了，包括私有云平台部署的就是阿里云一些私有化部署，我们也已经做成这样简单的分数。但是有一个很奇葩的东西，这张图不是我画的，这张图应该是前面有位老师讲的。
网络其实是一个很奇怪的东西，其他服务是说多个网元组成一个服务，或者一个大的SDS向上层提供很多种服务，但是只有网络是提供拓扑的服务，网络很多时候应用出了问题，但是应用找不到的时候就看一下网络是不是有问题，网络同学说不知道。
微软在2015年推了一个产品叫Pingmesh，通过各个节点形成一个网状的东西，SMP运行在第三层，它没问题不代表网络一定没问题，我们在此基础上做了一点点改进，我们叫pingmesh+，我们用HPB协议做了一个，现在不是全mesh，只是部分核心链路mesh的状况。

有前面讲到了健康度、动态关系获取，包括网络一些情况，我们就做了这样一个产品，我们叫云图。右上角是我们的应用系统，这主要是有计划部署的一些系统，这些系统其实对应的都有自己的APPID，可以和我的容器识别对应起来，容器再对应到承载的虚拟机，再对应到相应的服务器。
包括实际访问的消息中心件、访问的中心库，前面说的存放动态关系全部可以抓取，并且健康度也可以以颜色标识打在上面，所以这个时候对NOC来说更方便。但是这里还是有些问题，就是当某个应用有问题的时候，我再看这张拓扑，往往有很多红点，到底哪些红点有问题？
在这种情况下不知道，我们后面用叠加影响度的算法在这上面，影响度判断主要是几个，最简单的就是简单粗暴的办法，一个节点坏了，这个节点的影响度就是0.1，第二个也做了基于边缘相关性分析，另外就是我们也在尝试，社交网络关于影响度做得比较成熟，我们也尝试一些社交网络算法，尝试不断完善影响度。这是关于目明。

目明前面讲的是更高维度的，这里讲异常检测，我说一个简单总结，周荣老师讲得已经非常细了，白皮书上也有，前面还有一个数据源异常检测，最重要的或者我们现在做得比较多的两个方面一个是文本异常检测，第二个是指标异常检测。
第一个文本日常检测是日志，日志是这台机器对我说的话，不行的时候往往在求救，这个时候日志往往有体现，我们去回溯很多故障的时候发现很早的时候，日志都已经有相关信息存在了。
首先日志最原始可能是关键字匹配，没必要为了AI而AI，为了AI把以前传统都丢弃掉，肯定可以用。
二个是日志模式的挖掘，关键字也是我们约定俗成的，或者大家形成共识的一种模式，但是日志里面还有哪些模式呢？其实人不一定理得那么清楚，尤其应用一些日志，这个时候可以用一些聚类的方法做一些日志模式的挖掘。
三个是日志的趋势、日志的本身是一个数值，可以转换成指标来进行异常检测的，看一下过去4小时、过去1小时这些网元哪些日志变化量最大，这个网元八九不离十有问题，当然这个问题可大可小。
第二个是指标的异常检测，我比较喜欢这个分法，人也是这样干的。
做异常检测和谁比较呢？第一和历史做对比，前面没有AI的时候也这么干，过去指标怎么样。第二和同类做对比，10万台机器，有没有离群的机器？
从定量和数量有单指标、多指标异常检测。检测模型列了一些，有些会有交叉的部分。做异常检测更多是用业务侧指标更适合做异常检测，平台侧有没有这样一些指标呢？其实也有。比如说我的存储时延、存储的吞吐量、负载均衡性时延，这是平台常用的检测场景。
前面讲到网络，通过各种方法的组合，不是单纯某一种方法，从最开始的时候可能预告警1万条，这个时候没有办法处理，全是垃圾信息，现在压缩到每天20条左右，当然还可以压缩，这个时候我们NOC可以处理了。

关于异常检测几点分享：
第一，不要拿着榔头看全世界都是钉子，我们犯过这个错，去年异常检测业界用得比较成熟，我们看似也掌握几个异常检测的算法，恨不得所有指标都拿过来试一下，其实没有必要。
第二个是学会妥协，在查全率和查准率之间要做一个平衡。我们现在牺牲了查准率保证查全率，这样不可避免会有一些误报，这个时候的误报靠NOC做一些校准。
第三个是吃什么样的草，产什么样的奶。数据的质量非常关键，这不仅仅是适用于异常检测，在我们算法里面数据质量非常关键。到后面也会讲一些关于数据相关的内容。
前面讲的是耳聪、目明，接下来是心灵，心灵指的是故障定界，或者故障定位。

我们把故障定界分为两种，一种叫水平定界，一种叫垂直定界，当客户有问题的时候，很有可能是其中某个应用有问题，这个水平定界是靠应用完成的。水平定界完成之后平台侧开始介入，平台侧做的是垂直定界，分四级，第一级是应用问题还是平台问题。
第二个是如果是平台问题，到底是哪个技术栈问题，第三个如果是技术栈根因组件问题。到三级定界基本可以采取错误，比如前面讲的应急、切换、限流等操作。NOC给他的指标在这里，我们做到5分钟三级定界成功率90%左右。四级定位往往放在事后来做，由各个专业条线做四级定位。因为我们还是坚持先恢复后修复的原则，不管三七二十一，不用找到问题根因先恢复了再说。

这个是关于心灵，故障定界、定位。一种方法叫人类定位问题的思路，人类定位问题是什么呢？如果是某一个系统有问题，把应用系统相关服务、组件找出来，看一下指标、日志、异常检测结果有没有问题，这是一方面。
另一方面，经常变更设备故障率比不变更设备故障高43%。我们也会把相应网元变更信息拉出来看一下，会不会是变更导致的。
这里举一个真实的案例，我们上个月末发生的问题，当天晚上有应用上线，做测试的时候发现业务量有问题，因为这个时候平台侧没有做任何动作，所以基本上肯定是应用上线导致的，从打分来看也都正常。
但是我们根据前面讲的思路，做了一个智慧推荐的产品，内存有问题，对于内存使用数据库来说内存到100%也不是什么问题，相对平常使用率是有异常，跟开发确认是配置有问题，本来不应该用这个内存，结果用了这个内尊，本来作为静态配置的内存承载不了这样的业务量，导致内存本身出现了问题，应用也受影响。

这是人类定位问题的思路。还有一种是用AI方法辅助定位，或者非人类定位的方法。第一个是基于关联规则的相关性分析，第二个是基于决策树的根因分析，现在比较火的周荣老师也提到，MDRCA，清华在举办的AIOps挑战赛就是这个。
单指标多维下钻分析，为什么说人类解决不了呢？本身维度非常丰富，维度取值非常多，具体解决方案的步骤是说第一步做异常检测，第二步是重新进行PS计算与分层减值，PS是指维度或者可能性的程度。PS计算比赛里面基于指标，再工程落地的时候也可以引用其他一些维度信息去做一些权重的调整。这是关于心灵。

接下来是手巧。手巧指的是自动化操作，自动化操作一般大家都会说，自动化前提一定是标准化，没错，标准化是自动化的前提。我想补充一下，场景化也是标准化的前提，没有场景化是没有意义的。
左边画的是自动化平台的一部分，后面会讲到运维中台的架构，最底层有一些自己开发的agent，以及大数据平台管理接口，管控层更多是命令下发的通道，同时也做一些操作定义管理、目标管理以及管理的功能。
我们目前上面的操作中心，操作中心是做一些编排，场景我认为主要有两个，一个是批量操作，另外就是一些复杂的组合命令场景，在应急场景下，把技术栈常用应急预案做到平台上面，并且和健康度也做了一个打通和关联，当单个网元或者对业务影响不是特别大的故障，NOC可以直接通过可靠工具直接进行操作。这是手巧。

效果怎么评估？白皮书第九章，关于效果度量讲了很多，我这里其实是从另外一个维度看这个事情，在底下听苗老师讲的时候发现他也讲了这个东西。对应用来说有一个很重要的指标就是平均故障恢复时间，有四个阶段，MTTI，平均识别时间，MTTK平均判断时间，MTTF平均恢复时间，MTTV平均验证时间。MTTI+MTTK占到MTTR总时长的80%，我们现在更多做MTTI和MTTK的压缩。
对于识别的话，前面已经讲多管齐下，K通过人类、非人类定位方法，通过工具赋能做这个事情，F是通过一键应急，通过自动化手段，紧密协作。V是自动校验。前面两个阶段相加的事情大概占50%，不同专业也会有特殊情况，比如网络分析起来确实很慢，但是解决起来比较快。这是关于效果评估。
讲完耳聪、目明、心灵、手巧是不是还有其他的？当然还有，所以后面我又加了两条，一个叫嘴甜，我们现在做的是通过微信机器人基于知识库做简单的答疑，这个张真老师是专家。第二点是坐稳，指的是责任心和意识问题，常说的是心智模式的问题。我认为现阶段AI可能解决不了，更多是靠管理手段。

三、我们的AIOps2.0

前面讲的是NOC AIOps1.0。接下来介绍一下2.0，1.0是过去做的事情，2.0是当下做的一些事情。前面讲那么多，一直是在讲怎么样降低MTTR的四个阶段，苗老师讲到，他直接讲了MTBF，平均无故障时间，对于运维来说，一方面出了故障快速解决，另一方面怎么样保证不出故障。核心就是这两个。

除了降低MTTR还要拼命提升MTBF。MTBF靠NOC已经不行了，前面大家已经听出来了，NOC就是一群小白，如果要提升MTBF一定要拉人入伙，第一，解决他不想要的，什么是他不想要的？运维痛点是他不想要的。
这里提一句，也是我们之前走得一些弯路，更多应该通过场景找算法，而不是通过算法找场景。一开始看到一些算法，觉得别的互联网公司用得挺好，自己也想用一下，跟专业团队聊了半天没聊出东西。

后来换了一个问法，问你有什么痛点，巴拉巴拉说自己有什么痛点，后来也确实碰到一些问题，还是要根据自己实际痛点找痛点，而不是看别的互联网公司用得好我也想用，不一定合适。第二，给他想要的，我们认为通过中台赋能。

接下来是整个运维中台的功能架构，底下是资源层，这里画得不全，我们现在把应用一些数据、应用一些对象全部纳入进来。
第二层是驱动层，我认为是和维护对象联系非常紧密的一些。第三层是管控层，前面讲自动化讲了一部分，当然那里不全，主席有两部分，第一个是数据的采集，第二个是命令的下发，可以认为是两个同道，以及同道上的东西。
数据智慧层是现在最核心的一层。一个是数据中心，一个是学件中心。
数据智慧层以上就是功能中心和服务层，调度中心是给NOC用的，及时调度各个专业条线。作业是自动化平台，流程是传统的。资源前面也介绍到，我们动态的资源管理。
还有两块是运营中心和开发中心，这不在我的平台里面，在云管平台上。上面就是各种互联网门户、综合运维、租户门户。这是运维平台功能架构。

这是我们的数据中心。最底层有数据接入，第二层做的是数据清洗以及把想要的一些维度信息在这个阶段打到两张表，一张实时储存，一个是直接入Hive。我们现在用的一些技术组件前面老师也很详细介绍华为用的一些东西。还有一些MPP的数据存储。
我们用了一些传统的运维大数据的技术组件，但是逐步在转向商业大数据平台，用商业大数据玩运维大数据。目前阿里是这么做的，为什么这么做？AI生态和商业大数据平台会有更好的结合。
在AIOps这条路上，我们会逐步去迁移到商业大数据平台上。传统运维大数据平台要不要保留？还会用。主要作用可以帮助我们不断校准、提升数据质量。
关于数据质量多说一句，像传统企业可能做AIOps80%工作花在数据上，因为相比大厂我们也去一些互联网公司交流过，数据质量高到让人羡慕，一个团队想做的事情从底层基础设施数据到自己平台数据上层应用数据全用，而且很完整，根据已有数据做一些数据分析以及算法模型相关工作，只有两个人做这个事情。对我们来说几乎不可能。
数据市场方便上层用户快速找到我们数据。其实我们做的是从ODS到DWD的转换，数据分析服务也是用DACP的数据挖掘的工具，商业大数据这么用，我们也直接套过来。上层应用团队可以用这个工具基于我提供的数据进行建模。关于数据治理，周老师也提到，这里不赘述了。

关于数据要说的挺多的，我一般分为运维大数据和运维小数据，小数据指的是配置数据，大数据主要是这几种日志的数据、指标数据和事实数据。ebay做了一个Google黄金指标，主要指成功率、饱和度、吞吐量和时延，Google讲了一点，对于用户可见系统，要了解这个系统知道这几个就够了。
对于AIOps不仅仅是这几个指标，我们把运维数据建设分四个阶段，第一阶段是数据再现，以前分布在网元的数据，现在统统集中起来，现在用BI的方法做数据分析报表，第三是用AI算法做数据智能，第四阶段实现数据自驱，数据自己发现自己的问题，自己驱动自己不断完善。这里还有一句很重要的话，数据决定了业务价值的上限，而算法只是无限去逼近这个上限。

接下来是学件中心，第一层是数据层，更多是从数据中心过来的。学件也做了一些归纳和整理等常用的一些。上面是配置层可以进行算法选择、模型配置，上面是常用的场景。
有了上面这些之后，中台肯定是希望能够做到百花齐放，但是我们目前也有一些跟各个专业条线碰撞很多东西，目前做了一些，第一个是行为分析，这是数据库的一个案例，因为在我们基本上已经解决了一体机的大问题以后，现在数据库自身导致的问题已经很少，基本上都是被应用搞死的。
怎么知道呢？我们要做一些应用分析，SQL执行频次异常，通过这样一些标签发现用户异常行为异常，这也不一定需要AI东西在里面，当然可以用AI。
清华最近又发了一篇文章，也在做一些行为分析，可以有算法，但是一开始能出效果不一定非常复杂的东西。因为已经有1000多个节点，本身负荷已经非常大，我们严重怀疑上面有很多空任务，消耗了资源也消耗了空间，所以我们也做了一些血缘分析。
第三个是维护模式的转换，从孤儿模式到双亲模式，这主要是容器的场景。容器化以后，租户对这个问题不了解，以我们传统的分工界面，我们也很难说，虽然也搞了很多培训，但是也没有办法做到手把手教你，孤儿模式就是不管你，只要保证服务商好就行。
双亲模式一种是母爱模式，母爱模式是说我事无巨细都告诉你，这个信息给你，那个信息给你，自己分析判断。一种是父爱模式，只要照着我说的办，你就做就行了。我们提供给租户的建议，比如容器发现最近运行有些问题，我们建议他做某些动作。AIOps2.0主要是这些介绍。

四、展望AIOps3.0

接下来是我们对未来的展望。先说一下我们的心路历程，这个图最近挺火的，巨婴在愚昧的山峰觉得自己很牛，随着智慧增长跌到绝望的谷底，随着智慧增长爬到开悟之坡，最后成为大师。

一开始我们觉得自己很了不起，回过头来看觉得那个时候挺傻的，回过头来再看这个片子还觉得自己挺傻的，AIOps肯定是我们将来的方向，虽然短期效果不如大家直观感受到的，但是未来在一段时间，肯定会有比较长足的发展。这个片子广有流传，总是高估近期变化而低估远期收益。
最后是写了对AIOps成功的要素，需要数据、算法、平台、场景，人才是标大的。