中国银行DevOps历程、 效果及展望

白凡

讲师 | 张新
编辑 | 白凡

今天很荣幸能跟大家一起分享作为传统金融行业，中国银行在DevOps应用上整个建设的过程，取得的一些成果和未来的规划。
整个介绍分为五个部分：

• 第一，目前的背景
• 第二，整体的建设过程
• 第三，中国银行特点的DevOps体系
• 第四，取得的效果

第四部分我可能会给大家分享一下实践过程中遇到的实例，在这些实例分享中看看能不能给大家起到参考和借鉴的作用。

1. 背景

其实中国银行和所有软件公司一样面临的问题最主要的矛盾就是产品的交付速度不能够满足业务部门日益增长的需求。我们也一直在做各种转型，我们在做敏捷开发，敏捷转型，但是敏捷开发和转型还是关注在开发和测试阶段，还是没有把运维打通，仍然关注在开发和测试的过程中，没有实现端到端的交付。

中国银行本身产品业务种类比较多，产品的架构也比较复杂，其实各个领域部门也都很大，有开发、测试、运维，版本的安装、环境的管理，系统管理等等。其实每个团队他们都在自己的局部在做改善，在做改进，在做优化，但是这些点上的优化不能够对整体的交付速度产生很强烈的影响，不能够很快速的完成版本的交付。
其中我们还有一些特点，第一个系统接耦合。各个子系统之间的耦合度比较强，尤其后台的系统跟其他的外围系统都有关联，核心系统存在问题会影响整个全局的交付速度，所以会影响版本的发布。
我们在开发和测试阶段用的自动化工具比较少，而且这些过程还不是很标准，也不是很规范，所有的问题都会遗留到集成阶段，到了功能测试环节的时候会存在很大的问题。这个时候问题发现的阶段很滞后，会影响到的成本和效率。

在运维的过程中，在功能测试和生产环节里边，因为我们的环境很多，因为产品有几百个，涉及的环境也比较多，尤其是环境还不一致，开发环境和测试环境本身不一样，测试环境和生产环境也不一样，功能测试环境本身就有很多套，几百个产品，每个产品都有五套环境在并行着用。所以环境管理的成本也很高，各个环境里边产品的部署都采用手工的方式，效率也比较低。
我们存在的问题可能跟大家比较类似，都集中在设计和开发阶段，第二，测试阶段，第三，运维阶段。根据我们存在的问题我们也想到了现在业界最流行的软件开发实践DevOps，从开发到测试到运维，有融合和协作。
我们的DevOps跟互联网也不会一样，因为我们业务种类比较繁杂，有传统的，后台的，银行类的，还有前面变化比较快的，互联网金融类的业务。主要的技术架构也是有两种，一种是传统的集中模式，还有一种是分布式的架构。
我们在做我们DevOps建设的时候不能只考虑前面，也不能只考虑后面，DevOps既要支持传统的，集中式的架构，又要支持分布式架构产品的应用。

2. 建设历程

中国银行DevOps建设总共经历了四个阶段：

• 第一个阶段是2009年到2011年。所有四个阶段都是根据相应的问题，根据相应的问题找到相应的解决方案。第一部分09年到2011年这个时候中国银行当时正处于蓝图建设时代，在蓝图建设的时候大家全扑上去做一件事情，任务很多，版本、产品都比较混乱。当时为了解决这种局面一定要把任务管理起来，要把每个产品的版本管理起来，同时要把每个产品的版本和对应的任务在开发、测试、生产的环节也要建立一对一的关系。所以在第一个阶段完成了中国银行全生命周期配置管理系统。

• 第二个阶段是2012年到2014年，在这个阶段因为蓝图建设积压了很多业务部门的需求，这个时候业务部门就要求我们的业务迅速的上线，要求快。所以这个时候我们就在开发阶段引入了持续集成，在版本的组包、构建、代码复查、部署，形成了相应的规范和模型。2012年和2014年完成了软件中心所有产品在开发阶段的应用。

• 到了2015年和2016年中国银行又迎来了变革，这个时候的变革就是我们的机构整合了。测试中心作为一个独立的存在并入到了软件中心来，这个时候测试上存在的这些问题就迁移到软件开发的过程。这个时候我们就要把技术往后，延长到测试阶段，完成了功能测试阶段的交付应用，实现了产品在不同环境下部署的应用。同时对原有的模型和规范，和成熟度模型进行进一步的优化。

• 去年年底到2017年这个阶段主要是DevOps应用阶段，这个时候我们面临的是主机的下移，分布式架构的兴起，运维人员面临更多的问题，因为分布式架构运维的时候机器很多，管理起来、部署起来就会存在很大的困难。这时候我们要把生产环境的自动化部署和运维监控纳入到整体的建设来，这就是我们第四个阶段，就是DevOps应用的阶段。

3. 中国银行DevOps体系

基于这个模型的建设，首先是基于精益管理的思想，采用了相应的工程方法，有敏捷管理、持续交付、IT运营管理。在基于工程和方法之上我们建立了自己的交付流水线，其实就贯穿了从需求到运维，到反馈，整个端到端的过程。
在流水线上我们有相应的实践，包括任务拆分、看板、集成和代码的管理、部署和发布。所有的实践离不开工具的支撑，我们采用了自动化的工具，包括开源和外购的，我们自己开发的一些工具。在这些建设上我们最终形成了相应的一套DevOps应用流程和规范，通过这些流程和规范来促进开发、测试和运维，一起来完成交付流水线。
针对我们的问题在开发、测试、运维都存在这样的问题，要解决这样的问题要用体系化的实施方法，我们在基础架构上要做基础架构的自动化，要对应用架构也要做改善、迁移、结耦。任务上我们采用了精益的方法、看板，通过标准化、自动化和可视化形成了相应的规范和模型，促进了各个团队之间的协作。最终的目的也是实现快速的价值交付。

在任务上生产任务看板的实践，在流程上以标准化、自动化、可视化为原则，形成了相应的体系和规范。这个流程纳入了中心体系文件参照执行的。在组织上主要是通过流程的建设促进大家进一步的协作和融合，同时我们也形成了中国银行评价模型，DevOps应用成熟度评价模型，来实现我们在这个领域上的持续改进。应用架构上我们有技术结耦和主机下移。

基础架构上实现了X86架构虚拟资源自动的申请和注销，对容器的技术进行了研究，并且形成了相应的使用规范。最主要的是形成了三条交付流水线，是我们整个DevOps应用核心的建设，同时我们也进行了容器技术的研究。

中国银行DevOps的建设依据刚才的分解，我们是围绕这五个方面：

• 第一个是做流程体系，要建立统一、协作的流程，通过流程我们实现在开发、测试和运维各个团队之间密切的合作，打通我们的交付流程
• 第二，模型和规范，根据前期做的经验，我们把所有软件开发过程中遵循的规范、规则和要求写到相应的规范文件里边。同时对于X86这条线的产品，DevOps应用怎么做，我们形成了相应的模型，模型和规范中心内进行发布和执行。
• 第三，交付流水线，在交付流水线上我们把开发和测试阶段上用到的技术往后推，让他们在生产环境进行复用，不断地优化我们的自动化部署和自动化测试的资产。同时要把代码复查和安全方面的软规范的要求也集成到交付流水线中去。
• 第四，度量评价体系。
• 第五，文化环境，我们通过组织各种活动，包括跟高校运维社区的活动和内部的活动，把各个相反方都撮合在一起，形成了比较融洽的文化环境。

4. 实施的效果

4.1 统一协作流程，促进融合协作

中国银行数据中心是负责运维的，软件中心主要是负责开发的，软件中心里边有开发群主和测试群主，数据中心主要是系统管理和维护。DevOps应用上主要形成了统一的工作组，采用了两个实施方针，要管理上强调融合，强调协作，技术上要通过标准化、自动化、可视化的手段来实施统一的协作。有些流程里边牵头的部门是做配置管理的团队来负责做这些事情，管理部主要是做中国银行DevOps的设计和规划的。同时要去协调、开发、测试和维护相关的团队和成员按照这个计划和方案实施相应的流程和测试的工作。

4.2 建立DevOps应用模型和相关规范

另外搭建了整个中国银行集成应用的平台，并且形成了相应的应用模型。开发群组在交付流水线的基础上根据自己部门里边的产品，因为每个开发部都有很多的产品，看看适合哪种的应用模式，按照相应的应用模型和规范实施持续集成的应用，通过对自动化部署流程的定制来提升部署的效率。同时也在单元测试和主观测试里边进行自动化测试的应用。

版本安装团队主要负责的功能测试管理，因为刚才说了功能测试环境非常多，产品也很多。专门有一个团队是来负责功能测试环境部署的，要提出对自动化部署的需求和改进的建议。同时要对功能测试版本的产品自动化部署的流程进行应用。这是它的主要职责。

维护群主要提出在生产环境里边自动化部署的一些需求和改进的建议，同时要实施在生产环节版本的自动化部署，而且要协助提供流程建设里边所需要的软硬件的资源和网络的环境。这是我们整体的协作组织。
刚才说到开发、测试和运维相关的过程里边都形成了相应的技术规范和相应的应有模型，为软件开发中心里边所有的产品来提供DevOps应用技术的指导。这些文件都作为体系文件，纳入到我们中心的体系文件里边进行发布。

为了流水线的畅通和快捷，我们也进行了工具链的建设。在工具链的建设中，在代码管理、变更管理、部署、测试、代码复查等等领域一共大概用了90多个工具，包括开元、自主开发，建设的相关系统有三个系统。

4.3 打造中国银行特色交付流水线

我们建设了三条交付流水线。中国银行业务类型比较复杂，根据我们的分析分成了三大应用产品：

• 第一类应用产品基于AIX系统应用产品，我们建立了AIX交付流水线
• 第二个核心银行系统所应用的产品，我们也建立了基于ZOS的交付流水线
• 还有就是基于X86架构的产品，一共是三条交付流水线

这三条交付流水线贯穿了从需求到构建，到开发，到代码复查，到测试，到功能测试环节，一直到生产整个过程。我们是通过版本在流水线的流动也搭建了数据中心和软件中心之间的桥梁，让部门之间的协作更加融合。右边这个图说的是我们的部署系统，在流水线里边我们的部署系统是我们的核心，这个部署系统在开发过程中主要是跟我们的构建和组包的工具是相关联的。在开发完成了以后，我们形成了相应的执行码以后就会直接把包传送到我们的部署系统里边去，通过部署系统进行自动的部署，然后部署到我们的开发环境，然后进行后面自动化的单元测试和内部测试。

在功能测试环节，我们开发人员完成了代码提交，提交到配置管理系统以后，配置管理系统会经过相应版本的审核，审核完成了以后会自动的推到相应的部署系统，部署系统会自动的在功能测试环境进行部署，部署完了以后进行相应的测试。

这是在开发和测试过程。到了数据中心以后，我们这个版本通过两边的协作建立了通道，我们的版本可以通过软件中心的产品库推送到数据中心的版本发布平台。在这里部署系统就和数据中心的版本发布平台进行关联，版本发布平台收到了版本以后会自动的推送到相应的部署平台上去，在演练环境里边进行自动部署，部署完了以后会有一个业务验证性的测试。

这里边演练和生产中间，它俩之间网络是不通的，这个版本是从这儿推到演练环境的部署平台，演练和生产之间的桥梁这儿就结束了。后面是在另外一个网络里进行的，因为金融系统对安全的要求会更高一些。在宣传环境里边，对用户安全管理要求非常高，部署系统会跟用户管理系统做一个对接，然后自动的管理我们要部署的目标环境用户，自动获取，然后进行自动部署。

4.3.1 版本推送

原来版本从开发部门提到产品库以后会做相应的合规性检查，检查完了以后会放到相应的产品库地址上去，并且同时会内部发邮件到数据中心的调度团队。调度团队收到邮件以后会取出版本，也要进行版本的合规性检查，因为他们对版本有另外一套规则的验证，如果检查合规的话就会放到数据中心的版本服务服务器上去。

实施DevOps流程以后，通过互相的工具改造，流程进行了精简和优化。我们把在数据中心做版本检查这一块的版本检查点前移到前面去，移到了开发中心的版本检查点，我们就不会因为他检查的不合格，使得版本的回退这种事情的发生。这前面也都是自动化的完成，检查完了以后自动把版本推送到了演练环境的部署平台。

在这里边涉及到的几个工作步骤：

• 第一个依据版本的标识会把版本从软件中心自动的推到服务器上，因为生产和演练是不连的，所以要放在中间的桥梁上。
• 演练的部分直接推送到演练对应服务器指定的地址。我们要把版本再推到生产环境的相应指定位置
• 第三，平台自动获取版本，会找相应的生产环境对应的版本，拿到部署的平台上去。

另外要分享的点就是WAS这一块，手工模式部署拿到的普通用户在控制台上的操作，这个时候我在控制台上做WAS部署就可以顺利的完成。采用自动化流程了以后我们的第一个方案是通过部署平台来实现目标环境自动化的部署。通过第一个方案需要普通的部署用户拥有根目录下的权限，有几个文件是需要权限的。后来这个方案拿到了总行和数据中心安全团队进行评估的时候被否定了，权限会有漏洞，安全是第一位的。
所以第一个模式就被打回来了，其实第一个是最高效和最快的，但是因为有安全的隐患。后来WAS专家们在一起又商量采用了第二个方案，在目标环境和部署系统之间增加一个堡垒机，部署系统通过WAS的堡垒机向目标环境进行WAS的部署。

在这个方案里边我们也进行了反复的验证，里边遇到了很多问题，WAS堡垒机的版本和你要带部署目标环境一定要在大版本保持一致。如果目标环境是8.0，这个一定得是8.0，如果是8.5就不行。这之间要有匹配。如果你的目标环境WAS版本非常多的话，这个堡垒机今后维护起来就是一个问题。第二个问题待会儿再详细讲，WAS本身有很多的坑在里边。

4.3.2 流水线-自动化测试

我们在流水线建设上还有一些自动化测试的应用，在自动化测试的应用上主要建设了自动化测试的平台，通过运用自动化的工具，主要开展了以组装测试为主的，并且涵盖了代码复查和性能测试等多种测试能力。同时也建立了分级的测试体系，有组装测试、功能测试和验证性测试。根据我们的交付流水线我们也建立了不同的应用模型。

自动化测试在流水线上的目标，其实是想通过自动化测试平台的管理功能，利用前期积累的自动化测试脚本资产，希望把自动化测试推到我们的演练环境和生产环境中。因为在演练和生产结束以后没有自动化验证的手段，除了部署的验证以外其他都是靠人工的，维护人员对这一块也提出了相应的需求。我们今年的目标就是要把自动化的测试在演练环境进行应用，主要是涉及到系统级的和业务级连通的验证。

这里边涉及到的工作流程是这样的：

• 首先需要在演练和生产环境单独搭一台自动化测试的平台，相应的数据库和存储
• 第二，需要我们准备相应的自动化测试案例，这些自动化测试的案例有很多流程方面的东西根据版本下发到相应的数据中心。
• 第三还有自动化测试版本的维护，因为这里边有很多会员的信息和帐户的信息需要单独维护。
• 第四步要做生产数据的恢复，自动化部署以后自动的调起自动化测试的平台，执行结束以后会把相应的结果展示在平台上，如果有问题进行检查和验证。这是自动化测试在演练和生产环境的应用。

4.3.3 流水线建设

基础架构的自动化，基础架构自动化主要是集中在开发环境的应用。随着转型和下移的产品越来越多，对虚拟化资源的要求越来越多，造成效率的降低。因为原来的申请都是通过流程，一层一层的审批和流转。现在我们创建了自动化申请平台，通过这个平台可以自助的申请开发环境所需要的资源。 通过这个可以精简审批的流程。开发团队可以按需申请资源，用完了以后可以及时的释放出来，可以提升整体资源利用的效率。
资源管理部对这些资源的使用情况也会比较清楚，为后续的审计和决策起到帮助的作用。这是基础环境自动化。

4.3.4 应用实例自动化部署

应用实例就是自动化部署系统投产的应用场景。在投产前的两到三日我们把自动化部署平台在生产环境完成了相应的搭建和版本的准备工作，在投产当日我们实施了相应的自动化部署，进行了部署的验证，第二天对它进行相应的业务验证，标志我们整个部署系统正常。
在这里边也遇到了一个小的问题，刚才说到也是WAS本身8.0和8.5系统的问题。我们做WAS部署的时候第一步要先做WAS的备份，备份的方案选择全量的备份方案，如果有一个架包里边含有某个文件的时候，自动的导出会失败。这个架包是怎么产生的？上一次部署生成以后系统会自动生成，这两个版本才有这个问题。这是我们当时遇到的问题。这一块部署上我们还存在很大的优化空间。

今年最需要关注的重点就是四个方面：

• 怎么样实现版本无缝的对接，两个中心之间流水线上自动的推送。这是比较重要的环节。
• 第二，要满足生产上用户安全管理，我们现在因为数据中心对所有生产环境的用户要求非常高，我们部署的用户和目标环境在部署系统里头怎么纳入到数据中心一体化统一管理中。
• 第三，我们的WAS部署，刚才介绍WAS部署的方案我们觉得还不是最优化的，后面我们还要对这个做进一步的优化，因为现在堡垒机太多了，今后维护起来是一个很大的工作量。
• 第四，自动化测试，现在应用的场景还是集中在开发和测试阶段，在部署以后生产环节的应用不是很多。这也是我们后面要关注的重点。

4.4 多维度的度量和评价体系

主要涵盖了我们在开发过程中的构建过程、组包过程和部署，代码复查和测试等等过程，然后衡量每一个过程成熟度的水平。跟今天上午做标准的一样，我们也是定义了几个能力等级，我们涵盖的范围要少一点，没有应用架构，没有基础架构，没有组织建设，还是这些工程系统里边的能力水平。

4.5 建立DevOps文化

通过DevOps应用，通过流程的建设还是要建立这样的文化，要把这种理念渗透到开发测试和运维每个相关人员里边，把内化为一种行为习惯和责任意识，促进我们团队的协作，让大家能够建立起共同的目标。

我们也组织了很多的沙龙活动、论坛活动和技术交流活动，包括外面的活动，和相关的人员一起把交互流水线做得更加完善。

5. 未来展望

未来我们还是依据整体体系化的方法，会在基础架构、流程建设和流水线的提升上，包括在团队协作上进一步的完善中国银行DevOps应用的流水线，为中国银行的业务发生助力。