民生银行的DevOps实践之旅

白凡

分享：何佳佳
编辑：白凡

讲师介绍：我本人03年参加工作，一直从事IT领域方面的一些工作。然后是这样，我前半段一直都是在制造企业。没有关系，我前半段在制造业做过系统、开发、运维，基本上方方面面在做。我是10年加入民生银行，加入后主要做核心系统，包括公共安全的一些组建的技术平台，以及运维方面的工作，直到最近两年开始了精力放在公共工具和平台建设，还有流程体系的改造，还有DevOps在民生银行科技部的一个推进，还有实践的一些工作，主要是协调这块的工作。

今天我从四个方面给大家分享:

• 介绍当前的机遇和挑战。机遇和挑战下面我们有哪些当前的现状，是不是能满足和适应这些挑战
• 我们的目标到底是什么
• 怎么去实现
• 计划和展望

1. 机遇和挑战

首先看看民生银行的概念，民生银行开起来是一个中国的字样，其实它是一家一个个民营企业的发起的银行，可能现在民营银行它的概念比较火，民生银行应该是正派的第一家银行，他是发展速度非常快，从数字大家可以看到，从22年吧，从数字累积下来的话，到现在形成了一个大型全国性的商业银行，它的业务模式有一定的特色，包括有灵活性，多样化，还有团队作战的能力。

谈到机遇和挑战我从三方面看：
1. 第一是业务发展方面，刚才提到民生的业务发展近些年非常迅速，包括它的多样性带来流程改造的需求，同时近年来也有一些互联网的冲击，包括现在面临网点的电子替代率逐年在提升，这对我们IT有非常大的挑战。
2. 这一些挑战带来一些问题，下一个阶段就是说架构的方面，其实业务角度来讲，业务的调整自然会带来顶层业务架构的调整，这一些业务架构的调整会驱动中下层的应用架构，以及技术架构的演进，这一些演进会促进技术的迭代。
3. 本身技术新技术的不断普及，包括大数据，包括机器学习啊，或者是语音和或者容器方面的东西。
这一些新技术的普及也是给我们IT带来了很大挑战，这三方面，从业务、架构和技术都是互相影响和促进的。我们刚才说业务驱动技术的变革，那技术反过来，比如说大数据分析，可能带来一些业务上的机遇。

2. 背景与目标

2.1 Devops实现背景

从我们信息科技的角度来看呢，其实有很大的变化，从2000年左右的时候，从一个单体大核心的运用，这一个所有的系统是在一个集中式及时应用里面，然后我们直到12年新核心项目上线，是实现了SOA架构的改造，这一个改造变化很大，把一些模块该结合的结合，该聚合的聚合，把它形成了新的框架。直到2017年我们又有一个新的跨域，这一个跨域主要体现在一个发布式或者是服务架构的演进，包括业务的演进。

举个例子我们分布式分布系统现在正式上线了，上面承载的是我们所有电子直销银行的账户体系的运转，下一步计划是把整个线下账户体系会迁移过去。像我们新零售信贷体系其实也是分布式架构上面，同时它还通过大数据技术，包括智能分析能力提升它的反欺诈，包括决策引擎，还有一些贷后的风险监测的功能，这也是一个新技术的变革。另外提到企业综合服务平台和零售综合服务平台，这两大平台是我们科技协同业务在座的一个对公和零售两大业务条线业务转型，基于这一些转型的实现技术实现，就是这两大平台。另外还有一些电子渠道的一些所谓的中盘的战略，这一些都是巨大的变革。

多说一句，从科技的角色来讲也有一些变化，从最早只是跟随实现业务需求的成本中心，到现在是紧跟战略一个跟随者，再到现在我们作为借助金融科技的一些新发展，而去协同业务一起去创新。这一些变化和挑战我们有没有能力应对，这是我们下一步阶段要看的，给大家分享一下。

从整体背景来看，形势上来讲跟定银行讲以客户为中心，要快速、稳定响应客户的需求，同时也讲数字化转型，这对于整体IT软件的交付和运营提出了更高要求。

另一方面，从科技自身来看还有很大的提升空间，包括协同能力，包括工具链的建设，还有端到端的工程管理，这一些都还有一些提升空间。从这两方面来看，从形势和内部提升来讲，我们对DevOps的实践有一个要求，就是做精益的运营和交付。

2.2 Devops目标

在这个背景下呢，我们在2017的时候，从开发到测试，到运维，我们三大条线联合发起DevOps的实践活动，就组建了一个跨条线的量和小组，这个小组负责整个环境交付的流程体系，包括所有的模块做了梳理和调研，争取做全局性的方案，包括可落地实践活动的设计。经过分析我们总体来讲看有一些劣势存在，我们的团队是业务团队一样的，是化整为零，并且是灵活多变的模式，这种模式其实更多是以模块为维度，或者是以项目为维度，由开发、测试、运维灵活地去组合，去协同。

流程上面我们有一些比较好的项目形成了测试、运维直接前置到做需求的设计，把测试的需求，把运营状态的需求，非功能需求前置到最前面。去一起推进项目上线。同时实现了两周一个单位的发布策略。平台类的工具里面都是类目的名称，就是一些工程管理，包括测试管理，包括项目管理以及生产流程的一些平台。但是同时也有一些劣势，就是我们现在DevOps的理念还没有推广起来，还有自动化的程度，包括端到端的一些可视化，响应的反馈体系有待加强。

这是软件交付的流程，当时的情况看，从全局看是通用常见的流程。这一些流程没有太大的问题，但是细看有一些地方可以优化，有一些流程可以线下流转，这是要改进，交付周期要在不同的流程之间跳转，这一些流程之间呢，像我们提到的测试和项目管理，还有变革，这三大流程体系里面，其实它的耦合度比较高，集成难度还是有一些。还有一些在评审或者是质量管理的环节，其实是各条线有独立进行的情况，这一个也是需要去改进。

基于这一些背景和优势劣势，我们定了一个实践目标，就是体现三个数字上面，就是135，1就是构建一个平台，这个平台是DevOps平台，他会把所有的当前存在的流程平台把它串联起来去做集成和融合，让大家在一条线上做线上的协作。继续围绕着一个平台，我们把三个角色连接起来，这三个角色就是开发，运维、测试。以前的模式可能传统上来讲就是各管一段，就像铁路警察，刚才提到的这一些。我们未来可能借助这一个平台去把它融合起来，让它不要形成部门墙，而是一个小组化的融合的方式去推进，借助这一个平台和三个角色的融合，我们下一步要把整个软件交付的五个环节完全打通，不像以前的绿地火车，未来可能就是一个高速铁路。整体目标是这样，最终目标是要实现高质量的交付能力。

3. 方案和实现

3.1 Devops方案

目标设定好了，我们方案和实践方法给大家详细介绍一下。这是我们基本的思路，我们把DevOps看成三大块，主要组织文化，流程、技术。技术层面就是端到端的工具链，版本管理，包括平台化，标准化一系列技术层面的把控。流程层面是精益化为目标的一种方法，把当前流程集成与融合，这一个集成和融合会让流程会以更高质量去运转、去加速。构建在技术和流程之上是组织和文化。我们组织和文化的思路有两个，一个是有效信息共享，再一个持续改进和学习，形成自主的能力，这一些思路落到方法论上就是三步工作法，以及工程层面的方法论。就是像持续集成，持续交付，还要版本控制，还有品质这一些服务化的一些基础的概念。

这一个图是我们针对我们行自己的特色来把刚才的思路拆解一下，还是三步工作法的概念，我们可以去看，横向是开发、需求、测试，生产这四大阶段。其实第一步我们要做的就是把这一些各个环节的规范做垂直深入的标准化，之后形成一个可靠可重复的交付流水线，去把它流转起来，再下一步是把各个环节的反馈机制构建起来，在这两个基础上形成一个全局的可视化，再基于改进的能力形成一个整体的DevOps的体系。

刚才提到的领域，其实我们设计下来的话，就是这一幅整体方案的蓝图，可能比较复杂，其实我们是把它切分几块，横向来讲还是需求、开发、测试、生产四大阶段。纵向的话，可以简单来看，上面是流程的体系，就是管理的流程体系，它主要是复杂项目管理，包括测试状态的管理，包括生产这一边的发布管理，变更管理这样一个管理流程层。下层就是跟工程相关的，还有包括代码啊，包括相应的一些具体的技术实现。

其实我们的重点是中间这一层，就是流程和可视化这一层，我们通过这一层实现一个核心的流程引擎，通过这一个引擎把上层的管理流程和下层的工程实现去把它做集成，然后做全局的可视化。这是我们核心一个关键。当然集成化还有一些关键的技术点，包括底层的一些统一制品仓库啊，还有我们现在做的容器化的技术的探索。这是整体的一个设计蓝图。

基于这个呢，我们其实现在提双速IT，我们设计了软件交付的流程体系，也是快速类和传统类两大类，快速体现我需求变化，营销类和变化非常快的系统，举个例子电子渠道类的东西，像手机银行，网银这一些电子类的体系，他们的需求是多、杂、快，响应速度要快，这块我们现在已经做到了，像手机银行、网银直销这一些都是一周一次发布，我们现在还没有提到敏捷的思路，我们现在还没有做到敏捷，但是我们是瀑布敏捷的一个结合的中间状态。

这一个状态的频率已经非常高的，像刚才提到快速的是一周一次，像我们传统类的应用是两周一次发布。它们俩最大的区别是运行态的不同，上面是依托于容器的，下面的传统的设施设施方式去做。快速类是以能掌控的流程体系去实现，包括工具和流程。然后依托于这一种开源软件，包括一些简化的流程来实现，来带动我们传统类流程的向前进步。传统类流程更多是在于把各个方面、各个环节的工具包括管控能力去做垂直深入的这一种探索和挖掘，去加强一致软件交付的管控。

其实快速类和传统类体系都有公共的地方，就是顶端的流程，这一个发起的流程，切分成几块，和刚才一样，就是把整个项目管理，开发工程管理，测试管理、生产运维来作为一个全局来看。那项目计划其实和测试计划是要联动起来前置出去一起做，包括业务需求，测试需求，运营需求这三部分是同时提上来上来的。然后这些需求汇总成为一个整体的项目需求，再拆解成任务，开发任务和测试任务之间有一些映射关系。还包括它们的进度，包括它们的状态，甚至底层还有版本控制和制品一系列作为支撑，同时也发布管理贯穿前端到后端的一个全局，包括生产的分析，也会做一个反馈，这是一个通用的流程。

其实刚才提到快速流程的基础，就是容器平台，这是我们去年开始做的一个新探索，主要是用体现在Docker容器技术去实现全流程的管理，形成这一种流水线，包括现在也做到多环境部署，就是应用滚动升级和发布。然后在。生产的一端我们依托大数据的数据做日志收集和监控分析，再去做分析，这一个后面会详细提一下。

这是快速类流程设计图，就是还是依托于我们集中那个中间的流程引擎，其实就是持续进深，持续发布的服务器，我们叫它服务器，这一个服务器是我们DevOps平台的核心组建，这一个核心的组建之上有一些前台的功能，包括可视化，统一的管理，监控等等，下层是与做联动，包括容器的发布，容器的编排，还有一些分层体系的构建。这一个对于开发来讲，我们也做一些标准化的动作。跟开发一起联动在做。

传统类其实与快速类的流程没有特别大的变化，唯一区别是底层没有和容器集成在一起，同时他的工具会更多元化，包括商业套件，包括开源组建，大家可以看到这一边，我们还有大量的一些套件，还有包括Jenkins这一些，他的工具包括我们开发的框架很多，所以这一块很难立刻统一的，我们把每一项都深度挖掘，把它实现从版本到代码到测试状态，各种质量把控做强硬质的管控。

在软件工程度量分析方面我们也做了一些工作，至少目前实现了一些最基本的多维度分析，可以实现的是从应用视角来看的话，就是我们开发团队的条线，他的板块，他的团队，甚至每个应用的构建、部署、扫描、安全的汇总情况会作一个多维度的分析，来提升我们工程的质量，刚才的度量分析可以放到移动端分析，这是一个小功能点。

3.2 Devops实现

我本人是运维的，我侧重介绍一下我们运维方的一些实践：

• 工具平台的支撑体系的建设
• 我们现在在做运营分析和可视化的能力
• 是我们持续开进业务联系线的流程体系

我们整体设计了一个运维工具平台，这个整体管理平台，其实包括几大部分，一个是可视化，数据分析，监控采集，自动化管控，还有IT服务管理。具体的不详细介绍了，这是具体的一些模块和组件。

这是我们一个新的思路和创新，就是我们基于机器学习和研究机构合作，研发智能运维的平台，是嵌入到我们工具体系里去，提升根本原因的分析这一些内容。
刚才提到运营可视化的一些概念，我们现在是实际的案例。

我们这一个运营可视化我们叫做全景运维平台，首先看，最上面这一层是全景运维最上面是入口的视图，就是上面看全景，看全景是体现所有银行的交付情况，基于这些密密麻麻的东西，它的节点是应用，应用可应用之间是可以它可以通过动态引擎把下面的应用啊，包括链路上面遇到的一些从从交易底数、从性能、从异常三个角度来看的异常情况把它汇聚到上层来体现，比如说A到B调用有问题，他会在这一个链条上直接高亮出来，告诉你这一条链路有问题，同时支持下转，那下转下来就可以到应用层，或者是应用链路程，这一层会把刚才提到到的三大指标集，交易量，性能，议程到底那个方向有问题，再去下转，包括再往下的调用方，服务器，服务到底是什么。

另外一个功能就是端到端的一个追踪，就是一个端到端的追踪，就是我们有一套全局唯一的流水号，通过这一个流水号去识别到底是那个环节和节点出了问题，哪个节点损耗时间最长。
这是我们设计的思路，就是这套平台的设计思路。就是在旁路的方式去做日志输出，包括报文的复制。不影响业务的情况下，去把这一些数据拉取出来了之后，通过流处理方式把它做持久化，再通过API评估到上一层，经过多维分析，包括动态的规则引擎，甚至现在也在纳入机器学习做一些更高级别的一些展示和交易链的分析能力。这是我们在金融电子化上获得的一个奖。这一个项目我们运维团队少数几个人利用业余时间开发的一套平台，目前用途也比较广泛。

其实除了这一些工具以外，还有可视化的建设以外，我们在组织也有探索，这是我们以前的组织架构，大家看到生产运营部是我们数据中心，这一块比较重头是在我们应用运维这一层，应用运维我们建立了多个中心，通过中心化的方式去做管理。然后每一个中心下面针对每个应用去做不同的专业的岗位设置，A岗、B岗这样的，这一个以前传统的方式去加强它深度的掌控能力。这一个方式在应用上的时候没有问题，应用大面积推广起来了之后，这一种管理的成本，包括协同能力会有挑战。基于这些考虑，我们做了虚拟化的探索，2017年我们把内部的这一些相关的应用系统做汇聚，形成一个应用小组，是一个弱小的小组，大概九个人的样子，组建是负债应用小组，资产运用小组，还有数据应有小组，这一些小组内部呢，他们可以沟通更顺畅。

外部来讲，上面到下面其实是一个垂直化、扁平化的管理方式，大家的资源，包括管理，包括各种流程的体系是遵守统一方式。而且小组和小组并不是割裂开的，它是动态调整的。待会儿后面也会提到这个动态我们是怎么做的。同时我们跨中心、跨部门做虚拟化的，包括工具平台组，还有ITSM这一种流程组。

这是我们虚拟化的工作协同，主要涉及两个方面，一个是小组化运维，这一个小组化运维其实来源我们像开发绝对编程的一个概念，其实对于我们译员来讲，我们初级阶段实现了绝对运维，从绝对运维小小组化运维发展，这一个小组运维发展更多是指整个小组对整个小组的应用一定要非常熟悉，当然可以各有侧重，但是所有的应用要掌控在自己的手里，然后我们建立了一个三人沟通制，这不一定适合所有的地方，我们任何一个小组的共同议题一定要至少三个人以上去讨论这一个事情，增加信息共享的能力。在小组之间形成桥接的模式，相互的轮换，加强协同和通讯。怎么支撑这一个虚拟化的工作模式，我们建立三大支柱，一个是嵌入流程的管理体系，工具与平台，还有流程整个体系的建立。

这一个时候在我们运维侧的一个敏捷化探索，我们把任务按照专项工作先形成一个待办项目，然后拆解形成待办任务，这一个待办任务再拆解到每周去做任务看板。利用这种敏捷化的思路管理小组化团队，右边是我们的实例，就是分成集中方式每周去统计当年的任务，也会有专会，也会有总结会，是这样的模式。

4. 计划和展望

刚才基本上是我们实践的情况，我们未来还有哪些计划，大家可以看一下，邓老师也提到了，我们DevOps是一个非常长期的过程，不是一蹴而就，我们设计了三个阶段性的目标：

1. 短期呢，我们更多侧重于平台的打通，包括流水线的建立，还有双速流程的建立
2. 中期是在可视化、度量分析、交付模式的一些创新
3. 长期可能是高效地反馈机制，包括分层测试体系的嵌入，还有经济开发交付的一些探索

说到重点领域，我们下一步要考虑的，就是整体的分支管理和集成的规范。我们会机遇Git FloW模式，去探索一个适合银行的，适合大多数应用核项目的分支管理策略。另外是自动化测试盒分层测试体系，这是我们正在构建新的测试平台，是在测试团队里面贵贱的，我们跟他做融合，看怎么嵌入到我们DevOps流程里面。还有一个是需求条目化，这一个需求条目话更多的意义在于怎么把需求做规范化，并且和任务做无缝的对接。
这一个是测试体系的嵌入，就是怎么嵌入到这一个流程里面，就是在各个环节里面形成第一层的自动化的测试，第二层的手工测试，第三层的回归测试，是这样的模式在进行的。另外的重点领域在于持续增强我们持续集成能力，包括我们把现在做的C口的评审，安全扫描嵌入到整个集成过程中去，作为强管控。

还有标准化、平台化的推广，我们开发平台、开发框架尽量做统一化，把非功能需求形成组建化去组建这个平台。还有我们度量分析和可视化刚才也提到了，还有容器平台我们持续实现分层管理能力，还有快速弹性伸缩这一块。

第三部分是我们还会加强一个重点，就是开发本地化的规约能力，我们更多技术上的体现是我们会把当前的一些代码的扫描作为插件的方式嵌入到开发者的本地，这样的话他在本地开发的时候就已经受到各种扫描啊，这一些状态的质量把控的约束。

还有一些平台化的一些实现，会嵌入到插件里面去。配置管理更多是指我们集中应用的配置，还有包括机遇部署发布的配置。部署发布刚才提到了，我们会增强它的能力，我们现在是蓝绿部署的方式，容器层面的。未来可能基于流量的灰度发布，还有金丝雀发布模式做下面的探索。在运营反馈方面，我们基于场景化的方式来做运维和运营的一些分析。因为现在其实现在更多银行是基于应用视角来看，包括我们现在做也是基于应用视角来看，但是未来会转变成基于场景，以场景入手看流程，通过流程到应用，这一种方式做分析。这几大体系，这几大重点领域，再结合到DevOps的整体体系建设，这是我们的未来的展望。