2019年12月18-19日，第十四届中国IDC产业年度大典在北京国家会议中心正式召开。作为数据中心云计算产业内知名的盛会以及IDC企业、电信运营­­商、互联网、金融、政府和厂商等产业上下游的高效沟通平台，与会嘉宾包括政府领导，行业专家和企业代表数千人。 以“智能运维与安全”为主题的分论坛于19日下午举行，中国民生银行信息科技部应用运维二中心负责人毕永军出席本次会议，并发表了《金融数据中心智能运维的探索和实践》主题演讲。 

中国民生银行信息科技部应用运维二中心负责人毕永军

毕永军：很高兴参加本次年度大典，其实去年的时候也参加过IDC圈的会来讲了智能运维，刚才我回顾了一下，关于智能运维这个话题从17年开始就讲，18、19年，每次讲感觉会不太一样，17年的时候讲的更多的是愿景，我们要搞智能运维，希望未来能做成什么样子，18年的时候就有一些思路了，讲我们要做的思路，要建设成一个什么样的平台，今年可能会讲得更细一些，这说明一个什么问题呢，说明智能运维这一块现在越来越深入、越来越细化，而且开始投入实际使用。像姚总演示的机器人颜值就很高，在机房里放一个肯定是非常吸引眼球的。    

下面开始今天的演讲，大概分几个部分，简单介绍一下智能运维，我们这边做的智能运维跟前面做数据中心及机房巡检这块略微不同，我们是偏向应用系统运维方面的。另外讲一下我们做智能运维探索当中都会做哪些场景。最后把我们实践当中的成果跟大家分享一下。    

先来看为什么要做智能运维，我们知道机器设备、包括机房随着互联网分布式架构是越来越多，像我们股份制银行服务器的级别大概在万级，国有大行应该接近十万级，互联网大厂基本上往百万级走了，面对这么大的系统规模，运维挑战很大，不能像以前那样靠堆人解决问题了。另外现在系统架构复杂度也会提高，分布式、微服务越来越多，实际上发现上了这个系统之后也是一个坑，为什么是个坑呢？本来一台主机问题就解决了，现在两百台服务器上去，机器故障率、占地、耗电、制冷各方面都是挑战，分布式、微服务架构投产后得上些手段，要不然运维是非常痛苦的。    

再来看故障的处理难度，像刚才讲到的金融数据中心对故障处理要求太严了，根据监管的要求，我们希望出现任何事情要在半小时内解决掉，但是系统很复杂，半小时内怎么解决掉？像民生银行提的双十标准，10分钟定位问题，10分钟解决问题，抽出我们在故障解决当中最费时间的两个环节，我们希望把它花费的时间减少。    

再一个是运维数据量还是很大的，机器规模上来了，日志各个方面都很多，大家觉得应该是有价值的，但是这个数据实际上是贫矿，有用价值的数据并不多，怎么把它用起来就需要进一步的挖掘，所以这个面临很多的挑战。    

Gartner以前列了一个智能运维的图，类似于中国企业提的监管控，Gartner认为2022年全球部署智能运维的企业要达到40%，这是一个潮流，我们肯定往这个方向走。从前几年的演讲来讲，肯定是处于起步阶段，从场景入手，以前靠人巡检，人也容易疲劳、出错，我们可以靠机器人做这种事情，现在智能运维还是从点上出发，以功能点为主。    

我们再反过来看智能运维这个事情，其实很多年前大家在提商业智能BI的时候，大家都会提，我们是从数据出发，数据里边可能会提供一些信息，信息总结之后会变成知识，再高一层次我们说人作为一个高级动物，认知功能在里边是提供智慧，所以智能运维这一块发展我们做一些事情对于数据的处理基本上还是符合这个步骤的。    

我们具体怎么做的呢？从17年去做，在做的过程中也认识到AI本身还是有些局限性的，现在大家讲很多是感知型的人工智能，还有认知型，希望像人一样去认知去思考，像机房机器人也是感知，要拍照识别，但是它能不能像人一样思考联系一下这个故障可能跟哪些东西有关，怎么解决这个故障呢？现在可能还做不到，所以我们现在做的很多还是根据统计学、关联、因果的关系做这些事情。当然数据挑战也很大，对我们来讲几百套业务系统遵循的标准不一样，处理这些数据也会面临挑战。另外原来的人基本上是专业性很强的，做服务器的、存储的、网络的，实际上懂AI、算法的人还比较少，人也比较缺。有很大的挑战。所以我们定了一个思路是从痛点出发把比较难做的，做起来比较慢的或者需要很多人力的场景去做，重点是降低运维成本提高效率，同时希望智能运维系统能够学习人的经验，通过一些专家知识的方式提高我们的运维效率。    

下面看一下我们在做运维场景设计的时候，基本上是去抽取典型的场景，因为做智能运维肯定不能全部都去做，一定要找典型场景，怎么做这件事情呢？一个是能够把运维信息整合起来的场景要重点突破，因为机器处理比人的优势是处理能力比人强、做运算比人强，但是做推理、逻辑思考现在还是比较困难的。另外对于一些人有经验的，能够固化、标准化起来做自动化处理的场景重点考虑，重点在于提升效率而且这种场景要融入现有流程，其实现在大家对人工智能感触很多，比如到机场发现人脸识别，身份识别马上可以通过安检了，这就用到图象识别技术，串在安检流程当中去，未来运维当中也是一样的，这个场景一定会串到日常运维流程里边，在里边发挥作用。    

我们首先看一个很典型的场景，我们做故障处理的，做运维的很重要的环节，一般会做影响分析，看影响定界是什么，这个问题影响哪些系统、哪些业务，再根据抓的数据做特征分析，这个问题是一个服务的故障还是多个的、还是多个系统的？监控指标正常不正常，是不是服务器不正常导致业务不正常还是存储不正常导致业务不正常了？还有看系统运行的日志信息，拿到信息之后要靠历史经验做共性分析，分析之后觉得以前这个问题碰到过，知道是什么问题，这个问题怎么解决，后面做执行解决。大概处理的时候是人去处理的过程。在这个过程里用智能运维在每个环节能够发挥什么作用，就把它放进去。    

根据刚才画出来的图，可用性发现里面有单指标的异常检测，对日志有些异常检测，影响分析的时候会对交易进行多维分析，看看到底哪些交易、哪些点出问题了。另外一个是跨系统，多个系统之间做故障传播分析，通过分析和排查把所有监控指标汇聚到一起，看哪些监控指标产生了异常，找一些蛛丝马迹做匹配。最后刚才讲过自动化流程，通过自动化流程把既定操作步骤串起来解决问题。这是整个过程。    

下面我们看一下实践的成果，对于可用性故障发现希望发现及时还不能漏报少报，我们就从这个出发抓对业务系统来讲、对于用户体验的关键性指标，可用性指标，交易率、成功率、响应时间等等，从这个看有没有异常，这个做了一些算法，这种算法看起来以前也有类似的简单算法，像3sigma、LOF、孤立森林，在特定情况下产生效果，有些情况下会产生误解，所以我们设计的时候采用GBRT回归基带算法，中间加一些处理，包括跑批时长、尖峰、偏移、节假日等等。    

智能运维给我们带来一些好处，这个系统响应率偏低，告警系统会设一个阈值，低于95%告警，系统出问题到95%之间时间还很长，我们做的监测系统大概能提前一个小时发现问题，这一个小时还是非常宝贵的，能够解决很多问题。还有一个，系统出现问题的时候会产生告警风暴，这时候我们怎么做一些进一步的分析呢？这个例子是我们举的交易量的分析，我一个系统对外提供服务，比如提供500个服务，但是中间可能个别服务出现问题了，这时候看到系统不正常，但是要排查这500个服务找哪个服务有问题需要花很长时间，这时候我们怎么做？把这些交易数据网络传输做出来之后，把数据通过交易的实时分析可以对它进行区分，区分到每个不同的交易类型，比如几个计费服务，银行系统做有些中间服务要收费，计费系统就是计价的，这时候我们看发生告警，告警说某个服务响应时间低于多少，另外对于主机也做了细分，是哪几台主机有这个问题，当人看到这个信息的时候会帮你排除掉很多噪音，省掉很多排查问题的时间，让你快速找到问题的原因。    

前面杨总也提到护网行动，特别金融行业，今年护网行动持续一个多月，我们很紧张，都在7×24小时盯着这个事情，我们智能运维在这个过程当中也做了一些贡献，刚才我们做检测的时候发现它有些特殊性的攻击，大家知道传统做安全防护有防火墙，在交易层面会做交易过滤，但是伪装成正常交易发到服务器上来，就不好监测。服务器负载能力是有限的，大量发交易一定会把你搞垮。这个例子中我们发现查询客户信息的一个正常交易过来的特别多，属于异常情况。从它的来源分析，我们就能很快锁定攻击的IP，把攻击的IP封掉，就封堵了这次的网络攻击，这是一个很好的应用案例。    

第三个是多维故障筛查，我们拿手机银行的交易来看，我们做个转账维度信息很多，客户属于哪个分行，做跨行转帐、转给谁，会发现很多信息，但是当故障出现的时候要去仔细分析，比如通过人行系统做一个跨行转账，某对手行系统出问题了，其他行都是好的，就这个行有问题，这时候我们要准确快速的区分出来哪个行的系统可能出问题而不是我们行的系统有问题，这时我们要去做故障分析。下面一个例子，比如我们做抢购，黄金当时涨价了，很多人都去买实物黄金、纸黄金，一般会通过互联网渠道去买，我们就发现这个交易量上升，上升之后互联网渠道一般负载能力比较强，会传导到后端系统上去，这时候要对后端系统做重要的保障。    

简单讲一下它的原理，主要还是在交易层面，从交易明细提取维度来，形成交易明细的维度库，根据维度库信息、事件出发来的信息进行多维定位，根据渠道，所属银行、交易明细是黄金购买，就基本上确定了问题点。    

另外这是另外一个多维故障异常定位的例子，这个例子提前十个小时就发现问题，发现个别交易存在无响应的交易，无响应交易集中在查询交易明细，并有个源系统，这就比较好的定位问题了，跟源系统的人沟通解决，这个可以提前十小时定位问题，这个图因为当时还没有正式投产，在试运行过程当中，是事后复盘的图可以看到效果，理论上说多为故障定位投产了后，大家关注这个告警就不会有后面成功率降下去的情况出现了。    

多维故障筛查的时候，交易出故障之后我们做筛查这个例子是做理财交易，大家知道现在经济增速下滑，很多国家在降息，美国降息，欧洲也降息，银行有比较好的产品锁定高利率的就是大额存单和一些高利率的理财产品，我们当时发现突然系统响应率下降了，因为网上都在抢大额存单，但是大额存单产品是有开放时间的，10点钟放出来才能买，并有一定的额度限制，在此之前去抢发现产品没有开放，但是对于系统访问的压力已经上来了。    

刚才讲的基本上是个单系统的问题，实际上我们刚才讲的微服务系统之间越来越复杂，很多交易全是跨系统的，跨系统的就有个问题，特别是后端系统出问题的时候发现前端手机银行网银各方面都会出问题，到底问题在哪儿呢？每个人负责自己的系统肯定上去一顿查，在查的过程中信息沟通也没有那么顺畅，所以我们做故障传播，希望当告警出现的时候就能快速定位哪个系统出现问题了，就能集中精力检查这个系统出现的问题，提升效率。    

我们做的方法是构建一些架构拓扑与系统的调用关系，以及故障的传播关系建立相应的信息，当故障出现的时候根据这些信息做计算，推荐出可能的TOP3系统帮助人进一步做定位。 

这个例子是十多套系统展示有告警，拓扑关系就可以展示出来，定位是调用的最底层系统出问题了，这样花的时间比较少，最后涉及到指标定位的时候关联过去，看这个系统到底出现什么异常，发现有异常的系统指标，当时是我们数据库的某个节点出问题，这样快速地定位到根源。    

另外一个是监控指标的排查，现在监控指标非常多，出了问题怎么查，这时候可以通过人工智能进行分析，把系统指标分析出来，哪些类别哪些指标出现异常可以关联起来。做法就是通过对每个指标做异常度的评价，因为大多数指标特别是性能类的和容量类的指标是比较稳定、比较有规律的，出现异常就打分，通过机器学习的算法打分高的排前面，查找问题的时候发现异常指标的排名进一步诊断，右下的图能看出来出了问题，所有服务器某一指标上都出现了异常，这样可以帮助我们快速的定位问题。这里一个例子，当时某个系统响应时间增加，这边的定位结果是磁盘繁忙，因为我们分运维专业，银行数据中心一般有应用运维，下面会有系统、网络岗位，要跨专业条线找其他人帮你看这个事情，有这个系统之后关联起来了，出现问题发现现在磁盘有问题，马上找存储的人解决这个问题，存储的人一看确实业务量比较大，存储前端口比较繁忙，后续优化一下分布一下负载量。这是我们碰到的一个典型的例子。    

还有某个系统响应率失败率下降的时候，我们通过繁杂的指标里面找到是某一个进程出问题了，一个系统里面的进程也是很多的，可以准确定位到出问题的进程。    

再有一个是日志，大家知道日志非常多，我们现在接了200多套系统放进去，每天日志量接近20TB，量还是非常大的，但是看日志也很麻烦、很复杂，所以我们在这一块也做了探索，根据我们建的日志平台抓取的日志，对日志做分析，日志分析很复杂，非结构化的数据，首先要做变量分词，形成日志模板，中间有变量，根据这个出统计信息，基本上把日志模板相当于做了画像，正常运行情况下日志分布情况也是差不多的，每一种模式的比例、数量都差不多，当出现异常的时候就会发现某类日志就会出现异常，这也是我们当中的一个例子，当时出现问题发现日志量增大了很多，出现很多前端过来做访问的日志，从日志分析里面发现这类日志增加特别多，经过分析以后发现是某些客户端存在问题，它向服务器发送了大量的无效请求这是通过智能日志分析定位问题的例子。    

前面是对数据做处理，系统复杂度是很高的，有时候专家很重要，一招鲜，别人来了不管用，他来了一下解决问题了，但是我们不能依赖专家，专家不在怎么办？我们想怎么把专家的知识提炼出来，让他的思考模型去形成模型放在系统里边再加上我们抓取的数据做专家模式的事件匹配。如图是其中一个例子，我们访问某套系统出现问题，一下出现14个告警，根据我们以前建立的专家模型发现它可以定位到出问题的系统是什么系统。    

专家模式事件匹配做的方法，构建模型做挖掘，最后把模型做实时分析予以匹配。我们专家模型事件匹配做了宿主机模型，大家现在讲云，做容器特别多，容器底下还是在物理机上或者依托于虚拟机，一台物理机出问题会影响一两百台虚拟机都出问题了，这时候怎么找到这个问题？当时就出现类似的问题，八九个系统同时出现问题，最终我们根据这个模型监测出来它都是属于这个宿主机，宿主机下面挂了某个存储的某个盘出现问题了，这个存储停了一会又恢复了，因为虚机的镜像都在里面，相当于静止了一段时间用不了，这是我们通过专家模式事件匹配判断宿主机故障的案例。    

除了做这个之外刚才讲到我们在点上做实践，所以DBA团队在数据库智能排障方面也做了很多工作，大家知道我们现在的应用架构是水平扩展的，至少银行目前是这样，但是要对交易做一致性一定要有数据库，数据库就是单点，数据库出问题整个系统就不能用了，所以数据库特别重要，所以我们现在对指标做了全部的管控串联起来，而且能够做根因分析，定位到SQL语句，利用专家分析收集了28种场景，把场景关联起来做挖掘，我们现在用的比较多的db2，mysql指标是非常多的，后续也会接入JVM和其他的指标，右图就是我们根据专家知识构建的像知识图谱的概念了，是把这些指标联系起来了，这个出来之后现在DBA每天早上可以看一看，系统里面根据我们的智能算法有没有哪些异常，再针对性的做预防性的维护。从监控指标定位到SQL语句，看SQL语句有没有问题，如果有问题要跟开发人员一起快速解决这个问题。 

这是我们做的一个面板，看到整体的运行情况。目前三个月，下面是分了不同的场景，在这个系统里面命中场景的情况，其中某一次系统出问题的时候出了一个告警尖峰，尖峰出来之后根据知识图谱看到有些红色异常的指标，根据异常指标点击进去可以找到对应的SQL语句。SQL语句对于DBA来讲还是非常关键的，出问题的时候，一条SQL语句就能把系统搞死，要找到SQL语句非常重要，通过这个系统一下子就能找到。找到这个语句后面做一些分析，分析数据库的情况，发现数据库当前是锁等待竞争比较严重，我们快速把锁竞争问题解决掉就可以了。这是SQL的时间分布，大家主要在等锁，这样就有方向了，定向的把问题解决掉。    

基本上前面讲的内容就是这么多，简单总结一下，前面讲到的，一个是我们做了三年我们认为智能运维不是万能的，不是说哪儿都行，那天跟朋友聊天说，你们是不是放个机器人值班就可以了？我说这是未来世界的情况，现在没有到这个程度，所以不是万能的。我们要做哪些呢，针对我们人工流程当中难慢重的部分，基本上是用场景+算法+数据的方式简化我们的运维工作。另外我们在做的过程当中发现每个场景落地都会花很长时间，发现数据质量非常重要，数据质量决定效果，数据质量不行出不来效果。另外刚开始有一个想法或者有篇论文发表了，觉得这个算法可行，但是要做成一个产品投入生产使用那个时间也非常长，我们在做的过程中也有很多失败，整体来看智能运维前景还是非常广阔的，所以未来肯定会有更大的发展。    

谢谢大家！