AIOps 如何优雅服务应用运维？看民生银行智能运维实践与探索

Posted 2021-04-24 高效运维

作者简介

张舒伟
中国民生银行 智能运维平台负责人

分享：张舒伟
编辑：白凡

各位领导、各位来宾，大家上午好！今天很高兴来到这里和大家分享民生银行在智能运维方面的探索和实践，今天主要是从应用运维的视角来看 AIOps 可以做什么事情，以及是我们是怎么做的。

今天的分享从三个部分来进行，应用运维的挑战是什么，为什么要用 AIOps，第二部分是利用智能运维可以做什么事情，我们应该怎么看待怎么定位，第三个部分，在这个定位基础上民生银行做了一些什么探索。

1. 民生银行科技发展趋势

回顾一下民生银行的科技发展过程，我们在2000年左右的时候是大集中架构，到2012年上线了基于SOA的新核心项目，最近在向分布式和微服务化的方向演进。大家知道我们在2017年的时候上线了行业内第一家分布式核心系统，用在直销银行上。

在整个科技框架里，应用运维担负着什么定位呢？应用运维做应用系统全生命周期管理，包括应用系统的上线，准入评估，每次变更的评审和最后变更发布的过程和监控，业务流程优化都会参与到里面去，以及这个系统遇到的所有的问题，包括故障和终端用户提上来的服务请求。

还包括一些工具体系的开发，总之做所有和应用系统相关的事情，像一个保姆一样。我们内部的定位是所有和应用系统相关的事情全部找应用运维，应用运维再推动或者驱动其他部门配合我们来完成这个工作。

我们总结了应用运维运行过程中的一些原则，也是借鉴了很多Google SRE的理念，比如对于服务质量负责，以发现问题为荣。关于工具开发这块，Google 规定 SRE 要有 50% 的时间用来做工具开发，我们虽然没有做强制规定，但是我们同样认为工具和琐事之间有一个跷跷板效应，工具做的越好做的越多，琐事相应就减少了，反过来是一个恶性循环。

一个好工具不是规划出来的，不是说我们开开会就能规划出来，而是从一线工程师的一些需求和实际的运维场景出发来提出这样的工具。

所以我们很多工作直接是从应用运维这边来做的。问题跟踪和应急管理也基本上按照SRE的理念来执行。说一下优先恢复服务的理念，作为一个搞IT的人看到一个问题总是要第一时间要把这个问题排查清楚，来龙去脉是什么样的，怎么解决，有什么规避措施和方案，作为运维的话要打破这个思维，我们要有一个意识，优先恢复服务，不管发生什么事情，先把服务搞正常了，再去找原因。

这几年我们的业务不断的推陈出新，不断的创新，我们的技术架构一直在演进，引入了很多新架构，分布式、微服务这些概念，包括区块链、人工智能这些东西都在上，相对来说运维的改革要滞后一些，我们看到了一些现象，比如说软件和硬件的数量有一个大幅度的增长，应用和架构的复杂程度也越来越复杂；

应用相关的变更每年要超过一万次，调用链路的增加也是非常显著的，最长的调用链路达到了17次，一个终端请求在数据中心内部经过了十七个系统，每天 的日志平台的增量数据大约有20个T，监控指标每分钟有上百万，交易明细每天好几亿，总之故障处理难度变大了很多。

并且这么多数据，人看不过来，必须有一个办法进行分析和挖掘，还有就是这么多的运维人员，运维价值怎么体现，大家不能只当背锅侠，出问题你背锅，不出问题大家不知道你默默无闻，这也是一个很大的挑战，我们希望通过 AIOps 帮助我们解决这些方面的问题。

2.  关于智能运维的思考

数据中心提出了数据驱动运维的理念，就是要用数据说话、用数据决策。我们想到了数据、信息和知识这三个词，我们知道数据是原始分散的，是描述性的东西，比如说一个机器 CPU 使用率达到了60%，这是一个描述事实，是一个描述性语言，什么是信息，这样的数据经过我们的监控系统，变成了一条告警，属于某个系统数据库的机器，发生了一个主要告警，这个告警会发送到运维人员手上，运维人员可能会对这个告警进行分析，进行经验总结，把前面的告警进一步联系了很多其他的信息，变成了一条经验，这就是知识。

这部分工作现在我们完全是由人工来做的，我们希望看智能运维能不能替代其中一部分工作，也就足够了。

所以我们说智能运维是下一代运维技术的必然选择，前面说的海量数据、复杂关系，处理问题时对人的依赖。智能运维希望通过算法驱动、智能决策，帮助我们从各个方面来提升。

智能运维到底能够做什么事情？这个图是我从AIOps实施建议白皮书里面摘的，主要是三个方面，效率提升、质量保障、成本管理。

效率提升，智能变更、智能问答、智能决策、容量预测、职场检测、故障诊断、故障预测、故障自愈、成本优化这么多事情，智能运维是万能的吗？我们觉得可能不是，智能运维在落地过程当中还有一些局限和面临一些挑战的，所以我们需要做一个准确定位。

第一个局限我们觉得是AI本身的局限，有人讲AI是现代统计学，是对历史规律的总结，不会产生新的知识，包括现在有一些生成式文本的东西也是对历史规律的总结，并没有给我们惊喜。

AI对关联关系和因果关系没有明确的分割，没办法识别哪个是关联关系，哪个是因果关系，可能我们可以做到我们在交易量升高的时候发现CPU也升高，但是AI是不知道是因为交易量升高了导致CPU升高，还是CPU升高导致交易量增加。

第二部分是数据挑战，我们知道运维数据比较杂比较乱缺少标准的，我们可以通过数据治理搞定这个事情，但是还有一些事情是数据治理也搞不定的就是数据完备性，刚才讲的这些事情，运维可能有很多背景支持是在人的脑子里的，没有办法数据化。

技术方面现在的 AI 技术都是对单一场景比较有效，之前 AlphaGo 比较火爆，也是对围棋这样一个单一场景比较奏效，是一个规则很明确，数据很完备的场景。但是运维的场景，比如说根因分析，输入输出是什么，其实都是很模糊的概念，没有人可以把这个概念定义清楚，我们需要把这个场景继续拆解。

还有就是算法是不典型的，因为我们现在这几年AI发展，用的比较好的地方，我感觉都是在分类方面用的比较好，都是一些有监督算法，但是我们运维的场景往往很难打标注或者成本很高，只能用一些无监督方法进行处理。

我们需要给智能运维一个准确定位，我们认为运维经过了这么多年的发展，其实积累出了非常多的经验，每个应用运维工程师在处理问题的时候，脑子里面都有一套方法论，所以我们觉得现在的智能运维还不能超越人，只能向人学习经验，把人处理问题的过程抽象出来，把其中可以被自动化或者AI化的部分替换掉，这是一个可行的路径，从而提升人的效率，把人的精力解放出来做更加高阶的工作。

所以民生这边我们会从一些痛点出发，从痛点场景出发，人处理比较难的，比较慢的，比较重复的工作，同时具备信息比较完备，再加上一些适合的算法。

还有一点很重要就是要嵌入运维流程，不要打破现在已经运行良好的秩序，而是融入这个秩序里面去。

3. 民生银行的探索与实践

基于上面这些认识，我们来看一下民生银行的探索和实践。

第一部分是我们的架构设计，其实比较简单，最底下一层是运维对象层，可能有机房，机房里面的设备，数据库、操作系统、存储，把他们的状态收集上来，收集上来进入智能运维平台里面去。

平台主要分三个部分，第一部分就是数据；第二部分算法；第三部分算力。经过这样一个加工之后，对外做一个输出，最后在质量保障、效率提升和成本优化方面提升我们的运维水平。

说智能运维肯定离不开数据支撑，数据这边我们先对所有的运维数据进行了摸底，然后把数据给出一些标准，每类数据都有一些标准，最后可能梳理下来有28个数据模型，这些模型是不是都一次性全部接到我们的平台里面去，只是说把现在条件比较好的，数据比较齐全的，这部分数据接进来，使用过程当中不断补充、不断提高数据的质量。

前面讲的到应用运维最大的挑战就是故障处理，接下来会对故障处理的框架做一个更详细的说明，把人工排障故事抽象一下做了梳理。

首先从告警出，告警是触发我们做故障分析的来源，有了告警以后我们会讲，现在这个问题是全局的还是局部的，到底有多严重。这可能决定了我们后面具体要怎样来处理这个问题，会有一个影响分析的过程，有了影响分析之后我们会想这个问题是自己的问题还是由别的系统引起的，这需要问题界定工作。

有了这个工作之后，就会关注到一个真正有问题的系统，现在的问题能不能总结出一些规律，有没有一些特征，是说某一个服务有问题，还是说我们的响应码，报错响应码都是一样的，还是说报错都来自于同样一个地区，这对于我们排查是有用的，如果没有任何特征，这可能是全局的问题。

接下来需要做监控指标排查，我们有这么多监控指标，有这么多机器，哪些监控指标和现在的问题有关联有关系。我们的监控指标正常吗？现在主要的做法是通过监控指标告警，但是监控指标告警现在也是基于固定阈值，报出来的都是比较严重的问题，还有一些监控指标并没有被纳入进来，并没有被纳入监控里面去，是一些很细微很长尾的监控指标，排查起来是有困难的。

还有就是日志监控，看日志里面有什么东西。其实做排障过程当中，脑子里面一直想，这个事情有没有出现过，如果和上次出现的问题有点像，当时是怎么处理的的，这个问题要拿过来借鉴，如果说这部分也没有解答我们的问题，可能我们会做一些其他的联想，比如说现在有五个机器都有一样的现象，这就很奇怪了，我们想看看这五个机器是否有一些共性，是否都基于某一个存储，或者说基于宿主机，有共性在里面，如果这些都解决不掉，只能去现场分析了。最后我们找到了问题原因，面临具体操作的问题。

我们希望把里面抽象出来的框框全部换成AI可以做的事情，接下来分场景来介绍一下。

第一个场景，可用性故障发现，要解决的问题是及时发现故障，要少一点漏报，少一点误报，故障发现的对象是什么呢？是我们的核心指标，就是四个黄金指标，这些指标出了问题，多半系统服务有问题，和我们SRE的目标是一致的，现在的做法是固定阈值，会带来漏报误报比较多，人工维护成本比较多的问题。

我们发现简单的算法也不能奏效，我们也试了一下，用3sigma和孤立森林这些做法进行检测，在单一一个KPI曲线上，经过我们的调参可以很完美把这个问题解决掉，如果换一个曲线，这个算法就没用了，这是一个核心挑战。

另外还有一些节假日的规律，工作日的周一和节假日的周一是完全不一样的。我们的算法是单指标检测，首先算出来历史规律是什么样的，不要超过这个规律就是正常的，除了这个还加上一些专项检测和一些特殊的检测。

比如说突变检测，同样在基栈里面，上一分钟还是一百，下一分钟变成了50，变化量很大，要检测出来。还有一个是剧变适配，如果用传统的方法可能需要好久的时间，可能需要几周的时间才能适应这个新的模型，如果发现这个指标有变化，我们需要快速适应新的模型。

下面有一个复盘的例子，有一天有一个很重要的系统出现了一个响应率低的情况，当然这个告警是在比较晚的时候，大概六点钟的时候发出来了，原因可能是因为头一天上线之后，内存一直泄露，直到晚上七点钟才对系统造成了影响，我们用这个算法复盘，相对于固定阈值，我们可以提前一个小时发现，可以节约出很多故障排查时间。

第二个，介绍一下多维故障筛查，主要用来解决当前的问题能不能总结出一些特征这件事。我们知道每笔交易都有很多维度，地理维度：是哪个机房哪个分片哪个服务器，还有很多业务属性，我们希望挖掘到业务属性，发起机构是哪里，产品编码是什么，会是一些很个性化的维度。当出现这样的问题之后，我们能不能快速定义到这样一个交叉维度，这对于迅速定位问题是有很大作用的。

具体做法，从交易明细出发，用关联办法提取每个系统的关键维度，把同时共现的维度抽出来，然后在出现故障的时候用多维定位的算法，基本上是基于蒙特卡洛树搜索算法。因为我们不可能24小时都在，不可能一出问题马上做这个事情，所以这是给我们事件快速总结特征的好办法。

同样展示一个案例，我们有一套系统，有一天未响应交易量突然飙升，快速定位到一个交易码是某个查询交易，原系统是某某某，直接就定位到了原因。

故障传播分析，主要解决的故障是到底是哪个模块的问题。随着调用链不断加长，在外面看到的只是冰山上面的部分，冰山下面还存在着很多系统。传统的方法一个系统出问题就一个一个往下找，像烽火台上的狼烟一样，我们希望从上帝视角告诉你现在就是认证系统的问题，就会减少很多人员的精力。

下一个场景，监控指标排查。如果前面这些都不奏效，那么监控指标到底有没有异常，原来是靠告警的，但是只会对比较严重的问题告警，长尾指标关注不到，轻微指标异常也不会告警。

我们用算法来做，用一个非参数校验的办法把每个指标的异常程度做一个打分，有了这个打分之后再根据前面提到的指标分类，我们再算每个分类和每个节点里面的严重程度做一个排序。最后告诉我们的是某一个模块里面的mysql有问题，或者说磁盘有问题，然后再往下看详细的指标。

有一个例子，某系统响应率和失败率有下降，通过这个算的定位发现有一个进程，几个监控指标有这样一些微小波动，这个波动其实是非常非常小的，监控不可能监控到这么细的程度的。只有通过这种办法发现出来，最后证明确实这个进程有问题。

最后是日志分析，日志大家知道里面的信息非常多，我们怎么进行分析呢？

我们现在已经建了一个日志平台，每天十几T的日志人肯定分析不过来，我们的做法就是把相似的日志聚在一起，然后做一个模板，有固定的部分和有变量的部分，固定的部分可以统计出现频率做成时序数据进行异常检测。

我们有一天有一个文件系统就飚上去了，通过对比前一天和当时的日志，我们发现有一种类型的日志打印非常非常多，其中一种变量的分布也发生了很大变化，有助于我们快速定位到真正的问题。 当然关于日志方面我们还在不断的探索。

最后做一下小结，我们认为智能运维不是万能的，需要给一个合理定位，我们要把人工步骤抽象出来，把其中可以被自动化的替换掉。数据质量如果达不到的话，智能运维无从谈起。

另外从算法DEMO到产品存在巨大鸿沟，需要对流程进行对接和效果进行打磨。实践是检验算法的唯一真理，不要尝试改变流程，而要融入流程。现在智能运维仍处于单点应用时代，未来随着整个行业一起努力，相信会达成一个由点及面，快速发展的态势。

我今天的分享就到这里，谢谢大家！

说明： 以上为民生银行智能运维平台负责人张舒伟在 GOPS 2019 · 上海站的分享。

投稿邮箱：[e-mail]，或添加联系人微信：135 2116 9787.

你点的每个在看，我都认真当成了喜欢