DB32 T 3884-2020 金融机构信息科技系统运行维护自动交付规范.pdf

《DB32 T 3884-2020 金融机构信息科技系统运行维护自动交付规范.pdf》由会员分享，可在线阅读，更多相关《DB32 T 3884-2020 金融机构信息科技系统运行维护自动交付规范.pdf（17页珍藏版）》请在麦多课文档分享上搜索。

1、ICS 03.080.01 A 12 DB32 江 苏 省 地 方 标 准 DB 32/T 3884-2020 金融机构 信息科技系统运行维护 自动交付规范 Automatic Delivery Specification for Operation and Maintenance of Information Technology System in Financial Institutions 2020 -10 - 13 发布 2020 -11 -13 实施 江苏省市场监督管理局 发布 DB32/T 3884-2020 I 目 次 目次 . I 前言 . II 1 范围 . 1 2 规范性

2、引用文件 . 1 3 总则 . 1 4 环境管理 . 1 4.1 环境类型选择 . 1 4.2 环境构建 . 2 4.3 环境依赖与配置管理 . 2 5 数据管理 . 2 5.1 测试数据管理 . 2 5.2 数据变更管理 . 3 6 配置管理 . 3 6.1 版本控制 . 3 6.2 变更管理 . 5 7 构建与持续集成 . 6 7.1 构建实践 . 6 7.2 持续集成 . 6 8 测试管理 . 7 8.1 明确测试分层策略 . 7 8.2 代码质量管理 . 8 8.3 自动化测试 . 9 9 部署与发布管理 . 10 9.1 部署与发布模式 . 10 9.2 部署流水线 . 11 10

3、度量与反馈 . 12 10.1 度量指标 . 12 10.2 度量驱动改进 . 13 DB32/T 3884-2020 II 前 言 本标准 按照 GB/T 1.1-2009标准化工作导则 第 1部分：标准的结构和编写给出的规则起草。 本标准 由中国人民银行南京分行提出。 本标准 起草单位： 苏州银行股份有限 公司 、 中国人民银行苏州市中心支行、中国人民银行盐城市中 心支行。 本标准 主要起草人： 张小玉、李微羽、张振兴、许燕刚、姜静 、 卜家怡 、钱卫星 、魏晋、 周秋亭 、 谢凯 、黄海、石刚 、 周桢骑 。 DB32/T 3884-2020 1 金融机构 信息科技系统运行维护自动交付规

4、范 1 范围 本 文件规定了金融机构 信息科技系统运行维护自动交付 过程中的术语和 缩略语 、总述、 环境管理 、 数据管理 、配置 管理 、 构建与持续集成 、 测试管理 、 部署与发布管理 及 度量与反馈 。 本文件 适用于江苏省各金融机构单位提升运行维护自动交付能力的建设。 2 规范性引用文件 下列文件对于本文件的 引用 是必不可少的。 凡是注日期的引用文件 ， 仅所注日期的版本适用于本文 件。凡是不注日期的引用文件 ， 其最新版本 （ 包括所有的修改单 ） 适用于本文件。 GB/T 28827.2-2012 信息技术服务 运维维护 GB/T 32399-2016 信息技术云计算参考架构

5、 GB/T 32400-2015 信息技术云计算概览与词汇 GB/T 33136-2016 信息技术服务数据中心服务能力成熟度模型 YD/T 2441-2013 互联网数据中心技术及分级分类标准 3 总则 持续交付是一种持续的将各类变更（包括新功能、缺陷修复、配置变化、实验 等）安全、快速、高 质量地落实到生产环境或用户手中的能力，信息科技系统运行维护自动交付是持续交付的必要手段，在 应用软件集成交付环节，从环境管理、数据管理、配置管理、构 建与持续集成、测试管理、部署与发布 管理、度量与反馈七个方面（如表 1 所 示），保证软件持续顺畅、高质量的对用户完成发布。 表 1 自动交付分级技术环节

6、 持续交付 环境管理 数据管理 配置管理 构建与持续 集成 测试管理 部署与发布 管理 度量与反馈 环境类型 选择 测试数据管理 版本控制 构建实践 明确测试分 层策略 部署与发布 模式 度量指标 环境构建 数据变更管理 变更管理 持续集成 代码质量管 理 部署流水线 度量驱动改 进 环境依赖与 配置管理 自动化测试 4 环境管理 4.1 环境类型 选择 DB32/T 3884-2020 2 研发环境的种类 宜 具有 齐备性 ， 并能 满足不同阶段业务需求的能力 ， 具体要求如下： a） 宜 建立全面的测试与灰 度环境包括：开发环境，技术测试及业务测试环境以及灰度发布环境 等； b） 宜 根据

7、业务与应用的需要，弹性分配各类环境 。 4.2 环境构建 应 从交付过程和交付速度中体现生成方式和交付能力 ， 具体要求如下： a) 环境构建 宜 通过自动化来完成 ； b) 环境准备时间小时级 ，如 环境的构建可以通过 容器化快速交付，则环境准备时间分钟级 ； c) 环境的构建 宜 通过自服务的资源交付平台来完成 ； d) 环境 宜 根据业务及应用架构弹性构建 。 4.3 环境依赖与配置管理 通过环境所依赖的内容的识别和管理，以及环境变更的有效跟踪反馈的方法， 宜 确保环境的一致性 和受控 ， 具体要求如下： a) 宜 通过配置管理工具实现操作系统级别的依赖管理，如 操作系统版本、组件 版本

8、、程序包版本 等； b) 以应用为中心， 建立 服务级依赖的配置管理 能力，如依赖的关联服务，数据库服务、缓存服务、 关联应用服务 等 ； c) 环境和依赖配置管理 宜 实现代码化描述 ； d) 宜 具备 实例级的动态配置管理能力， 根据业务和应用架构弹性变化 。 5 数据管理 5.1 测试数据管理 5.1.1 数据来源 通过 测试数据的生成方式 ，可产生 用以满足不同测试类型需求 的 数据来源 ， 具体要求如下： a) 导出部分生产环境数据并清洗敏感信息后形成基准的测试数据集 ； b) 部分测试用例专属的测试数据 宜 按需通过模拟或调用应用程序 API 的方式自动生成 。 5.1.2 数据覆

9、盖 通过 测试数据对于各种测试类型需求的支持能力 可实现 数据覆盖 ， 具体要求如下： a) 宜 建立体系化测试数据，进行数据依赖管理，覆盖全部测试分层策略要求的测试类型 ； b) 测试数据 宜 覆盖安全漏洞和开源合规等需求场景 ； c) 宜 定期更新机制，持续 优化数据管理方式和策略 。 DB32/T 3884-2020 3 5.1.3 数据独立性 测试数据在测试执行各阶段的完整性和一致性 ， 不 应 受到其他任务执行结果的影响 ， 以 确保 数据独 立性 ， 具体要求如下： a) 测试数 据 宜 明确备份恢复机制； b) 宜 实现测试数据复用和保证测试一致性； c) 宜 对测试数据分级，形

10、成元数据和测试用例专用数据； d) 测试用例的执行不 应 依赖其他测试用例执行所产生的结果数据，每个测试用例 宜 拥有专属的测 试数据，具备明确 的测试初始状态 。 5.2 数据变更管理 5.2.1 变更过程 设计 通过 数据库相关信息的更新方法和实现机制 确保 变更过程 ， 具体要求如下： a) 数据变更 宜 作为软件发布的一个独立环节 ，单独实施和交付 ； b) 宜 使用自动化脚本完成标准的数据变更 ； c) 宜 将数据变更纳入持续部署流水线，经人工确认后自动完成 ； d) 应用程序部署和数据库变更 宜 解耦，可单独执行 ； e) 宜 建立 持续优化的数据管理方法，持续改进数据管理效率 。

11、 5.2.2 兼容 回退 通过 数据库变更的向下兼容性以及回退变更的能力和方法 确保 兼容 回退 ， 具体要求如下： a) 宜 建立数据库和应用的版本对应关系，并持续跟踪版本变更 ； b) 每次数据变更 宜 提供明确的 回退 机制，并进行变更测试，如提供升级和 回退 自动化脚本 ； c) 数据变更 宜 具备向下兼容性，支持保留数据的 回退 操作和零停机部署 。 5.2.3 数据监控 通过对数据变更过程的日志、状态、 指标的收集 、 分析 及 决策的能力 确保数据监控 ， 具体要求如下： a) 宜 收集和分析数据变更日志，实现变更问题快速定位 ； b) 宜 针对不同环境和重要 程度对数据变更建立

12、分级监控机制 ； c) 宜 对数据变更进行监控，发现和修复异常变更 ； d) 宜 持续监控和优化数据变更机制 。 6 配置 管理 6.1 版本控制 6.1.1 版本控制系统 DB32/T 3884-2020 4 通过记录一个或若干文件内容变化，能够查阅特定版本修订情况的版本控制系统 ， 具体要求如下： a) 宜 使用统一的版本控制系统 ； b) 宜 将全部源代码纳入版本控制系统管理 ； c) 宜 将配置文件、构建和部署等自动化脚本纳入版本控制系统 管理 ； d) 宜 建立健全的版本控制系统管理机制，包括：代码库命名规范、备份与可用性保障机制、权限 专人专岗管理等； e) 宜 将数据库变更脚本和

13、环境配置等纳入版本控制管理； f) 版本控制系统相关操作 宜 以自动化的方式实现，而非手工操作； g) 宜 建立针对 版本控制系统的度量与监控机制 ； h) 宜 将软件生命周期的所有配置项纳入版本控制管理 ； i) 宜持续优化 版本控制系统 。 6.1.2 分支管理 通过对软件研发过程中的分支和集成策略的管理（分支策略代表了研发协作方式）实现分支管理 ， 具体要求如下： a) 分支可以频繁地向主干合并 ； b) 主干随时可进行指定版本的测试和发布 ； c) 可 以针对不同业务和技术要求，选用不同的分支策略，在指定时间发布 ； d) 特性代码可按需合并到主干进行验证和发布 ； e) 宜 建立 持

14、续优化的分支管理机制 。 6.1.3 制品管理 通过 对软件研发过程中生成产物的管理，即 作为最终交付物完成发布和交付的制品管理 ， 具体要求 如下： a) 宜 使用统一的制品库管理构建产物 ； b) 应具备 清晰的存储结构 且有唯一 版本号 ； c) 宜 通过统一的制品库地址进行构建产物分发 ； d) 应 将依赖组件纳入制品库管理 ； e) 制品库 读写 应 建立清 晰的权限管控制度 ； f) 宜 对制品库完成分级管理以建立体系化的制品库管理策略，包括：备份与恢复机制 、 制品库完 整性与 一致性保障机制 等； g) 宜 持续优化制品管理机制 。 6.1.4 单一可信数据源 DB32/T 3

15、884-2020 5 通过 信息数据模型和关联模式，保证每个数据元素只存储一份，确保数据的一致性的单一可信数据 源 ， 具体要求如下： a) 开发测试部署环节所用到的源代码 应 来源于统一版本控制系统 ； b) 版本控制系统和制品库 应 作为单一可信数据源，覆盖部署环节 ； c) 单一可信数据源 应 贯穿整个研发价值流交付过程 ； d) 在组织内部 宜 开放共享，建立知识积累和经验复用体系 。 6.2 变更管理 6.2.1 变更过程 设计 通过变更的触发条件和实施手段，覆盖完整生命周期的变更过程 ， 具体要求如下： a) 应 建立 包括 代码 和基础设施配置项的 基线 ； b) 应 使用统一的

16、变更管理系统 ， 所有配置项变更由变更管理系统触发 ； c) 应 针对重点变更内容进行评审 ； d) 宜 记录代码变更管理信息 ； e) 应 建立变更的分级评审机制 ； f) 变更管理过程 宜 覆盖从需求到部署发布全流程 ； g) 针对每次变更内容 宜 进行评审，尽可能使用自动化手段 ； h) 宜 建立 可视化变更生命周期，支持全程数据分析管理 。 6.2.2 变更追溯 通过变更相关信息和状态的识别和查询，包括变更人员、变更时间、变更原因、变更内容等 进行 变 更追溯 ， 具体要求如下： a) 应 清晰定义版本号规则 ； b) 宜 实现制品和代码基线的关联，可追溯指定版本的完整源代码信息 ；

17、c) 宜 实现版本控制系统和变更管理系统的自动化关联，信息双向同步和实时可追溯 ； d) 变更依赖关系 宜 被识别和标记 ； e) 宜 实现数据库和环境变更信息的可追溯 ； f) 宜 实现从需求到部署发布各个环节的相关全部信息的全程可追溯 。 6.2.3 变更 回退 通过将变更恢复到变更之前状态的变更回退 ， 具体要求如下： a) 宜 实现变更管理系统和版本控制系统的 一 同 回退 ，保证状态的一致性 ； b) 回退 操作 宜 实现自动化 ； c) 宜 自动化 回退 全流程的所有变更包括变更依赖 ； DB32/T 3884-2020 6 d) 宜 准备经过验证且可接受的其它补偿或应急措施 以应

18、对不适用回退 的 场景 。 7 构建与持续集成 7.1 构建实践 7.1.1 构建方式 设计 通过源 代码转变为可运行程序的方法和过程的构建方式 ， 具体要求如下： a) 宜 采用脚本实现构建过程自动化 ； b) 宜 定义结构化构建脚本，实现模块级共享复用 ； c) 构建脚本 应 由专人统一维护 （可 兼职） ； d) 宜 实现构建方式服务化，可按需提供接口或用户界面，将构建能力赋予整个研发 团队 ； e) 宜 按场景实现构建过程可视化编排 ； f) 宜持续优化 构建服务平台，持续改进服务易用性 。 7.1.2 构建环境 搭建 通过构建实际运行过程的设备和资源依赖的载体的构建环境 ， 具体要求

19、如下： a) 宜 建立独立的构建服务器，多种任务共用构建环境； b) 构建环境配置 应 实现规范化； c) 宜 建立独立的构建资源 池； d) 宜 持续改进构建 环境以提高构建效能 。 7.1.3 构建计划 明确 通过 构建被触发的方式，频率和编排过程 ， 具体要求如下： a) 宜 细分构建类型， 如发布构建、测试构建 ； b) 宜 明确定义构建计划和规则，并在团队内共享 ； c) 宜 实现定期自动执行构建和代码提交触发构建 。 7.1.4 明确构建职责 通过 构建相关工具，系统和过程的责任主体 职责 ， 具体要求如下： a) 构建工具和环境 宜 由专门团队维护并细分团队人员职责 ； b) 宜

20、 构建实现自服务，将构建能力赋予全部团队成员，并按需触发构建实现 。 7.2 持续集成 7.2.1 搭建 集成服务 通过 持续集成运行的系统和环境 ， 以及集成团队的职责划分 的 集 成服务 ， 具体要求如下： DB32/T 3884-2020 7 a) 宜 搭建统一的持续集成服务 ； b) 宜 组建专门的持续集成团队，负责优化持续集成系统和服务模板 ； c) 宜 实现持续集成服务化和自助化，研发团队可自行使用持续集成服务 ； d) 宜 持续优化和改进团队持续集成服务，提升组织交付能力 。 7.2.2 集成频率 设定 研发编写的源代码向代码主干分支合并过程的方法和实施频率 ， 具体要求如下：

21、a) 研发人员 宜 具备 每天向代码主干集成一次 的能力 ； b) 研发人员 宜 具备每天多次向代码主干集成的能力，可按需集成任何变更（代码，配置，环境）。 7.2.3 集成方式 明确 通过 代码集成的触发条件和集成过程中的环节及输入输出 的 集成方式 ， 具体要求如下： a) 在部分分支上 宜 进行每天多次的定时构建 ； b) 每次代码提交 宜 触发自动化构建，构建问题通过自动分析，精准推送相关人员处理 ； c) 每次代码提交构建 宜 触发自动化测试和静态代码检查 ； d) 发现测试问题 宜 自动提醒 ； e) 测试结果 应 作为版本质量强制要求，如 采取质量门禁等方式强化主干代码质量 ；

22、f) 应 实现持续集成下的自动化测试分级 ，如单元测试、 SIT、 UAT。 8 测试管理 8.1 明确 测试分层策略 8.1.1 分层方法 选择 通过 测试体系按照不同的测试对象 ， 类型进行分类聚合的方法 ， 每一层对应了特有的测试需求分层 方法 ， 具体要求如下： a) 宜 采用 接口 /服务级测试对模块 /服务进行覆盖全面的接口 /服务 测试 ； b) 宜 采用探索性测试方法对需求进行深入挖掘测试 ； c) 系统 宜全面 进行性能、容量、稳定性、可靠性、易用性、兼容性、安全性等非功能性测试 ； d) 宜 采用代码级测试对核心模块的函数或类方法进行单元测试 ； e) 宜 采用代码级测试对

23、模块的函数或类方法进行覆盖全面的单元测试 ； f) 宜 采用测试驱动开发的方式进行代码级、接口级测试（ TDD） ； g) 宜 采用验收测试驱动开发的方式进行用户 /业务级的 UI 测试（ BDD/ATDD） 。 8.1.2 分层策略 建立 DB32/T 3884-2020 8 通过 基于测试分层策略对每部分的测试比重和投入 ， 以及覆盖 度等的划分策略 分层策略， 具体要求 如下： a) 宜 建立测试分层策略 ； b) 测试设计 宜 对接口 /服务级测试为主，兼顾用户 /业务级测试，辅以少量的代码级测试 ； c) 宜 对非功能性测试进行全面系统的设计 ； d) 测试分层策略的各层测试 宜 具

24、备交叉互补性； e) 对代码级测试 宜 尽可能提高覆盖度； f) 宜 定期验证测试分层策略，是否完整、有效，持续优化策略。 8.1.3 测试时机 选择 通过 测试接入软件研发过程的时间点和参与形式以及期望结果 的 测试时机 ， 具体要求如下： a) 在需求阶段 宜 进行用户 /业务级测试设计； b) 测试在自动交付过程中的介入时间 宜 提前到开发的编码阶段； c) 接口 /服 务级测试在模块的接口开发过程中 宜 同步进行和完成； d) 在需求特性开发、交付整个过程中 宜 同步进行并完成测试； e) 代码级测试在模块的函数或类方法开发过程中 宜 同步进行和完成。 8.2 代码质量管理 8.2.1

25、 质量规约 建立 通过对软件代码质量的 要求 和 规范 ， 涵盖编码规范 、 复杂度 、 覆盖率以及安全漏洞 、 合规性要求等 多个方面 的质量规约， 具体要求如下： a) 规约范围 宜 覆盖部分代码质量指标，如代码规范、 圈复杂度、重复度等质量指标 ； b) 应 建立组织级代码质量规约，在此基础上建立团队级定制的代码质量规约 ； c) 宜 建立完整的质量规约，将安全漏洞 检查 、合规检查纳入规约 ； d) 宜 建立强制执行的质量门禁体系 ； e) 宜 建立规约固定更新机制 ， 可根据业务需要灵活扩展和定制 ； f) 宜 定期验证代码质量规约的完整性和有效性，持续优化 。 8.2.2 检查方式

26、 明确 通过 代码质量规约检查 执行手段 、 触发条件 ，对执行效率、易用性等方面提出要求， 具体要求如下： a) 代码质量检查 宜 采用自动化结合手工方式进行 ； b) 对代码质量检查发现的部分问题 宜 自动提出修改建议，支持可视化 ； c) 宜 具备企业级的代码质量管理平台，以服务的形式提供对代码质量的检查、分析 。 8.2.3 反馈处理 DB32/T 3884-2020 9 通过 代码质量检查结果的收集、跟踪、处理的完整流程，可通过代码质量综合指标群（ 包括代码复 杂度、代码重复率等一系列业内常见详细指标）进行衡量 的 反馈处理 ， 具体要求如下： a) 宜 在研发阶段主动解决代码质量问

27、题； b) 整体代码质量问题 应 呈 现 下降趋势； c) 对代码质量数据 宜 进行统一管理； d) 应 有效追溯并对代码质量进行有效度量。 8.3 自动化测试 8.3.1 自动化 测试 设计 通过 测试分层中各种测试类型的自动化设计方法 ， 用于指导自动化测试工作的有效执行 ， 具体要求 如下： a) 宜 对故障和测试进行复盘，对遗漏的测试用例进行补充，不断优化和完善，持续提升覆盖率 ； b) 宜 对用户 /业务级的 UI 测试进行自动化设计 ； c) 宜 对接口 /服务级测试进行自动化设计 ； d) 宜 对代码级测试进行自动化设计 ； e) 宜 对性能、稳定性、可靠性、安全性等非功能性测试

28、进行自动化设计 。 8.3.2 自动化测试 开发 通过 依据自动化 测试 设计进行自动化测试工具、脚本、用例、框 架、系统等不同层面的开发 ， 具体 要求如下： a) 宜 使用版本控制系统对自动化测试脚本进行有效管理 ； b) 宜 建立统一的自动化测试框架，统一管理自动化测试用例 ； c) 宜 建立自动化测试自服务平台 ； d) 宜 优化自动化测试执行效率 ； e) 自动化测试 宜 资源池化 ； f) 宜 建立 持续优化的自动化测试平台 。 8.3.3 自动化 测试 执行 通过 自动化测试的执行条件和触发机制 ， 以及测试问题的跟踪处理机制 ， 从而满足自动化 测试 设计 的目标 ， 具体要求

29、如下： a) 宜 对用户 /业务级 UI 测试采用自动化测试 ； b) 宜 对接口 /服务级与代码级测试采用自动化测试 ； c) 自动化测试 宜 由流水线自动化触发； d) 宜 建立组织级的统一自动化测试平台，和上下游需求、变更管理系统打通； DB32/T 3884-2020 10 e) 宜 可以根据需求选择关联的自动化测 试用例执行 ； f) 可以将由于版本原因导致的失败用例和缺陷关联 ； g) 宜 定期验证自动化执行策略，持续优化测试执行效率和资源利用率 。 8.3.4 自动化 测试 分析 通过 自动化测试结果的准确性数据分析能力 ， 以提供更多的反馈信息用来优化和持续改进自动化测 试流程

30、 ， 具体要求如 下： a) 自动化测试数据模型 宜 规范化，和上 下游需求、缺陷等研发数据关联，可以对自动化测试效果 进行度量分析，如 需求测试覆盖率、测试通过率和测试效率等 ； b) 对自动化测试结果 宜 进行智能分析，自动分析失败用例的失败类型，能自动向缺陷管理系统提 交缺陷。 9 部署与发布管理 9.1 部署与发布模式 9.1.1 部署方式 选择 通过 软件包部署到线上生产环境或者交付用户的过程所采用的工具和方法 ， 具体要求如下： a) 运维人员 宜 通过自动化脚本实现部署 ； b) 部署发布服务 宜 自动 化，实现 开发测试阶段自助一键式多环境自动化部署 ； c) 宜 支持数据库

31、脚本 自动化部署 ； d) 宜持续优化 部 署发布模式和工具系统平台 。 9.1.2 部署过程 通过 软件上线部署环节的实践方法以及完成部署活动的能力 ， 具体要求如下： a) 应 使用相同的过程和工具完成所有环境部署 ； b) 一次部署过程中 应 使用相同的构建产物 ； c) 部署过程可灵活响应业务需求变化，通过合理组合实现灵活编排 ； d) 开发或测试环境下持续部署，每次变更都 宜 触发自动化部署过程，以便于快速开发或验证 。 9.1.3 部署策略 通过 部署过程的执行频率和部署内容以及部署手段来保证安全快速顺畅的生产部署 ， 具体要求如 下： a) 宜 实现测试环境的自动化部署 ； b)

32、 应用和配置 宜 进行分离 ； c) 宜 采用定期部署策略，具备按天 进行部署的能力 ； DB32/T 3884-2020 11 d) 宜 通过低风险的部署发布策略保证流程风险可控，如 蓝绿部署，金丝雀发布 ， 进行安全可靠地 部署和发布。 9.1.4 部署质量 通过 部署活动的成功率和确保部署质量提升的机制和能力 ， 具体要求如下： a) 宜 实现应用部署的 回退 操作，问题可及时修复 ； b) 每次部署活动 宜 提供变更范围报告和测试报告 ； c) 宜 部署活动集成自动化测试功能，并以测试结果为部署前置条件 ； d) 宜 建立监控体系跟踪和分析部署过程，出现问题自动化降级； e) 宜 建立

33、持续优化的部署监控体系。 9.2 部署流水线 9.2.1 协作模式 确立 通过 软件从需求到上线交付各个环节中各责任主体之间的信息传递 和交互方式 ， 体现整体交付过程 顺畅程度 ， 具体要求如下： a) 宜 通过定义完整的软件交付过程和清晰的交付规范，保证团队之间交付的有序 ； b) 团队间交付 宜 按照约定由系统间调用完成，仅在必要环节进行手工确认 ； c) 团队间依赖 宜 解耦，尽可能实现独立安全的自主部署交付 ； d) 宜 持续优化交付业务组织以灵活响应业务变化，改善发布效率 。 9.2.2 流水线过程 通过 软件交付过程中各个环节活动的实现机制和整体交付的触发条件 ， 具体要求如下：

34、 a) 软件交付过程中的各个环节 宜 建立自动化能力以提升处理效率 ； b) 宜 打通软件交付过程中的各个环节，建立全流程的自动化能力并根据 自动化测试结果保障软件 交付质量 ； c) 宜 建立可视化部署流水线，覆盖整个软件交付过程 ； d) 每次变更都会触发开发测试环境下完整的自动化部署流水线 ； e) 宜 持续改进部署流水线 。 9.2.3 过程可视化 建设 通过 软件交付过程中信息的可见程度 ， 以及所展现数据对于业务价值的展现能力 ， 具体要求如下： a) 交付状态可追溯 ； b) 交付过程组织内部 宜 按需配置可见 ； c) 宜 团队共享度量指标 ； d) 对过程信息 宜 进行有效聚

35、合分析展示趋势 ； DB32/T 3884-2020 12 e) 宜 对 部署流水线过程信息进行数据价值挖掘，推动业务改进 。 10 度量与反馈 10.1 度量指标 10.1.1 度量指标定义 通过 度量指标设计的依据和生效领域，用于识 别符合业务需求的度量指标 （如表 2 所 示） ， 具体要 求如下： a) 在自动交付各个阶段 宜 定义部门级的度量指标； b) 宜 建立跨组织度量指标，进行跨领域综合方面的度量； c) 宜 共享核心业务度量指标； d) 宜持续优化 度量指标，自我驱动持续改进。 10.1.2 度量指标类型 选择 通过 度量指标的覆盖，确保 完整度 ， 具体要求如下： a) 宜

36、 覆盖结果指标，如变更频率，需求交付前置时间，变更失败率和平均修复时间 ； b) 宜 覆盖过程指标，客观反映组织研发现状 ； c) 宜 覆盖探索性指标，并展示趋势，预测潜在问题，并及时预警 ； d) 宜 建立度量指标的有效反馈机制，并持续优化度量指标分类 。 10.1.3 度 量数据管理 通过 度量数据的收集 ， 分析和管理 ， 具体要求如下： a) 宜 持续收集度量数据，历史度 量数据具备明确 的管理规则 ； b) 宜 对历史度量数据进行有效的挖掘分析 。 10.1.4 度量指标更新 通过 度量指标的更新机制 ， 具体要求如下： a) 度量指标可以按照需求进行更新 ； b) 度量指标可基于大

37、数据分析和人工智能自动识别和推荐动态调整指标优先级 。 表 2 部分 参考度量指标 阶段 度量指标定义 版本控制 代码仓库数量 代码提交数 代码提交频率 代码提交时间分布 DB32/T 3884-2020 13 构建 构建次数 构建频率 构建时长 构建失败率 构建修复时间 代码 代码行数 代码复 杂度 代码重复率 单元测试覆盖率 单元测试用例数 单元测试成功率 环境 环境变更时长 变更频率 容器镜像更新 活跃容器数量 资源使用统计 部署 部署版本数量 部署时间 部署成功率 部署回退率 10.2 度量驱动改进 10.2.1 内容和生成方式 通过 度量报告的生成手段和数据展示能力 ， 具体要求如下

38、： a) 度量报告 宜 以自动化方式生 成，明确规 范格式定义 ； b) 度量报告 宜 进行分类分级并按需生成内容 ； c) 宜 建立跨组织级统一的数据度量平台，度量报告基于平台定制化生成，支持多种类型，如表格、 看板等 ； d) 宜 持续优化度量方法、 度量平台和度量展现形式 。 10.2.2 数 据时效性 通过 度量报告所体现结果的及时性以及实时更新能力 ， 具体要求如下： a) 数据报告可展现最新状态 ； b) 宜 通过可视化看板实时展示数据 ； c) 宜 通过可视化看板聚合报告内容，多方面展示实时状态，支持自动生成数据趋势图和趋势分析 。 10.2.3 覆盖范围 可查看度量报告的人员范围 ， 具体要求如下： a) 宜 实现报告精准范围推送，支持主动订阅 。 10.2.4 反馈改进 DB32/T 3884-2020 14 通过 度量发现的问题的处理方式 ， 具体要求如下： a) 度量反馈问题 宜 纳入研发迭代的待办事项列表，作为持续改进的一部分 ； b) 宜 建立度量问题持续改进机制，预留工作时间用于解决度量反馈问题，识别有效改进并扩展 到 整个组织，作为企业级知识体系积累保留 ； c) 宜 通过数据挖掘实现跨组织跨流程数据度量分析，分析结果作为业务决策的重要依据，帮助组 织持续改进 价值交付流程 。 _