【IDCC2019】中国民生银行毕永军：金融数据中心智能运维的探索和实践

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

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

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

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

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

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

谢谢大家！

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!