一、DevOps 标准体系

2017年11月17日，云计算开源产业联盟第一次跟高效运维社区一起在上海合办了首届金牌运维峰会，在工信部软件司的指导下，由中国信通院牵头的云计算开源产业联盟在推动运维相关标准方面也有了很大成果，我将代表编写团队，发布两个已经完成的标准（DevOps 标准、蓝鲸运维标准），本文将着重介绍 DevOps 标准。

1.1、DevOps 体系

DevOps 的标准体系，目前我们发布的是一个 Beta 版，用我们业界比较流行的代码术语是一个体验版。

为什么要做 DevOps 的标准体系，已经有这么多的最佳实践和开源工具，我们为什么要做这个事情呢？

我们经常在不同的场合听到了 DevOps 这个词，但是我听到大家讲的角度维度都不一样，有人认为自动化运维就是 DevOps，有人认为运维的人员会开发，是不是就是 DevOps，那么还有一些我们的容器厂商从产品的角度说 DevOps，还有我们从培训的角度去玩玩沙盘，是不是就会懂了 DevOps，是不是我们把上面的组合起来就知道什么是 DevOps 呢？其实不是的。

我们在不同场合听到 DevOps 都好像盲人摸象一样，谁都只是摸到了大象的一部分。所以我们做这件事情的目的主要有两方面：

第一个方面就是三正，正什么呢？

• 第一正概念，就是 DevOps 的概念，它的范畴；
  
  

• 第二个就是正框架，我们 DevOps 到底包含哪几个过程，从人员组织架构到工具，到底要达到一个什么样的框架才是 DevOps；
  

• 第三个就是正能力，很多人说 DevOps 太难了，目前我们公司做不到，其实有的时候觉得难，是因为我们不知道如何达到，所以在这里我们的标准叫做能力的成熟度模型，也就是说你很容易的清楚自己在哪个层级，那么你也很清楚如何晋级到更高级的 DevOps 的能力，这样一个很清晰的标准。
  

正因为我们可以做到三正，所以这个标准是有实操意义的，拿了这个标准，不管是运维人员还是 CIO 等等，就可以看到你们的公司团队如何根据这个标准去明确不同的流程，明确不同的组织架构，明确如何一步一步的去实施。

1.2、DevOps 体系系列标准——前三部分

我们这个标准体系一共有7部分：

第1部分是总体架构，包括概念和框架和能力的分级。从第2部分到第7部分就是我们这个框架里的每一个部分的能力成熟度模型，主要包括敏捷开发过程，持续交付过程，技术运营过程，还有总的应用框架、安全管理和组织结构。可以看到从第2部分到第4部分，都是过程类的，第5部分是应用架构类的，第6部分是安全管理类的，第7部分是组织结构类的。

“研发运营一体化能力成熟度模型”，是国内外第一个 DevOps 标准体系。

DevOps 标准体系包含下面两大目的：

• 第一，是明确概念、框架、能力。DevOps 的概念、框架和能力到达什么程度，做一个非常详细明确的说明。
  
  

• 第二，对于 DevOps 涵盖的流程、组织、实施，有明确的指引，企业可以按照这个标准去提升自己 DevOps 各个环节的能力。
  
  

本次发布的是前3部分的征求意见稿。

二、DevOps 系列标准前三部分

前三部分为总体架构，敏捷开发管理过程和持续交付过程相关标准。以下为您详细解读。

2.1、第1部分：总体架构

研发运营一体化（DevOps）能力成熟度模型覆盖端到端软件交付生命周期全流程，是一套体系化的方法论、实践和标准的集合。研发运营一体化总体架构可划分为三部分，即过程（敏捷开发管理、持续交付、技术运营）、应用架构和组织结构。

• 研发运营一体化过程： 从需求开发、交付、运营这几个环节的过程，这三个过程涵盖了很多内容。整个过程我们把它标准化地分成了三部分。
  
  

• 敏捷开发管理从需求管理、计划管理、过程管理、度量分析这四个维度，关注需求到开发阶段的有序迭代，灵活响应，以及价值的快速交付。
  
  

• 持续交付关注应用软件集成交付环节，通过配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理和度量管理领域的能力建设和工程实践保证软件持续顺畅高质量的对用户完成发布。
  
  

• 技术运营，技术运营环节关注应用系统服务发布后的环节，涉及运维成本服务、高可用架构服务、用户体验服务、客户服务、监控服务、产品运行服务和运营数据服务，保障良好的用户体验，打造持续的业务价值反馈流。这里大家要记住一点，我们没有提运维，提的是运营。DevOps 涵盖了敏捷开发、持续交付和技术运营三个过程，这是从过程去理解 DevOps。
  
  

为什么呢？因为 Operation 这个词它本身的含义就有运维运营的双重意思。

并且现在运营人员所做的事情，已经不是简单的背锅。往往背锅的时候还要提炼点东西。大家要用大数据也好，智能化也罢，都是把自己的运维能力转变为运营部门提供更多的数据支撑。

• 研发运营一体化应用架构，DevOps 的标准除了过程工程以外，还涉及到应用架构。应用架构指的是应用系统的开发、测试和部署，是否用了微服务等架构。
  
  

• 研发运营一体化安全管理，这是非常重要的，因为 DevOps 在一定程度上降低了安全性，也称为很多企业落地 DevOps 的阻碍之一。这次侧重全流程端到端的全局考虑安全管理及服务。
  
  
  

• 研发运营一体化组织结构，最深层的就是组织结构的问题。我们知道怎么去做，但是不一定能做到？是因为这三个过程覆盖了某个企业N个部门。据我了解不同的行业，开发、运维都是不同的部门。甚至在金融行业、银行的开发、测试和生产也在不同的部门。
  
  

所以如果应用架构、安全管理和组织架构跟不上，也是做不到 DevOps 能力的。往往是每个环节把自己的事做好的，需求迸发出来了，可能才会去推动进一步的组织结构的变动，这是第三个纬度的事情。

理解 DevOps 可以从过程、多个点、不同维度去理解。DevOps 是一个过程，过程里的每一个小环节，涉及到人、团队、工具。后面分级的理念也是每个小环节从人、过程管理、工具团队的协作这几个纬度去分的。

要做好 DevOps，首先把每个小环节做好，进而把整个过程做好了，然后再推动整个组织架构一系列的变革。

为什么这里叫运营研发一体化，不叫 DevOps 呢？

因为国内标准不能出现英文词的，而且 DevOps 这个词它是具有阶段性的。也许过个十几年就没有 DevOps 了，标准要普世性，所以这里没有用 DevOps，用的是研发运营一体化。从这个词也可以看出来它贯穿了研发，一直到运营。

成熟度分级的对象，就是研发运营一体化，研发运营一体化就是刚才讲的那几个纬度。我们分级的时候，可以对整个研发运营一体化进行分级，也可以小到某个环节，大到某个部分去进行成熟度的分级。

这样有助于了解每个环节的情况，有助于逐个击破，提升自己 DevOps 的能力。分级成熟度就是从阻碍一直到优化这五个级别，很容易理解。

2.2 、第2部分：敏捷开发过程

这里面讲的是敏捷需求管理、迭代计划管理和敏捷过程管理，属于刚才讲的第一级的环节，每一个环节可以分成很多小环节。

其中需求管理细分为需求收集、需求分析、需求与用例和需求验收四个细分维度。需求收集从单个需求点、需求全貌、需求的管理、人员机制以及工具能力五个维度进行评估；需求分析从需求内容和形式、需求协作、需求的管理、人员机制以及工具能力五个维度进行评估；需求与用例从需求与用例编写、需求用例验证、需求与用例的管理、人员机制以及工具能力五个维度进行评估；需求验收从需求验收频率、需求验收范围、需求验收反馈效率、人员机制以及工具能力五个维度进行评估。

其中计划管理细分为需求澄清与拆解、故事与任务排期、计划变更三个维度。需求澄清与拆解从需求澄清的时间、内容的完备性、协作、人员机制以及工具能力五个维度进行评估；故事与任务排期从排版要素、排版容量、排版管理、人员机制以及工具能力五个维度进行评估；计划变更从变更决策、应对变更、减少变更、人员机制以及工具能力五个维度进行评估。

其中过程管理细分为迭代管理、迭代活动、过程可视化及流动、度量分析四个维度。

• 迭代管理从迭代时间周期、迭代协作机制、迭代流程改进、人员机制以及工具能力五个维度进行评估；
  
  

• 迭代活动从迭代活动约定、迭代活动时间约定、迭代活动范围、人员机制以及工具能力五个维度进行评估；
  
  

• 过程可视化及流动从过程可视化、过程价值流动、迭代过程改进、人员机制以及工具能力五个维度进行评估；
  
  

• 度量分析从度量粒度、度量范围、度量驱动持续改进、人员机制以及工具能力五个维度进行评估。
  
  

以下就部分内容进行阐述。

敏捷开发过程-需求管理-需求收集

需求收集环节是需求提出方和产品经理之间明确产品需求的阶段，是产品研发运营一体化最初始阶段，把产品的需求具象化，形成待办事项列表的过程。

需求收集环节包括三个方面工作:

• 明确单个需求点 即以问题驱动为核心，探索问题核心相关事项的过程
  
  

• 梳理需求全貌 应能列出为了落实产品的愿景而需要 完成的所有事项，即待办事项列表
  
  

• 确定待办事项列表 应包括用户需求所涉及的所有事 项，并且作为产品研发路线图
  
  

这三个工作从人员机制到工具能力，会用到不同程度的工具，以及人员协作的流畅度，协作的程度是不一样的。所以把它分成五级，大家可以看一下上图右边的内容。

最高级的是，需求方就是产品经理可以把需求方的每个点形成一个功能点，并且把功能点形成整个需求的全貌，形成一个列表，进一步形成路线图，这个路线图可以是在后续的迭代开发中不断的优化。

在工具能力方面会用到很多需求管理，用统一的工具对需求进行管理。组织架构方面，企业采用扁平化的敏捷团队组织架构，赋予团队围绕产品自组织、自管理的权力，包括但不限于产品规划、建设、运营、人力、绩效、核算等。

例如，敏捷团队以业务价值为核心以运营为驱动的敏捷工作模式，企业为团队提供IT基础设施、基础管理等支持。第一个环节，如果做到这一级的话，是非常好的。如果是普通程度的情况，一个是传达的需求不明确，第二个没有用到任何的工具，这样普通的级别在后续的迭代计划中根据计划的改变而进行改变，是不够灵活的。

这是需求收集环节我们的分级。大家可以对应表看看你是属于哪个程度哪一级的。

敏捷开发过程-需求管理-需求分析

需求分析是产品经理将需求细化和拆解成用户故事的过程。

主要体现三个方面:

• 明确需求内容和形式 需求分析形成用户故事，用户故事描述用户场景
  
  

• 需求分析协作 用户故事是适度详细并适应变化的，可以在开发过程中对其进行评估不断细化
  
  

• 需求管理方式 用户故事统一管理，并按照业务价值由高到低排定优先级
  
  

需求分析最主要的方式把整个甲方或者需求方的需求场景，进行统一的分类。在开发过程中对它进行不断的评估，进行细化，最后把场景按照业务价值，由高到低进行排定优先级。

上面需求收集只是说形成了一个待办事项列表，保证不停的更新。这个时候需求分析能够按照不在待办事项里，能够按照优先级去进行标注，进一步根据后面的迭代开发情况进行不断的反馈。

敏捷开发过程-需求管理-需求与用例管理

需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性，能验收产品功能是否满足用户故事的要求的过程。

主要体现在三个方面:

• 梳理需求用例 编写需求验收标准，形成测试用例的过程
  

• 使用需求用例 需求用例指导需求开发，验证产品功能的过程
  

• 管理需求用例 建立需求与用例的统一管理库，持续的使用和优化
  
  

刚才已经把需求分了级，分了场景后，开发有没有达到我们的需求呢？这个地方对需求管理很重要了，要预先有一些测试例，能够很好地判断后面的开发有没有达到。如果有问题再反馈回来，我们的需求进一步调整。

应建立企业级可视化便捷的平台，管理需求文档，且可以通过需求文档能查看产品的全貌，且通过平台，需求提出人、最终使用人、产品经理、开发运维人员进行更好的沟通和协作。保证可持续性，它有一个持续，每个环节都可以持续，持续都是持续到下一个环节，交付环节的。

敏捷开发过程-需求管理-需求验收

需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，要求能对需求进行快速测试、快速确认、快速反馈、快速优化。

本节的需求验收，仅是指功能验收，非功能测试不在本节的范围内。需求验收主要体现在以下三个方面:

• 需求验收的频率 指不同角色对需求功能验收的频率，频率越高效果越好
  
  

• 需求验收的范围 指需求验收应尽量具备有业务价值的端到端的验收
  
  

• 需求验收的反馈效率 指需求验收的结果能准确、快速的反馈到开发团队的过程
• 
  
  
  

最后是需求的验收，包括设计验收的频率、制定验收的测试方案、指标等等。并不是强制要求你的频率一定要达到多少次。不同的产品验收频率验收结果是不一样的。更多是告诉你一种方法论，在这个过程中也是需要你用到一系列的工具，去辅助你能够自动化去进行需求的验收等等。

最高级别应建立企业级大数据分析工具，能抓取用户行为数据，通过大数据分析，在用户功能验收和用户体验时作为辅助决策依据，持续优化改进。需求的环节在敏捷开发里是非常重要的，下面的环节叫迭代计划管理。

其他相关标准内容，详解相关文档（文末可下载）。

2.3、 第3部分：持续交付过程

第三个标准就是持续交付的过程，它分为配置管理、部署等等，分了好几个环节。每个环节包括一些子环节，每个子环节从很多纬度进行能力的评估。

其中配置管理细分为版本控制、版本可追踪性两个维度。版本控制从版本控制系统、分支管理、构建产物管理、单一可信数据源四个维度进行评估；版本可追踪性从变更过程、变更追溯、变更回滚三个维度进行评估。

其中构建与持续集成分为构建实践、持续集成两个维度。构建实践从构建方式、构建环境、构建计划、构建职责四个维度进行评估；持续集成从集成服务、集成频率、集成方式、反馈周期四个维度进行评估。

其中测试管理分为测试分级策略、代码质量管理、测试自动化三个维度。测试分级策略从分层方法、分层策略、测试时机三个维度进行评估；代码质量管理从质量规约、检查策略、检查方式、反馈处理四个维度进行评估；测试自动化从自动化设计、自动化开发、自动化执行、自动化分析四个维度进行评估。

其中部署与发布管理分为部署与发布模式、持续部署流水线两个维度。部署与发布模式从部署方式、部署活动、部署策略、部署质量四个维度进行评估；持续部署流水线从协作模式、流水线过程、过程可视化三个维度进行评估。

其中环境管理分为环境类型、环境构建和环境依赖与配置管理。

其中数据管理分为测试数据管理和数据变更管理两个维度。测试数据管理从数据来源、数据覆盖、数据独立性、数据安全四个维度进行评估；数据变更管理从变更过程、兼容回滚、版本控制、数据监控四个维度进行评估。

其中度量与反馈分为度量指标和度量驱动改进两个维度。度量指标从度量指标定义、度量指标类型、度量数据管理、度量指标更新四个维度进行评估；度量驱动改进从报告生成方式、报告有效性、报告覆盖范围、反馈改进四个维度进行评估。

持续交付-配置管理-版本控制

版本控制是从版本控制系统、分支管理和构建产物管理和单一的可信数据源。

从五个方面对它进行成熟度的分级。最高级，比如在版本控制系统方面，要有版本的控制系统，产品开发的版本控制系统。它是有生命周期的，所有的版本，包括修改等等流程都可以进行管理。比如分支的管理，就是持续优化分支管理策略，等等。

持续交付-配置管理-版本可追溯性

版本的可追溯性，版本可追溯性是指软件系统中的每一次变更都可以追溯变更的详细信息，并向上追溯变更的原始需求、流转过程等所有关联信息。支持全程的数据分析管理和满足审计的要求。这里审计要求是指你这个产品的开发，每一步 BUG 的修改、每一步的变更是谁做的，它修改了哪一步。也是可追溯的意思。

可追溯性也是版本回滚的历史依据和实施基础，建立良好的版本可追溯性可实现对任一版本完整环境流程的自动化，精确回滚，快速重现问题和恢复正常环境。

持续交付-构建与持续集成-构建实践

版本的管理就是构建与持续的集成。构建的实践包括持续优化的构建服务平台、持续改建服务的易用性。

构建是将软件源代码通过构建工具转换为可执行程序的过程，一般包含编译和链接两个步骤，将高级语言代码转换为可执行的机器代码并进行相应的优化，提升运行效率。

持续集成是软件构建过程中的一个最佳实践，在版本控制的基础上，通过频繁的代码提交，自动化构建和自动化测试，加快软件集成周期和问题反馈速度，从而及时验证系统可用性。

这里可以用容器管理工具，因为容器很方便可以把很多应用做成标准化，封装成容器的格式，方便不断做镜像，不断进行扩充管理。方便了微服务架构的开发，可以去管理一些应用，所以这里很多人都会用到容器的原因，在这把它当做一个管理的工具去实现了。

持续交付-构建与持续集成-持续集成

跟构建实践差不多的，持续优化和改进团队的持续集成的能力和变更。

持续交付-部署与发布管理-部署与发布模式

部署与发布泛指软件生命周期中，将软件应用系统对用户可见，并提供服务的一系列活动，包括系统配置，发布，安装等。整个部署发布过程复杂，涉及多个团队之间的协作和交付，需要良好的计划和演练保证部署发布的正确性。

其中部署偏向技术实践，即将软件代码，应用，配置和数据库变更应用到测试环境、准生产环境和生产环境的过程。发布偏向于业务实践，指将部署完成的应用软件功能和服务正式对用户可见，提供线上服务的过程。部署和发布的有机结合，实现了软件价值向最终用户的交付。

持续交付-部署与发布管理-持续部署流水线

持续部署流水线是 DevOps 的核心实践，通过可靠可重复的流水线，打通端到端价值流交付，实现交付过程中各个环节活动的自动化和可视化。部署流水线通过将复杂的软件交付流程细分为多个阶段，每个阶段层层递进，提升软件交付质量信心，并且在流水线过程中提供快速反馈，减少后端环节浪费。

可视化流水线可以增强跨组织的协同效率，提供有效的信息共享平台，从而统一组织目标，并且不断识别流水线中的约束点和瓶颈，以及潜在的自动化及协作场景，通过持续改进而不断提升软件交付效率。

持续交付-环境管理

环境作为 DevOps 持续敏捷交付过程中最终的承载，环境的生命周期管理、一致性管理、环境的版本管理都变得非常重要。环境管理是用最小的代价来达到确保一致性的终极目标。

其他相关标准内容，详解相关文档（文末可下载）。

三、DevOps 系列标准的幕后英雄

这里也非常感谢写 DevOps 工作组的所有成员，他们不仅有来自运维厂商的，还有很多运维运营多年的专家。这个标准是在我们中国通信标准化协会，也就是云计算开源产业联盟的挂靠单位下的 TC1 工作组立项为标准的。

四、DevOps 系列标准相关下载

原创：栗蔚　　中国信息通信研究院主任工程师 / 云计算开源产业联盟秘书长

一、DevOps 标准体系

2017年11月17日，云计算开源产业联盟第一次跟高效运维社区一起在上海合办了首届金牌运维峰会，在工信部软件司的指导下，由中国信通院牵头的云计算开源产业联盟在推动运维相关标准方面也有了很大成果，我将代表编写团队，发布两个已经完成的标准（DevOps 标准、蓝鲸运维标准），本文将着重介绍 DevOps 标准。

1.1、DevOps 体系

DevOps 的标准体系，目前我们发布的是一个 Beta 版，用我们业界比较流行的代码术语是一个体验版。

为什么要做 DevOps 的标准体系，已经有这么多的最佳实践和开源工具，我们为什么要做这个事情呢？

我们经常在不同的场合听到了 DevOps 这个词，但是我听到大家讲的角度维度都不一样，有人认为自动化运维就是 DevOps，有人认为运维的人员会开发，是不是就是 DevOps，那么还有一些我们的容器厂商从产品的角度说 DevOps，还有我们从培训的角度去玩玩沙盘，是不是就会懂了 DevOps，是不是我们把上面的组合起来就知道什么是 DevOps 呢？其实不是的。

我们在不同场合听到 DevOps 都好像盲人摸象一样，谁都只是摸到了大象的一部分。所以我们做这件事情的目的主要有两方面：

第一个方面就是三正，正什么呢？

• 第一正概念，就是 DevOps 的概念，它的范畴；
  
  

• 第二个就是正框架，我们 DevOps 到底包含哪几个过程，从人员组织架构到工具，到底要达到一个什么样的框架才是 DevOps；
  

• 第三个就是正能力，很多人说 DevOps 太难了，目前我们公司做不到，其实有的时候觉得难，是因为我们不知道如何达到，所以在这里我们的标准叫做能力的成熟度模型，也就是说你很容易的清楚自己在哪个层级，那么你也很清楚如何晋级到更高级的 DevOps 的能力，这样一个很清晰的标准。
  

正因为我们可以做到三正，所以这个标准是有实操意义的，拿了这个标准，不管是运维人员还是 CIO 等等，就可以看到你们的公司团队如何根据这个标准去明确不同的流程，明确不同的组织架构，明确如何一步一步的去实施。

1.2、DevOps 体系系列标准——前三部分

我们这个标准体系一共有7部分：

第1部分是总体架构，包括概念和框架和能力的分级。从第2部分到第7部分就是我们这个框架里的每一个部分的能力成熟度模型，主要包括敏捷开发过程，持续交付过程，技术运营过程，还有总的应用框架、安全管理和组织结构。可以看到从第2部分到第4部分，都是过程类的，第5部分是应用架构类的，第6部分是安全管理类的，第7部分是组织结构类的。

“研发运营一体化能力成熟度模型”，是国内外第一个 DevOps 标准体系。

DevOps 标准体系包含下面两大目的：

• 第一，是明确概念、框架、能力。DevOps 的概念、框架和能力到达什么程度，做一个非常详细明确的说明。
  
  

• 第二，对于 DevOps 涵盖的流程、组织、实施，有明确的指引，企业可以按照这个标准去提升自己 DevOps 各个环节的能力。
  
  

本次发布的是前3部分的征求意见稿。

二、DevOps 系列标准前三部分

前三部分为总体架构，敏捷开发管理过程和持续交付过程相关标准。以下为您详细解读。

2.1、第1部分：总体架构

研发运营一体化（DevOps）能力成熟度模型覆盖端到端软件交付生命周期全流程，是一套体系化的方法论、实践和标准的集合。研发运营一体化总体架构可划分为三部分，即过程（敏捷开发管理、持续交付、技术运营）、应用架构和组织结构。

• 研发运营一体化过程： 从需求开发、交付、运营这几个环节的过程，这三个过程涵盖了很多内容。整个过程我们把它标准化地分成了三部分。
  
  

• 敏捷开发管理从需求管理、计划管理、过程管理、度量分析这四个维度，关注需求到开发阶段的有序迭代，灵活响应，以及价值的快速交付。
  
  

• 持续交付关注应用软件集成交付环节，通过配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理和度量管理领域的能力建设和工程实践保证软件持续顺畅高质量的对用户完成发布。
  
  

• 技术运营，技术运营环节关注应用系统服务发布后的环节，涉及运维成本服务、高可用架构服务、用户体验服务、客户服务、监控服务、产品运行服务和运营数据服务，保障良好的用户体验，打造持续的业务价值反馈流。这里大家要记住一点，我们没有提运维，提的是运营。DevOps 涵盖了敏捷开发、持续交付和技术运营三个过程，这是从过程去理解 DevOps。
  
  

为什么呢？因为 Operation 这个词它本身的含义就有运维运营的双重意思。

并且现在运营人员所做的事情，已经不是简单的背锅。往往背锅的时候还要提炼点东西。大家要用大数据也好，智能化也罢，都是把自己的运维能力转变为运营部门提供更多的数据支撑。

• 研发运营一体化应用架构，DevOps 的标准除了过程工程以外，还涉及到应用架构。应用架构指的是应用系统的开发、测试和部署，是否用了微服务等架构。
  
  

• 研发运营一体化安全管理，这是非常重要的，因为 DevOps 在一定程度上降低了安全性，也称为很多企业落地 DevOps 的阻碍之一。这次侧重全流程端到端的全局考虑安全管理及服务。
  
  
  

• 研发运营一体化组织结构，最深层的就是组织结构的问题。我们知道怎么去做，但是不一定能做到？是因为这三个过程覆盖了某个企业N个部门。据我了解不同的行业，开发、运维都是不同的部门。甚至在金融行业、银行的开发、测试和生产也在不同的部门。
  
  

所以如果应用架构、安全管理和组织架构跟不上，也是做不到 DevOps 能力的。往往是每个环节把自己的事做好的，需求迸发出来了，可能才会去推动进一步的组织结构的变动，这是第三个纬度的事情。

理解 DevOps 可以从过程、多个点、不同维度去理解。DevOps 是一个过程，过程里的每一个小环节，涉及到人、团队、工具。后面分级的理念也是每个小环节从人、过程管理、工具团队的协作这几个纬度去分的。

要做好 DevOps，首先把每个小环节做好，进而把整个过程做好了，然后再推动整个组织架构一系列的变革。

为什么这里叫运营研发一体化，不叫 DevOps 呢？

因为国内标准不能出现英文词的，而且 DevOps 这个词它是具有阶段性的。也许过个十几年就没有 DevOps 了，标准要普世性，所以这里没有用 DevOps，用的是研发运营一体化。从这个词也可以看出来它贯穿了研发，一直到运营。

成熟度分级的对象，就是研发运营一体化，研发运营一体化就是刚才讲的那几个纬度。我们分级的时候，可以对整个研发运营一体化进行分级，也可以小到某个环节，大到某个部分去进行成熟度的分级。

这样有助于了解每个环节的情况，有助于逐个击破，提升自己 DevOps 的能力。分级成熟度就是从阻碍一直到优化这五个级别，很容易理解。

2.2 、第2部分：敏捷开发过程

这里面讲的是敏捷需求管理、迭代计划管理和敏捷过程管理，属于刚才讲的第一级的环节，每一个环节可以分成很多小环节。

其中需求管理细分为需求收集、需求分析、需求与用例和需求验收四个细分维度。需求收集从单个需求点、需求全貌、需求的管理、人员机制以及工具能力五个维度进行评估；需求分析从需求内容和形式、需求协作、需求的管理、人员机制以及工具能力五个维度进行评估；需求与用例从需求与用例编写、需求用例验证、需求与用例的管理、人员机制以及工具能力五个维度进行评估；需求验收从需求验收频率、需求验收范围、需求验收反馈效率、人员机制以及工具能力五个维度进行评估。

其中计划管理细分为需求澄清与拆解、故事与任务排期、计划变更三个维度。需求澄清与拆解从需求澄清的时间、内容的完备性、协作、人员机制以及工具能力五个维度进行评估；故事与任务排期从排版要素、排版容量、排版管理、人员机制以及工具能力五个维度进行评估；计划变更从变更决策、应对变更、减少变更、人员机制以及工具能力五个维度进行评估。

其中过程管理细分为迭代管理、迭代活动、过程可视化及流动、度量分析四个维度。

• 迭代管理从迭代时间周期、迭代协作机制、迭代流程改进、人员机制以及工具能力五个维度进行评估；
  
  

• 迭代活动从迭代活动约定、迭代活动时间约定、迭代活动范围、人员机制以及工具能力五个维度进行评估；
  
  

• 过程可视化及流动从过程可视化、过程价值流动、迭代过程改进、人员机制以及工具能力五个维度进行评估；
  
  

• 度量分析从度量粒度、度量范围、度量驱动持续改进、人员机制以及工具能力五个维度进行评估。
  
  

以下就部分内容进行阐述。

敏捷开发过程-需求管理-需求收集

需求收集环节是需求提出方和产品经理之间明确产品需求的阶段，是产品研发运营一体化最初始阶段，把产品的需求具象化，形成待办事项列表的过程。

需求收集环节包括三个方面工作:

• 明确单个需求点 即以问题驱动为核心，探索问题核心相关事项的过程
  
  

• 梳理需求全貌 应能列出为了落实产品的愿景而需要 完成的所有事项，即待办事项列表
  
  

• 确定待办事项列表 应包括用户需求所涉及的所有事 项，并且作为产品研发路线图
  
  

这三个工作从人员机制到工具能力，会用到不同程度的工具，以及人员协作的流畅度，协作的程度是不一样的。所以把它分成五级，大家可以看一下上图右边的内容。

最高级的是，需求方就是产品经理可以把需求方的每个点形成一个功能点，并且把功能点形成整个需求的全貌，形成一个列表，进一步形成路线图，这个路线图可以是在后续的迭代开发中不断的优化。

在工具能力方面会用到很多需求管理，用统一的工具对需求进行管理。组织架构方面，企业采用扁平化的敏捷团队组织架构，赋予团队围绕产品自组织、自管理的权力，包括但不限于产品规划、建设、运营、人力、绩效、核算等。

例如，敏捷团队以业务价值为核心以运营为驱动的敏捷工作模式，企业为团队提供IT基础设施、基础管理等支持。第一个环节，如果做到这一级的话，是非常好的。如果是普通程度的情况，一个是传达的需求不明确，第二个没有用到任何的工具，这样普通的级别在后续的迭代计划中根据计划的改变而进行改变，是不够灵活的。

这是需求收集环节我们的分级。大家可以对应表看看你是属于哪个程度哪一级的。

敏捷开发过程-需求管理-需求分析

需求分析是产品经理将需求细化和拆解成用户故事的过程。

主要体现三个方面:

• 明确需求内容和形式 需求分析形成用户故事，用户故事描述用户场景
  
  

• 需求分析协作 用户故事是适度详细并适应变化的，可以在开发过程中对其进行评估不断细化
  
  

• 需求管理方式 用户故事统一管理，并按照业务价值由高到低排定优先级
  
  

需求分析最主要的方式把整个甲方或者需求方的需求场景，进行统一的分类。在开发过程中对它进行不断的评估，进行细化，最后把场景按照业务价值，由高到低进行排定优先级。

上面需求收集只是说形成了一个待办事项列表，保证不停的更新。这个时候需求分析能够按照不在待办事项里，能够按照优先级去进行标注，进一步根据后面的迭代开发情况进行不断的反馈。

敏捷开发过程-需求管理-需求与用例管理

需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性，能验收产品功能是否满足用户故事的要求的过程。

主要体现在三个方面:

• 梳理需求用例 编写需求验收标准，形成测试用例的过程
  

• 使用需求用例 需求用例指导需求开发，验证产品功能的过程
  

• 管理需求用例 建立需求与用例的统一管理库，持续的使用和优化
  
  

刚才已经把需求分了级，分了场景后，开发有没有达到我们的需求呢？这个地方对需求管理很重要了，要预先有一些测试例，能够很好地判断后面的开发有没有达到。如果有问题再反馈回来，我们的需求进一步调整。

应建立企业级可视化便捷的平台，管理需求文档，且可以通过需求文档能查看产品的全貌，且通过平台，需求提出人、最终使用人、产品经理、开发运维人员进行更好的沟通和协作。保证可持续性，它有一个持续，每个环节都可以持续，持续都是持续到下一个环节，交付环节的。

敏捷开发过程-需求管理-需求验收

需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，要求能对需求进行快速测试、快速确认、快速反馈、快速优化。

本节的需求验收，仅是指功能验收，非功能测试不在本节的范围内。需求验收主要体现在以下三个方面:

• 需求验收的频率 指不同角色对需求功能验收的频率，频率越高效果越好
  
  

• 需求验收的范围 指需求验收应尽量具备有业务价值的端到端的验收
  
  

• 需求验收的反馈效率 指需求验收的结果能准确、快速的反馈到开发团队的过程
• 
  
  
  

最后是需求的验收，包括设计验收的频率、制定验收的测试方案、指标等等。并不是强制要求你的频率一定要达到多少次。不同的产品验收频率验收结果是不一样的。更多是告诉你一种方法论，在这个过程中也是需要你用到一系列的工具，去辅助你能够自动化去进行需求的验收等等。

最高级别应建立企业级大数据分析工具，能抓取用户行为数据，通过大数据分析，在用户功能验收和用户体验时作为辅助决策依据，持续优化改进。需求的环节在敏捷开发里是非常重要的，下面的环节叫迭代计划管理。

其他相关标准内容，详解相关文档（文末可下载）。

2.3、 第3部分：持续交付过程

第三个标准就是持续交付的过程，它分为配置管理、部署等等，分了好几个环节。每个环节包括一些子环节，每个子环节从很多纬度进行能力的评估。

其中配置管理细分为版本控制、版本可追踪性两个维度。版本控制从版本控制系统、分支管理、构建产物管理、单一可信数据源四个维度进行评估；版本可追踪性从变更过程、变更追溯、变更回滚三个维度进行评估。

其中构建与持续集成分为构建实践、持续集成两个维度。构建实践从构建方式、构建环境、构建计划、构建职责四个维度进行评估；持续集成从集成服务、集成频率、集成方式、反馈周期四个维度进行评估。

其中测试管理分为测试分级策略、代码质量管理、测试自动化三个维度。测试分级策略从分层方法、分层策略、测试时机三个维度进行评估；代码质量管理从质量规约、检查策略、检查方式、反馈处理四个维度进行评估；测试自动化从自动化设计、自动化开发、自动化执行、自动化分析四个维度进行评估。

其中部署与发布管理分为部署与发布模式、持续部署流水线两个维度。部署与发布模式从部署方式、部署活动、部署策略、部署质量四个维度进行评估；持续部署流水线从协作模式、流水线过程、过程可视化三个维度进行评估。

其中环境管理分为环境类型、环境构建和环境依赖与配置管理。

其中数据管理分为测试数据管理和数据变更管理两个维度。测试数据管理从数据来源、数据覆盖、数据独立性、数据安全四个维度进行评估；数据变更管理从变更过程、兼容回滚、版本控制、数据监控四个维度进行评估。

其中度量与反馈分为度量指标和度量驱动改进两个维度。度量指标从度量指标定义、度量指标类型、度量数据管理、度量指标更新四个维度进行评估；度量驱动改进从报告生成方式、报告有效性、报告覆盖范围、反馈改进四个维度进行评估。

持续交付-配置管理-版本控制

版本控制是从版本控制系统、分支管理和构建产物管理和单一的可信数据源。

从五个方面对它进行成熟度的分级。最高级，比如在版本控制系统方面，要有版本的控制系统，产品开发的版本控制系统。它是有生命周期的，所有的版本，包括修改等等流程都可以进行管理。比如分支的管理，就是持续优化分支管理策略，等等。

持续交付-配置管理-版本可追溯性

版本的可追溯性，版本可追溯性是指软件系统中的每一次变更都可以追溯变更的详细信息，并向上追溯变更的原始需求、流转过程等所有关联信息。支持全程的数据分析管理和满足审计的要求。这里审计要求是指你这个产品的开发，每一步 BUG 的修改、每一步的变更是谁做的，它修改了哪一步。也是可追溯的意思。

可追溯性也是版本回滚的历史依据和实施基础，建立良好的版本可追溯性可实现对任一版本完整环境流程的自动化，精确回滚，快速重现问题和恢复正常环境。

持续交付-构建与持续集成-构建实践

版本的管理就是构建与持续的集成。构建的实践包括持续优化的构建服务平台、持续改建服务的易用性。

构建是将软件源代码通过构建工具转换为可执行程序的过程，一般包含编译和链接两个步骤，将高级语言代码转换为可执行的机器代码并进行相应的优化，提升运行效率。

持续集成是软件构建过程中的一个最佳实践，在版本控制的基础上，通过频繁的代码提交，自动化构建和自动化测试，加快软件集成周期和问题反馈速度，从而及时验证系统可用性。

这里可以用容器管理工具，因为容器很方便可以把很多应用做成标准化，封装成容器的格式，方便不断做镜像，不断进行扩充管理。方便了微服务架构的开发，可以去管理一些应用，所以这里很多人都会用到容器的原因，在这把它当做一个管理的工具去实现了。

持续交付-构建与持续集成-持续集成

跟构建实践差不多的，持续优化和改进团队的持续集成的能力和变更。

持续交付-部署与发布管理-部署与发布模式

部署与发布泛指软件生命周期中，将软件应用系统对用户可见，并提供服务的一系列活动，包括系统配置，发布，安装等。整个部署发布过程复杂，涉及多个团队之间的协作和交付，需要良好的计划和演练保证部署发布的正确性。

其中部署偏向技术实践，即将软件代码，应用，配置和数据库变更应用到测试环境、准生产环境和生产环境的过程。发布偏向于业务实践，指将部署完成的应用软件功能和服务正式对用户可见，提供线上服务的过程。部署和发布的有机结合，实现了软件价值向最终用户的交付。

持续交付-部署与发布管理-持续部署流水线

持续部署流水线是 DevOps 的核心实践，通过可靠可重复的流水线，打通端到端价值流交付，实现交付过程中各个环节活动的自动化和可视化。部署流水线通过将复杂的软件交付流程细分为多个阶段，每个阶段层层递进，提升软件交付质量信心，并且在流水线过程中提供快速反馈，减少后端环节浪费。

可视化流水线可以增强跨组织的协同效率，提供有效的信息共享平台，从而统一组织目标，并且不断识别流水线中的约束点和瓶颈，以及潜在的自动化及协作场景，通过持续改进而不断提升软件交付效率。

持续交付-环境管理

环境作为 DevOps 持续敏捷交付过程中最终的承载，环境的生命周期管理、一致性管理、环境的版本管理都变得非常重要。环境管理是用最小的代价来达到确保一致性的终极目标。

其他相关标准内容，详解相关文档（文末可下载）。

三、DevOps 系列标准的幕后英雄

这里也非常感谢写 DevOps 工作组的所有成员，他们不仅有来自运维厂商的，还有很多运维运营多年的专家。这个标准是在我们中国通信标准化协会，也就是云计算开源产业联盟的挂靠单位下的 TC1 工作组立项为标准的。

四、DevOps 系列标准相关下载

原创：栗蔚　　中国信息通信研究院主任工程师 / 云计算开源产业联盟秘书长