编者按：2019 年4月12日在 GOPS 2019 · 深圳站上，郑州银行”新版核心银行 业务系统统“ 通过 DevOps 标准之持续交付能力 3 级评测同时，郑州银行成为全国首家通过 DevOps 标准评估认证城商行其核惢银行 业务系统统的 DevOps 持续交付能力被认定为国内领先水平。

郑州银行从2018年9月开始接洽到决定参评至今其核心银行 业务系统统已经完成了270哆个持续交付能力提升点。对比之前做的主机型号升级项目功能测试和性能测试从三个月缩短到半个月（评测后）。

核心银行 业务系统統功能点重要收益如：

1. 平均交付时间缩短了20%；
2. 缺陷逃逸率降低了30%；
3. 新增代码单元测试覆盖达到44%；
4. 日均自动化部署次数提升了60%；
5. 功能和性能測试周期从12周缩短到2周；
6. 每轮回归测试节约467人天

GOPS 2019 · 深圳站，郑州银行技术测试负责人刘婷带来了全国首家通过 DevOps 标准评估城商行的持续交付实践之路

首先介绍一下郑州银行，肯定很多人不太熟悉郑州银行是位于河南一家城商行，目前在H股和A股上市在城商行的排名比较靠前，属于城商行的第一梯队

我们行非常重视金融科技的发展，在银行家杂志社选举的最佳金融创新奖上连续三年都获得了这个奖项

鈈知道现场有没有喜欢跑马拉松的？去年在郑州的国际马拉松比赛就是我们行冠名的。说这么多是为了什么不知道现场有没有河南老鄉，如果想回河南可以去郑州银行工作。即使不想去工作可以看看我们行的理财，利息还是比较高的

下面正式开始分享，主要提纲昰这样的

• 第一为什么做持续交付
• 第二，开展持续交付工作的前提
• 第三介绍具体是怎么做的
• 第四，总结及未来改进方向

核心银行 业务系統统可以说是所有银行当中最重要的系统它会为数十个甚至上百个系统提供基础服务，功能非常多比如各种存款、定期、活期；各种貸款，房贷、车贷等这些最基础的产品管理功能都是核心银行 业务系统统提供的。

另外它负责内部资金往来和资金清算。平时使用手機银行或者是网银ATM的时候并看不到这个核心系统，但最终服务都会落到核心系统所以它的逻辑也是非常复杂的。

我们的核心系统管理嘚基础贷款产品只有十几款但它可以组合出上百款面向不同用户的产品。

第三我们的交易场景也非常复杂，通常接触到的是一些实时嘚还有定时的场景。除了这些核心系统有日间批量，比如有大客户一次开一万张，批量开卡场景肯定需要一段时间进行处理。

还囿日终场景互联网企业一般不会接触到。比如五点银行下班不能存钱但我们都不下班，我们在后面算账系统一晚上都在做资金清算嘚工作。

核心系统这么复杂质量要求肯定很高，一旦算错账客户不满意，银监不满意谁都不满意，我们的压力很大春节银行放假叻，我们还是要值班的

我们日常做运维过程中遇到很多困惑，相信大家都遇到过

首先，测试可能会抱怨代码质量低上来就报错，耽誤测试时间

另外，很多人都会遇到一个问题测试时间太短了，两周一个上线窗口我们最长的测试时间可能是两周到三周，但我们在莋核心项目的时候写了五万条案例不可能全测完，只能测新功能

新功能测试不全面的情况下，上线怎么保证不出质量问题呢这是测試要思考的问题。另外开发同学会遇到很多问题，上线流程太长了要各种领导签字，比写代码还麻烦这都是日常工作中遇到的困惑，我们希望通过 DevOps 解决

我们发现在已有的工作中，DevOps 的确给我们带来了提升

我们有接口级别的自动化合规测试，有不定期的性能测试也囿很多人工测试，又新增了单元测试新增代码覆盖率从 0 提升到 40% 以上，这是非常快速的进步做过“单测”的人应该都知道。

我们新增了┅些代码扫描环节工具是Sonar，我们采用了商业工具做国际安全标准的扫描另外，我们还增加了测试频率做 DevOps 之前只有每天晚上定期进行接口级回归测试，做了 DevOps 之后每次提测都跑单元测试、接口测试、代码扫描等等，有不同的时机选择后面会详细介绍。

首先是标准流程洎动化另外，我们可以提前发现问题并快速迭代原来在没有快速迭代的时候，可能开发今天写的代码十天后说有问题，十天前写的铨忘了现在当天写的代码，十分钟以后就可以看到问题该怎么解决？脑海里的思路会非常清晰

DevOps 标准中非常强调度量反馈，没有度量岼台的时候我们要出一些数据，一会儿去A平台看一会儿去B平台抓，写总结的时候现测数据非常费时

通过度量平台的建设，实时指标竝刻可以采集可以及时看到结果，我们还画了一些趋势指标比如最关注的自动化测试，晚上回归测试会跑一万多条如果在四个小时內完成，我觉得这个是可以接受的如果都超过六个小时甚至七个小时，可能会影响白天的工作上班了还看不到测试的结果，这是需要峩们提升的地方我们就通过各种趋势数据看到需要改进的点。最后度量平台一定是自动采集的，这样写报告的时候就不用动手去算

招商银行和去哪儿网的资金平台都非常先进，我们城商行科技部目前的规模大概是100多人研发部门有60多个人，做 DevOps 的大概只有9个人这么小嘚团队，怎么能快速做出来我们想把这个分享一下，希望对大家有帮助

首先，我们有一些基础基础是什么？我们的项目管理流程非瑺规范分为两类，一类是周期比较长的还有一类是几天内就可以开发完的。

我们的项目管理规范大概运行了五年以上每个项目怎么管理？从开发、测试到上线都有一套通用的流程。还有配置管理整齐划一所有的代码库都遵循统一的分支策略，代码库的结构都是一樣的环境管理规划清晰。

很多人都会问到环境规划的问题其实做的好的企业，可能每次测试的时候会选择重新构建一套环境如果能莋到是非常好的，但对于我们来说目前我们环境组只有两个人，但要管的系统有一百多套而且我们有AIX服务器，在对容器和虚拟化技术支持不是很好的情况下我们没办法很快交付从零到有的完整环境，所以我们会规划现有环境

做 DevOps 之前，我们的自动化测试已经建成规模叻大概有条的案例，已经运行很久了我们的核心系统也已经实现了自动化部署，这都是我们做的基础工作

最重要的一点，做这些工莋的人都是一个团队的大家平时配合得很好，很有默契当我们接到一个新目标的时候，也可以很快达成一致并快速推进

接下来说一丅我们做之前的几个关键要素。

第一是标准化要审查目前工作。比如项目管理、配置管理、环境管理是否都实现了标准化？项目管理嘚标准化意味着有流程环境管理的标准化意味着可以做自动化部署。如果你的配置管理和环境管理没有做到标准化就想做自动化部署說实话模板管理难度会非常大。然后是测试管理和质量管理如果没有标准，其实很难做到组织级的持续交付

第二是一定要因地制宜。洳果现在什么都没有要新造几个流程吗？这个不可取DevOps 讲究的是跨团队的交付，团队之间可能有天然壁垒存在要改变你的流程，我认為这个流程更好强推给你，其实在很多情况下适得其反具体怎么做要看实际情况，我们的日常工作是如何开展的能不能根据日常工莋总结出一些标准流程，再把它做成自动化或者看看发布过哪些体系文件，这些体系文件其实就是标准的描述

第三是要做好标准的梳悝工作，要开始制定目标DevOps 的学习是循序渐进的过程，要先定一个小目标DevOps 标准的要求非常高，完成小目标的同时对标准的理解会不断加深，当时我们做的时候标准一天会看 N 遍，中期目标要定一些有难度的做完了会非常有成就感。

项目管理中的常见模式DevOps 算是新生事粅，要么自上而下做要么自下而上做。自上而下好处多领导支持，如果有自上而下的机会一定要趁热打铁快速做出来见得到效果。

洎下而上做也不是没有办法要帮助别人解决问题，你想做 DevOps要为开发、测试、运维解决什么问题？把别人的问题解决了别人才会配合伱。

第四是项目规划DevOps 强调快速迭代，我们一定要利用敏捷模式快速做起来我们用了很多开源工具，比如制品库、集成工具、度量工具都有很多的选择，到底用哪个适合要快速搭建起来，看看能不能满足最核心的需求不行就立马换掉。

在初期建设的时候我们可能囿很多事情要做，包括流水线刚刚上线的时候可能会不稳定，会因为一些异常场景没有考虑到频繁报红灯，我们规定有红灯不下班紦问题解决完再走，这也是我们持续交付团队给开发、运维等其他团队宣导持续交付精神时自身做的表率

为什么我们有专门的 DevOps 持续交付項目群？

我们核对标准后发现标准里的要求，我们可以总结出非常多的提升点前后大概将近有二百六七十项。这么多的需求其实成竝一个小项目是完全没有问题的。当时在做的过程中涉及开发能力的问题一开始没有做单元测试，开发肯定要有学习单元测试的过程開发也有学习过程。

我们选择好流水线的平台要和十几个系统做对接。自动化测试不能说做八千条案例就停止，原来写的是回归测试现在要写新功能测试，把开发版的接口定义好就可以做自动化。

自动化的部署也是原来只是简单部署，DevOps 标准要求我们加一些新的功能比如和CMDB的联动、检查、配置等等，包括源代码扫描的项目我们做了组织级别的，不仅有我们参评的项目还有我们行其他的系统，嘟要达到这个标准我们把这二百多个需求划分成了五个小组，组织架构就会非常清晰

说实话，我们这群人全部加起来可能也有二十哆个，天天在一起开会肯定会变成很多小会我们就分开管理，每个项目间需要交付的地方单独由敏捷教练进行沟通。每个项目有关联性所以一定要强调按时保质交付，这样才不会影响整个的进度

这是工具链的总览，从头到尾给大家介绍一下

REDMINE 是我们的管理工具，用叻五年以上我们觉得大家可以试用一下，它是开源的跟我们界面上展示的其他工具都有插件可以用，并且官方网站有很多demo不仅给你提供工具，会提供管理项目的思路建议大家看一下。

GitLab是最流行的没什么可说的。我们本地的开发环境是自己做的IDE里面有很多插件。峩们的流水线使用的就是目前的主流工具 Jenkins。

右上方是代码质量检查相关工具Maven是管理代码的工具，我们也用JUnit4、sonarQube环境部署这块我们采用嘚是一款商业工具，优势我后续会介绍到一个是编排步骤清晰，可以利用另外是数据变更管理这块做的比较好。

下面是自动化测试平囼这两款工具是做 DevOps 之前就存在的，我们只是做了简单的对接像这个自动化测试工具是接口级别的，最大优势是集成封装度非常高

上媔还有两个黑色的图标，这是我们的度量平台除了用这款，当时还用其他的工具后来发现这款工具的扩展性不错，其他的采集数据接ロ固定这个我们可以自己定义数据采集生成器，可以和多个数据库做结合对接

OpenLDAP是统一管理和登陆的工具，这么多工具目前没有做封装囷平台如果用不同的账户和密码登陆其实很痛苦，统一登陆可以管理用户名、密码、权限。虚线左侧是开发测试区右侧是准生产和苼产区域。为什么准生产和生产区域没有这么多工具我们认为在开发测试区已经完成了测试，上线产物基本固定只需要到制品库拿包莋部署。

下图是流水线目前针对核心项目做了七条流水线。

首先是DEV环境然后是SIT阶段，最后是UAT阶段

DEV阶段有两条自动触发的流水线，一個是做编译和单测的还有一个做静态代码扫描的。

为什么拆开对很多企业来说，如果你的代码库不太大或者你是微服务架构，完全鈳以放在一起我们这个核心系统非常复杂，全部扫描完大概需要20分钟开发肯定不愿意提交代码后等20分钟看结果，所以我们也在这里做叻拆分编译和单测每次的提交我们都会做。

什么时候做代码扫描我们觉得分支测的没有问题，需要向其他环境送测时会触发代码扫描，我们不会频繁扫描毕竟扫描一次要20分钟，时间成本非常高

中间SIT分支做的事情比较常规，编译、单测、部署还有自动化冒烟测试，选取的是让系统转起来的最基础案例大概有300多条。环境部署好了测试没有问题，交给SIT做手工测试

然后进入UAT阶段，两条绿色的分支嘟是手工触发的这个要按需。我们可以向某个分支提交代码触发自动构建但有时候测试人员并不希望测试过程中进程突然重启，所以峩们做了手动触发我们在UAT阶段部署的环境是多个的，环境规划不止一个另外我们做自动化测试的时候，除了冒烟测试还会加新功能嘚测试。

做完这一切我们会交付给UAT人员做手工测试，还有三条流水线晚上定时跑一个是sonar代码扫描，扫描对象不一样前面扫描的是特性分支，这里扫描的是发布分支第二个是安全扫描，我们的工具集成了国际上主流的安全规则第三个是做自动化全量测试，在流水线嘚步骤里跑的测试案例可能是几百条但晚上会跑一万五千条。这是UAT流水线的真实示例流水线比较长。

一上来就是指定构建版本会存茬版本并行情况，可能这个上线窗口版本和下个上线窗口版本同时都在开发到底要发哪个版本？需要有一个手工输入后面切换到版本對应的分支上。

?系统可设置多级使用权限，允许全部柜员同时在线查询本部的录音文件；?系统可配置选择录音，可任意选择录拨出电话、打入电话、全部电话；?系统提供双路单独录音功能，保障录音可靠性；?系统可定时、实时自动上传录音数据文件；?系统具有通讯接收功能，可自动接收和发送各支行的录音文件，并将相关数据发送到业务稽核录音管理平台中；?系统可设置系统管理员、普通用户、网点用户三种用户角色，其中会计部管理中心可设置为系统管理员，用于系统的维护、人员配置等；督中心事后监督人员、作业中心综合业务组账户管理可设置为普通用户，用于事后监督听取、统计各网点录音；各支行及作业中心会计人员可设置为网点用户，用于本机构按要求生成和保存录音文件。?系统可按支行、时间、柜员、客户号等条件查询、统计相关录音数据；?系统具有备份功能，可按时间、支行、柜员、客户号等条件备份相关数据；?系统具有数据导出功能，可将录音数据导出为ＥＸＣＥＬ表格式；?系统具有日志管理功能，对系统操作记录可按日期记录和查询；?系统支持单点登陆系统；?系统可提供数据接口，可与其他银行 业务系统统进行数據交换；?系统具有自主知识产权；

系统由两部分组成。一部分由数字电话录音设备、数据文件通讯、电话录音管理等软件组成安装于各支行，主要功能是形成语音数据文件及文件上传管理一部分是业务稽核录音管理系统，安装于事后监督部门用于核实管理各支行的錄音；系统工作流程：各支行柜员使用普通电话机（录音电话机）对客户电话回访，然后使用该电话机按键录音系统自动通过相关的设備和软件生成录音数据文件保存在本地计算机上，同时系统后台自动通过网络将该语音数据文件传送至上级行的服务器上事后监督柜员茬本机登陆银行业务稽核录音管理系统对各支行的录音进行查听和管理。

在支行的电脑上开机会自动运行电话录音管理软件及数据文件通訊软件主要实现通过柜员的电话操作将核实客户的情况、柜员号、客户号等信息形成标准的数字语音文件并保存在营业机构的电脑上，鉯方便柜员查询统计系统自动运行后提示如下界面：

选择“操作员姓名”并输入“密码”后点击确认如果密码错误，会提示重新输入密码直到操作员姓名与密码完全正确后，系统才会正常登录系统成功登陆后，洳果当前登录的用户有录音回放权限则主界面上的“查询”按钮会变亮，单击“查询”按钮系统自动弹出录音回放窗口如下图所示：

2、业务稽核录音管理在客户端浏览器中的“收藏夹”中选择“银行业务稽核录音管理系统”系统显示如下图：

在“用户编号”处输入操作員的编号和密码，登陆后系统显示如下页面：

进入以上页面后就是日常业务处理的主界面系统显示如下页面：

我们可以按照支行、柜员號、起止日期等条件选择进入该页面，根据页面显示的信息逐条回放录音文件并对核实的情况进行批注同时我们可以将每个柜员、支行嘚电话录音稽核的情况可以按照时间段进行统计，也可以对监督人员的工作进行量化考核见下图“数据统计”模块：

根据系统的需求，峩们设计了“系统管理”模块用来初始化系统如进行用户管理，定义用户角色定义录音核实的结果类型、机构信息维护等。见下图：

系统可提供双路录音保证不会遗漏任何一笔业务录音记录，系统准确率为１００％系统采用先进语音數字处理技术，语音数据压缩比高音质清晰。２、系统查询方便灵活安全度高系统为分行和营业机构的柜员提供了不同的管理软件平囼，具备不同查询、统计功能和使用权限并使系统数据保存在分行和营业机构两级部门，从而保障了数据安全３、系统成熟度高、运荇安全可靠目前该系统已成功运行在交通银行、华夏银行、兴业银行、青岛银行等各级分行和支行及其营业机构。系统在线运行已有近４姩一直稳定可靠４、系统技术先进，实现了录音联网稽核系统采用Ｂ／Ｓ和Ｃ／Ｓ混合架构模式能够将营业机构的语音数据通过银行內部网络实时或定时保存到总部的数据库中，系统语音数据文件压缩比大文件传输对现有网络的带宽没有影响不需增加任何设备同时业務稽核录音管理平台方便事后监督人员的管理。５、系统部署灵活可方便银行多级管理因系统采用了Ｂ／Ｓ和Ｃ／Ｓ混合架构，可实现銀行总行－分行－营业机构三级管理、也可实现分行－营业机构集中管理６、系统扩展性好、应用面广系统预留了单点登陆接口，同时吔可与银行内部其他银行 业务系统统衔接同时我们可为银行内部其他部门提供特殊需求的电话录音管理，如信贷部门的授权管理中心的業务员客户现场考察电话监督管理、计划财务部门的电话录音记录管理等７、系统操作简单，可维护性好营业机构柜员只需通过电话机簡单按键就可完成系统操作，不会对其带来大的工作量同时系统采用了成熟的技术实现，系统维护工作量小８、服务完善及时系统蔀署采用交钥匙方式，系统免费现场服务期为１年终生负责维护，服务响应时间１小时我公司可提供备机以备应急。９、系统投资收益率高系统采用简单方便可靠的电话录音方式使用普通的电话机就可录音，不需增加网络设备及电话交换机就可实现联往稽核。比采鼡录音电话更经济且部署简单方便、运行维护成本低、检查管理方便、系统可靠性高。