1、 ICS 35.020 L70 YD 中华人民共和国通信行业标准 XXXX-XXXX 代替 YD/T 研发运营一体化（ DevOps）能力成熟度 模型 第 8 部分：系统和工具技术要求 The capability maturity model of devops part 8: system and tools technical requirement （报批稿） （本稿完成日期： 2020.06.28） -发布 -实施 中 华 人 民 共 和 国 工 业 和 信 息 化 部 发 布 YD/T 0605T2019 I 目 次 引 言 .VI 前 言 .V 1 范围 .1 2 规范性引用文件
2、 .1 3 术语和定义 .1 4 缩略语 .9 5 总体架构 .10 5.1 项目与开发管理 .11 5.1.1 项目管理 .11 5.1.2 工作项管理 .11 5.1.3 计划管理 .12 5.1.4 文档与知识管理 .12 5.1.4.1 文档管理 .12 5.1.4.2 知识管理 .13 5.1.5 团队协同 .13 5.1.6 统计度量 .14 5.1.7 项目集管理 .14 5.2 应用设计与开发 .15 5.2.1 应用框架 .15 5.2.2 集成开发环境 .15 5.2.3 威胁建模 .16 5.3 持续交付 .17 5.3.1 版本控制系统 .17 5.3.2 构建与持续集
3、成 .18 5.3.3 流水线 .19 5.3.4 制品管理 .19 5.3.5 部署管理 .20 5.3.6 发布管理 .21 5.3.7 环境管理 .21 5.3.8 应用配置管理 .21 5.3.9 数据变更管理 .22 5.3.10 移动应用安全加固 .22 5.4 测试管理 .23 5.4.1 用例与测试计划管理 .23 5.4.1.1 用例管理 .23 5.4.1.2 测试计划管理 .23 YD/T 0605T2019 II 5.4.2 测试数据管理 .24 5.5 自动化测试 .25 5.5.1 代码质量管理 .25 5.5.2 单元测试 .25 5.5.3 接口 /服务测试 .
4、26 5.5.4 UI 测试 .26 5.5.5 移动应用测试 .27 5.5.5.1 适配兼容测试 .27 5.5.5.2 移动自动化测试 .27 5.5.5.3 客户端性能测试 .28 5.5.6 性能测试 .29 5.5.7 安全性测试 .29 5.5.7.1 静态应用安全测试 .29 5.5.7.2 开源组件安全测试 .30 5.5.7.3 动态应用安全测试 .31 5.5.7.4 交互式应用安全测试 .32 5.5.7.5 移动应用安全测试 .32 5.5.7.6 容器静态安全测试 .33 5.5.7.7 基础设施安全测试 .34 5.6 技术运营 .35 5.6.1 配置管理 .3
5、5 5.6.2 运维数据分析 .36 5.6.2.1 数据采集与接入 .36 5.6.2.2 数据处理 .37 5.6.2.3 数据存储 .37 5.6.2.4 数据建模 .37 5.6.2.5 数据查询 .38 5.6.2.6 数据分析 .38 5.6.2.7 数据可视化 .38 5.6.3 应用性能监控 .39 5.6.4 基础监控管理 .41 5.6.5 日志监控管理 .42 5.6.6 自动化作业平台 .44 5.6.7 容量管理 .45 5.6.8 成本管理 .45 5.6.9 资产安全风险管理 .46 YD/T 0605T2019 III 引 言 研发运营一体化是指在 IT软件及相
6、关服务的研发及交付过程中，将应用的需求、开发、测试、部 署和运营统一起来，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的 无缝集成。帮助企业提升 IT效能，在保证稳定的同时，快速交付高质量的软件及服务，灵活应对快速 变化的业务需求和市场环境。 YD/T 0605T2019 IV 前 言 本标准是研发运营一体化（ DevOps）能力成熟度模型系列标准之一。该系列标准的结构及名称如 下 : 研发运营一体化（ DevOps）能力成熟度模型 第 1部分：总体架构 研发运营一体化（ DevOps）能力成熟度模型 第 2部分：敏捷开发管理 研发运营一体化（ DevOps）能力成熟度
7、模型 第 3部分：持续交付 研发运营一体化（ DevOps）能力成熟度模型 第 4部分：技术运营 研发运营一体化（ DevOps）能力成熟度模型 第 5部分：应用设计 研发运营一体化（ DevOps）能力成熟度模型 第 6部分：安全及风险管理 研发运营一体化（ DevOps）能力成熟度模型 第 7部分：评估方法 研发运营一体化（ DevOps）能力成熟度模型 第 8部分：系统和工具技术要求 本部分是第 8部分：系统和工具技术要求 本部分按照 GB/T 1.12009给出的规则起草。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本部分由中国通信标准化协会提出并
8、归口。 本部分起草单位：中国信息通信研究院、北京华佑科技有限公司、腾讯云计算（北京）有限公 司、阿里云计算有限公司、北京百度网讯科技有限公司、华为技术有限公司、中兴通讯股份有限公 司、北京凌云雀科技有限公司、北京神州泰岳软件股份有限公司、平安科技（深圳）有限公司、亚信 科技（中国）有限公司、苏宁消费金融有限公司、北京优特捷信息技术有限公司、东软集团股份有限 公司、京东云计算有限公司、安徽继远软件有限公司、中国移动通信集团有限公司、中国电信集团有 限公司、新华三技术有限公司、北京金山云网络技术有限公司、畅捷通信息技术股份有限公司、中国 联合网络通信集团有限公司、普元信息技术股份有限公司、中软国际
9、科技服务有限公司 本部分主要起草人：牛晓玲、萧田国、景韵、刘凯铃、党受辉、刘章雄、孙辰星、张嵩、庄飞、 李青、徐毅、武丹、杨文兵、殷柱伟、董越、黄博文、陈鑫、韩晓光、熊星、鞠炜刚、单致豪、王津 银、 Daniel Morinigo、吴平福、张凯、梁奂、戚文平、车昕、顾黄亮、李滨、张祖优、乐元、吴文 灏、饶琛琳、考明军、王超、茹炳晟、井亮亮、姚剑芒、何毅鹏、王一男、聂智戈、姚彬、王晓君、 冯斌、刘通博、冷大鲲、申屠欣欣、林科、张小燕、石磊、金桐、杨奕、隆迪、王永霞、马全一、张 婷婷、程莹、郭圣珠、吕全林、熊昌伟、王燕子、李卜、王浏明、李明亮、王迪、王云峰、马婷、李 励立 YD/T 0605T20
10、19 1 1 范围 本部分规定了研发运营一体化（ DevOps）过程中所涉及的系统和工具的能力技术要求。 本部分适用于 IT软件研发交付运营的使用方实施相关系统、工具和服务建设进行评价和指导；可 供其他相关行业或组织进行参考；也可作为第三方权威评估机构衡量软件开发交付运营工具成熟度的 标准依据。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本 文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 1 GB/T 8566-2007 信息技术 软件生存周期过程 2 GB/T 11457-2006 信息技术 软件工程术语
11、 3 术语和定义 下列术语和定义适用于本文件。 3.1 项目 project 需要协同工作的一组任务，其目的在于开发和（或）维护一个具体的产品。产品可以包括硬件、 软件或其他成分，一般项目有自己的经费、成本核算和交付进度。 GB/T11457-2006： 2.1255 3.2 项目集 program 经过协调管理以获取单独管理所无法取得的收益的一组项目、子项目集和项目集活动。 3.3 子项目集 sub program 作为另一个项目集的组成部分而被管理的一个项目集。 3.4 研发运营一体化（ DevOps）能力成熟度模型 第 8 部分：系统和工具技术要求 YD/T 0605T2019 2 负载
12、均衡 load balance 一种计算机技术，用来在多个计算机（计算机集群）、网络连接、 CPU、磁盘驱动器或其他资源中 分配负载，以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的，用于解 决互联网架构中的高并发和高可用的问题。 3.5 运行环境 runtime environment 构建中运行的环境或者计算机。 3.6 金丝雀发布 canary release 在黑与白之间，能够平滑过渡的一种发布方式。又称灰度发布， A/B测试就是一种灰度发布方式， 让一部分用户继续用 A，一部分用户开始用 B，如果用户对 B没有什么反对意见，那么逐步扩大范围，把 所有用户都迁移到
13、 B上面来。可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以 保证其影响度范围的一种发布方式。 3.7 蓝绿发布 blue-green release 在发布过程中，新旧版本相互热备，发布过程是不停止老版本，直接部署新版本然后进行测试， 通过切换路由权重的方式（非 0即 100）实现将流量切到新版本，然后老版本同时也升级到新版本，是 一种可以保证系统在不间断提供服务的情况下的发布方式 。 3.8 回滚 rollback 程序或数据处理错误，将程序或数据恢复到上一次正确状态的行为。回滚包括程序回滚和数据回 滚等类型。 3.9 网络钩子 Webhook 微服务 API的使用范式之一
14、，即前端不主动发送请求，完全由后端推送。 3.10 环境 environment 应用程序运行所需的所有资源和它们的配置信息，通常分成两大类：基础设施资源及其配置；应 用程序独立运行所需要的操作系统和中间件资源及其配置信息。 3.11 配置项 configuration item YD/T 0605T2019 3 一个配置中的实体，它满足一项最终使用功能，并能在给定的基准点上单独标识。 GB/T 8566- 2007： 3.6 3.12 配置管理 configuration management 是一个过程，通过该过程，可以维护一切与环境相关的信息，这些信息可以被定义、修改、存储 和检索。应用
15、技术和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的 变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。 GB/T11457-2006： 2.313 3.13 开发环境 development environment 用于维持开发过程的一个或者一组资源及其配置信息，面向的是开发者。 3.14 测试环境 test environment 测试运行其上的软件和硬件环境的描述，以及任何其他与被测软件交互的软件，包括驱动和桩。 3.15 生产环境 production environment 用于维持开发过程的一个或者一组资源及其配置信息，面向的是运维，但其运行服务
16、面向的是用 户或者客户。 3.16 基础设施 infrastructure 支持应用运行的所有服务，包括 DNS服务器、防火墙、路由器等等。 3.17 中间件 middleware 一种类型的软件模块，它处在系统软件和应用软件之间，依赖系统软件的支持，又为应用软件提 供支持，以方便应用软件的开发。 GB/T11457-2006： 2.954 3.18 性能测试 performance test 通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测 试。评价系统或部件与规定的性能需求的依从性的测试行为。 GB/T11457-2006： 2.1135 3.19 构建环
17、境 build environment YD/T 0605T2019 4 指执行构建任务时所在设备的软件和硬件环境。 3.20 构建任务 build task 指定义从输入到输出过程对构建环境、构建方法等必要因素的定义。 3.21 构建过程 build process 指构建任务从开始执行到结束。 3.22 复刻 fork 在软件开发中，开发者为一个版本仓库创建一份拷贝，并在拷贝上进行独立于源版本仓库的开 发，从而分离出一个新的软件副本的活动。复刻不仅仅创建了一个分支，还将软件开发活动与源版本 库分离开来。 3.23 合并 merge 当一个版本在多个独立分支中被修改后如何合并这些修改成为同一个版本的操作。 3.24 合并评审 merge requests 在合并之前，允许多人对合并时所提交的变更内容进行代码审查，并给予合并意见的过程。 3.25 基线 baseline 版本仓库中每个版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标 准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记 录为一个差值，直到建成下一个基线。 3.26 版本仓库 repositories 被用来存储源代码等版本文件。 3.27 代码审查 code review YD
