一、背景

2021年上半年，我行的新核心银行项目建设到了关键、紧要的冲刺阶段，1个新核心银行系统、1个新柜面系统、100余套外围系统需要同期上线。在这次大规模、集群式上线中，各系统间关系复杂，投产窗口有限，操作步骤繁杂。如何有效提高效率、确保版本变更100%成功率、压降操作强度和风险，成为我行新核心项目的一项重点工作内容。

版本变更自动化投入使用前，我行各业务系统版本变更以手工操作为主，其存在以下问题：

1）版本变更操作复杂

绝大多数系统的版本变更包含程序上传下载、备份、服务启停、程序更新、配置文件修改、数据文件更新、投产后技术检查等操作，操作比较复杂。

2）版本变更操作耗时长

由于各业务架构复杂，服务器数量多，每个系统每次版本变更需耗时1个小时以上，耗时长。

3）版本变更人员投入颇大

出于版本变更成功率控制及风险管控，95%以上的变更都是在变更窗口期进行，时间紧、任务重。在短时间内，每套系统的变更需要执行人和复核人共同完成变更还需要对他人的操作进行复核，工作强度大。

4）版本变更技术检查落实不到位

版本变更完成后由由系统负责人根据经验进行检查，可能会因为工作强度大、服务器数量多而导致个别服务器的技术检查不到位。

二、实现目标和实施方向

实现目标如下：

1）落实多次新核心周例会要求，实现至少100套新核心银行建设项目涉及系统的版本变更自动化；

2）落实疫情常态化防控要求，大限度降低操作人员的聚集密度。

项目实施方向如下：

1）实现变更流程标准化、自动化，从投产程序包版本校验、备份、更新到技术检查，全流程实现自动化，应用负责人在平台进行复核确认，降低版本变更工作强度。

2）提升版本变更操作水平，降低版本变更过程中人为操作风险。

3）实现变更流程规范化，如投产程序版本检查、技术检查均作为变更流程的关键环节自动进行，降低版本变更风险。

4） 提高版本变更效率，缩短版本变更耗时。

三、技术实现

1、逻辑架构

其逻辑架构如图1所示：

图1 变更自动化逻辑架构

变更自动化由目标服务器、数据存储、客户端应用、Agent远程代理等部分组成。

1）用户层：基于系统提供的如流程设计、版本管理、变更管理、权限控制等调度功能，提供了3个重要的工具允许开发人员及管理员进行变更流程设计、变更调度及变更过程监控。

2）业务功能层：应用系统通过代理Agent，根据业务关系进行分组管理，通过调度接口，执行具体的作业任务，实时监控作业情况，及时将变更步骤的作业信息及日志反馈给版本变更自动化调度服务器，终由客户端进行操作、监控、管理。

3）系统核心层：具备调度集群、心跳检测、负载均衡及失效备援等高可用机制。

4) 受控系统层：实现版本报下载、投产校验、程序备份、服务启停、程序变更、配置文件修改及变更检查等综合应用功能。

2、功能说明

2.1 版本下发功能

根据变更单号自动将版本下发到目标服务器指定路径。

变更说明包含系统、月度版本、特殊需求编号、发布日期等信息，后续可通过版本号追溯版本或提供统计信息。

2.2 应用程序部署功能

1、实现应用程序自动发布功能

版本变更自动化流程具有通用及易用性，在某一应用系统部署流程发生变更，或新上线其他相似架构系统时，可以迅速复用到新系统，无需进行二次开发。

可根据参数配置实现按单台或多台服务器进行应用程序部署。

可设置定时任务，定时发起流程。

2、应用程序下载功能

可与SVN服务器或介质服务器对接，每次部署可直接读取指定目录下的文件，并下载至目标服务器。

下载完成后，通过MD5码校验下载文件完整性。

3、程序备份功能

可自动解析投产应用程序包，根据程序包增量备份应用程序。

备份完成后，将备份包的内容与程序包内容进行核对，发现差异进行提醒。

同一程序包多次投产，备份包需分别命名及存放。

4、服务启停

可根据用户需要进行应用程序服务启停，应用程序包含WAS、tomcat、第三方开发的应用。

启停完成后，进行启停结果的自动检查，发现问题进行提醒。

5、应用程序部署启停

可根据用户需要进行应用程序部署，应用程序包含WAS、tomcat、第三方开发的应用。

部署方式支持增量部署及全量部署。

6、技术检查功能

版本变更完成后，需强制性进行技术检查。

技术检查内容包含且不仅限于：进程状态检查、端口状态检查、应用日志错误码检查等。

3、技术方案

通过制定标准开发规范，对变更操作进行统一管理，根据开发规范，开发版本变更自动化流程及脚本，实现版本变更自动化。

3.1 版本变更自动化实现方案

开发规范的制定及落实，为版本变更流程及脚本的开发提供了标准及规范参考；要实现版本变更自动化，还需制定变更流程及脚本。变更流程囊括了应用系统所有的变更步骤及各步骤之间的逻辑依赖关系，变更脚本是实现变更步骤的具体操作。

（一） 变更自动化流程的制定

 为将各系统版本变更自动化纳入平台进行统一管理，将应用系统的变更自动化流程进行标准化。变更流程制定过程如下：

1、关联服务器变更次序的整理

 制定某系统升级流程前，需先调研该系统各变更服务器的关联关系，确定各服务器的升级顺序及各服务器升级流程的并发度。

2、升级流程的制定

系统不同，变更步骤却大体相同。为提高升级流程的通用性，使升级流程适用于每次变更，以便在实际变更中可根据需要选择执行。经梳理、总结，版本变更流程如图2所示。

图2 版本变更流程

（二） 变更脚本的开发

为使变更规范化、流程化，版本变更自动化对变更脚本进行了归类及标准化。

1、下载投产程序包脚本

下载投产程序包脚本分为三步：登陆FTP服务器、进入版本包目录、下载版本包到目标服务器。该脚本适用于所有的应用系统。

登陆FTP服务器，为保障数据安全性，统一使用SFTP方式登录。

脚本根据投产前平台配置的投产程序包的路径，自动进入文件服务器版本包目中。

脚本根据投产前平台配置的投产程序包指定路径，自动将文件服务器上投产程序包，下载到目标服务器上的指定路径。

2、检查投产程序包是否下载成功脚本

检查目标服务器的指定路径下投产程序包是否存在，判断投产程序包是否下载功。

3、服务启停脚本

对于特定启停脚本的系统，直接复用原手工升级的系统脚本，该脚本不具有通性。

对于有通用API服务启停的脚本，则将服务名称，路径等作为参数，该脚本具有通用性，可适用于一类系统的服务启停。

4、服务启停检查

服务启停检查可通过进程、端口、日志进行检查。

进程检查脚本，将进程名称，进程号等作为参数，脚本能适用于所有应用系统的进程检查。

端口检查脚本，将端口号作为参数，脚本能适用于所有应用系统的端口检查。

日志检查脚本，将关建字作为参数，脚本能适用于所有应用系统的日志检查。

5、备份脚本

全量备份：联合运维自动化平台配置，通过读取平台配置路径，将应用服务器指定路径下所有文件统计打包到备份路径保存，以备回退是快速使用。

增量备份：根据本次更新投产程序包解析现有应用服务器中存放路径后，复制到备份路径，并打成统一规范tar包。

6、应用程序升级脚本。

文件直接解包升级，直接通过调用解包命令，将升级包中的文件按照路径，覆盖目标变更服务器的原文件，或在对应目录下新增文件。该脚本适用于所有采用文件直接解包升级的系统。

7、检查升级是否成功

采用文件解包方式升级，可通过读取投产程序包中文件的更新时间判断更新是否成功。

8、变更后技术检查

变更后技术检查一般有进程、端口等检查。

3.2 版本变更自动化开发规范的制定

目前，各应用系统的变更步骤不相同，同一应用系统每次的变更步骤也不尽相同，各应用系统的备份、更新等步骤脚本也各有差异，若纳入版本变更自动化平台进行统一管理，则脚本开发工作量大，大规模推广困难。

为解决以上问题，推动版本变更自动化系统的全面推广，必须制定版本变更自动化开发规范，如下：

1、按系统分类（文件覆盖类、WAS类等）进行备份、更新、启停服务等变更脚本的标准化，使脚本具有通用性，减少重复开发，提高效率。

2、规范各应用系统的版本变更时的变更步骤，将技术检查等操作统一纳入版本变更自动化的范围，形成标准的变更流程。

3、标准化要求各应用系统的变更操作，以降低变更操作步骤对经验的依赖性。

四、创新点

我行新核心银行项目建设涉及100余套外围系统，各个系统已形成自己的发版方式，本着“不影响新核心已有发版方式、大程度兼容各个系统投产”的原则，对版本变更自动化进行了全新的设计，按照组件、模块、场景进行归纳整理，具备模块化、参数化、强兼容等特点，主要体现在以下几点：

1、投产作业流控和参数灵活设置，保证投产平台高可用性。平台以“灵活可配置”为原则，抽象出6类作业模板，根据每次变更程序资源动态配置对应作业流控。抽象出投产参数，通过参数配置实现当数据集发生变化后直接修改配置参数，不需要改动程序，大限度确保平台高可用性。 

2、流程形成闭环。只需登录运维自动化平台即可完成流程相关操作，流程操作分散到主机程序投产的各个环节，用户不需额外操作，减少了操作流程。 

3、变更流程兼容性。增加对各环节的裁剪、略过、禁用等功能，应变临时调整，增加服务器优先级设置，增加模板实例，为不同需求建立不同的模板实例。

4、变更流程敏捷性。变更流程的开发采用模块化方式，通过复制同类业务系统的变更流程，再经过简单的个性化调整即可上线。

5、投产记录可追溯。运维自动化平台设计了完善的变更日志与统计功能，详细记录投产各环节的操作人、操作时间和操作对象，并对变更实施结果进行保存。同时，设计变更统计模块，对各项变更分类进行统计汇总。

6、异常投产可回退。对于投产后出现问题的程序，设计开发了逆向的程序回退模块，便于快速进行程序回退。

五、项目难点及解决成效

版本变更自动化初期，面临系统架构复杂、环境差异较大、操作无统一的规范、应用负责人操作习惯不同等困难。经过摸索与实践，解决以下难点问题：

表1 难点及解决成效

六、成果

新核心银行系统项目历经8轮投产演练，通过对各系统手工部署方案进行梳理，历时两个多月，实现126套系统应用版本变更自动化，纳管设备429台。

图4 阶段历程

7月24日，新核心系统一次性大规模、“集群式”使用变更自动化进行投产，如此大规模使用，在同业中也属首次；变更自动化成功率为97.62%，投产平均耗时为542秒，与手工部署相比，平均节约时间92%以上，大大提高投产部署效率，为新核心银行系统上线节省了宝贵的时间，结果如图5所示；

图5  结果展示

部分系统自动化投产耗时与手动投产耗对比，如图6所示；

图6 投产耗时对比

以新核心银行系统为例，共16台服务器，服务多、服务器多，应用部署与服务启停有之间存在依赖关系，这导致手工投产操作复杂、执行时间长；经对手工操作方案进行梳理，综合考量各步骤间的依赖关系，整合为20个步骤，形成自动化投产流控，如图7所示；在新核心上线期间，共投产50次，平均耗时1072秒。

图7 新核心银行系统自动化变更流控

变更自动化实现了测试环境、投产演练环境、生产环境应用版本的自动化部署，保障了新核心银行系统顺利上线，为实现开发、测试至生产的DevOps一体化奠定基础；同时，可将运维中心日常自行发起的变更任务分类，针对每类变更实现模板化和标准化，通过运维自动化进行实施，进一步提高变更效率和准确性，降低操作复杂性和风险。