当前位置:首页 > 新闻中心 >新闻详情

中国民生银行:智能运维引领数据中心数字化转型

发布时间:2021-03-04 17:55:00

大家下午好!
今天我演讲的题目是《智能运维引领数据中心数字化转型》,跟大家分享民生银行在智能运维领域的探索和实践。



01/数字化转型,运维新挑战

金融行业是对信息技术应用最为广泛和彻底的行业。首先,我从民生银行的角度,向大家简要介绍一下银行业科技的演进趋势。
 
2000年初,我们进行了银行系统大集中,建设了管理银行账户的单体核心应用系统,当时用户需要去网点办理业务,而随着互联网发展和个人主机的普及,银行开通了网上渠道。到了2012年,民生银行完成了基于SOA架构的新一代核心系统投产,以面向服务的架构重构了整个业务体系,对业务的支持能力进一步加强,从原来只是实现业务需求变成紧跟业务战略发展,支撑银行业务的持续发展。
 
近几年,随着金融科技和互联网金融的发展,银行业务和IT架构有了非常大的变化。现在民生银行基于分布式和微服务技术,自主研发并投产了分布式核心系统,把银行账户体系和业务系统迁移到分布式架构上来。分布式核心系统采用了多中心的部署架构,能够支撑海量的并发访问。基于 “薄前台、强中台、稳后台”的思路,我们对业务与应用架构也进行了升级,持续进行信息系统的构架转型,以敏捷的方式满足客户需求,支撑业务发展。金融科技赋能业务创新,进一步提升了客户服务水平。
 
刚刚过去的2020年,大家经历了非常不一样的一年。年初疫情突发,武汉封城,由民生银行首创的“7*12小时”远程银行服务,应用音视频传输与解码、数据交互及加密传输、物联网等技术,在业内率先实现了基于手机银行的多场景个人和对公业务服务,远程柜员在线办理、全流程无纸化服务及数据化交互体验,真正实现了“突破时空限制”,“实时在线”、“全程无接触”服务,让用户在疫情中感受到民生银行的暖心服务。
 
同时,民生银行聚焦提升客户体验,打造有温度的银行。一方面积极利用人工智能、云计算、边缘计算、自然语言处理等前沿技术,业内首发5G手机银行,围绕交互体验与智能服务打造六大亮点,颠覆了传统手机银行服务模式。另一方面打造小微金融3.0模式,以数据、工具、系统平台为基础,围绕小微客户的生意圈和生活圈,定制综合金融解决方案,全面满足客户需求,着力提升差异化、精细化服务水平。

总体来说,随着产品推陈出新和流程优化改进,银行业务越来越注重客户体验,能够快速响应客户需求,提供更优质的银行服务。而这些服务和系统都运行在数据中心,数据中心的各种设备、技术栈和系统关系越来越复杂。从物理服务器到虚拟化云平台,从商业产品到开源技术,从集中式架构到分布式架构,这些都给运维带来了更大的挑战。如何应对新挑战是我们当下面临的严峻课题。
 
那么,我们现在面临哪些挑战呢?首先,银行与互联网企业不一样,互联网企业采用的技术栈比较新,而我们的银行系统从二十年前的系统大集中发展到现在,处于新老架构并行和双栈运行的状态,运行环境更为复杂;

其次,业务创新速度快,要求频繁发版。基本上,我们每周都会做版本发布,但因为系统的云化和微服务化,每次版本发布都会对系统的稳定性运行带来很大的影响,如何做好影响分析和控制变更风险是我们面临的重要课题;
 
再次,数据中心技术专业条线多,需要运维人员具有“十八般武艺”,维护系统的稳定运行需要依赖运维专家的独特经验,而运维专家经验难以复用;
 
然后,因为技术新老不一,应用架构标准化程度不一样,我们有运行时间超过10年的应用,也有新开发的应用,这进一步增加了运维的复杂性;
 
最后,随着大数据技术的发展和监管控运维工具的完善,我们有非常丰富的运维数据,但存在“数据孤岛”问题,各专业条线的数据不易做共享。

 

02/数据驱动运维

为了应对挑战,民生银行采用“数据驱动运维”战略来解决目前面临的运维难题。“数据驱动运维”战略围绕以下几个方面展开:
 
一、感知能力
我们在数据中心的建设过程当中,应用数字孪生技术,把运维对象数字化,构建可视化的界面。运维人员通过界面可以直观看到系统的运行状况。同时,我们的监控平台覆盖了运维全领域,拥有维度丰富的数据,再通过智能运维算法智能发现故障,对数据中心整个运行组件做到全感知。
 
二、决策能力
以往单纯依赖运维专家的过程主要是人工决策,当然人工决策对数据中心来说依然很重要。现在我们采用了“可视化+专家大脑”去做人工决策,同时通过“大数据+机器学习” 来智能决策。
 
三、执行能力
有感知有决策,当服务质量有所下降或出现故障的时候,要怎么去恢复服务、降低故障恢复时间?这就需要在执行能力方面下功夫。我们建设了标准化流程、标准化动作、标准化场景,之后再通过自动化运维系统固化起来,在出现对应的故障的时候,可以采用一键恢复的方式,来提高问题处理的效率。
 
四、数据底座
要建设上面提到的三种能力,数据底座是基础。前面提到,我们运维工具很多,数据很丰富,但因为“数据孤岛”加上数据维度庞杂,构建统一的运维数据中台作为底座就非常重要,在数据底座建设上我们下了很多功夫。
 
五、组织转型
 
数据中心都是各个领域的技术专家,网络专家精专于网络知识,系统专家负责系统。而采用智能运维的方式时,运维感知和决策建立在数据的基础上,这时候就需要组织做相应的转型。我们采用了Google SRE的理念,来提高运维开发能力,提升运维效率。
 
我们认为,数据驱动运维的落地不单单依赖一个简单的平台,而是数据中心所有工具平台的有效整合和集成。上图右侧“落地产品”就是目前我们采用的一些平台和工具。
 
这里,再跟大家分享一下数据底座的建设。我们大概从2018年开始做数据底座建设,遇到很大的问题是运维数据治理。我们之前的运维数据标准化程度不够高,想用算法消费数据来提供感知和决策能力时,就必须先做数据治理。因此,我们对所有的数据做了摸底,建立运维数据的标准,并且通过自动化程序和配置采集程序来采集标准数据,经过加工汇总到28个数据模型,最后汇聚到数据运维中台上,对外提供数据消费的接口。接下来做智能运维,数据直接来自于数据中台的数据服务。这个过程中,数据治理是难度比较大的一件事情,我们花了很大精力,目前也在根据一些运维场景不断地优化和完善。
 
运维数据中台提供数据资产加工和数据服务的能力,高效满足前台数据分析和应用的需求,总结为以下四点:
 
  • 其一、基于大数据平台,通过Spark/Flink集群的实时计算,达到秒级响应、实时计算的能力,提供大吞吐量的数据处理能力;
  • 其二、全量数据,目前每天有20TB的数据量,每分钟有百万级的监控指标,每天有数亿笔的交易明细,这些全部集中到数据底座进行加工;
  • 其三、数据治理,数据经过加工清理,然后分门别类存放;
  • 其四、在提供易用的应用开发接口之后,组织运维小组按照场景进行攻关,利用运维数据中台的数据去做开发,取得了比较明显的效果。

 
接下来谈一下组织转型,下图是我们实际的行政组织,应用运维中心是按照银行业务划分的组,其他是按照技术条线进行分组,我们在做数据驱动运维转型的时候,形成了跨各个中心的运维数据中台虚拟组、智能运维虚拟组和可视化虚拟组,分专题进行专项攻关。对于运维工具的建设,我们站在整个数据中心层面来统筹安排,协调资源,统一建设。现在看起来,这种方式取得了比较好的效果。
 
回到今天智能运维的主题,其实现在业界对智能运维的范围界定并不是很清晰,狭义的智能运维是指利用数据+算法来获得数据系统运行的感知和决策能力,我们目前是按照狭义目标来进行探索和实践,智能地进行自动化操作暂时还没有覆盖。
 
这几年我们在智能运维方面主要做了以下工作:在故障发现层面,做KPI指标异常检测、应用日志异常检测;在故障分析层面,做调用链分析和多维分析;在系统画像方面,分析系统健康状况、系统应用架构、系统提供的服务类型;在故障预测方面,根据性能指标趋势来预测未来可能产生故障的时点,便于做主动性防御;对于性能瓶颈,我们做了周期性、主动性容量评估的尝试;在知识图谱方面,我们尝试构建数据中心各个运行组件之间的关系,告警以及运维知识库内容的关联,通过知识图谱的方式把实体和关系关联起来,然后按图索骥,在告警出现时找到对应的解决方案。



03/民生智能运维实践分享

民生银行异常检测和故障定位主要聚焦两个方面:横向定位故障系统,定位到哪个系统出了问题;纵向定位故障原因,找到系统中哪个组件出了问题,原因是什么?
 
下图左侧是我们需要用到的数据,在横向故障定位的时候,需要用系统调用数据以及系统间服务调用数据来分析;在下一层应用架构逻辑部署关系上,利用好应用模块关系、应用部署关系以及服务内部逻辑;在底层用传统软件模块上,根据各自模块的特点,各个突破,找到各自的故障定位逻辑;在基础设施方面,我们对服务器、交换机和存储也有详尽的数据。
 
从问题解决路径来看,首先是要发现故障,在可用性故障发现层面,根据系统的可用性指标和特殊的单指标,通过机器学习发现这个指标的规律,如果出现异常能够做到及时告警;在日志异常检测层面,通过构建日志模板发现系统异常。
 
在发现异常后会进行故障影响分析,通过交易明细数据界定影响的范围。影响的是分行机构,还是全行层面,还是某个第三方?可以清晰地界定出来。
 
分析出影响范围后,进一步定位问题根因,通过调用链分析定位到具体哪个应用模块出了问题,接下来去找具体原因跟解决方案。是数据库的问题,还是应用的问题?还是底层虚拟机的问题,或者网络问题?需要在各个组件层面进行深入定位,然后通过可视化的方式提示根因,并且推荐出相应的解决方案。
 
以上是我们日常做故障处理的流程,以及用到的一些智能运维技术。
 
故障发现
其实,做故障发现不是一件容易的事情。我们要做故障发现算法一定要适用于各个系统,但银行各个系统的运行特点不一样,比如性能指标每天的曲线、每周的曲线、每月的曲线都不一样,所以做智能运维算法的时候要做很多考量,比如考虑系统批处理时间的影响,识别一些指标的陡升陡降,因为一些业务的关停或新开,可能就会出现陡升陡降的情况。再比如春节、国庆等节假日,指标与平时不一样,也需要算法有效识别出来,保证故障异常发现的准确性。这规避了传统监控方法要设置不同的阈值,而且阈值要根据业务变化进行人工调整。现在我们直接用智能算法就能检测业务KPI的异常。

 
调用链分析
如今大家使用手机银行比较多,它对银行整体业务的替代率在90%以上,但是每个业务并不是手机银行独立提供,而是依赖于后台的很多系统,比如业务集成系统、产品系统、核心账户系统等,这是一个很长的调用链,而且调用链也不是一个简单的单流程,可能涉及到多次业务查询和账务操作,才能完成一笔交易。在调用链出来之后,大家就会发现它其实很复杂。
 
当系统出现异常的时候,我们要找出真正导致异常的调用链和根因,首先要把调用链构建出来,之后采用算法做异常调用剪枝,保留异常调用链路,再进行组合排序来评判它的异常程度,最终确定到底哪个异常调用的链路才是故障的根因。
 
多维特征分析
大家用Excel的时候,经常会做一些数据分析或者数据筛选,可以从不同角度勾选不同的维度,来观察相应的数据。我们做的多维特征分析,是通过算法把数据进行组合、分组和计算,再跟正常情况进行对比,快速找出交叉维度组合,并支持下钻分析。
 
从下图右下方可以看出,通过多维特征分析,可以直观看到异常交易类型是什么、调用交易的源系统是哪一个、调用返回码是什么。我们通过智能运维算法直接把多维数据分析结果显现出来,省去逐步查看日志、查看系统监控指标、分析数据和原因的过程,节省了大量的时间和人力。
 
基础软件故障定位
刚才讲到调用链的分析,我们系统间的故障定位基本上基于交易指标,把系统运行的一些黄金指标拿来去做运算。系统运行出现异常一定是组成系统的某个组件出了问题,也许是一个外部服务,也许是一个数据库,也许是一个消息队列。由于每一类应用软件的工作原理和指标都不一样,就需要非常丰富的专家知识去解决这个问题。

我们在做基础软件故障定位时,其实是借助运维专家的专家知识,梳理成一个指标的集合,对指标进行整体的管理管控,同时构建指标之间的影响关系图,然后可以用一些算法去定位系统中到底哪个指标出了异常。这是我们现在在数据库层面做的故障定位,可以做到一键定位问题,分析出数据库里面运行的Top SQL,及时发现SQL执行效率降低的问题。
 
这里讲一个案例,之前有一个系统响应时间变慢,我们快速故障定位发现是本系统出了问题,通过智能算法的可视化路径看到应用服务器各项指标是正常的,数据库有一些异常的情况出现。我们进一步通过基础软件故障定位,找到是数据库有一个指标产生异常——磁盘写日志缓慢,导致数据库的响应效率降低,进而引起应用系统的响应速度变慢。
 
日志故障定位
应用系统运行时都会打印运行日志,而运维人员会花很多时间去查看系统日志,发现应用程序运行到什么步骤出的问题,再根据代码排查根因。然而随着系统规模的增大,一个系统可能有几百台服务器,每台服务器上的应用服务器都会产生大量的日志,这时候怎么快速定位出问题的节点、出问题的日志,根因又是什么?这给我们带来了很大的挑战,也是我们启动日志故障定位的原因。
 
首先通过ELK平台把日志收集到一起,然后通过智能算法对日志文件做训练,创建出日志模板,并建立基线,最后根据日志模板对日志进行实时检测分析。因为系统在运行的时候,它的行为是有规律可循的,像系统正常运行时错误日志就很少,所以我们通过把正常运行的日志模板提取出来,再根据日志模板实时对日志进行异常检测的时候,如果说日志出现了不符合基线的异常日志点,可能就是系统出现问题了,可能是某类日志突然打多了,或者是日志里有些取值或者变量分布发生了变化。比如Web服务器访问返回码正常是200,突然一下子出现了很多4XX的返回码,就可以通过web服务器日志发现系统异常。
 
这是我们做日志故障定位的思路,当出现问题的时候,通过日志故障定位功能分析日志是否异常,是哪个组件出现了异常,再根据异常做进一步处置。

经过几年的时间,民生银行智能运维实践积累了一些经验。首先是数据先行,把数据中心各个运维工具的数据做治理,统一到相应的运维数据中台,这样我们就有了数据底座,有了数据处理和服务能力。
 
其次是算法创新。人工智能发展到现在,像语音识别、图像识别等技术已经很成熟,但这些都属于特定领域的算法。从运维来讲,我们碰到的场景是异常复杂的,标准化程度也没有那么高,所以做异常检测和故障定位时需要在算法上做创新,可以对一些经典的算法进行组合使用。
 
最后是场景驱动。刚开始做智能运维难度很大,因为这是一个全新的课题,所以我们当时决定通过场景驱动的方式,找到日常运维工作中特别难、特别慢、特别繁琐又亟需提升效率的场景,集中精力去突破,通过“算法+数据”的方式来简化运维工作。
 
在本届国际AIOps挑战赛中,我们提供了真实的业务系统,输出相应的基础软件监控指标、系统运行的交易服务指标、系统调用链数据和日志数据,供选手们来做故障检测和根因定位。
 
预祝各位选手在2021国际AIOps挑战赛中取得好成绩,祝AIOps挑战赛圆满成功,谢谢大家!


问答环节

此次主题演讲聚焦中国民生银行的智能运维探索,分享业务实践下的AIOps落地成果和经验,引发了线上观众的热情提问与讨论。现将提问及答疑整理如下:

Q:是否可以分享一下知识图谱在民生银行的使用场景以及解决的问题?
A:民生银行数据中心在知识图谱方面的主要思路是:一、基于现有的配置管理数据,涉及应用系统之间的调用关系,以及应用系统内的调用关系,包括各个应用组件、服务器、交换机和存储设备等。二、把告警和告警处理方法形成知识库,尝试用知识图谱进行关联。这样一来,我们搜索告警的时候,就能快速找到告警发生在哪个组件、会影响哪些组件,推荐针对该告警的解决方案。
 
Q:民生银行引入AIOps后落地应用有多少?在效率提升方面有没有量化数据?
A:目前,民生银行主要是对实时交易系统接入了智能运维,落地系统有80余套。在智能运维的效率提升方面,对于一些可能影响客户的生产事件,我们对故障发现和根因定位的准确率有要求。2020年,从已经接入AIOps的系统来看,故障发现率在86%,根因定位准确率在66%。同时,关于故障修复时间,民生银行数据中心制定了“双十”要求,即10分钟定位故障、10分钟恢复服务。现实情况还未完全达到这个标准,我们今后会进一步提升智能运维水平。
 
Q:民生银行在智·能运维方面投入的人员配比是什么样的?
A:我们不是一个部门或者一个团队去做智能运维,而是涵盖数据中心各个技术团队组成虚拟小组,从运维数据处理到数据标准化、再到智能运维算法,核心投入成员二三十人。这些核心成员在完成本职工作的同时,参与到智能运维探索和研究。他们有丰富的运维经验和领域知识,对运维有很深的理解,有助于智能运维实践取得更好的效果。
 

 

TOP

010-82362970