@gaoxiaoyunwei2017
2017-11-24T08:19:29.000000Z
字数 8169
阅读 725
DevOps 标准解读 --- 栗蔚·工信部主任
北哥
作者简介
栗蔚
为什么要做这个标准？现在很多人都在讲DevOps是自动化运维，是运维会开发，是敏捷开发，是用容器实现工具等等。其实每个人都是从自己擅长的DevOps某一个领域去看DevOps，都不是DevOps的全部。
DevOps不仅仅是敏捷开发，也不仅仅是用容器做的自动化的工具。它是一个非常具有体系化的标准全称，所以我们做这个标准就是让大家不再是从不同的领域拼拼凑凑听一些DevOps的东西。
DevOps标准体系包含下面两大点：
- 第一，是概念、框架、能力，你的DevOps的能力到达什么程度，做一个非常详细明确的说明。
- 第二，对于DevOps涵盖的流程、组织、实施给你一个明确的指引，你可以按照这个标准去提升自己DevOps各个环节的能力。
“研发运营一体化能力成熟度模型”,是国内外第一个 DevOps 标准体系。
一. 研发运营一体化能力成熟度模型 系列标准(Beta版)
- 研发运营一体化能力成熟度模型 第1部分:总体架构(已完成)
- 研发运营一体化能力成熟度模型 第2部分:敏捷开发过程(已完成)
- 研发运营一体化能力成熟度模型 第3部分:持续交付过程(已完成)
- 研发运营一体化能力成熟度模型 第4部分:技术运营过程(制订中)
- 研发运营一体化能力成熟度模型 第5部分:应用架构(制订中)
- 研发运营一体化能力成熟度模型 第6部分:组织结构(制订中)
这是我们现在做的体系标准框架。第一部分是总体架构，第二部分到第六部分是每个DevOps涵盖的部分的成熟度能力模型。从技术运营过程、应用架构和组织结构还在制定当中。
二. 研发运营一体化能力成熟度模型 第1部分:总体架构
DevOps可以从三个纬度去解读。
研发运营一体化过程从需求开发、交付、运营这几个环节的过程，这三个过程涵盖了很多内容。整个过程我们把它标准化地分成了三部分。敏捷开发管理是敏捷开发最开始的部分。敏捷开发的管理包括从需求以及到制定计划，这个环节完了就是产品经理做的活。持续交付做完上面后就交给开发，开发根据需求进行开发。技术运营最后交给运营团队上线，进行持续地运营。这里大家要记住一点，我们没有提运维，提的是运营。为什么呢？因为Operations这个词它本身的含义就有运维运营的双重意思。
现在运营人员所做的事情，已经不是简单的背锅。往往背锅的时候还要提炼点东西，锅烧了还是要有点渣子。大家要用大数据也好智能也罢，把自己的运维能力为运营部门提供更多的数据。
DevOps涵盖了敏捷开发、持续交付和技术运营三个过程，这是从过程去理解DevOps。
研发运营一体化应用架构除了过程以外，我们知道怎么去做，但是不一定能做到？是因为这三个过程覆盖了某个企业N个部门。据我了解不同的行业开发、运维都是不同的部门。甚至在金融行业、银行的开发、测试和生产也在不同的部门。所以你知道这个过程了以后，如果你的应用架构和组织架构跟不上，你也是做不到DevOps流畅的能力的。因此第二个纬度就是业务架构，业务架构指的是你整个的部署，用DevOps你的应用架构要满足什么样的条件。研发运营一体化组织结构最深层的就是组织结构的问题。往往是每个环节把自己的事做好的，这种需求迸发出来了，可能才会去推动进一步的组织结构的变动，这是第三个纬度的事情。
理解DevOps可以从过程、多个点、不同维度去理解。DevOps是一个过程，过程里的每一个小环节，涉及到人、团队、工具。后面分级的理念也是每个小环节从人、过程管理、工具团队的协作这几个纬度去分的。
要做好DevOps，首先把每个小环节做好，进儿把整个过程做好了，然后再推动整个组织架构一系列的变革。
为什么这里叫运营研发一体化不叫DevOps呢？因为国内标准不能出现英文词的，而且DevOps这个词它是具有阶段性的。也许过个十几年就没有DevOps了，标准要普世性，所以这里没有用DevOps，用的是研发运营一体化。从这个词也可以看出来它贯穿了研发，一直到运营的。
成熟度分级的对象，就是研发运营一体化，研发运营一体化就是刚才讲的那几个纬度。我们分级的时候，可以对整个研发运营一体化进行分级，也可以对小到某个环节，大到某个部分去进行成熟度的分级。这样有助于了解每个环节的情况，有助于逐个击破，提升自己DevOps的能力。分级成熟度就是从阻碍一直到优化这五个级别，很容易理解。
三. 研发运营一体化能力成熟度模型 第2部分:敏捷开发过程
这里面讲的是敏捷需求管理、迭代计划管理和敏捷过程管理。这属于刚才讲的第一级的环节，每一个环节可以分成很多小环节。比如说敏捷需求可以分成需求收集、需求分析等。
3.1 敏捷开发过程-需求管理-需求收集
需求收集环节是需求提出方和产品经理之间明确产品需求的阶段，是产品研发运营一体化最初始阶段，把产品的需求具象化，形成待办事项列表的过程。
需求收集环节包括三个方面工作:
明确单个需求点即以问题驱动为核心，探索问题核心相关事项的过程梳理需求全貌应能列出为了落实产品的愿景而需要 完成的所有事项，即待办事项列表确定待办事项列表应包括用户需求所涉及的所有事 项，并且作为产品研发路线图
这三个工作从人员机制到工具能力这两个纬度，会用到不同程度的工具和人员协作的流畅度，协作的程度是不一样的。所以把它分成五级，大家可以看一下上图右边的内容。
最高级的是需求方，就是产品经理可以把需求方的每个点形成一个功能点，并且把功能点形成整个需求的全貌，形成一个列表，进一步形成路线图，这个路线图可以是在后续的迭代开发中不断的优化的。
在工具能力方面会用到很多需求管理，用统一的工具对需求进行管理。我们讲第一个环节，如果做到这一级的话，是非常好的。如果是普通的话，一个是传达的需求不明确，第二个没有用到任何的工具。第三个在后续的迭代计划中根据计划的改变而进行改变，是不够灵活的。
这是需求收集环节我们的分级。大家可以对应表看看你是属于哪个程度哪一级的。
3.2 敏捷开发过程-需求管理-需求分析
需求分析是产品经理将需求细化和拆解成用户故事的过程。
主要体现三个方面:
明确需求内容和形式需求分析形成用户故事，用户故事描述用户场景需求分析协作用户故事是适度详细并适应变化的，可以在开发过程中对其进行评估不断细化需求管理方式用户故事统一管理，并按照业务价值由高到低排定优先级
需求分析最主要的方式把整个甲方或者需求方，我们叫需求场景，进行统一的分类。在开发过程中对它进行不断的评估，进行细化，最后把场景按照业务价值，由高到低进行排定优先级。
上面需求收集只是说形成了一个待办事项列表，保证不停的更新。这个时候需求分析能够按照不在待办事项里，能够按照优先级去进行标注，进一步根据后面的迭代开发情况进行不断的反馈。
3.3 敏捷开发过程-需求管理-需求与用例管理
需求与用例管理是指产品经理和开发团队把用户故事的验收标准和测试用例进行关联性，能验收产品功能是否满足用户故事的要求的过程。
主要体现在三个方面:
梳理需求用例编写需求验收标准，形成测试用例的过程使用需求用例需求用例指导需求开发，验证产品功能的过程管理需求用例建立需求与用例的统一管理库，持续的使用和优化
刚才已经把需求分了级，分了场景后，开发有没有达到我们的需求呢？这个地方对需求管理很重要了，要预先有一些测试力，能够很好地判断后面的开发有没有达到。如果有问题再反馈回来，我们的需求进一步调整。
可以看到在需求管理这个环节，很重要的一点反映了跟以前不一样的一点。它有一个持续，每个环节都可以持续，持续都是持续到下一个环节，就是交付环节的。
3.4 敏捷开发过程-需求管理-需求验收
需求验收是指产品经理、需求提出者和最终用户对产品的功能验收，要求能对需求进行快速测试、快速确认、快速反馈、快速优化。
本节的需求验收，仅是指功能验收，非功能测试不在本节的范围内。需求验收主要体现在以下三个方面:
需求验收的频率指不同角色对需求功能验收的频率，频率越高效果越好需求验收的范围指需求验收应尽量具备有业务价值的端到端的验收需求验收的反馈效率指需求验收的结果能准确、快速的反馈到开发团队的过程
最后是需求的验收，包括设计验收的频率、制定验收的测试方案、指标等等。并不是强制要求你的频率一定要达到多少次。不同的产品验收频率验收结果是不一样的。更多是告诉你一种方法论，在这个过程中也是需要你用到一系列的工具，去辅助你能够自动化去进行需求的验收等等。
需求的环节在敏捷开发里是非常重要的，下面敏捷开发的环节叫迭代计划管理。
3.5 敏捷开发过程-迭代计划管理-需求澄清
需求澄清是产品经理和开发团队沟通和确认需求的过程，包含沟通和明确用户故事的细节(包括但不限于背景信息、UI和交互设计、测试要点等)，确定用户故事的技术实现方案，识别技术风险和依赖，团队对用户故事进行任务拆分，产品经理和团队对于以上信息达成共识，明确用户故事完成的定义。
主要体现在下面几个方面：
需求澄清的时间指需求澄清发生在研发过程中的合适的阶段，以便适应研发过程中的变化及开发团队工作的开展需求澄清内容的完备性指在需求澄清过程中，是否澄清需求的所有内容需求澄清协作指产品经理、开发团队及其他干系人如何协作开展澄清工作
开发人员接到产品经理的需求以后，首先是需求澄清。很多企业有点混乱，开发者拿到需求会按照自己的理解开发，往往开发出来的不是产品要的，所以这个环节非常关键。
从这里可以看到已经跨部门进行协作了，所以在人员机制方面，这一点的要求是非常高的，在前面需求管理是没有的。
3.6 敏捷开发过程-迭代计划管理-故事与任务排期
敏捷开发将开发过程分为多个短冲刺，故事与任务的排期过程就是确定迭代冲刺目标的过程，根据产品待办列表中用户故事的优先级、依赖关系、故事规模和团队速度，确定迭代待办列表，迭代待办列表确定之后，团队成员根据优先级认领故事和任务。
主要体现在三个方面:
排版要素指进入排版时，信息的完备性，例如产品待办列表中用户故事的优先级、依赖关系、故事规模和团队速度等排版容量指排版容量的大小有据可依，根据实际用户故事规模和团队速度并考虑其他影响因素后确定排版管理指排版活动的组织形式
在迭代计划管理里面开发人员需要有一个完整的排期，排期也要跟需求的优先级相对应，要严格按照分析环节进行相应的开发。如果不行，需要在需求澄清环节跟产品经理进行沟通，跟他探讨需求是否要改变优先级。
所以这个地方故事与任务排期很重要，很多人用白板的方式，网上的很多工具开发团队都在用，比如完成了某个模块就进行标记，这种工具可以提高团队的开发和排期。
3.7 敏捷开发过程-迭代计划管理-计划变更
计划变更是指在迭代过程中，迭代目标发生变化，“响应变化胜过遵循计划”是敏捷的核心价值观之一，但进入迭代的内容发生变化会影响研发团队的工作效率，所以需要采取措施尽量减少计划变更的负面影响。
主要体现在三个方面:
变更决策是指决定变更和接受变更的决策方式应对变更是指接受变更后，是否具备措施减少变更的影响减少变更是指是否具备措施减少变更的发生
如果你的开发遇到问题或者在实际的落地当中某个需求不可能完成，或者有更好完成的方式。这个地方就要有变更决策，变更决策需要在变更的时候，首先要有变更决策，其次是要有应对变更，第三是要有减少变更。
3.8 敏捷开发过程-过程管理-迭代管理
** 迭代管理，即贯穿于产品研发过程中以保持恒定的时长为周期，每个周期都遵从相同的框架过程，并且交付潜在的可发布最终产品增量。**
迭代管理主要体现在以下三个方面:
敏捷迭代周期指团队能约定迭代时长、交付时长迭代协作机制指团队内或团队间的工作进行相互配合，使得产品开发能快速交付迭代流程改进指团队能通过不断检视迭代过程，对发现的问题能持续改进
从需求环节到迭代计划环节，你都是参与者，现在要跳出来作为一个第三方去看一看。整个过程是不是流畅了，哪个环节有问题，把整个过程的迭代周期、协作机制建立起来。
3.9 敏捷开发过程-过程管理-迭代活动
敏捷迭代活动，是指从产品规划、研发过程、产品交付、持续改进等维度来定义的产品迭代研发中的一系列过程，目的在于推进敏捷迭代团队的持续改进和产品的快速交付。
迭代活动主要体现在以下三个方面:
迭代活动约定是指团队能能在约定的时间、相对固定的场所举行相关活动迭代活动时间约定是指团队能按照约定的时间长短进行各种会议迭代活动范围是指团队能在各类敏捷会议中遵守约定的会议内容。
3.10 敏捷开发过程-过程管理-过程可视化及流动
通过对敏捷迭代过程的可视化展示，实时反映用户故事的迭代进展，体现产品从需求、研发、交付端到端的价值流动，通过在制品数量等工具实现价值流动的拉动式管理。
过程可视化及流动主要体现在以下三个方面:
过程可视化通过各种数据记录，反馈敏捷开发过程质量过程价值流动通过各种工具体现敏捷过程的业务交付价值流动过程迭代过程改进对数据反映的各种问题，不断改进迭代过程
很多人用一些白板或者工具，这个主要是靠工具实现的过程可视化，比如到谁那里，完成得怎么样。
3.11 敏捷开发过程-过程管理-度量分析
度量分析是对迭代过程中研发效率、质量数据进行分析，反映过程的健康程度；通过对产品端到端指标数据进行分析，实时反映产品的表现。驱动敏捷迭代的过程改进，推动企业组织架构、人员结构、财务制度等方面进行不断优化。使用敏捷迭代的方式推进改进措施的实施。
度量分析主要体现在以下三个方面:
度量的粒度是指敏捷迭代分析度量的详细程度度量的范围是指分析度量涉及人员组织，范围大小度量驱动持续改进是指在分析发现问题后，能不断进行落地改进
四. 研发运营一体化能力成熟度模型 第3部分:持续交付过程
第三个标准就是持续交付的过程，它分为配置管理、部署等等，分了好几个环节。每个环节包括一些子环节，每个子环节从很多纬度进行能力的评估。
4.1 持续交付-配置管理-版本控制
版本控制是从版本控制系统、分支管理和构建产物管理和单一的可信数据源。
从五个方面对它进行成熟度的分级。最高级，比如在版本控制系统方面，第一，要有版本的控制系统，产品开发的版本控制系统。它是有生命周期的，所有的版本，包括修改等等流程都可以进行管理。第二，要有分支的管理，就是持续优化分支管理策略，这是版本控制的分级。
4.2 持续交付-配置管理-版本可追溯性
版本的可追溯性，支持全程的数据分析管理和满足审计的要求。这里审计要求是指你这个产品的开发，每一步BUG的修改、每一步的变更是谁做的，它修改了哪一步。也是可追溯的意思。
4.3 持续交付-构建与持续集成-构建实践
版本的管理就是构建与持续的集成。构建的实践包括持续优化的构建服务平台、持续改建服务的易用性。
这里为什么用到了容器实现的管理工具呢？因为容器很方便可以把很多应用做成标准化，封装成容器的格式，方便不断做镜像，给一些私有地址，不断进行扩充管理。方便了微服务架构的开发，可以去管理一些应用，所以这里很多人都会用到容器的原因，在这把它当做一个管理的工具去实现了。
4.4 持续交付-构建与持续集成-持续集成
跟构建实践差不多的，持续优化和改进团队的持续集成的能力和变更。
4.5 持续交付-测试管理-测试分层策略
测试从分层的策略、分层方法、测试的时机等等去把测试团队的能力进行分级。最高级采用验收的测试开发的方式进行业务的用户级进行测试。我们会定期验证分层策略是否完整有效，持续地优化策略。测试在我们开发以后，会根据需求开发是不是它达到了很多功能，以及可用性安全性等等方面进行测试。
4.6 持续交付-测试管理-代码质量管理
根据开发的产品目前的成熟度是不是能够上线以及它的质量进行管理。从质量规约等方面进行分级。
4.7 持续交付-测试管理-自动化测试
这个地方用到自动化测试的工具，包括自动化运维、自动化脚本使用、测试用例等等。这个地方所有的测试焊接都跟需求环节用例有所对应的。
4.8 持续交付-部署与发布管理-部署与发布模式
测试完后就是部署与发布了，它也要符合部署的方式、部署的活动、部署的质量等方面进行分级。
4.9 持续交付-部署与发布管理-持续部署流水线
持续部署流水线跟运维有关系，不仅仅是开发的事，开发一款产品以后，是否能够很快部署到生产环境下，完全是取决于运维平台它对新应用的支持能力。后面会讲到这个标准，比如说好的运维系统平台，从开发到部署上线是非常快的。
4.10 持续交付-环境管理
环境作为DevOps持续敏捷交付过程中最终的承载，环境的生命周期管理、一致性管理、环境的版本管理都变得非常重要。
环境管理是用最小的代价来达到确保一致性的终极目标。
4.11 持续交付-数据管理-测试数据管理
测试数据需要满足多种测试类型的需求（手工测试，自动化测试），覆盖正常状态，错误状态和边际状态，测试数据需同时满足测试效率和数据量的要求。
测试数据的输入需要受控，并运行在受控环境中，保证输出的有效性，同时由于持久数据的必要行，要避免数据被未授权的篡改，以影响测试结果的客观一致性。
为了模拟类生产环境系统运行情况，常采用仿生产环境数据，此类测试数据在使用时需要注意数据安全，避免敏感用户数据泄露，及时进行数据清洗和漂白。
4.12 持续交付-数据管理-数据变更管理
数据变更管理主要关注应用程序升级和回滚过程中的数据库结构和数据的变更，良好的变更管理策略可以保证应用版本和数据库版本兼容匹配，以应对应用的快速扩容缩容等线上场景。通过应用变更和数据变更的解耦，减少系统变更的相互依赖，实施灵活的升级部署。
4.13 持续交付-度量与反馈-度量质量
度量指标的拣选和设定是度量和反馈的前ᨀ和基础，科学合理的设定度量指标有助于改进目标的达成。在拣选度量指标时需要关注两个方面，即度量指标的合理性和度量指标的有效性，合理性方面依托于对当前业务价值流的分析，从过程指标和结果指标两个维度来识别DevOps实施结果，以及整个软件交付过程的改进方向；有效性方面一般遵循SMART原则，即指标必须是具体的、可衡量的、可达到的、同其他目标相关的和有明确的截止时间，通过这五大原则可以保证目标的科学有效。
4.14 持续交付-度量与反馈-度量驱动改进
度量驱动改进关注软件交付过程中各种度量数据数据的收集，统计，分析和反馈，通过可视化的度量数据客观反映整个研发过程的状态，以全局视角分析系统约束点，并在团队内部共享，帮助设立客观有效的改进目标，并调动团队资源进行优化。同时对行之有效的改进项目进行总结分享，帮助更大范围组织受益于改进项目的效果，打造学习型组织和信息共享，不断驱动持续改进和价值交付。
