何佳佳：民生银行基于开源的运维实践

2018年3月21-22日，由中国信息通信研究院主办、中国通信标准化协会支持的”OSCAR云计算开源产业大会”在国家会议中心举行。

银行业云计算发展论坛作为大会分论坛之一，于22日下午召开。

李晓枫：下面请民生银行的技术专家何佳佳给大家分享民生银行基于开源的运维实践。开源体系坑多，所以才把运维和开发理念合在一起，出了新词。既然你要用开源建私有云，绕不过开源，我们听民生银行怎么介绍，请。

民生银行技术专家何佳佳带来的精彩演讲题为《民生银行基于开源的运维实践》。

以下为演讲实录:

何佳佳：各位领导、专家，大家好，我的分享主题是民生银行基于开源的运维实践，其实前面几位领导和专家都已经在云计算，包括开源方面的发展做了一些指引方面的描述，包括蓝图方面的介绍。我更多会从底层运维支撑角度来看，怎么去做云计算，包括开源的支撑。

我是03年参加工作，基本上到现在刚好分上下半场。上半场在传统制造业，做过几乎绝大部分IT各方面的工作，所以IT各个领域基本都有一定了解。下半场加入民生银行，基本上做核心系统运维，包括关键组件的运维。这两年更多把精力偏向工具平台建设，包括ITIL流程，DevOps平台建设，现在民生银行在做实践落地。

民生银行是比较特殊的银行，它是第一家民营性质全国性股份制银行，它发展非常快，21年的历程从最开始资本金10几亿，到现在3700亿的发展速度。它有一个特点，业务与需求追求短平快，要效果，以结果为导向。所以，在这种情况下，我们会面临哪些挑战呢？刚才提到业务的高速发展情况，有自己的业务特色，包括它的灵活性、多样性。再加上最近几年互联网金融模式，对我行的冲击比较大，不过民生这方面应对也很及时。比如在余额宝出来之后很快对标出来如意宝。在这种业务发展情况下，从业务架构来讲调整速度非常快，从而带动底层应用架构，甚至技术架构不停的转变和演进。同时对技术迭代要求非常高。从以前单一的开发运行框架到现在多样化的框架，各类新技术层出不穷，比如大数据、人工智能，机器学习等等。当然，比较重要的是从封闭商业软件模式到基于开源模式的转变。有一个数字可以证明这些变化量，我们2017年全年所有应用变更超过1万次，而且还在递增。

从信息科技角度来看，2000年左右我们主要是单体应用架构。2012年到2013年之间，随着“新”核心项目上线，改造为了SOA架构，可以从架构图看到逻辑和应用架构的复杂性。这两年有更大的跨度，分布式和微服务化的改造，和新技术新架构的高速演进，同时通过刚才提到的那些新技术会去引领业务，包括应用这块的技术革新，包括的业务革新。比如，2015年开始我们有一个和发改委合作的金融云科研项目，经过2年的研究积累，我们设计实施了分布式和微服务架构方案，上线了分布式的核心系统。该系统主要采用分布式架构，也就是我们当时做的金融云科研项目的落地化。另外，新零售信贷体系，利用新兴的大数据智能分析等技术，实现了决策引擎，反欺诈，贷后监测等功能，给业务带来很大的业务革新，诸如此类的创新还有很多。

当然，这也给我们的运维带来了一些难题。从应用架构演进到技术迭代，速度是越来越快的，而我们曾经的运维支撑能力发展相对会比较缓慢。这其中存在两大难题，一个是传统的运维模式，难以适应支持高速变化的应用与技术，导致运维不停的被动响应需求。另外一个是封闭的商业软件工具依赖，需求受限，转型缓慢不灵活，变相增加了运维的被动性，支撑能力因而发展缓慢。针对这些问题，我们也在思考如何破局。

首先，我们把视角转向运维模式。我们最早的数据中心是传统的组织架构，会建立很多个专业领域的中心，实现中心化管理。岗位会有明确职责，岗位之间有一定的隔离性。工具层面，包括流程层面，会和应用运维层面有比较清晰的定义。这种机制，是当时的一种比较理想的情况，但不一定适合不断变化的环境。那怎么去改变它呢？我们考虑组织机构的“云”化。主要从三个方面解决，首先是虚拟化，我们从最痛点的应用运维入手，建立虚拟的运维小组，把岗位做业务相关性聚合分组，化整为零，通过虚拟小团队提高灵活性，同时鼓励跨组跨中心的轮岗。在此基础上，建立了两个跨中心的虚拟组，一个是流程小组，一个是工具与平台小组。流程组会跨中心设立流程负责人，整体设计把控各种IT流程，包括问题、事件、变更等。工具与平台小组也是多中心协同，会从实际应用场景出发，全局考虑怎么构建我们的工具和平台。在这种虚拟化划分的基础上，从而做到整体扁平化管理，统一资源调配，统一工作流程，实现更有效地协同合作能力，实现全局信息共享，应用场景与工具、流程的深入融合设计。

工具和平台层面，我们参考AIOps的理念和漠视，转化设计了一套自己的运维发展蓝图。核心基础能力层面是我们的基础，主要由系统管理中心这边专门的大数据平台团队独立设计，实现了基于开源的大数据基础架构。另外，这个团队基于开源实施了日志技术平台。中间逻辑平台层包含三个方面。一个是监控，主要基于开源Zabbix搭建监控体系；自动化与DevOps部分，以前更多是使用商业软件，逐步以开源的Ansible，Jenkins等软件为后台，做上层的封装和整合。两者通过IT服务管理进行交互与流转。最外层是应用场景层面，会从应用运维角度看具体的痛点或需求，面向消费场景来驱动设计。我们在开源方面还是比较积极的，发展较快的。比如大数据平台团队现在不光是在用开源，而且开始贡献社区。慢慢的我们就会从购买使用封闭的商业软件转向商业软件与开源的融合发展。下边简单给大家介绍这几个层次的情况。

核心基础能力主要是指大数据基础架构，设计实现了三大集群，分计算集群、非计算集群和实时计算集群，三个平台各司其职，分别服务于批量数据任务、联机查询以及实时消息和流处理。这么多资源怎么管控是一个很大的问题，大数据管控平台是我们团队专门自主研发的，用于支撑大数据基础架构运行。平台层面实现界面逻辑和执行层Ansible的封装。支持项目管理、功能管理，同时还有批量作业发起，资源池使用监控跟踪等功能。日志技术平台，主要是基于ELK技术栈构建，我们建立了全行的整体日志视图，总行和分行的分层体系结构，通过平台统一管理所有的日志。包括日志收集、传输、存储、分析、可视化，都在这个大平台里面完成。

监控方面，主要是在zabbix之上做二次开发和封装，一个是建立新的监控体系，二是和老的监控平台的集成融合。通过大数据平台做分析，以及后处理响应动作。另外，我们近期在实施容器云，容器方面的监控重要的工作，我们也是通过基于Zabbix的新监控体系来实现对容器的支持。

接下来是重点的应用场景层。应用场景我们更多是从应用运维角度出发进行设计实现。给大家介绍几个场景，第一个场景， onplat全景运维平台，实现实时业务数据分析和可视化。主要功能包括业务数据可视化，实时分析，根本原因分析与问题诊断，主动感知系统交易质量，包括异动、风险，及时反馈。这个项目在去年获了两个奖，一个是金融电子化颁发的运维创新贡献奖，一个是行内科技创新二等奖。这个图比较直观，当前银行的架构变得越来越复杂，比如SOA，分布式、微服务化面临同样的问题。举一个例子，3秒钟的交易，要穿过很多城市机房、系统，包括服务器，怎么定位，怎么找问题原因，其实是一个特别难的话题。

下边这幅图是以前的一个真实的案例，一个比较局部的交易缓慢问题引发的一次特别费力的诊断过程，这里不再详细描述，主要是两大难题亟待解决。一个是全局优化没有特别直观的告诉我们到底哪个点出了异常，二是局部问题掩盖在全局得海量交易里面，难于定位。

基于这些痛点，我们开始着手发起这个项目。主要的设计思路是在应用服务运行过程中，旁路无感知的自动完成信息收集和各项检查，通过API提供给上层做实时展示，多维度分析，甚至通过动态规则引擎、机器学习的参与，再反馈到上层做问题根本原因分析和整体运行情况汇聚实时展示。下边这幅图是当前的实现，一个是非常简单的主页入口，能输入很多要素，比如返回码、IP系统简称、流水号、服务名、日期、系统A到系统B的访问关系等，后台自动区分进入不同的分析视图。另外也可以直接访问系统全局运行视图，实时地汇聚展示了系统健康情况和每个系统之间链路的情况。如果下层某个指标出现异动，会在上层快速响应出来，比如做红色高亮显示，能够很快知道出了问题以及问题所在。视图支持点击下钻到应用或链路视图。我们设立了三个指标集，交易量、性能和异常，围绕这三个指标集进行多维度分析。

应用视图，用于展示应用和交易链路的情况，同样围绕着刚才提到的三个指标集进行分析。通过动态规则引擎以及机器学习，进行分析和判断，识别异常变动和趋势。例如左下角的服务调用分析，通过规则判断，展示当前交易情况和历史同期正常情况，进行比对展示。另外还有交易尖峰分析，我们可以在界面上快速拖拉拽，快速识别异常点和问题原因。

下边的功能场景是单笔交易链路分析。这部分功能对于运维来讲非常有用，比如图上这一笔端到端的交易调用，途经十几个系统、服务，通过这个功能可以直观的看到具体慢在哪个原子服务，到底哪个环节出了异常。

这个平台整个框架比较简单，数据分析逻辑是基于大数据平台来实现的，使用了Kafka，Spark Streaming，ES，Redis等等组件。流程可视化层，利用民生自有的开放框架形成平台，上层使用开源的UI组件，嵌入自然语言处理。

第二个应用场景是我们的自主创新项目实时指标驾驶舱，用于展示商业银行的基本经营指标，包括资产、负债等等的实时情况。民生银行过去只能做到T+1日报表查看前一天的数据，通过这套新的框架，现在可以秒级近实时地看到当前指标，包括存款、贷款等各项指标。现在我们的行领导每天都要多次查看这个功能。这个功能可以在手机上方便的查看实时情况，实现下钻分析到多个维度，比如按机构统计。另外实现快速识别大额异动的交易。逻辑角度不再详细描述，主要包括三层，数据接入层，数据计算层，接口服务层，最终提供到手机上进行展示。

第三个场景是针对更多的分布式系统上线，提供关键的分布式交易追踪功能。分布式架构内部的调用复杂，难于故障排查。我们通过分布式的服务框架，逐笔按照规范定义记录调用信息，通过ES进行持久化存储，集成开源Zipkin进行分布式追踪展示，这样分布式系统的问题定位会很便捷。这个功能已经与之前的Onplat项目打通，实现外部调用与内部调用的联动整合。

第四个是应用系统一眼清平台，实现基于模板快速进行配置，把所有信息汇集在一起，包括交易情况，各种中间件、服务器、数据库等中下层基础设施的信息，做到一眼就能看清应用系统的整体运行情况。

刚才提到的这些应用案例只是我们运维工具和平台建设的一部分，还有其他的一些工作。比如正在进行的标准化组件开发，我们建立了标准的日志组件提供给应用开发团队使用，其他类型的组件也在设计。运维下一步的规划分几个方面，一方面深入设计应用场景，部分开始实现业务方面的需求，这个我们与业务部门在做合作推广；另一方面，会加强前端平台层面的建设，即时通讯的联动，提供更丰富的API，移动端的展示等等；同时，计划把更多海量数据通过机器学习，抽象为知识沉淀到知识管理体系，再形成一套固定的后处理方案，通过自动化，实现自愈自治的能力。

我的分享就到这里，谢谢大家！