金融机构信息科技系统运行维护自动交付规范

金融机构信息科技系统运行维护自动交付规范

1范围

本文件规定了金融机构信息科技系统运行维护自动交付过程中的术语和缩略语、总述,环境管理、

数据管理、配置管理、构建与持续集成、测试管理、部署与发布管理及度量与反馈。

本文件适用于江苏省各金融机构单位提升运行维护自动交付能力的建设。

2规范性引用文件

下列文件对于本文件的引用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文

件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

GB/T28827.2-2012信息技术服务运维维护

GB/T32399-2016信息技术云计算参考架构

GB/T32400-2015信息技术云计算概览与词汇

GB/T33136-2016信息技术服务数据中心服务能力成熟度模型

YD/T2441-2013互联网数据中心技术及分级分类标准

3总则

持续交付是一种持续的将各类变更（包括新功能、缺陷修好、配置变化、实验等）安全、快速、高

质量地落实到生产环境或用户手中的能力，信息科技系统运行维护自动交付是持续交付的必要手段，在

应用软件集成交付环节，从环境管理、数据管理、配置管理、构建与持续集成、测试管理、部署与发布

管理、度量与反馈七个方面（如表1所示），保证软件持续顺畅、高质量的对用户完成发布。

表1自动交付分级技术环节

持续交付

环境管理数据管理配置管理构建与持续测试管理部署与发布度量与反馈

集成管理

环境类型明确测试分部署与发布

测试数据管理版本控制构建实践度量指标

选择层策略模式

代码质量管度量驱动改

环境构建数据变更管理变更管理持续集成部署流水线

理进

环境依赖与

自动化测试

配置管理

4环境管理

4.1环境类型选择

研发环境的种类宜具有齐备性，并能满足不同阶段业务需求的能力，具体要求如下：

a）宜建立全面的测试与灰度环境包括：开发环境，技术测试及业务测试环境以及灰度发布环境

等；

b）宜根据业务与应用的需要，弹性分配各类环境。

4.2环境构建

应从交付过程和交付速度中体现生成方式和交付能力，具体要求如下：

a）环境构建宜通过自动化来完成；

b）环境准备时间小时级，如环境的构建可以通过容器化快速交付，则环境准备时间分钟级；

c）环境的构建宜通过自服务的资源交付平台来完成；

d）环境宜根据业务及应用架构弹性构建。

4.3环境依赖与配置管理

通过环境所依赖的内容的识别和管理，以及环境变更的有效跟踪反馈的方法，宜确保环境的一致性

和受控，具体要求如下：

a）宜通过配置管理工具实现操作系统级别的依赖管理，如操作系统版本、组件版本、程序包版

本等；

b）以应用为中心，建立服务级依赖的配置管理能力，如依赖的关联服务，数据库服务、缓存服

务、关联应用服务等；

c）环境和依赖配置管理宜实现代码化描述；

d）宜具备实例级的动态配置管理能力，根据业务和应用架构弹性变化。

5数据管理

5.1测试数据管理

5.1.1数据来源

通过测试数据的生成方式，可产生用以满足不同测试类型需求的数据来源，具体耍求如下：

a）导出部分生产环境数据并清洗敏感信息后形成基准的测试数据集；

b）部分测试用例专属的测试数据宜按需通过模拟或调用应用程序API的方式自动生成。

5.1.2数据覆盖

通过测试数据对于各种测试类型需求的支持能力可实现数据覆盖，具体要求如下：

a）宜建立体系化测试数据，进行数据依赖管理，覆盖全部测试分层策略要求的测试类型；

b）测试数据宜覆盖安全漏洞和开源合规等需求场景；

0宜定期更新机制，持续优化数据管理方式和策略。

5.1.3数据独立性

测试数据在测试执行各阶段的完整性和一致性，不应受到其他任务执行结果的影响，以确保数据独

立性，具体要求如下：

a）测试数据宜明确备份恢复机制;

b）宜实现测试数据复用和保证测试一致性；

c）宜对•测试数据分级，形成元数据和测试用例专用数据；

d）测试用例的执行不应依赖其他测试用例执行所产生的结果数据，每个测试用例宜拥有专属的

测试数据，具备明确的测试初始状态。

5.2数据变更管理

5.2.1变更过程设计

通过数据库相关信息的更新方法和实现机制确保变更过程，具体要求如下：

a）数据变更宜作为软件发布的一个独立环节，单独实施和交付；

b）宜使用自动化脚本完成标准的数据变更；

c）宜将数据变更纳入持续部署流水线，经人工确认后自动完成；

d）应用程序部署和数据库变更宜解耦，可单独执行；

e）宜建立持续优化的数据管理方法，持续改进数据管理效率。

5.2.2兼容回退

通过数据库变更的向下兼容性以及回退变更的能力和方法确保兼容回退，具体要求如下：

a）宜建立数据库和应用的版本对应关系，并持续跟踪版本变更；

b）每次数据变更宜提供明确的回退机制，并进行变更测试，如提供升级和回退自动化脚本；

c）数据变更宜具备向卜.兼容性，支持保留数据的回退操作和零停机部署。

5.2.3数据监控

通过对数据变更过程的日志、状态、指标的收集、分析及决策的能力确保数据监控，具体要求如下：

a）宜收集和分析数据变更日志，实现变更问题快速定位；

b）宜针对不同环境和重要程度对数据变更建立分级监控机制：

c）宜对数据变更进行监控，发现和修复异常变更；

d）宜持续监控和优化数据变更机制。

6配置管理

6.1版本控制

6.1.1版本控制系统

通过记录一个或若干文件内容变化，能够查阅特定版本修订情况的版本控制系统，具体要求如下:

a）宜使用统一的版本控制系统；

b）宜将全部源代码纳入版本控制系统管理；

c）宜将配置文件、构建和部署等自动化脚本纳入版本控制系统管理；

d）宜建立健全的版本控制系统管理机制，包括：代码库命名规范、备份与可用性保障机制、权

限专人专岗管理等；

a）应建立包括代码和基础设施配置项的基线；

b）应使用统一的变更管理系统，所有配置项变更由变更管理系统触发；

c）应针对重点变更内容进行评审；

d）宜记录代码变更管理信息；

e）应建立变更的分级评审机制；

0变更管理过程宜覆盖从需求到部署发布全流程；

g）针对•每次变更内容宜进行评审，尽可能使用自动化手段；

h）宜建立可视化变更生命周期，支持全程数据分析管理.

6.2.2变更追溯

通过变更相关信息和状态的识别和查询，包括变更人员、变更时间、变更原因、变更内容等进行变

更追溯，具体要求如下：

a）应清晰定义版本号规则；

b）宜实现制品和代码基线的关联，可追溯指定版本的完整源代码信息；

c）宜实现版本控制系统和变更管理系统的自动化关联，信息双向同步和实时可追洲；

d）变更依赖关系宜被识别和标记；

e）宜实现数据库和环境变更信息的可追溯；

f）宜实现从需求到部署发布各个环节的相关全部信息的全程可追溯。

6.2.3变更回退

通过将变更恢复到变更之前状态的变更回退，具体要求如下：

a）宜实现变更管理系统和版本控制系统的一同回退，保证状态的一致性；

b）回退操作宜实现自动化；

c）宜自动化回退全流程的所有变更包括变更依赖；

d）宜准备经过验证目.可接受的其它补偿或应急措施以应对不适用回退的场景。

7构建与持续集成

7.1构建实践

7.1.1构建方式设计

通过源代码*变为可运行程序的方法和过程的构建方式，具体要求如下：

a）宜采用脚本实现构建过程自动化；

b）宜定义结构化构建脚本，实现模块级共享到用；

c）构建脚本应由专人统一维护（可兼职）；

d）宜实现构建方式服务化，可按需提供接口或用户界面，将构建能力赋予整个研发团队；

e）宜按场景实现构建过程可视化编排；

f）宜持续优化构建服务平台，持续改进服务易用性。

7.1.2构建环境搭建

通过构建实际运行过程的设备和资源依赖的载体的构建环境，具体要求如下：

a）宜建立独立的构建服务器，多种任务共用构建环境；

b）构建环境配置应实现规范化；

c）宜建立独立的构建资源池；

d）宜持续改进构建环境以提高构建效能。

7.1.3构建计划明确

通过构建被触发的方式，频率和编排过程，具体要求如下：

a）宜细分构建类型，如发布构建、测试构建；

b）宜明确定义构建计划和规则，并在团队内共享；

c）宜实现定期自动执行构建和代码提交触发构建。

7.1.4明确构建职责

通过构建相关工具，系统和过程的责任主体职责，具体要求如下：

a）构建工具和环境宜由专门团队维护并细分团队人员职责；

b）宜构建实现自服务，将构建能力赋予全部团队成员，并按需触发构建实现。

7.2持续集成

7.2.1搭建集成服务

通过持续集成运行的系统和环境，以及集成团队的职责划分的集成服务，具体要求如下：

a）宜搭建统一的持续集成服务；

b）宜组建专门的持续集成团队，负贡优化持续集成系统和服务模板；

c）宜实现持续集成服务化和自助化，研发团队可自行使用持续集成服务；

d）宜持续优化和改进团队持续集成服务，提升组织交付能力。

7.2.2集成频率设定

研发编写的源代码向代码主干分支合并过程的方法和实施频率，具体要求如下：

a）研发人员宜具备每天向代码主干集成一次的能力；

h）研发人员宜具备每天多次向代码主干集成的能力,可按需集成任何变更（代码.配置.环境

7.2.3集成方式明确

通过代码集成的触发条件和集成过程中的环节及输入输出的集成方式，具体要求如卜.：

a）在部分分支上宜进行每天多次的定时构建；

b）每次代码提交宜触发自动化构建，构建问题通过自动分析，精准推送相关人员处理；

c）每次代码提交构建宜触发自动化测试和静态代码检查：

d）发现测试问题宜自动提醒；

e）测试结果应作为版本质量强制要求，如采取质量门禁等方式强化主干代码质最：

0应实现持续集成下的自动化测试分级，如单元测试、SIT、UAT。

8测试管理

8.1明确测试分层策略

8.1.1分层方法选择

通过测试体系按照不同的测试对象，类型进行分类聚合的方法，每一层对应了特有的测试需求分层

方法，具体要求如下：

a）宜采用接口/服务级测试对模块/服务进行覆盖全面的接II/服务测试：

b）宜采用探索性测试方法对需求进行深入挖掘测试；

C）系统宜全面进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非艺能性测试；

d）宜采用代码级测试对核心模块的函数或类方法进行单元测试；

e）宜采用代码级测试对模块的函数或类方法进行覆盖全面的单元测试；

0宜采用测试驱动开发的方式进行代码级、接II级测试（TDD）；

g）宜采用验收测试驱动开发的方式进行用户/业务级的UI测试（BDD/ATDD）。

8.1.2分层策略建立

通过基于测试分层策略对每部分的测试比重和投入，以及覆盖度等的划分策略分层策略，具体要求

如下：

a）宜建立测试分层策略；

b）测试设计宜对接口/服务级测试为主，兼顾用户/业务级测试，辅以少量的代码级测试；

c）宜对非功能性测试进行全面系统的设计；

d）测试分层策略的各层测试宜具备交叉互补性；

c）对代码级测试宜尽可能提高覆盖度；

0宜定期验证测试分层策略，是否完整、有效，持续优化策略。

8.1.3测试时机选择

通过测试接入软件研发过程的时间点和参与形式以及期望结果的测试时机，具体要求如下：

a）在需求阶段宜进行用户八也务级测试设计；

b）测试在自动交付过程中的介入时间宜提前到开发的编码阶段：

c）接口/服务级测试在模块的接口开发过程中宜同步进行和完成；

d）在需求特性开发、交付整个过程中宜同步进行并完成测试；

e）代码级测试在模块的函数或类方法开发过程中宜同步进行和完成。

8.2代码质量管理

8.2.1质量规约建立

通过对软件代码质量的要求和规范，涵盖编码规范、复杂度、覆盖率以及安全漏洞、合规性要求等

多个方面的质量规约，具体要求如下：

a）规约范围宜覆盖部分代码质量指标，如代码规范、圈复杂度、重复度等质量指标：

b）应建立组织级代码质量规约，在此基础上建立团队级定制的代码质量规约：

c）宜建立完整的质最规约，将安全漏洞检查、合规检查纳入规约；

d）宜建立强制执行的质量门禁体系；

e）宜建立规约固定更新机制，可根据业务需要灵活扩展和定制；

D宜定期验证代码质量规约的完整性和有效性，持续优化。

8.2.2检查方式明确

通过代码质量规约检查执行手段、触发条件，对执行效率、易用性等方面提出要求，具体要求如下：

a）代码质量检查宜采用自动化结合手工方式进行；

b）对代码质量检查发现的部分问题宜自动提出修改建议，支持可视化；

c）宜具备企业级的代码质量管理平台，以服务的形式提供对代码质量的检查、分析。

8.2.3反馈处理

通过代码质量检查结果的收集、跟踪、处理的完整流程，可通过代码质量综合指标群（包括代码复

杂度、代码重复率等一系列业内常见详细指标）进行衡量的反馈处理，具体要求如下：

a）宜在研发阶段主动解决代码质量问题；

b）整体代码质量问题应呈现下降趋势：

c）对代码质量数据宜进行统一管理；

d）应有效追溯并对代码质量进行有效度量。

8.3自动化测试

8.3.1自动化测试设计

通过测试分层中各种测试类型的自动化设计方法，用于指导自动化测试工作的有效执行，具体要求

如下：

a）宜对故障和测试进行复盘，对遗漏的测试用例进行补充，不断优化和完善，持续提升覆盖率；

b）宜对用户/业务级的UI测试进行自动化设计；

c）宜对接口/服务级测试进行自动化设计：

d）宜对代码级测试进行自动化设计；

e）宜对性能、稳定性、可靠性、安全性等非功能性测试进行自动化设计。

8.3.2自动化测试开发

通过依据自动化测试设计进行自动化测试工具、脚本、用例、框架、系统等不同层面的开发，具体

要求如下：

a）宜使用版本控制系统对•自动化测试脚本进行有效管理;

b）宜建立统一的自动化测试框架，统一管理自动化测试用例；

c）宜建立自动化测试自服务平台；

d）宜优化自动化测试执行效率；

e）自动化测试宜资源池化；

0宜建立持续优化的自动化测试平台。

8.3.3自动化测试执行

通过自动化测试的执行条件和触发机制，以及测试问题的跟踪处理机制，从而满足自动化测试设计

的目标，具体要求如下：

a）宜对用户/业务级UI测试采用自动化测试；

b）宜对接口/服务级与代码级测试采用自动化测试；

c）自动化测试宜由流水线自动化触发：

d）宜建立组织级的统一自动化测试平台，和上下游需求、变更管理系统打通；

e）宜可以根据需求选择关联的自动化测试用例执行；

0可以将由于版本原因导致的失败用例和缺陷关联；

g）宜定期验证自动化执行策略，持续优化测试执行效率和资源利用率。

8.3.4自动化测试分析

通过自动化测试结果的准确性数据分析能力，以提供更多的反馈信息用来优化和持续改进自动化测

试流程，具体要求如下：

a）自动化测试数据模型宜规范化，和上下游需求、跌陷等研发数据关联，可以对自动化测试效

果进行度量分析，如需求测试覆盖率、测试通过率和测试效率等；

b）对自动化测试结果宜进行智能分析，自动分析失败用例的失败类型，能自动向缺陷管理系统

提交缺陷。

9部署与发布管理

9.1部署与发布模式

9.1.1部署方式选择

通过软件包部署到线上生产环境或者交付用户的过程所采用的工具和方法，具体要求如下：

a）运维人员宜通过自动化脚本实现部署；

b）部署发布服务官自动化，实现开发测试阶段自助一键式多环境自动化部署；

0宜支持数据库脚本自动化部署；

d）宜持续优化部署发布模式和工具系统平台。

9.1.2部署过程

通过软件上线部署环节的实践方法以及完成部署活动的能力，具体要求如下：

a）应使用相同的过程和工具完成所有环境部署；

b）一次部署过程中应使用相同的构建产物；

c）部署过程可灵活响应业务需求变化，通过合理组合实现灵活编排；

d）开发或测试环境下持续部署，每次变更都宜触发自动化部署过程，以便于快速开发或验证。

9.1.3部署策略

通过部署过程的执行频率和部署内容以及部署手段来保证安全快速顺畅的生产部署，具体要求如下:

a）宜实现测试环境的自动化部署；

b）应用和配置宜进行分离；

c）宜采用定期部署策略，具备按天进行部署的能力；

d）宜通过低风险的部署发布策略保证流程风险可控，如蓝绿部署，金丝雀发布，送行安全可靠

地部署和发布。

9.1.4部署质量

通过部署活动的成功率和确保部署质量提升的机制和能力，具体要求如下：

a）宜实现应用部署的回退操作，问题可及时修复；

b）每次部署活动宜提供变更范围报告和测试报告；

c）宜部署活动集成自动化测试功能，并以测试结果为部署前置条件；

d）宜建立监控体系跟踪和分析部署过程，出现问题自动化降级：

e）宜建立持续优化的部署监控体系。

9.2部署流水线

9.2.1协作模式确立

通过软件从需求到上线交付各个环节中各责任主体之间的信息传递和交互方式，体现整体交付过程

顺畅程度，具体要求如下：

a）宜通过定义完整的软件交付过程和清晰的交付规范，保证团队之间交付的有序；

b）团队间交付官按照约定由系统间调用完成，仅在必要环节进行手工确认；

c）团队间依赖宜解耦，尽可能实现独立安全的自主部署交付：

d）宜持续优化交付业务组织以灵活响应业务变化，改善发布效率。

9.2.2流水线过程

通过软件交付过程中各个环节活动的实现机制和整体交付的触发条件，具体要求如下：

a）软件交付过程中的各个环节宜建立自动化能力以提升处理效率；

b）宜打通软件交付过程中的各个环节，建立全流程的自动化能力并根据自动化测试结果保障软

件交付质量；

c）宜建立可视化部署流水线，覆盖整个软件交付过程；

d）每次变更都会触发开发测试环境下完整的自动化部署流水线；

e）宜持续改进部署流水线。

9.2.3过程可视化建设

通过软件交付过程中信息的可见程度，以及所展现数据对于业务价值的展现能力，具沐要求如下：

a）交付状态可追溯；

b）交付过程组织内部宜按需配置可见；

c）宜团队共享度量指标；

d）对过程信息宜进行有效聚合分析展示趋势；

e）宜对部署流水线过程信息进行数据价值挖掘，推动业务改进。

10度量与反馈

10.1度量指标

10.1.1度量指标定义

通过度量指标设计的依据和生效领域，用于识别符合业务需求的度量指标（如表2所示），具体要

求如下：

a）在自动交付各个阶段宜定义部门级的度量指标；

b）宜建立跨组织度量指标，进行跨领域综合方面的度量：

c）宜共享核心业务度量指标；

d）宜持续优化度量指标，自我驱动持续改进。

10.1.2度量指标类型选择

通过度量指标的覆盖，确保完整度，具体要求如下：

a）宜覆盖结果指标，如变更频率，需求交付前置时间，变更失败率和平均修复时间；

b）宜覆盖过程指标，客观反映组织研发现状；

c）宜覆盖探索性指标，并展示趋势，预测潜在问题，并及时预警；

d）宜建立度量指标的有效反馈机制，并持续优化度量指标分类。

10.1.3度量数据管理

通过度量数据的收集，分析和管理，具体要求如下：

a）宜持续收集度量数据，历史度量数据具备明确的管理规则；

b）宜对历史度量数据进行有效的挖掘分析。

10.1.4度量指标更新

通过度量指标的更新机制，具体要求如下：

a）度量指标可以按照需求进行更新；

b）度量指标可基于大数据分析和人工智能自动识别和推荐动态调整指标优先级。

表2部分参考度量指标

阶段度量指标定义

代码仓库数量

代码提交数

版本控制

代码提交频率

代码提交时间分布

构建次数

构建频率

构建构建时长

构建失败率

构建修复时间

代码行数

代码第杂度

代码重夏率

代码

单元测试覆盖率

单元测试用例数

单元测试成功率