案例|上海银行数据中心智能运维建设实践

点击观看演讲视频上海银行数据中心智能运维建设实践 选自Zabbix2022中国峰会_哔哩哔哩_bilibili

本文整理自上海银行数据中心郑晓在2022Zabbix峰会演讲分享。ppt可在公众号后台回复“ppt".

其实做监控，一直被有领导问到这几个问题，你覆盖全了吗？生产上有1,000台主机，你能保证一台都不落吗？时效性高不高？生产上有一个告警出了，生产上有个故障，你1分钟之内能够发现它？告警有效吗？你们是不是一个“狼来的孩子”？处理有没有及时？报警出来之后你们多快速度能够解决故障？使用便捷吗？他的平台的UI是否好用？对客户是不是友善？

我觉得大家都应该会碰到这些问题。解决上面这些问题，不像我们今天这么轻松。很多问题是出在什么时候？故障分析会的时候，我就发现一个规律，每次开故障分析会，领导和我是必到场的，其他的一线都是流水的。每次开完分析会，我就会带一个大礼包回去，整改、梳理、优化。每次带大礼包回去，时间长受不了，会折腾死人的。

基于此，我们痛定思痛，决定从几个方向对我们的平台进行一次优化，一共5个层面。

第一，集中化，即我们对所有的数据进行集中，因为之前数据可能会分散有各个专业的数据，比如说有OEM的数据，系管的数据，网管的数据，都没有做整合，那第一要做的所有东西，数据的集中是基础。

第二，智能化，通过算法来提升故障异常感知的能力。

第三，标准化。数据的规范，指标的体系，这些标准化自动化，提升我的故障处理时效。

最后，可视化。可视化提升，大家有更好的界面去看。

基于这些，我们重新设计运维体系架构，一共分为4层。

最底层，就是所有的IT资源,倒数第二层就是采控层，采控层包括我们和所有基础IT资源打交道的那些应用系统，比如说日志采集的flume，自动化的Agent，我的自动发布的NCB，以及当然还有最主要的Zabbix。

还有专业的管理平台，比如说网管、系管也对他们自己的专业平台有采控的功能。再往上是我们的两个能力中台，数据中台和管控中台，数据中台承载的所有下面采集的数据往上做聚合、计算梳理这么一个过程，包括机器学习，集中告警，了多维分析。

所有东西都会聚合到它上面去做处理，对外暴露统一的数据服务接口。右边是我们的运维管控中台，主要有流程平台和自动化流程引擎组成、流程平台、网上提供统一的运维服务接口、经过流程的审批运转之后、驱动自动化做驱动自动化引擎、调度下面的所有的采控平台工具，去做基础的采控操作。  

再往上就是可视化平台，通过封装、定制化以及引入自定义的BI工具能够让最终的用户达到他们自己的各种的运维场景的定制化查询，看板等等，所有东西都可以通过用户自己的拖拉拽方式去做去实现。

最后讲一下，我们上海银行Zabbix的情况，Zabbix其实我刚刚看到是在采控层，它现在已经是采控层中最大体量的一个平台,有很多子平台。它是我们当中最大的一个平台，上海银行大概是在2016年开始接触Zabbix，当初经过一年的选型到2017年确定正式以Zabbix作为替代原有商业软件的工具。我们经过一年的试运行，经过两年的和商业软件共存的这么一个情况，我们主要是以CD类系统，主要开源平台AB类系统还是进BMC为主。

一直到2020年到2021年之间，逐渐我们开始不在原有的BMC平台上新增监控节点,全部迁移到Zabbix平台，所以现在我们大概有超过1万个节点200万个监控项50万个触发器，MVPs大概超过2万，后续节点出来还会更多。刚才看到，我们现在之前的很多采控的功能。还涉及到很还在很多的专业平台上，但是后面，我们会把它专业平台上的采集能力全部引入过来，比如说：存储、网络服务器这块硬件，我们都会迁移过来。

至于上面这些，我们给自己定一个小目标，1分钟发现，5分钟定位，10分钟恢复。在后面的实践分享当中，我们也会围绕这三个点做说明。

先看1分钟发现。1分钟发现的基础就是采集。采集是所有监控的基础。从采集角度来说对于采集情况的，评判标准就是他的监控覆盖度，我们认为监控覆盖度是有两个层面的广度和深度。广度是说他的采集对象要覆盖全不能有一个遗漏。深度就是说对于指定对象的监控的画像，他的指标是不是覆盖全，我是这么理解的。

先看下广度，其实评判监控的广度是不是覆盖全的，方法很简单，就是跟CMDB做比对，大家有没有发现这是个好消息。我们可以把锅甩给CMDB出来，因为很多时间都是背锅的，现在偶尔可以甩个锅。

当时有个坏消息,CMDB也是我管的,我左手甩到右手,还有个问题,就是一旦问题放到CMDB里面去,他就涉及到不单单是覆盖器,CMDB覆盖的完整度,而且还涉及到数据的准确性、一致性以及逻辑性是否准确,那锅越来越大。

所以，我们从2021年的时候，我们重建CMDB，在CMDB的过建设过程中，我们把数据的准确性，放在第一要素，所以基于此，我们采取规则减和、加图算法的这两种方式。

先看规则减和。主要是分这四大类。

打个比方，操作系统往上肯定是有操作系统，往下肯定是有个资源的，即使是一个虚机，也有可能是个物理机。如果当中有一方缺失，那他的数据就是不准确的，也就是说我的CMDB数据是漏的，还有比如说,怎么样保证我是生产上所有的都准？我们去做ARP的比对,认为主要是有一个资源或者是一个组建在生产上活着,他肯定会在ARP上做留痕,我们在核心交换机上,做ARP表的采集。

我们会把CMDB上所有的IP信息和ARP表做比对，拿出这些不在ARP表中的，但是实际CMDB上没有的IP我会取出来，取出来再做具体的分析跟踪，包括完整性。我们设计很多规则，包括一次性比对一个机柜一个设备的机房位置，楼层应该都是一模一样的，这都做很多一致性的比对，那这些比对规则，加起来有超过1200项，但是同时这又带来一个问题，这些比对的规则跟我的模型是仅耦和的，这么大的量我以后的模型一变动，我的规则，维护的工作量是非常大的，所以在基础上，我们又引入图算法。

通过实体解析相似度的图算法，让它自动的去产生关联关系，自行让他去判断识别出来有哪些CI的数据的孤岛，帮助我们去做减核，减轻人工负担。所以我们是通过两方面结合去做的，经过以上这些东西，我们认为数据已经采集全，我们对象全，就是对我们的指标进行细化。

下面是网络硬件中间件，这些就是有个长效机制的，我们会定期根据生产上的案例，或者是跟厂商交流，有哪些值得采集的指标，我们会纳入进来，上面还有交易指标，除通用场景指标或黄金指标，成功率、交易量、成功数、失败数，等等这些东西。

我们还有很多业务的指标，因为这两年都是运营转运维、转运营,所以我们有很多信贷的指标，排队叫号的指标，审批的指标，用来对外做看板用，对象指标细化之后，那就提高要求。

原先我们是通过固定阈值的判定，也就是说，以上图为例，原先我们是连续多少分钟为0，那就认为交易不可用，但其实，告警条件是根本就是没必要的，为啥？当他为0的时候，客户已经打电话过来，客户已经帮我们完成波测，因为指标本身的反馈是滞后于用户反应的。

所以我们又引入智能检核的算法，他能去智能检测异常的趋势先于用户去发现，我们的生产上的波动，或者是服务不可用的趋势等等，那至此，我认为基础的采集，以及原始的判异，在一分钟发现环节已经全部做完，后面就需要在对于这些原始的判异数据如何进行加工，帮助做尽快定位和分析以及处置。

在这之间，我认为有一个环节非常重要，那就是数据治理，就是我们的数据不单单是Zabbix，还有其他许多其他的数据过来，那很多的运营业务场景都是，数据和数据之间要做关联分析的。如果前期数据治理质量不行，那最后会花非常大的成本去做数据的融合，去做分析去做消费去做挖掘，就以刚才我在PS和CMDB做关联分析为例，Zabbix和CMDB当中以一个数据库实力为例，他们的名字必须是一致的，如果名字不一致当然也能做，但是当中会有发生非常复杂转接的规则，这些规则维护起来觉得你量的提升会非常麻烦，所以，我们非常强调数据治理，我们认为数据治理是后面所有做定位的基础。

刚才说采集面广、指标细、基础异常、异常判异点多之后，我们发现告警风暴多，反而给现场的值班人员带来很大的困扰，一个故障往往引发非常非常多的一连串的告警，那时候现场值班同事反而没有方向，以我们传统的值班模式来说，大屏告警出来之后会反馈给大屏，大屏看到之后，我们会开一张事件单，开完空单之后，打电话给当天的专业值班，人员说有故障你要去处理，当突然100条事件出来之后，整个大屏就刷屏，而且，一个告警可能涉及到多个专业科室，对于现场值班，他根本就没有办法去区分这么细，所以我们做几个优化的点。

自动开单。不需要人工去通知，因为人工通知是有延时的，所以说他告警出来之后，我们会有根据他的不同的级别，会有外呼，会有短信等等去做通知，让当天的专业值班人员能第一时间知道现在生产上的情况，条件多之后他第一电话会被呼死，所以我们后面还有动态等级的调整，他会根据历史的事件的处理情况，做事件的智能调级，不是所有事件出来都是P1的，他会帮你做调级往后降，如果事件连续多次出现，今天又出现他会往后降，降到P2、P3往后降，进行降级的处理，降级处理之后，但是时间上事件的数量并没有减少，当我们的专业值班人员发现这件事情的时候，还是满屏的告警，但是时候我们是要借助，相似度模型的分析，去把它的相关的告警进行聚类。

比如说一个操作系统挂之后。我上面会有日志的告警、交易的告警、进程的告警、端口的告警，这些告警都是跟我的这台主机是做相关联的，他们的共同属性就是我的IP，是我的主机名。这时候，他们会把这些告警进行压缩合并成一条，交易告警也是的。一个交易的波动，可能造成他的交易量的下降，成功率的下降，错误数的提升，那这些东西如果是同一个交易类型的，同一个交易类型，也会进行合并，因为他们有一个相似度的特征进行合并，那通过这一步，我们就把散乱的监控数据聚合成点，但是点和点之间的关系，我们还无法得知，因为现在的整个交易链路特别特别长，下面的组件也特别特别复杂，同时一个应用系统下面有有可能多的有100多台机器，上微之后，同时一个交易电路可能从头到尾，从网关可以创造我们的核心当中又创造很多很多要交易系统，那当具体是哪个交易或者是哪个应用系统去触发这一整串的故障链。

所以说我们通过横纵两种算法去处理第一个，通过整个交易链路的串联，我们会把所有的故障，应用交易故障的点打在上面，通过定位是哪个故障点出问题，通过找到这条故障点，去向下分析它所有的CMDB的架构，纵向是以CMDB数据为基础架构，找到具体是哪个具体的组件告警，再做具体的定位分析，我们认为这样相当于，给专业值班人员指明一个处理的方向。到这里，其实基本的定位已经定位完，后面就是处理。

从这张图可以看到，我们做采集处理，告警和场景的识别等等，最终就到处理，处理环节看看很简单，其实非常复杂，一般的处理环节其实就是300伏，重启、停机还有隔离等等。但是，随着应用系统越来越多，架构越来越复杂，并不是每一个值班人员都对所有应用系统的处置都非常了解，对他的技能要求就非常的高，这时候我们就借助自动化的手段，把所有的处置流程作为标准化，当天值班人是用来做决策的，决策完之后，所有的处置都是一件事的，他会跟刚才的告警定位。同时放在一个界面里面，在一件事定位，一件事处置，通过这种方式去把他们全部都给处置。

后续展望，我们后面还有工作要做，已经规划大概两年，会从用户体验，业务指标引入APM，把可观性做好，还有就是易购监控平台的集中管理，即使是产品本身我们有多套，除产品本身，可能还会引入其他的监控平台，如何对这么多监控平台作为统一的管理配置，数据的采集处置是我们后面要分析的，后面还有数字孪生，通过数字孪生和CMDB结合起来，再通过动态静态数据的组合做到程度。

大致的分享内容就是这些，大家有没有发现，我们的整个监控和现在防疫特别像，他们面对的一个问题就是，都是在一个庞大数据复杂环境下的精确定位处置的问题，这两个场景有很多环节是共通的，全面采集，全民筛查是一样的，告警压缩，5人一管10人一管，流调就是交易链路，告警分歧，高风险、低风险，最后还有运维可视化，我们觉得其实大家方法都是相似的，那疫情其实通过这种差不多的方法论，疫情管控也是越来越好，因为我觉得在同样的方法论下，也会把我们的监控做的更加准确，今天分享即以上。

扫一扫｜加入技术交流群

微信号｜17502189550

备注“使用Zabbix年限+企业+姓名”

5000+用户已加入！