迈向智能运维时代， AIOps服务应用运维——民生银行的探索与实践

白凡

分享：张舒伟
编辑：白凡

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

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

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

大家知道我们在2017年的时候上线了行业内第一家分布式核心系统，用在直销银行上，应用运维在科技框架里面担负着什么定位，应用运维是做应用系统全生命周期管理，这个应用系统所有的事情都是和应用运维有关系，包括应用系统的上线，准入评估，原则上是有一票否决权的，每次变更的评审和最后变更发布的过程和最后的监控，包括系统业务黏性关系，这个系统的流程优化，包括业务流程优化，都会参与到里面去，会和业务部门反馈流程有什么问题，哪些地方可以做优化，以及这个系统遇到的所有的问题，包括故障和终端用户提上来的请求，包括应用运维做的一些工具体系的开发，所有做的和应用运维相关的事情，像一个保姆一样。

内部定位所有和应用系统相关的事情全部找应用运维，应用运维再推动或者驱动其他部门配合我们来完成这个工作。对于服务质量复杂，任何和应用运维相关的事情我们都要监控和干预，这其实是一把尚方宝剑，我们建立问题工单，推动开发和业务去优化。

SRE要有50%的时间用来做工具开发，我们虽然没有做强制规定，但是我们认为工具做的越好做的越多，琐事相应就减少了，反过来是一个恶性循环。我们认为一个好工具不是规划出来的，不是说我们开开会规划出来要做什么工具，而是从一线工程师的一些需求和实际的运维场景出发来提出这样的工具。所以我们很多工作直接是从应用运维这边来做的。

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

领导给我们定了一个比较严格的指标，十分钟定问题，十分钟解决问题叫做双十目标，给我们一个很大压力或者说挑战。
所以说这几年我们的业务不断的推陈出新，不断的创新，我们的技术架构一直在跟进，引入了很多新架构，分布式、微服务，这些概念，包括一些新的区块链、人工智能这些东西都在上，相对来说运维的改革，相对来说有点滞后，我们看到了一些比较难处理的一些现象，比如说软件和硬件的数量有一个大幅度的增长，应用和架构的复杂程度也越来越复杂，应用相关的变更每年要超过一万次，调用链路的增加是非常显著的，最长的调用链路达到了17次，一个终端请求在数据中心内部经过了十七个系统，每天的日志平台每天增量数据有20个T，监控指标每分钟有上百万，交易明细每天上亿，故障处理难度变大了很多，有这么多数据，人看不过来，必须有一个办法进行分析和挖掘，还有就是这么多的运维人员，运维价值怎么体现，大家不能只当背锅侠，出问题你背锅，不出问题大家不知道你默默无闻，这也是一个很大的挑战，我们希望通过AIOps帮助我们解决这些方面的问题。

2. 关于智能运维的思考

数据中心提出了数据驱动运维，用数据说话用数据决策。我们想到了数据、信息和知识这三个词，我们知道数据是原始分散的，是描述性的东西，比如说一个机器CPU使用率达到了60%，这是一个描述事实，是一个描述性语言，什么是信息，这样的数据经过我们的监控系统，变成了一条告警，属于某个系统数据库的机器，发生了一个主要告警，这个告警会发送到运维人员手上，这个运维人员可能会对这个告警进行分析，进行经验总结，然后可能会有一个回复是这样的，这个系统正在进行CPU清理，温度升高是正常的现象，只要不超过80%都是正常的，不需要关注。要关注数据库归档日志有没有升高，这是需要关注的事情，把前面的告警进一步联系了很多其他的信息，变成了一条经验。

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

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

到底能够做什么事情？这个图是我从AIOps实施建议白皮书里面摘的，主要是三个方面，效率提升、质量保障、成本管理。
效率提升，智能变更、智能问答、智能决策、容量预测、职场检测、故障诊断、故障预测、故障自愈、成本优化这些多事情，智能运维是万能的吗？我们觉得可能不是，智能运维在落地过程当中还有一些局限和面临一些挑战的。所以我们需要做一个准确定位。

第一个局限我们觉得是AI本身的决先，有人讲AI是统计学，是对历史规律的总结，不会产生新的东西，现在有一些生成式文本的东西也是对历史规律的总结，并没有给我们惊喜。
AI对关联关系和因果关系没有明确的分割，没办法识别哪个是关联关系，哪个是因果关系，可能我们可以做到我们在交易量升高的时候发现CPU也升高，但是AI是不知道是因为交易量升高了导致CPU升高，还是CPU升高导致交易量增加。
第二部分是数据挑战，我们知道运维数据比较杂比较乱比较缺少标准，我们可以通过数据治理搞定这个事情，但是还有一些事情是数据治理也搞不定的就是数据完备性，刚才讲的这些事情，运维可能有很多背景支持是在人的脑子里的，没有办法数据化。技术方面现在的AI技术都是对单一场景比较有效比较奏效，之前AlphaGo比较火爆，也是对围棋这样一个单一场景比较奏效，是一个规则很明确，数据很完备的场景，但是我们运维这边，比如说根因分析，输入输出是什么，其实都是很模糊的概念，没有人可以把这个概念定义清楚，我们需要把这个场景继续拆解，还有就是算法是不典型的，因为我们现在这几年AI发展，用的比较好的地方，我感觉都是在分类方面用的比较好，都是一些分类算法和监督算法，但是我们运维的场景往往很难打标注，只能用一些方法进行处理，还有一些人才方面的挑战。

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

所以民生这边我们会从一些痛点出发，从痛点场景出发，人处理掉难的，人处理一些比较慢，比较重复的工作，同时具备一些信息比较完备，数据也比较多，再加上一些适合的场景。然后才去，最重要的还有一点就是要嵌入运维流程，不要打破现在已经运行良好的秩序，不要把这个秩序打破，而是融入这个秩序里面去。

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

基于上面这些认识，我们来看一下民生银行的探索和实践。
第一部分是我们的架构设计，其实这块写的比较简单，最底下一层是运维对象层，可能有机房，机房里面的设备，数据库、操作系统、存储，把他们的状态收集上来，收集上来进入智能运维平台里面去，主要分三个部分，第一部分就是数据；第二部分算法；第三部分算力。经过这样一个加工之后，对外做一个输出，最后在质量保障、效率提升和成本优化方面提升我们的运维水平，这块介绍的比较简单。

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

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

首先从告警出，一般收到告警之后我们再做这个动作，告警是触发我们做故障分析的来源，有了告警以后我们会讲，现在这个问题是全局的还是局部的，到底有多严重.

这可能决定了我们后面具体要怎样来处理这个问题，会有一个影响分析的过程，有了影响分析之后我们会想这个问题是自己的问题还是由别的系统引起的，这需要问题界定工作。

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

我们的监控指标正常吗？现在主要的做法是通过监控指标告警，但是监控指标告警现在也是基于固定阈值，报出来的都是比较严重的问题，还有一些监控指标并没有被纳入进来，并没有被纳入监控里面去，是一些很细微很长尾的监控指标，波动也是和人有关系的，人排查的时候其实是很难的，这么多的监控指标，每个机器上可能有几百个监控指标，排查起来有困难。

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

最后我们找到了问题原因，面临具体操作的问题，我们希望把里面抽象出来的框框全部换成AI可以做的事情，就有了模拟人工排障。第一个步骤是故障发现，刚刚讲到人工处理，告警也有很多事情可以做，准确性如何、及时性如何，告警这块也会做一些优化，利用一些算法，我们用可用性故障发现场景，关于日志监控现在做的比较弱，我们会发现日志里面也会经常出现一些问题，有些时候某种日志疯狂出现，这个时候如果没有可用性问题，一般情况下是发现不了的，所以我们也要做日志检测。

通过多维的定位，来找出和我们现在的故障相关的特征，还可以做一些统计，比如说现在这个问题影响了哪些交易和分行，影响了哪些客户，影响了多少金额，这些都是可以想象的，现在的故障到底是我的系统问题还是其他的系统问题。

多维度筛查可以找出，日志检查有一个日志模板提取算法，然后再加上前面的多指标定位，把日志变成模板，相似的日志我们算出现频率，把日志变成了时间序列，这个时候就可以进行详细分析了。

关于相似的事件匹配，我们认为系统故障和系统故障之间，可能因为部署结构和系统特性没办法直接比较，但是组件是类似的，这个组件出现了这个问题，我们记录下来，下次出现了类似的问题，表现可能是相似的这个时候可以通过这种方式，通过指标相似性判断，找出相似事件。联想的部分可以用规则库匹配来实现。

最后操纵这部分，已经有的事件库都会对应一个自动化操作流程，最终只需要把里面的参数替换掉就可以继续往下做了。
这样一个框架能不能解决我们的问题，我们看一个事例，这是虚拟的，不是真实的，比如说渠道总线系统响应率掉到了80%，这是一个告警，日志也告警了，15号日志模板量增加，做了一些抽样，这个时候运维人员会收到告警，这个时候已经有很多信息了，影响分析层面我们看到没有影响的交易做了个人聚合，交易码都是来自于理财购买，渠道都是柜面系统，这对于应用运维有很大了帮助，做到了心里不慌的状态，如果说没有这个影响分析，只有告警，我觉得这是一种贩卖焦虑，因为一个合格运维人员收到这样的告警之后一定要很快找到这个问题原因，光告警不给描述信息其实在那干着急，如果只告警不加描述东西是不负责任的行为，从AIOps的角度来讲。
我们可以进一步往下做故障传播分析，我们发现刚开始渠道总线报警，最后推荐出来两个故障基础，一个是理财，第二个才是自己的系统，理财系统可能更是这次故障的原因，可能性会更高。接下来把目标转向理财系统，我们再做多维筛查，我们想做到字段级筛查，因为我们知道一个维度，一个交易维度是很多的，不同的系统之间的维度也是不一样的，我们希望能够做到不同的系统也能挖掘特色的维度，理财系统无响应交易集中在两个层面，交易码还是理财购买，这个没变，就是理财购买这个交易有问题，我们还定位出了理财产品编号0001，就是说都是买0001这个产品的出问题了，这个时候目标就很明确了，如果说这部分没有，如果说这部分没有结果，没有筛查出有用的特征，可能我们还会继续做监控指标排查，可能结果是MySQL数据库模块活动绘画数高，排序时间增加，这是一个以前出现的案例，没有建索引，这是一个例子，加入说会这样，解决方案可能是关联一个自动化流程里面去，这个时候我们只需要执行这个自动化流程，就可以把这个事件解决。如果这些都没有，我们还要看日志，日志筛查里面可能会出现这样一些结论，三号日志模板里面的二号变量，分布出现了一些异常，以前可能每年，这也是一个很有用的指标和功能。
接下来分场景来介绍一下。

第一个场景，可用性故障发现，要解决的问题是及时发现故障，要少一点漏报，少一点误报，故障发现的对象是什么呢？是我们的核心指标，就是四个关键指标，成功率、响应率、交易量，这些指标出了问题，多半系统服务有问题，和我们SRE的目标是一致的，现在的做法是固定阈值，会带来漏报误报比较多，人工维护成本比较多的问题。
接下来有几个例子，这可能都是成功率，不同的表现差异很大，第一排的成功率，如果用一个固定阈值优化可能就解决这个问题了。底下这个直接画一个固定欲阈值，可能有很多误报和漏报，这个时候我们可能会加个规则，这个规则成本就太高了。所以我们想用算法来解决，简单的算法能不能奏效，我们也试了一下，用3sigma和孤立森林这些做法进行检测，在单一一个KPI曲线上，经过我们的调参可以很完美把这个问题解决掉，如果换一个曲线，这个算法就没了，只是一个核心挑战。另外还有一些节假日的规律，工作日的周一和节假日的周一是完全不一样的，所以我们的算法是单指标检测，首先算出来历史规律是什么样的，不要超过这个规律就是正常的，除了这个还加上一些专项检测和一些特殊的检测。比如说突变检测，同样在基栈里面，上一分钟还是一百，下一分钟变成了50，变化量很大，要检测出来，还有一个是剧变适配，如果用传统的方法可能需要好久的时间，可能需要几周的时间才能适应这个新的模型，这个时候一直在告警是不可接受的，如果发现这个指标有变化，我们需要快速适应新的模型，还有就是节假日自适应推断。
下面有一个复盘的例子，有一天有一个很重要的系统出现了一个响应率低的情况，当然这个告警是在比较晚的时候，大概六点钟的时候发出来了，原因可能是因为头一天上线之后，内存一直泄露，直到晚上七点钟才对系统造成了影响，我们用这个算法复盘，相对于固定阈值，我们可以提前一个小时发现，可以节约很多故障排查时间。
第二个，介绍一下多维故障筛查，现在的问题有没有一些特征，能不能总结出一些特征，我们知道每笔交易都有很多维度，这笔交易发生在哪个机房哪个服务器上，总结一下地理纬度，是哪个机房哪个分片哪个服务器，还有很多业务属性，我们希望挖掘业务属性，发起机构是哪里，产品编码是什么，顺序代码是什么，可能是一些很个性化的维度。当出现这样的问题之后，我们能不能快速定义这样一个交叉维度，这对于我们刚才讲的缓解运维人员的焦虑是有很大作用的。

具体做法，从交易明细出发，提取每个系统的关键维度，用关联规则办法，把同时贡献的维度抽出来，然后在多维定位的时候会用到，然后在出现故障的时候用多维定位的算法，基本上是基于蒙特卡洛树搜索算法，我们不可能24小时都在，不可能一出问题马上做这个事情，这是给我们的一个运维人员减轻压力的好办法。
同样一个案例，异常检测，我们有一套系统，有一天未响应交易量突然飙升，但是很稳定，一直是几百条，因为白天的时候交易量比较高，响应率看起来没有那么低，到了晚上一两点，随着交易量下降，未响应交易导致我们的响应率下降到固定阈值，频繁的告警，频繁给值班人告警。因为这个阈值很重要，每次都要起来分析一下，最后发现结果都是一样的，都是说有这样一个交易码有一个查询交易，原系统是某某某。如果说我们可以把这个东西做出来的话，我们当时就上线的话，告警这个人看到了一直都是这个问题，第一次看了以后，以后再也不会关注，这个问题就过去了，不会被这么多的单位给吵醒。还有其他的例子，理财系统交易量增加，定义到某个产品没有开放，十点钟开放，九点50的左右大家开始抢购。大家都在抢大额存单。还有网银互联，定义出来的问题是失败交易全部是某一个银行，返回码是这个机构已经签退了，从网银互联这个系统里面已经签退了，肯定发过去的交易都失败了，如果直接报出来这些东西都不需要参与不需要关注了。

故障传播分析，主要解决的故障是这个问题是我的问题还是别人的问题，到底是哪个模块，调用链不断加长，在外面看到的只是冰山上面的部分，冰山下面还存在着很多系统。传统的方法是手机银行报警，找第三方支付，第三方支付找支付系统，一个一个往下走，像烽火台上的狼烟一样，我们想从上帝视角世界告诉你现在就是认证系统的问题，这个问题会减少很多人员的精力。这个做法其实就有三点。

一、我们以系统为节点，以系统的调用为节点，如果说我们认为A调B出了问题，我们认为B，被调用方那边有要求，这是一个原因。

第二个原因就是说如果出现了相同的表现应该是一样的，类似的，我们可以做比较，基于这个东西我们做出来。这是我们的监控大屏，有一天同时这么多系统告警，传统的方法是很麻烦的，每个系统都去看，到底是哪有问题，A找到B，B再找到C，这就很混乱了。但是如果我们用调用链算法分析的话我们发现其实有一个很漂亮的调用图，基本上直接可以推荐出第一个，就是它引起的。

我们其实还有别的算法，对里面的监控指标进行排查，我们发现这个指标里面的机器CPU掉下来了，CPU掉下来这个事情，一般我们监控其实不会把这个事情发出来的，CPU掉下来就告警一般是很说的。最后定位到一个问题，我们用的是双活数据库，节点切换的瞬间有一两分钟时间有很多不能响应的交易。

监控指标排查，如果前面这些都不奏效，监控指标到底有没有异常，原来是靠告警的，但是只会对比较严重的问题告警，长尾指标关注不到，轻微指标也不会告警，我们用算法来做，我们会有一个非参数校验的办法把每个指标的异常程度做一个打分，有了这个打分之后再根据前面提到的监控指标，有一个指标分级，我们再算每个分级，每个节点里面的严重程度做一个排序。
最后告诉我们的是某一个模块里面的MySQL有问题，或者说磁盘有问题，然后再往下看详细的。

这是另外一个案例，有一个系统响应时间上去了，并不知道是什么原因，我们就去查，数据库也在查，存储也在查，最后定位下来的结果，DB2模块，排名第一是磁盘，磁盘有问题，磁盘有什么问题呢？这两个机器的磁盘有问题，磁盘繁忙率有一个大幅度波动，这个波动在存储那边，因为是平均值看不到的，但是我们这边可以很快定位下来。

还有另外一个例子，响应率和失败率有下降，通过定位发现有一个进程，有这样一些波动，这个波动其实是非常的，大家看那个值非常小，监控不可能监控到这么细的程度的。只有通过这种办法发现出来，最后证明确实这个进程有问题，最后是日志模板分析，日志大家知道里面的信息非常多，我们怎么进行分析呢？

我们现在已经建了一个日志平台，人肯定分析不过来，我们的做法就是把所有的日志相似的聚在一起，然后做一个模板，有固定的部分和有变量的部分，固定的部分可以做持续数据进行遗产检测，前面是时间，中间这套不变，我们有一天有一个文件系统就标上去了，我们做复盘的时候发现，头羊一个模板频率在以前最高就是六七千，现在达到了12万，原来前一天正常的时候，这个变量大概占了三分之一，但是到那天占了四分之三，说明可能和他有关系。原来的底下的实际是译文是杂乱无章的，没办法画一个饼图，这天画成一个饼图了。

最后做一下小结，我们感觉智能运维不是万能的，需要进行合理定位，我们要把人工步骤抽象出来，把其中可以被自动化的替换掉，数据质量如果达不到的话，智能运维无从谈起，从算法DEMO到产品存在巨大鸿沟，需要对流程进行对接和效果进行打磨。实践是检验算法的唯一真理，不要尝试改变流程，而要融入流程。现在智能运维仍处于单点应用时代，未来随着大家这么多人一起努力，达成一个由点及面的态势，整体快速发展，我今天的分享就到这里，谢谢大家！