DB32T 金融机构信息科技系统运行维护自动交付规范.docx
《DB32T 金融机构信息科技系统运行维护自动交付规范.docx》由会员分享，可在线阅读，更多相关《DB32T 金融机构信息科技系统运行维护自动交付规范.docx（22页珍藏版）》请在冰点文库上搜索。
DB32T金融机构信息科技系统运行维护自动交付规范
ICSFORMTEXT0308001
FORMTEXTA12
DB32
江苏省地方标准
DBFORMTEXT32/TXXXX-XXXX
金融机构信息科技系统运行维护
自动交付规范
AutomaticDeiverSationTechnoogSteminFinanciaIntitution
FORMTEXTXXXX-XX-XX发布
FORMTEXTXXXX-XX-XX实施
FORMTEXT江苏省市场监督管理局发布
DB32/TXXXX—XXXX
PAGE14
目次
TOC\o"1-2"\h\\u目次I
前言II
1范围1
2规范性引用文件1
3总则1
4环境管理1
41环境类型选择1
42环境构建2
43环境依赖与配置管理2
5数据管理2
51测试数据管理2
52数据变更管理3
6配置管理3
61版本控制3
62变更管理5
7构建与持续集成6
71构建实践6
72持续集成6
8测试管理7
81明确测试分层策略7
82代码质量管理8
83自动化测试9
9部署与发布管理10
91部署与发布模式10
92部署流水线11
10度量与反馈12
101度量指标12
102度量驱动改进13
前言
本标准按照GB/T11-最新《标准化工作导则第1部分：
标准的结构和编写》给出的规则起草。
本标准由中国人民银行南京分行提出。
本标准起草单位：
苏州银行股份有限公司、中国人民银行苏州市中心支行、中国人民银行盐城市中心支行。
本标准主要起草人：
张小玉、李微羽、张振兴、许燕刚、姜静、卜家怡、钱卫星、魏晋、周秋亭、谢凯、黄海、石刚、周桢骑。
金融机构信息科技系统运行维护自动交付规范
范围
本文件规定了金融机构信息科技系统运行维护自动交付过程中的术语和缩略语、总述、环境管理、数据管理、配置管理、构建与持续集成、测试管理、部署与发布管理及度量与反馈。
本文件适用于江苏省各金融机构单位提升运行维护自动交付能力的建设。
规范性引用文件
下列文件对于本文件的引用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB/T288272-最新信息技术服务运维维护
GB/T32399-最新信息技术云计算参考架构
GB/T32400-最新信息技术云计算概览与词汇
GB/T33136-最新信息技术服务数据中心服务能力成熟度模型
YD/T2441-最新互联网数据中心技术及分级分类标准
总则
持续交付是一种持续的将各类变更（包括新功能、缺陷修复、配置变化、实验等）安全、快速、高质量地落实到生产环境或用户手中的能力，信息科技系统运行维护自动交付是持续交付的必要手段，在应用软件集成交付环节，从环境管理、数据管理、配置管理、构建与持续集成、测试管理、部署与发布管理、度量与反馈七个方面（如表1所示），保证软件持续顺畅、高质量的对用户完成发布。
表1自动交付分级技术环节
持续交付
环境管理
数据管理
配置管理
构建与持续集成
测试管理
部署与发布管理
度量与反馈
环境类型
选择
测试数据管理
版本控制
构建实践
明确测试分层策略
部署与发布模式
度量指标
环境构建
数据变更管理
变更管理
持续集成
代码质量管理
部署流水线
度量驱动改进
环境依赖与配置管理
自动化测试
环境管理
环境类型选择
研发环境的种类宜具有齐备性，并能满足不同阶段业务需求的能力，具体要求如下：
宜建立全面的测试与灰度环境包括：
开发环境，技术测试及业务测试环境以及灰度发布环境等；
宜根据业务与应用的需要，弹性分配各类环境。
环境构建
应从交付过程和交付速度中体现生成方式和交付能力，具体要求如下：
环境构建宜通过自动化来完成；
环境准备时间小时级，如环境的构建可以通过容器化快速交付，则环境准备时间分钟级；
环境的构建宜通过自服务的资源交付平台来完成；
环境宜根据业务及应用架构弹性构建。
环境依赖与配置管理
通过环境所依赖的内容的识别和管理，以及环境变更的有效跟踪反馈的方法，宜确保环境的一致性和受控，具体要求如下：
宜通过配置管理工具实现操作系统级别的依赖管理，如操作系统版本、组件版本、程序包版本等；
以应用为中心，建立服务级依赖的配置管理能力，如依赖的关联服务，数据库服务、缓存服务、关联应用服务等；
环境和依赖配置管理宜实现代码化描述；
宜具备实例级的动态配置管理能力，根据业务和应用架构弹性变化。
数据管理
测试数据管理
数据产生用以满足不同测试类型需求的数据产环境数据并清洗敏感信息后形成基准的测试数据集；
部分测试用例专属的测试数据宜按需通过模拟或调用应用程序API的方式自动生成。
数据覆盖
通过测试数据对于各种测试类型需求的支持能力可实现数据覆盖，具体要求如下：
宜建立体系化测试数据，进行数据依赖管理，覆盖全部测试分层策略要求的测试类型；
测试数据宜覆盖安全漏洞和开源合规等需求场景；
宜定期更新机制，持续优化数据管理方式和策略。
数据独立性
测试数据在测试执行各阶段的完整性和一致性，不应受到其他任务执行结果的影响，以确保数据独立性，具体要求如下：
测试数据宜明确备份恢复机制；
宜实现测试数据复用和保证测试一致性；
宜对测试数据分级，形成元数据和测试用例专用数据；
测试用例的执行不应依赖其他测试用例执行所产生的结果数据，每个测试用例宜拥有专属的测试数据，具备明确的测试初始状态。
数据变更管理
变更过程设计
通过数据库相关信息的更新方法和实现机制确保变更过程，具体要求如下：
数据变更宜作为软件发布的一个独立环节，单独实施和交付；
宜使用自动化脚本完成标准的数据变更；
宜将数据变更纳入持续部署流水线，经人工确认后自动完成；
应用程序部署和数据库变更宜解耦，可单独执行；
宜建立持续优化的数据管理方法，持续改进数据管理效率。
兼容回退
通过数据库变更的向下兼容性以及回退变更的能力和方法确保兼容回退，具体要求如下：
宜建立数据库和应用的版本对应关系，并持续跟踪版本变更；
每次数据变更宜提供明确的回退机制，并进行变更测试，如提供升级和回退自动化脚本；
数据变更宜具备向下兼容性，支持保留数据的回退操作和零停机部署。
数据监控
通过对数据变更过程的日志、状态、指标的收集、分析及决策的能力确保数据监控，具体要求如下：
宜收集和分析数据变更日志，实现变更问题快速定位；
宜针对不同环境和重要程度对数据变更建立分级监控机制；
宜对数据变更进行监控，发现和修复异常变更；
宜持续监控和优化数据变更机制。
配置管理
版本控制
版本控制系统
通过记录一个或若干文件内容变化，能够查阅特定版本修订情况的版本控制系统，具体要求如下：
宜使用统一的版本控制系统；
宜将全部源代码纳入版本控制系统管理；
宜将配置文件、构建和部署等自动化脚本纳入版本控制系统管理；
宜建立健全的版本控制系统管理机制，包括：
代码库命名规范、备份与可用性保障机制、权限专人专岗管理等；
宜将数据库变更脚本和环境配置等纳入版本控制管理；
版本控制系统相关操作宜以自动化的方式实现，而非手工操作；
宜建立针对版本控制系统的度量与监控机制；
宜将软件生命周期的所有配置项纳入版本控制管理；
宜持续优化版本控制系统。
分支管理
通过对软件研发过程中的分支和集成策略的管理（分支策略代表了研发协作方式）实现分支管理，具体要求如下：
分支可以频繁地向主干合并；
主干随时可进行指定版本的测试和发布；
可以针对不同业务和技术要求，选用不同的分支策略，在指定时间发布；
特性代码可按需合并到主干进行验证和发布；
宜建立持续优化的分支管理机制。
制品管理
通过对软件研发过程中生成产物的管理，即作为最终交付物完成发布和交付的制品管理，具体要求如下：
宜使用统一的制品库管理构建产物；
应具备清晰的存储结构且有唯一版本号；
宜通过统一的制品库地址进行构建产物分发；
应将依赖组件纳入制品库管理；
制品库读写应建立清晰的权限管控制度；
宜对制品库完成分级管理以建立体系化的制品库管理策略，包括：
备份与恢复机制、制品库完整性与一致性保障机制等；
宜持续优化制品管理机制。
单一可信数据源
通过信息数据模型和关联模式，保证每个数据元素只存储一份，确保数据的一致性的单一可信数据源，具体要求如下：
开发测试部署环节所用到的源代码应制系统和制品库应作为单一可信数据源，覆盖部署环节；
单一可信数据源应贯穿整个研发价值流交付过程；
在组织内部宜开放共享，建立知识积累和经验复用体系。
变更管理
变更过程设计
通过变更的触发条件和实施手段，覆盖完整生命周期的变更过程，具体要求如下：
应建立包括代码和基础设施配置项的基线；
应使用统一的变更管理系统，所有配置项变更由变更管理系统触发；
应针对重点变更内容进行评审；
宜记录代码变更管理信息；
应建立变更的分级评审机制；
变更管理过程宜覆盖从需求到部署发布全流程；
针对每次变更内容宜进行评审，尽可能使用自动化手段；
宜建立可视化变更生命周期，支持全程数据分析管理。
变更追溯
通过变更相关信息和状态的识别和查询，包括变更人员、变更时间、变更原因、变更内容等进行变更追溯，具体要求如下：
应清晰定义版本号规则；
宜实现制品和代码基线的关联，可追溯指定版本的完整源代码信息；
宜实现版本控制系统和变更管理系统的自动化关联，信息双向同步和实时可追溯；
变更依赖关系宜被识别和标记；
宜实现数据库和环境变更信息的可追溯；
宜实现从需求到部署发布各个环节的相关全部信息的全程可追溯。
变更回退
通过将变更恢复到变更之前状态的变更回退，具体要求如下：
宜实现变更管理系统和版本控制系统的一同回退，保证状态的一致性；
回退操作宜实现自动化；
宜自动化回退全流程的所有变更包括变更依赖；
宜准备经过验证且可接受的其它补偿或应急措施以应对不适用回退的场景。
构建与持续集成
构建实践
构建方式设计
通过源代码转变为可运行程序的方法和过程的构建方式，具体要求如下：
宜采用脚本实现构建过程自动化；
宜定义结构化构建脚本，实现模块级共享复用；
构建脚本应由专人统一维护（可兼职）；
宜实现构建方式服务化，可按需提供接口或用户界面，将构建能力赋予整个研发团队；
宜按场景实现构建过程可视化编排；
宜持续优化构建服务平台，持续改进服务易用性。
构建环境搭建
通过构建实际运行过程的设备和资源依赖的载体的构建环境，具体要求如下：
宜建立独立的构建服务器，多种任务共用构建环境；
构建环境配置应实现规范化；
宜建立独立的构建资源池；
宜持续改进构建环境以提高构建效能。
构建计划明确
通过构建被触发的方式，频率和编排过程，具体要求如下：
宜细分构建类型，如发布构建、测试构建；
宜明确定义构建计划和规则，并在团队内共享；
宜实现定期自动执行构建和代码提交触发构建。
明确构建职责
通过构建相关工具，系统和过程的责任主体职责，具体要求如下：
构建工具和环境宜由专门团队维护并细分团队人员职责；
宜构建实现自服务，将构建能力赋予全部团队成员，并按需触发构建实现。
持续集成
搭建集成服务
通过持续集成运行的系统和环境，以及集成团队的职责划分的集成服务，具体要求如下：
宜搭建统一的持续集成服务；
宜组建专门的持续集成团队，负责优化持续集成系统和服务模板；
宜实现持续集成服务化和自助化，研发团队可自行使用持续集成服务；
宜持续优化和改进团队持续集成服务，提升组织交付能力。
集成频率设定
研发编写的源代码向代码主干分支合并过程的方法和实施频率，具体要求如下：
研发人员宜具备每天向代码主干集成一次的能力；
研发人员宜具备每天多次向代码主干集成的能力，可按需集成任何变更（代码，配置，环境）。
集成方式明确
通过代码集成的触发条件和集成过程中的环节及输入输出的集成方式，具体要求如下：
在部分分支上宜进行每天多次的定时构建；
每次代码提交宜触发自动化构建，构建问题通过自动分析，精准推送相关人员处理；
每次代码提交构建宜触发自动化测试和静态代码检查；
发现测试问题宜自动提醒；
测试结果应作为版本质量强制要求，如采取质量门禁等方式强化主干代码质量；
应实现持续集成下的自动化测试分级，如单元测试、SIT、UAT。
测试管理
明确测试分层策略
分层方法选择
通过测试体系按照不同的测试对象，类型进行分类聚合的方法，每一层对应了特有的测试需求分层方法，具体要求如下：
宜采用接口/服务级测试对模块/服务进行覆盖全面的接口/服务测试；
宜采用探索性测试方法对需求进行深入挖掘测试；
系统宜全面进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能性测试；
宜采用代码级测试对核心模块的函数或类方法进行单元测试；
宜采用代码级测试对模块的函数或类方法进行覆盖全面的单元测试；
宜采用测试驱动开发的方式进行代码级、接口级测试（TDD）；
宜采用验收测试驱动开发的方式进行用户/业务级的UI测试（BDD/ATDD）。
分层策略建立
通过基于测试分层策略对每部分的测试比重和投入，以及覆盖度等的划分策略分层策略，具体要求如下：
宜建立测试分层策略；
测试设计宜对接口/服务级测试为主，兼顾用户/业务级测试，辅以少量的代码级测试；
宜对非功能性测试进行全面系统的设计；
测试分层策略的各层测试宜具备交叉互补性；
对代码级测试宜尽可能提高覆盖度；
宜定期验证测试分层策略，是否完整、有效，持续优化策略。
测试时机选择
通过测试接入软件研发过程的时间点和参与形式以及期望结果的测试时机，具体要求如下：
在需求阶段宜进行用户/业务级测试设计；
测试在自动交付过程中的介入时间宜提前到开发的编码阶段；
接口/服务级测试在模块的接口开发过程中宜同步进行和完成；
在需求特性开发、交付整个过程中宜同步进行并完成测试；
代码级测试在模块的函数或类方法开发过程中宜同步进行和完成。
代码质量管理
质量规约建立
通过对软件代码质量的要求和规范，涵盖编码规范、复杂度、覆盖率以及安全漏洞、合规性要求等多个方面的质量规约，具体要求如下：
规约范围宜覆盖部分代码质量指标，如代码规范、圈复杂度、重复度等质量指标；
应建立组织级代码质量规约，在此基础上建立团队级定制的代码质量规约；
宜建立完整的质量规约，将安全漏洞检查、合规检查纳入规约；
宜建立强制执行的质量门禁体系；
宜建立规约固定更新机制，可根据业务需要灵活扩展和定制；
宜定期验证代码质量规约的完整性和有效性，持续优化。
检查方式明确
通过代码质量规约检查执行手段、触发条件，对执行效率、易用性等方面提出要求，具体要求如下：
代码质量检查宜采用自动化结合手工方式进行；
对代码质量检查发现的部分问题宜自动提出修改建议，支持可视化；
宜具备企业级的代码质量管理平台，以服务的形式提供对代码质量的检查、分析。
反馈处理
通过代码质量检查结果的收集、跟踪、处理的完整流程，可通过代码质量综合指标群（包括代码复杂度、代码重复率等一系列业内常见详细指标）进行衡量的反馈处理，具体要求如下：
宜在研发阶段主动解决代码质量问题；
整体代码质量问题应呈现下降趋势；
对代码质量数据宜进行统一管理；
应有效追溯并对代码质量进行有效度量。
自动化测试
自动化测试设计
通过测试分层中各种测试类型的自动化设计方法，用于指导自动化测试工作的有效执行，具体要求如下：
宜对故障和测试进行复盘，对遗漏的测试用例进行补充，不断优化和完善，持续提升覆盖率；
宜对用户/业务级的UI测试进行自动化设计；
宜对接口/服务级测试进行自动化设计；
宜对代码级测试进行自动化设计；
宜对性能、稳定性、可靠性、安全性等非功能性测试进行自动化设计。
自动化测试开发
通过依据自动化测试设计进行自动化测试工具、脚本、用例、框架、系统等不同层面的开发，具体要求如下：
宜使用版本控制系统对自动化测试脚本进行有效管理；
宜建立统一的自动化测试框架，统一管理自动化测试用例；
宜建立自动化测试自服务平台；
宜优化自动化测试执行效率；
自动化测试宜资源池化；
宜建立持续优化的自动化测试平台。
自动化测试执行
通过自动化测试的执行条件和触发机制，以及测试问题的跟踪处理机制，从而满足自动化测试设计的目标，具体要求如下：
宜对用户/业务级UI测试采用自动化测试；
宜对接口/服务级与代码级测试采用自动化测试；
自动化测试宜由流水线自动化触发；
宜建立组织级的统一自动化测试平台，和上下游需求、变更管理系统打通；
宜可以根据需求选择关联的自动化测试用例执行；
可以将由于版本原因导致的失败用例和缺陷关联；
宜定期验证自动化执行策略，持续优化测试执行效率和资源利用率。
自动化测试分析
通过自动化测试结果的准确性数据分析能力，以提供更多的反馈信息用来优化和持续改进自动化测试流程，具体要求如下：
自动化测试数据模型宜规范化，和上下游需求、缺陷等研发数据关联，可以对自动化测试效果进行度量分析，如需求测试覆盖率、测试通过率和测试效率等；
对自动化测试结果宜进行智能分析，自动分析失败用例的失败类型，能自动向缺陷管理系统提交缺陷。
部署与发布管理
部署与发布模式
部署方式选择
通过软件包部署到线上生产环境或者交付用户的过程所采用的工具和方法，具体要求如下：
运维人员宜通过自动化脚本实现部署；
部署发布服务宜自动化，实现开发测试阶段自助一键式多环境自动化部署；
宜支持数据库脚本自动化部署；
宜持续优化部署发布模式和工具系统平台。
部署过程
通过软件上线部署环节的实践方法以及完成部署活动的能力，具体要求如下：
应使用相同的过程和工具完成所有环境部署；
一次部署过程中应使用相同的构建产物；
部署过程可灵活响应业务需求变化，通过合理组合实现灵活编排；
开发或测试环境下持续部署，每次变更都宜触发自动化部署过程，以便于快速开发或验证。
部署策略
通过部署过程的执行频率和部署内容以及部署手段来保证安全快速顺畅的生产部署，具体要求如下：
宜实现测试环境的自动化部署；
应用和配置宜进行分离；
宜采用定期部署策略，具备按天进行部署的能力；
宜通过低风险的部署发布策略保证流程风险可控，如蓝绿部署，金丝雀发布，进行安全可靠地部署和发布。
部署质量
通过部署活动的成功率和确保部署质量提升的机制和能力，具体要求如下：
宜实现应用部署的回退操作，问题可及时修复；
每次部署活动宜提供变更范围报告和测试报告；
宜部署活动集成自动化测试功能，并以测试结果为部署前置条件；
宜建立监控体系跟踪和分析部署过程，出现问题自动化降级；
宜建立持续优化的部署监控体系。
部署流水线
协作模式确立
通过软件从需求到上线交付各个环节中各责任主体之间的信息传递和交互方式，体现整体交付过程顺畅程度，具体要求如下：
宜通过定义完整的软件交付过程和清晰的交付规范，保证团队之间交付的有序；
团队间交付宜按照约定由系统间调用完成，仅在必要环节进行手工确认；
团队间依赖宜解耦，尽可能实现独立安全的自主部署交付；
宜持续优化交付业务组织以灵活响应业务变化，改善发布效率。
流水线过程
通过软件交付过程中各个环节活动的实现机制和整体交付的触发条件，具体要求如下：
软件交付过程中的各个环节宜建立自动化能力以提升处理效率；
宜打通软件交付过程中的各个环节，建立全流程的自动化能力并根据自动化测试结果保障软件交付质量；
宜建立可视化部署流水线，覆盖整个软件交付过程；
每次变更都会触发开发测试环境下完整的自动化部署流水线；
宜持续改进部署流水线。
过程可视化建设
通过软件交付过程中信息的可见程度，以及所展现数据对于业务价值的展现能力，具体要求如下：
交付状态可追溯；
交付过程组织内部宜按需配置可见；
宜团队共享度量指标；
对过程信息宜进行有效聚合分析展示趋势；
宜对部署流水线过程信息进行数据价值挖掘，推动业务改进。
度量与反馈
度量指标
度量指标定义
通过度量指标设计的依据和生效领域，用于识别符合业务需求的度量指标（如表2所示），具体要求如下：
在自动交付各个阶段宜定义部门级的度量指标；
宜建立跨组织度量指标，进行跨领域综合方面的度量；
宜共享核心业务度量指标；
宜持续优化度量指标，自我驱动持续改进。
度量指标类型选择
通过度量指标的覆盖，确保完整度，具体要求如下：
宜覆盖结果指标，如变更频率，需求交付前置时间，变更失败率和平均修复时间；
宜覆盖过程指标，客观反映组织研发现状；
宜覆盖探索性指标，并展示趋势，预测潜在问题，并及时预警；
宜建立度量指标的有效反馈机制，并持续优化度量指标分类。
度量数据管理
通过度量数据的收集，分析和管理，具体要求如下：
宜持续收集度量数据，历史度量数据具备明确的管理规则；
宜对历史度量数据进行有效的挖掘分析。
度量指标更新
通过度量指标的更新机制，具体要求如下：
度量指标可以按照需求进行更新；
度量指标可基于大数据分析和人工智能自动识别和推荐动态调整指标优先级。
表2部分参考度量指标
阶段
度量指标定义
版本控制
代码仓库数量
代码提交数
代码提交频率
代码提交时间分布
构建
构建次数
构建频率
构建时长
构建失败率
构建修复时间
代码
代码行数
代码复杂度
代码重复率
单元测试覆盖率
单元测试用例数
单元测试成功率
环境
环境变更时长
变更频率
容器镜像更新
活跃容器数量
资源使用统计
部署
部署版本数量
部署时间
部署成功率
部署回退率
度量驱动改进
内容和生成方式
通过度量报告的生成手段和数据展示能力，具体要求如下：
度量报告宜以自动化方式生成，明确规范格式定义；
度量报告宜进行分类分级并按需生成内容；
宜建立跨组织级统一的数据度量平台，度量报告基于平台定制化生成，支持多种类型，如表格、看板等；
宜持续优化度量方法、度量平台和度量展现形式。
数据时效性
通过度量报告所体现结果的及时性以及实时更新能力，具体要求如下：
数据报告可展现最新状态；
宜通过可视化看板实时展示数据；
宜通过可视化看板聚合报告内容，多方面展示实时状态，支持自动生成数据趋势图和趋势分析。
覆盖范围
可查看度量报告的人员范围，具体要求如下：
宜实现报告精准范围推送，支持主动订阅。
反馈改进
通过度量发现的问题的处理方式，具体要求如下：
度量反馈问题宜纳入研发迭代的待办事项列表，作为持续改进的一部分；
宜建立度量问题持续改进机制，预留工作时间用于解决度量反馈问题，识别有效改进并扩展到整个组织，作为企业级知识体系积累保留；
宜通过数据挖掘实现跨组织跨流程数据度量分析，分析结果作为业务决策的重要依据，帮助组织持续改进价值交付流程。
_________________________________
升级会员 