DevOps系列标准解读——持续交付

匡豆豆

作者简介：

石雪峰：

• Certificate DevOps Master
• Certified Jenkins Engineer
• DevOps时代社区核心成员
• 全开源端到端部署流水线主创成员
• DevOps行业标准持续交付部分主笔
• DevOpsDays，Jenkins用户大会金牌讲师
• 现任某大型互联网创业公司配置管理与工程效率总监，负责公司DevOps与持续交付体系与平台建设。曾任职于华为、尼康，从事持续交付推进及工具链平台建设工作，拥有多年持续交付落地实践经验。

绪言：

大家好，欢迎大家参加本次在线分享。我今天分享的主题是系列标准解读持续交付部分。我是本次的分享嘉宾石雪峰，我本人是认证的DevOps Master，也是认证的Jenkins工程师，近期一直参与到DevOps时代社区的很多活动，帮助DevOps在国内推广和落地。非常荣幸参与到本次DevOps行业标准的制定，目前负责其中的持续交付部分。

今天的分享分成三部分:

• 对整个标准的总体介绍
• 持续交付内容的深度解读
• 总结和回顾
-

一、标准总体介绍

DevOps标准背景介绍

不管大家是第一次听说这个标准还是之前已经对这个标准有深入的研究，在分享的最开始还是希望对整个DevOps标准背景做一个整体的介绍，让我们对标准能达到一个相同的认知。

本次推出这个标准的全称是研发运营一体化能力成熟度模型，也就是DevOps标准。之所以没有采用这个字眼，主要也是考虑到国家行业标准是要求使用中文字眼，所以我们对DevOps做了一个本地化的过程，翻译成了“研发运营一体化”。这个标准是由工信部软件司指导，由中国信通院牵头的云计算开源产业联盟发起组织的一个活动。

我本人也非常荣幸从一开始就参与到了整个标准的制定过程中，也见证了这个标准从无到有的过程。

在整个过程中，包括云计算、开源产业联盟和很多的会员单位给予了非常大力的支持，从一个侧面也反映了目前国内DevOps持续火热的状态。大家也越发认同在当前这种技术革命、产业数字化转型以及市场竞争日益加剧的大背景下，确实需要这样一个体系来帮助企业建设一个高效能的IT组织，从而实现业务价值的快速交付和市场需求变换的灵活响应。

根据2017年的DevOps状态报告的数据显示，目前整个DevOps团队的比例已经达到了27%。其中给出了一个地域数字，北美大概有54%的比例，亚洲只有10%。先不管这个数据是否准确，其实也能从侧面体现出近两年国内DevOps的飞速发展。

其实对DevOps理念在社区的推动和努力下，这两年已经可以说初步的普及，可以预见，2018年将会是整个DevOps在国内产业落地大爆发的元年，标准在这个时间点诞生，可以说是恰逢其时，非常有助于整个DevOps理念的推广和下一步的转型落地。这个标准从开始立项至今，历时3个月，其中经过了3轮线下会议，参与整个标准的各行业专家近30人，专家团规模也在持续扩大中。

从2017年9月标准筹备工作组成立，到2017年11月17日首届金牌运维峰会，也就是上海站的GOPS上，正式发布了征集意见稿。值得庆幸的是在2017年，也就是12月6日系列标准正式完成立项，这也是一个里程碑式的事件，也会加速整个标准的体系化和发布的节奏。不得不说，这个标准是国内外第一个DevOps标准体系，也体现了目前我们国内对于DevOps的重视程度。

DevOps标准完整体系

看一下DevOps标准体系的整体架构，从横向来看，黄色的部分是整个标准的四大领域，这四大领域基本贯穿整个研发价值交付的完整流程。其中包括DevOps过程、应用架构、安全管理、组织结构。在过程领域进一步细分为敏捷开发管理、持续交付和技术运营三个子部分，这三个子部分的划分也和目前业界通用的DevOps知识体系来互相呼应，覆盖了整个端到端价值交付的完整链条，有助于从全局视角来评估和优化DevOps改进的结果。

研发一体化（Devops）过程

看一下整个过程中的三个部分:

• 第一部分是敏捷开发管理

之前有人说DevOps是不是要去颠覆和取代敏捷，实际上这是一个错误的认识，DevOps是敏捷的一个延伸，也就是说将敏捷开发的一个活动向后端的技术运营去延伸的一个过程。这是DevOps诞生的一个初衷和动因。从整个业务敏捷的角度来看，实际上前端需求业务的敏捷是整个价值交付的推手和源动力。

• 第二部分是持续交付

连接了从敏捷开发到线上技术运营的过程，也打通了业务从需求到开发到上线交付的用户价值的过程。这里面遍布了大量的工程实践。

• 第三部分是技术运营

技术运营也愈发体现了运维的下一站，在当前一个比较复杂的场景下，需要有一个非常强大的运营能力和反馈能力，从而将整个价值交付流程实现闭环，不断驱动整个价值的正向流动。

这三个部分实际上是一个有机结合的整体，三个部分互相呈现出飞轮效应，互相带动、互相推动，从而帮助整个价值链条快速运转。

研发一体化（Devops）应用架构

DevOps所倡导的很多实践和文化，比如像团队自治、自服务组织、松耦合、低风险发布部署，都离不开应用架构的持续演进。并不是说一定要去颠覆所有的应用架构，而是希望在这里面去阐述符合DevOps理念的应用架构应该体现出的哪种特征。

研发一体化（Devops）安全管理

当整个价值交付节奏越来越快，这样一个快速交付的背景和行业监管还有高质量的诉求，实际上带来了更大的压力和挑战。如何在保证快速价值交付的同时将整个安全内建于价值交付流程，从而实现高质量和高效率兼得，这将是对整个安全观还有传统的价值意识的很大的一次升级。

在整个标准中它应该是最后被添加进来的一个部分，其实这也体现出来整个标准，我们在探讨的时候对安全的不妥协。

研发一体化（Devops）组织结构

组织结构是一个永恒的话题，组织结构也是企业文化和价值观的一个载体。在DevOps理念中无法忽视的部分就是关于文化建设方面，这跟组织结构是息息相关的。

DevOps倡导的是持续改进，大家现在看到的这样一个体系架构图，其实也是在不断的演进、不断的碰撞出来的一个结果，不排除将来也会根据实际的情况做出相应的变化，这也才符合当前整个业务价值交付快速变化的大背景。

DevOps标准当前进展

DevOps标准当前进展分成七部分，第一部分总体架构、第二部分敏捷开发过程、第三部分持续交付过程目前已经正式对外发布征集意见稿。另外四个部分包括技术运营、应用、安全、组织架构还在紧锣密鼓的制定中。也看到越来越多的行业专家和行业领袖参与到标准制定活动里，也替代这样一个标准能尽快发布。

DevOps标准的获取方式

现在已经公布出来的这三部分内容，大家可以通过下边的二维码获取。

DevOps的认知差异

提到DevOps，在很多分享中会引用这个盲人摸象的画面。近两年也愈发发现好像每个人都在谈DevOps，所有人都在给DevOps贴标签，有DevOps工程师，建设系统是DevOps系统，做认证是DevOps Master认证，好像所有的东西都是DevOps，贴这个标签很容易，但实际上这很难让它成为一个真正的DevOps。

另外一方面，随着越来越多的分享和交流，我们似乎觉得DevOps变成了一种魔法，它就代表了高效能、高价值、高成就，而且很多业界非常知名的公司，比如亚马逊、谷歌等，也似乎都在印证实施DevOps对企业的成功是至关重要的。大家都从这样的途径从侧面了解到DevOps对企业价值的重要性。但是好像一切好的实践都是DevOps，一切不好的都是DevOps的反模式，其实这种一种定义并没有什么实际的意义。

如果想探寻整个DevOps的本质，推荐大家看一看顾宇老师的系列文章《DevOps的前世今生》，在这个系列文章里记录了DevOps从诞生到发展的完全过程。最近顾宇老师也发了一个新的文章，里面提到了对DevOps不同的认识，这点上不谋而合。我引用一下在顾宇老师文章中的一段描述，现在DevOps从诞生至今，一直缺乏一个清晰和统一的认识。

在维基百科上有一个DevOps的描述，也不断在更新，DevOps的定义看了也基本不会明白说的是什么。

对于一个新生的事务缺乏一个官方的定义，它有两方面，好的方面是人人都可以去对它做定义，每个人都可以参与到里面，对它提供一个新的概念，帮助DevOps快速发展和快速繁荣。坏处也比较明显，后来人会面临一个越来越庞大的DevOps知识体系，很难从一个全局的视角去看清DevOps到底是什么，对DevOps的认识能达到一个应有的水平。

DevOps标准的价值 - 三正三明

DevOps标准所带来的价值，上次在金牌峰会上，栗蔚主任也给出了一个非常精辟的总结，三正三明，三正代表正概念、正框架、正能力，三明是明流程、明组织、明实施。

• 正概念

这三正三明对DevOps标准的价值是一个非常精辟的概括。通过这样一个标准，我们希望可以明确DevOps一个概念，统一DevOps的范畴，达成DevOps的共知。如果每个人理解DevOps都不一样，实际上对DevOps未来的转型落地是一种伤害。我们的交流是建立于共知和共识的前提下才能达到效率的最大化。标准的出现，也可以说结束了一个盲人摸象的时代。

• 正框架

通过这样一个标准去建立DevOps完整的体系框架，并且明确框架中各部分的内在联系，从而把握DevOps的全貌。通过一个全局的视角，而不是局部的优化，来落实DevOps。

在企业中，我们往往会关注资源效率，但实际上过多关注资源效率，反而会妨碍资源流动的效率，因为这个价值的快速流动才是DevOps落地的一个正确的姿势。这点在何勉老师的精益产品开发中有详细的阐述，如果大家对价值流动不是特别清晰，推荐大家去看一看何勉老师的书。

• 正能力

当我们明确了概念、框架，接下来是梳理DevOps的能力模型，帮助企业使用一把最佳实践的尺子来衡量企业当前的成熟度和所处的阶段。进而识别当前企业的约束点以及最优价值的改进事项，指导DevOps落地实践路径。

DevOps转型落地是一个相当漫长的过程，尤其在业务压力很大、业务资源有限的前提下，如何最大化转型改进效果，实际上是DevOps推广的一个非常重要的因素，在《DevOps Handbook》里也有一章专门提出了如何识别一个合适的改进方向，如何去组件这样一个团队，如何快速识别很好的帮手，帮助我们把初期的胜利扩大化，通过持续改进、不断反馈的环节，将优秀的实践在企业内部做扩展，从而实现DevOps滚动落地。

二、持续交付解读

持续交付的概念

提到持续交付，相信对持续交付有所了解的同学脑子里第一反应出来的就是这本书《持续交付 发布可靠软件的系统方法》，这本书的作者是Jez Humble，他现在是业界大神级别的任务。乔梁老师是本书的中文译者，之前有幸听过乔帮主对持续交付深入的分享，收益颇多。

持续交付从诞生至今已经将近7个年头，2010年诞生至今依然是经久不衰。这本书对持续交付的概念是怎么定义的，他说持续交付是一种能力，以一种可持续的方式，安全快速的把你的变更（特性、配置、缺陷、试验）交付到生产环境上让用户使用。持续交付是一种软件团队端到端的交付能力。

在这句话里我用不同颜色标记了一些关键字，实际上这句话也是对持续交付非常精辟的总结，体现了一种可持续的方式，并且安全快速的去做到生产环境的部署。

持续交付核心的理念就是要去降低风险，通过一种小批量、频繁的方式，帮助我们把原来比较痛苦的上线发布或者大爆炸这种发布的风险尽量减小。这里面引入了非常多的工程实践，帮助我们在做持续交付的过程中进行参考。

为什么持续交付有这么一部经典著作的时候我们还要推动持续交付的标准，最后一章给出了持续交付成熟度模型，这个模型是比较High level的形式，是基于整个持续交付的视角去做的成熟度模型。在企业实施改进的过程中有非常多细节的内容，比如配置管理、编译构建、测试等等，每一个领域都是一个非常庞大的知识体系。

我们的标准中是希望把成熟度进一步细化，细化到每一个模块或者每一个工程实践这种程度，来帮助企业进行持续交付建设的时候有所参考。

另外一个原因，持续交付诞生毕竟是在2010年，这几年来技术革命的变革也越发明显，尤其像容器技术，比如像微服务，等等这样一些新技术的诞生，也在不断的扩展持续交付的能力图谱。我们希望在标准中把这样一种新的技术和思想理念结合进来，与时俱进的去做持续交付的落地和发展。

持续交付与DevOps

谈到持续交付，看一看持续交付和DevOps之间的关系。不知道大家有没有思考过，持续交付和DevOps之间到底是什么关系，是平行的两组概念还是说彼此嵌套、包含的关系。

从我个人的理解，持续交付里面包含的主要是很多的工程实践，是从一种科学的维度去帮助我们实施和指导工程实践的落地，帮助我们修改、快速持续的上线发布。DevOps更多关注的是团队中的协作，通过打破组织之间的隔阂，来促进我们之间的沟通。而且DevOps随着近些年来的发展，它的体系不断扩大，它的认知也不断在进化。

现在行业里对DevOps体系的普通认知都是来源于这幅图片，它来源于DevOps Master培训的白皮书，这里面展示了持续交付和DevOps的一种关系，DevOps目前已经扩大到了从整个计划、需求一直到开发部署和运营的全生命周期流程。

而持续交付更多是关注在里面的一些工程实践，帮助我们以一种可靠、可持续的方法打造一个高效的部署流水线，帮助代码变更通过可重复的过程，不断流转到后端的IT运营领域里。

在持续交付和DevOps里都嵌入了非常多的精益思想，比如如何通过消除浪费，通过质量内建，来帮助我们做到真正快速高质量的交付。

DevOps标准的书写结构

当大家打开这样一个标准的时候，里面实际上包含了非常多的内容，我们在书写这样一个标准的时候也引用了一个标准的书写结构。

在解读持续交付内容之前，还是希望把结构跟大家说清楚，也帮助大家在看这样一个标准的时候能知道每一部分到底怎么看，代表什么内容。

标准的结构包括范围、规范性引用文件、术语、缩略语、综述和子模块。

• 范围和规范性引用文件

范围，一个标准需要有一个应用的，这个标准需要应用在哪个领域，作用的范围在什么地方，也约束了标准生效的程度，所以在标准的最开始都会去界定标准的应用范围。

规范性引用文件，标准是一个体系，整个标准中也不是一个大而全的概念，在标准里是可以去参考和借鉴其他已有的标准，来避免标准内容重复。很多参考了一些内容和外部参考的一些标准，都会写在这样一个规范性引用文件里，大家可以通过标准的编号来搜索，获取到相应的标准。

• 术语与缩略语

术语，因为标准的读者可能背景各不相同，里面很多专业术语是需要有一个非常普适化的语言来进行解释和解读，帮助大家去理解这里面一些内容。

缩略语对应了国外的一些英文简写的翻译，在书写标准的过程中，我们习惯上会引用一些比较专业的像CI/CD，它可能是英文首字母的缩写，为了让大家更好的去理解缩写的概念，在缩略语里会把涉及到英文的内容做一个中文的翻译目前，也也符合标准书写的要求。

• 综述与子模块内容

综述和各个模块的阐释，这块的结构是通用的，在每个部分分成两块内容。

第一块是对这一块实践简明扼要的描述，这里举了一个例子，7.1构建实践这块，首先会对构建实践进行一个定义，比如说什么是构建实践，我们在这里提到构建实践所包含的内容和涉及的范畴到底是怎么样的，我们怎么去理解这样一个构建实践。在明确了定义之后，接下来会给出它的能力模型。

能力模型的划分普遍会分为五级，一级是最低的，五级是最高的。

纵向会对实践的主要领域做一个细分，比如对构建来说，把它拆分成四个维度，包括构建的方式、环境、计划、职责，每一块相对会比较独立一些，大家去看这个标准的时候，首先先看定义，接下来去看标准细分的结构、细分的维度，再看每一个维度从低到高演进的过程，每一个维度里都定义了非常多的参考指标和参考实践，尽量以客观的描述去阐述，我达到这样的级别需要实现的水平，也帮助大家做自我的参考和比对。

持续交付标准解读 - 整体结构

对于持续交付标准解读，先看一看整体结构，持续交付领域有我刚才提到的一本《持续交付》，它相当于是持续交付的圣经，我们在总结持续交付这块内容的时候，很大程度上参考了书中的一些结构和定义。

对于持续交付我们把它细分为了七个维度，配置管理、构建与持续集成、测试管理、部署与发布管理、环境管理、数据管理、度量与反馈。

对每一个子领域又细分了相应的维度，纵向，比如配置管理分为版本控制、版本可追溯性，以这样二维的方式把每一个领域做了一个拆解，同时对每一个子领域定义了成熟度和里面所包含的一种优秀实践。

每个标准相对独立，如果大家比较关注测试环节，也可以先去独立看测试管理章节，里面会对测试具体的每个维度去做成熟度的界定，这样也可以帮助大家快速定位到自己当前所要改进或者下一步要做的方向。

开始持续交付标准深度解读。在正式解读之前想跟大家澄清一点，今天是做标准的解读，而不是讲解持续交付，如果真想把持续交付里所有的内容和红实践都讲清楚，估计希望三天三夜也讲不完。

凡是看过《持续交付》这本书的同学都知道，这本书看起来不厚，300多页，但里面的内容涵盖的领域非常多。我记得我第一次拿这本《持续交付》的时候是2011年，当时那这本书就打开看，看几页有点坚持不下去的感觉，硬着头皮读上几页就有一种打过的感觉，因为你对某一个领域很少的理解，真的没有办法达到同样一个维度，去明白这背后的价值和意义。

经过这几年工作，陆陆续续经验的扩展，才不断的把持续交付里面的内容看完，但是如果说百分之百吸收里面的精华，现在都觉得比较困难。

《持续交付》确实是一本非常经典的书，看的过程中还是要依托于现有的经验，有所侧重的去看，而不是通读的方法，从第一章一直看到最后一章，毕竟它里面很多东西是用来指导具体的实际工作的，所以说当我们有具体需求，不妨去翻开《持续交付》，看看人家怎么做的。

配置管理

我接触配置管理大概是在2011年，最近我也看到很多说法，包括在标准讨论群里，有同事说现在配置管理越来越被弱化，配置管理都转做工程效率。

我接触的一些以前做配置管理的同事，他们也都会有一些担忧，说现在配置管理是不是越来越走下坡路了，岗位就要被颠覆掉了，被取代掉了，大家可能马上要失业了。其实我个人不太理解，也不是特别认同这种说法。

我们打开《持续交付》正式内容的第一章，讲的是配置管理，可以说配置管理是整个持续交付的一个基础，如果说我们没有做好配置管理，基本上也是没有办法做持续交付的。

配置管理是整个持续交付的原点和源动力。为什么配置管理如此重要，看一看在标准里对配置管理做的细分。

版本控制

1、版本控制系统

其实配置管理最重要的一点就是版本控制，信心大家应该都用过类似像svn、git这样一些版本控制工具，或者说版本控制系统，但其实它最重要的功能，能记录你的变更，能快速记忆一个历史的版本去重现和访问任何一个历史版本，去比对版本变更的具体内容，基于任何一个版本去拉取你的构成分支。这就是版本控制一个非常重要的功能。

大家往往忽视的实际上是版本控制另外一个功能点，我们使用这样的版本控制，它也影响了整个团队协作交付软件的过程。

类似git这种工具，实际上它并不是一个简单的分布式的配置管理，它能做到离线操作，性能比较好，等等，其实这些都是它工具本身的属性。这么说当然是没有错，但实际上大家看git，围绕实际这个工具实际上有非常多研发的平台，比如像github，基本上是现在开源软件的标准，国外基本上都在使用github这种工作流。

这种版本控制方式定义了软件多地多人协同的方式。

从表面上来看，比如通过pull request分支开发，内建了一些比如持续集成、代码评审等方式，但实际上内涵包含了很多比如像精益思想，比如像拉动式的需求，可控的需求的改动。

整个版本控制工具体现了这样一种团队协同的方式，也就是说通过这样一种资源的共享、信息的透明，加快了整个问题定位和沟通解决的效率。

1、分支管理

提到分支，现在有非常多的优秀的分支模型，我们在谈到底哪种分支模型是最好的，大家经常，可能是跟我们这种开发模式是息息相关的。

有的公司我们在交流的时候提到，我们工程效率或者IT效能到底怎么样，其实可能都不需要去问你的发布频率或者发布周期，直接其看你的分支策略就一目了然了。如果我们采取一种非常混乱的长分支的模式，实际上也就体现出来交付的频率应该不会太高，而且最终集成的过程非常痛苦，充满错误。

包括在DevOps状态报告里也提到，高效能的IT组织，往往会采取短分支或者类似主干发布这样的模式，采取这种分支模式就定义了整个软件交付完整的过程。

之前在以前的公司也经常有pm会提出我们要在发布前对主干进行锁限，其实我个人一直对这个东西非常有意见，因为我理解这个东西就意味着DevOps的反模式。对主线做锁限，其实它对主线质量的提升并没有直接的作用，而且也体现了一种对立，一方面是对整个软件质量没有信心，另一方面也体现了不同角色之间彼此的不信任，我没有办法约束你，怎么办，就把权限收掉，你也不要提交了。

这和我们说所倡导的DevOps这种协作，打破筒仓，大家去共享责任、共享目标的方式，其实是背道而驰。也体现了研发在定义一个非常有效的、高效的分支策略，对我们最终快速发布产品或者说建立一个有效的持续集成落地的机制，实际上是非常重要的。

比如你采取的是一个多分支的研发方式，实际上你的持续集成也很难去开展，因为大家长期都在本地的分支上去做，彼此之间不去了解，所以你也很难做到持续集成。

3、构建产物管理

实际上就是制品库，为什么会有一个制品库，我们在所交付的内容最终是需要有一个统一地方管理的，如果没有一个有效的制品库，研发采取一种线下点对点传递的方式，你很难知道到底哪个制品或者哪个交付物是我们最终上线的这个版本。

这里面也体现了很多配置管理的核心思想，配置管理更多的是希望让整个研发过程变得有序，减少这里边一些没有必要的沟通，减少返工的过程，但实际上制品库就是里面一个非常好的实践，我们不仅需要有一个制品库，还需要把这个制品库进行清晰的目录结构和分级。

如果说我们这个制品库里面是一个乱七八糟的东西，实际上大家还是不知道我需要的这个制品到底放在什么地方，还是会来问你，我上线的版本到底是哪个版本，增加了很多不必要的沟通，从而降低了工作的效率。

制品库分级的理念源于我们要做流水线的分级，当我们交付的能力越来越强，交付的版本或者交付的制品越来越多，实际上我们制品库里的内容也会越来越多。如果把这些制品一股脑都交给测试，测试就会看到无穷无尽的待他们去验证的版本，相当于把每个人的工作台堆满。当你的待办事项非常长的时候，每一个待办事项相当于一个债务，如果你看到你这个待办事项是一个无穷无尽的列表的时候，估计这个人就直接崩溃掉了。

所以我们要做制品库的分级，要看研发阶段的制品和能进入到测试环境、准生产环境和生产环境发布的制品，实际深是不一样的，而且每个应该有一个对应的版本号或者相关的可追溯的定义。同时对制品库，实际上需要有一个比较成熟的备份还有清理规则，尤其随着很多团队现在都是一种分布式或者说卡地域的协作方式，这种制品的传递或者有效性、一致性，其实对整个团队共同语言的制作实际上非常重要。

4、单一可信数据源

其实我在过去很多分享里都有提到过这种SSOT的概念，翻译过来就是单一可信的数据源。这样一个数据源其实它应该是可以覆盖到整个配置管理的方方面面，包含版本控制系统，也包含制品库。

不仅如此，还包含了很多其他的内容，整个研发系统过程中的数据，它需要一个可控的状态，我们需要知道使用的数据的版本，需要知道使用的数据它们的来源在什么地方。这个数据源在企业内部的建立非常有助于大家在研发或测试或生产阶段能使用相同的版本，达到环境的一致性。

什么东西需要放入到这样一个单一可信数据源呢，应该说所有需要纳入版本控制的都是需要放在SSOT里面的，包含OS的镜像，包含在OS上安装一些软件包，也包括我们做编译构建里面用到一些类库或者第三方的Maven，包括像NPM等，这些东西都有一个版本的概念，如果说这种版本去滥用，实际上你依赖于的东西不可靠，你构建出来的东西也是不可靠的。

所以不管从一致性的要求，还是从安全，还是从各方面来考虑，我们都需要去建立这样一个单一可信的数据源，并且让这个数据源贯穿整个研发价值的交付流。同时一个数据源能体现一个非常重要的内容，建立组织内部的共享经验和知识积累的体系和平台。

我们经常说DevOps要把局部的改建扩充到整体的组织全局，怎么样建立一个有效的组织内部去开放共享这样一个机制体系，实际上是一个非常重要的课题。

谷歌使用了单根代码库，一个代码库里面有非常多的内容，其实也体现了他内部经验共享的思想，遇到问题的时候不一定都是要大家从零开始做，有很多现有的方案、机制可以共享出来，加速我们的很多工作，也避免不必要的浪费和重复建设。

版本可追溯性

所谓可追溯性，当我们一个变更从需求经过我们的开发，一直到测试、上线，在整个流程里它的信息如果我们不做可追溯，它实际上是割裂的，我们的软件经过研发，换了另外一种形态，成了制品，我们的需求通过一种开发的过程，变成了源代码。

1、变更过程

随着整个需求在交付过程中形态的变化，流转到不同的项目阶段，那我们就需要去建立可追溯性，我们所有的不管价值也好、缺陷也好，最终的源头都是变更。我们需要知道每一个变更它相关联的这些内容它的来源和具体的属性。

如果没有建立这样一种可追溯性，我们在做变更的管理或者最终版本的上线或回溯实际上是没有依据的，没有办法做到非常快速精准的自动化的重现和快速的恢复，这是版本可追溯性的第一个特征。

2、变量追溯

我们很多信息是不连贯的，信息的载体不一致，在做变更可追溯的时候实际上要建立一些规则。比如我们通过什么方式去实现这种需求，去建立一个提交日志的规则。另外我们需要有一些手段，去保证这样一些规则的一致性，如果说研发需要在很多地方去维护这样一些信息的时候，经常会出现这种信息的不一致。

这种一致性的思想需要嵌入到我们将来去构建的部署流水线里，当我们的代码经过一系列的检验、自动化的工作包括手工的验证，达到一定阶段的时候，那它相应的一些需求的状态实际上也需要自动切换过来，通过一种自动化的机制来保证我们信息的连贯和一致性。

3、变更回滚

回滚是我们要去做追溯非常核心的一个因素。不仅如此，回滚除了要快速的修复问题，从好的方面来说，也要帮助我们能快速上线一些历史已经上线的功能。比如说我们在开发多个产品的时候，很多需求也好、测试也好，很多东西是可以复用的。

如果说我们能建立这样一种从变更到代码的映射关系，当我们去开发一个新的产品的时候，我可能只需要把原来这种产品的需求拎出来，通过一个需求就能牵出一系列的，包括完整的，包括代码的改动，包括测试用例，包括很多测试数据等一些心理，都能快速应用到新产品开发上来，帮助我们新产品加快开发迭代速度，也是建立全局一致性和可追溯的非常重要的好处所在。

构建与持续集成

构建实践

相信这块大家都非常了解，也是每天都在接触的实践。

构建，我们简单去理解，就是帮助我们从软件的源代码变成一个可执行程序的过程，在构建里面我们分为四个维度：

1、构建方式

最开始的构建一般是通过手工共建或者IDE，集成研发环境的这种构建。实现方式基本上都是不可重复的过程。我们逐渐去优化构建方式，把整个构建做标准化、自动化。

这里面大家提到构建的标准化，标准来源于哪，就来源于配置管理，如果配置管理没有定义非常清晰的规则，构建也很难做标准化。配置管理所涵盖的领域非常多，就看你怎么看待这个问题。当我们构建完成标准化，这样的工具也可以实现一些复用，甚至说能提供一些可视化的编排等。

2、构建环境

构建的环境是千差万别的，尤其现在随着整个产品里面这种技术栈不断的发展延伸，经常会发现一个应用里，它的前端后端包括很多地方用到的技术栈非常不一致，这也对构建环境的建立提出了非常高的要求。

传统我们的做法，在固件服务器上去固化环境还有一些工具，把构建工作跟这样的环境做一个强绑定。最终的结果是，资源的分配不合理，闲的闲死，忙的忙死，因为每一个构建所消耗的资源和时间是不一致的。

随着技术的发展，慢慢引入了很多包括容器化的经验或者一些新的技术，保证了资源的抽象，所有的构建环境都是可以去动态生态，都可以动态调配，保证了资源的动态利用率，这样一种方式可以大大提升资源的利用效率和有效性，对资源的重复建设有非常大的改进效果。

我们之前在公司中推广这个工作时就做过一个衡量，如果采取这样一种动态式的构建集群，基本上成半的节省构建的时间和构建的成本，因为很多资源可以实现复用，而且可以实现有效的隔离。

做构建一开始可能只关注它的自动化，但随着对发布节奏的诉求越来越强，整个构建速度也提到非常高的要求，当提到做持续集成的时候，希望单次持续集成的过程不超过10分钟或者15分钟的水平，这个对整个构建速度的优化是非常有技术含量的内容。

之前如果说对整个构建系统或者编译语言比较了解的人，实际上也是非常有价值的一些人才，可以通过很多方案，比如缓存、分布式构建、可靠的增量式或者模块式的构建，通过这样一种是去保证很多东西可以真正有效构建，也加快构建的速度。

3、构建计划

构建计划也体现了整个版本交付的效能。从最开始没有一个明确的版本计划，到后来实现了每日构建。

每日构建并不是去倡导的持续集成，持续集成倡导的是能快速集成每次代码改动，但是每日构建还是一次性的大批量的集成的方式，而且每日构建的结果实际上也是不可靠，或者经常会出现一些问题，随着能力的逐渐提升及构建的频率、频次和灵活性也在不断提升，随着构建效能的提升，也越来越把这种构建的能力向外开放，赋予更多的人员，真正实现按需构建，这种方式也代表了构建性能的提升。

4、构建职责

构建相对还是有一些专业的属性和专业的背景和技能要求的，在初期团队一般都会有专门的人员去负责这样一种构建环境和构建工具的变形，而且会使用一种隔离的方式，只有少部分人去动这个构建工具，能去修改这样的构建环境，这个就是通过职能的方式去做的一种隔离，依赖于职责的方式去做构建。

在DevOps里叫做跨职能团队或者叫梯形人才，这样一种构建的能力怎么能通过一种很好的封装，能把它提供出来。这就带给我们去构建一个DevOps平台或者提供一个自服务，自主化的构建系统原始的初衷。

如果说我们这个构建已经做到一定程度的时候，构建能力可以赋予到全部团体成员的，所有人都可以去按需正确的去触发构建，不会担心一次错误的操作或者一个错误的选项导致一个错误的构建，这个系统应该能支持这样一种功能。

持续集成

持续集成实际上是工程领域的一种最佳实践，也存在了非常长的时间。

持续集成体现了一种降低风险、快速反馈的核心思想，通过我每次代码提交都去触发一个完整的构建和自动化测试的流程，来帮助我们在第一时间发现这一次集成过程中的问题，帮助研发快速去修复反馈这样一种问题，从而提升我们软件的质量，帮我们把质量直接内建在研发的过程中，最终达到的效果，让软件随时处于一个可发布的状态，至少是一个可测试的状态。

对于持续集成的标准，我们将它划分为四个主要维度：

1、持续集成服务

在大多数团队都有专门独立的持续集成服务器，有的团队也会有专门的负责人去负责持续集成服务的优化和建设，但实际上我们认为随着持续集成成熟度的提升，持续集成应该是一种能力，这种能力是需要嵌入到每一个研发团队的日常活动之中的，这种能力非常依托于整个持续集成服务自助化和服务化水平的建设，只有当这种持续集成的服务变得足够成熟，才能保证每一个团队都可以按需获取到持续集成带来的价值。

2、集成频率

持续集成就要求大家以一种非常频繁的方式向主干集成代码，随着持续集成频率成熟度的提升，研发向主干提交代码的频次也会逐步提升，相应的也会采取一种合适的分支策略，去推动一种分支策略的演进。

3、集成方式

推荐所有的持续集成是由代码提交来自动化触发的，而且每次持续集成会包含完整的代码构建、自动化测试以及相应的代码检查等一系列的活动，来保证持续集成过程中可以最快的进行版本质量的反馈，保证整个主线的提交质量。

4、 反馈周期

第一是持续集成发现问题或者出现错误的时候，是否能在第一时间给予反馈，并且这种反馈应该是一种精准的反馈，反馈到相应的负责人。

第二，相应的负责们收到反馈之后，他有多长时间才能修复这样的问题。

但实际上这一点不仅是能力的问题，还是团队文化和机制建设的问题，整个团队是否能够强调修复持续集成红灯的问题是最高优先级的，深入到每一个研发团队人员的意识里面，才能保证出现的问题能在第一时间去修复，能保证每个人在下班的时候我们的持续集成系统是可用的是完好的。

不仅如此，持续集成里面包含更多的优秀实践，它也是一个优秀实践的结合体。比如单一代码库、自动化构建、自动化测试、频繁提交、快速修复问题、缩短构建时间、使用类似生产环境等，所有的实践结合起来才构成一个有效的持续集成服务。

测试管理

测试分层策略

在传统的软件研发模式里，测试往往是一个独立的阶段，它会在研发完成之后才会接入到软件交付的过程里。但实际上在持续交付的思想里，测试不应该是一个独立在后端存在的阶段，而是作为一个整体来进行规划和执行，并且把测试融入到持续交付的各个链条中，来达到一种质量内建和测试左移的方法。

对于测试分层，业界也一个非常经典的测试三角形，包含UI用户级的测试，和接口服务级的测试，以及包含代码级的测试。

最开始的时候我们可能会更多的使用UI级的测试，逐渐会建设一些接口和服务级的测试，拓展到全面的代码级的测试。

同时测试分层比例也会成熟度的提升，越来越向前端向代码级去拓展，而且在测试策略分层建立的过程中，随着我们不断的发现后端测试或发现的一些问题，这些问题会把它成为一些相应的测试方法和测试用例，内建于更底层的测试里，来保证这样的问题可以尽快发现、尽快反馈。

在持续交付也好，在DevOps里也好，测试是永恒的话题，对于测试需要一个非常长久的积累过程，投入巨大，收入也巨大。

之前在《DevOps Handbook》里也提到过一个谷歌的案例，2005年的时候，谷歌自己没有自动化测试，谷歌提交代码也是没有质量保证的。对于这样一个非常追求工程能力的团队来说，他们的这种工程能力或者测试能力，也是一步一步通过一个非常漫长的阶段逐步积累和建设起来的。

他们在做这样一个自动化测试和推广的时候，采用了非常多也有意思的方法，比如成立一些测试的兴趣小组，比如去贴厕所小报，吸引更多人的关注。同时建立了一些测试认证的路线图，举办了一些活动，并且帮助很多其他的团队去优化自动化测试的流程。最终的结果，2015年的时候，谷歌每天会运行大概七千多万个测试用例，这是一个非常庞大的测试积累，所以这也需要我们重视测试能力的体系建设。

代码质量管理

这部分更多是关注一些代码质量的规约和检查策略、检查方式以及反馈处理等。

对于一家成熟的公司，他们都应该有一个非常完善和非常有约束性的代码质量规约和代码标准。对于这样一些规约和标准是需要嵌入到每次的代码提交和每次代码持续集成的过程中，并且每一个人在进行代码提交之前都会进行本地的代码扫描、代码质量检查。

之前阿里也推出了一个基于JAVA的PME的代码规约的扫描插件，在业界也是广受好评。通过这样一些插件，通过这样一些规范，把成文的规约固化到研发的过程中，并且通过一种自动化的方式，通过一种工具的方式，给予自动化的监测和反馈。

一来保证所有的代码提交质量是符合我们规范的，二来也帮助研发团队去快速提升他们自身的能力，去达到公司统一的水平。对于这样一些问题的处理是否严格，实际上也反映了对于代码质量管理这块能力成熟度的水平。

经常有的公司建立了很多基于文档上的代码质量规约，但实际上从来没有严格执行，这就导致随着我们代码提交量越来越多，我们的技术债务也会逐渐累积，扫描出来的问题也会不断增长，这就反映了我们对质量的态度或者对质量关的意识，只有重视代码质量，建设在日常活动之中，才能保证这样的问题不会长期积累和扩散。

自动化测试

其实大家也发现了，不管我们在谈任何部分的时候，都会引入自动化的能力。

自动化确实是我们在做持续交付的一个法宝或者说一个非常能体现效果的能力的建设。对于测试这种负责消耗人员、非常消耗资源的活动来说，其实它更依托于自动化测试能力的建设。

首先包括我们自动化测试的设计，自动化测试的设计映射到测试分层策略里，对于UI层或者接口层或者代码级，是否能逐渐建立相应的自动化测试能力，并且进行自动化测试的开发。

对于自动化测试执行也会要求嵌入到持续集成流水线里，去保证所有的测试可以端到端的打通，去自动化执行。而且每次测试的执行效率和执行时间是应该有所约束的，因为只有在前期快速进行测试和反馈，才能保证反馈速度。

对于自动化测试的结果要针对性的进行一些分析，比如建立一些模式的类库或者引入一些自动化分析和定位的能力，不仅能帮助研发快速的去分析和解决这样一行问题，而且随着这样一些问题库逐渐的累积，它也是一个团队内部去互相学习、提升能力的非常好的参考资料，它也会指导研发能力建设的方向和指标，对于测试的自动化能力来说，也要随着测试分级策略执行来不断强化，不断驱动，不断去建设完善。

部署与发布的管理

部署与发布模式

只有当软件真正在线上去完成部署和发布，对用户可见，这个时间点才是真正完成了一次又意义的价值交付的活动。

往往整个部署和发布的活动又是非常复杂和高危的，经常会伴随着很大的失败和潜在的风险。所以对于不符合发布模式的环节里，重点是关注交付过程中的具体实践，去把部署的活动尽量自动化，并且通过频繁的演练和实践，去帮助部署和发布的风险逐渐降低，成为研发过程中一部分，来最终实现可靠可重复的活动。

对于部署与发布模式，划分了四个维度：

1、部署方式

从最开始纯手工的部署到自动化的部署，一直到一键式部署，类似持续集成服务一样，部署应该也是一种能力，它这种能力也应该固化到持续交付系统里，来保证所有人都能安全可靠的完成一次上线部署

2、部署活动

对于原始的初级的部署活动来说，经常是复杂和不可控的，而且会伴随很多问题。随着流程文档标准化过程的定义以及所有部署过程和工具去固化到整个系统里，最终达到一种部署过程的灵活响应和能随时响应业务的部署和发布，来实现持续部署的目标。

3、部署策略

对于部署策略来说，从原始的大批量的部署到把这种部署的频率增高，来保证每次部署的变更足够小，来实现风险可控以及应用和数据库的分离。同时随着容器技术的成熟，每一个部署的最小单位也从一个应用延伸到完整的应用和系统、可运行环境的打包。

在这个过程中可以引入很多的部署策略，像蓝绿部署、金丝雀发布等，来保证可靠和低风险的部署能够持续进行。

4、部署质量

对于部署的质量来说，也需要我们去内建很多的回滚和监控的机制，来帮助我们发现在部署过程中一些潜在的问题，可以实现自动化的回滚。

持续部署流水线

相信了解持续交付的同学都知道，持续部署流水线实际上是DevOps或者持续交付里非常重要、非常核心的环节，经常需要去打造可靠可重复的流水线。

流水线的价值在于几点：

第一，可以可视化端到端价值交付的过程，因为在部署流水线里，从代码提交一直到部署上线完全的环节，通过这样一条统一的部署流水线，可以把软件交付中的各个环节、各个团队集中到这样一个部署流水线里，来保证交付过程的持续性。可以看到我们在交付过程中的一些瓶颈和问题。

第二，在部署流水线里建立反馈机制，在任何一个环节出现了问题都可以及时的去反馈，及时的去修复。

第三，部署流水线并不是要集成非常多的功能，它最大的意义在于可以把我们现有的在各个环节里的一些能力、一些系统拼接上来，统一接入到部署流水线里，一来可以复用现有的一些能力，二来也能实现端到端可视化的价值交付。同时自动化在各个环节的陷入，实际上也是提升部署流水线效率的一个非常重要的环节。

在这里面谈到的部署流水线，并不是说端到端去做持续交付的部署流水线，更多是关注我们去建设部署流水线具体的工程实践。

这里我们把它分成三个部分：

1、协作模式

通过部署流水线打通软件交付的过程，从一开始按照一些文档或者交付的checklist移交的方式，接下来不断延伸到实现一种自动化的交付和团队中的交接

2、流水线过程

更多的还是去体现一些自动化能力的建设，包括全流程的监控等。

3、过程可视化

过去很多交付过程实际上信息是停留在某一个团队内部的，经常会有项目经理去问这次版本发布到什么状态了，这次版本是否编译出来了，或者测试是否通过了里面会存在非常多的依赖于人的沟通和信息的同步。那么当我们去建设这样一条部署流水线，交付过程在团队内部大家都可以看到。

整个过程的信息可以进行有效的整合和分析，这也会帮助我们去发现在软件交付过程中一些潜在的风险，去帮助我们识别后续进行持续改进的一些有效的方向，最终帮助这样一些过程信息的价值挖掘，来推动业务的不断改进。

环境管理

环境作为DevOps持续交付最终的承载，环境类似生命周期管理还有一致性、版本等，都非常重要。环境管理的最终目标是用最小的代价来达到环境的一致性。

我们在做软件开发过程中经常会遇到这样一些问题，比如线上或者构建测试的时候出现了一些异常，我们其找到研发团队的时候，研发就会说，我在我本地的环境是没有问题的，是不是你服务器上环境的问题？这就很难说清楚了，到底是代码的问题还是环境的问题，这也导致大家在面临问题的时候会出现一些推诿或者彼此的不信任。

统一环境非常重要，最开始我们谈到配置管理的SSOT，也就是单一可信的数据源，有密不可分的关系，对于环境一致性说，不仅在生产环境，也要覆盖到软件交付的各个环节，甚至包括研发本地的环境。

对于环境管理，分成了三个维度：

1、环境类型

最开始只会区分生产环境和非生产环境，接下来会重视测试环境的建设，体现出一种环境分级或者环境分层的思想及随着持续交付过程意识到研发阶段，我们会逐渐去提供面向各个开发者独立的研发的工作区，并把环境覆盖到所有的环节。

2、环境构建

环境生成的过程最开始更多是通过人工的方式，随着脚本和基础设施及代码的成熟度，可以保证我们的环境可以一键生成，可以保证环境的一致性，而且通过Docker容器这样一种技术的成熟，可以保证所有的应用和可运行的环境可以打包去进行交付，这也保证了更高层面的一致性的要求。

3、环境依赖和配置管理

这里面也体现了很多类似于配置管理核心的策略，包括资源化的一些描述，像dockerfile及其实配置管理这种能力是需要嵌入到所有的持续交付每一个环节里的，包括我们对于环境一些配置脚本或者说一些配置文件等，这些都是需要纳入到配置管理的范畴里进行相同的一些代码的review，甚至说这样一些环境相应的变更也是需要触发同样的部署流水线。

数据管理

从我个人的角度来说，第六部分数据管理应该是持续交付所有部分里难度系数最高的环节，这里面也非常依赖于现有的一些业界的优秀实践，来指引这些方面数据管理的落地和实施。对于数据管理分成两部分，一块是测试数据管理，第二块是数据库的数据管理。

测试数据管理

测试之所以会非常依赖于我们的投入或者说它非常花时间，其实这个时间很大程度上就在于测试数据的生成和管理。

测试数据会分成四个维度：

1、数据的来源

对于数据的来源，我们从一开始要去手工建立测试数据，到基于生产环境区别导入这样一个子集，并且进行数据清洗以后来满足部分测试用例的要求。逐渐去提升测试数据生成的方式，包括自动化或者说通过API转存等，覆盖更多的测试内容，包括功能、非功能测试等。

2、测试数据覆盖

一开始测试数据的覆盖率普遍会比较低，随着测试数据来源或者测试数据生成能力的提升，测试数据也会逐渐覆盖更多的测试类型，比如正常类型，一些边界类型。同时测试数据也会逐渐成为体系化，去覆盖更加复杂的业务场景，去满足安全漏洞以及开源合规等特殊场景的需求。

3、测试数据独立性

往往测试数据一开始没有所谓的版本控制和备份机制，所有的测试都是使用同一个测试数据，这就导致测试对数据造成的一些修改，会影响每一个测试执行的可靠性。在这里面我们就需要有一些手段去保证我们测试数据是独立的，同时是可以有一些类似于版本控制机制。

因为整个测试数据集可能是非常庞大的数据量，如果说对每一个测试有一个完整的测试数据集，对管理来说也是不高效的方式。所以我们需要建立一些测试数据的分级，来实现专属的测试和通用的测试数据的分离。同时保证不同类型的测试数据可以灵活组合，实现测试数据独立性的同时去保证测试数据的有效管理。

4、数据安全

测试数据如果使用到一些生产环境的数据，这里面需要很多安全合规以及进行数据清洗的过程。这部分在安全管理这个独立的章节里也会有更加详细的阐述。

数据变更管理

数据变更管理，更多是关于数据库包括数据库的结构和数据库数据管理的最佳实践。

随着应用无状态化甚至像基础设施也逐渐实现无状态化，数据的管理成了一个非常老大难的问题。

我们可以对应用做快速的水平伸缩和扩展，对数据进行滚动升级或者降级，其实对一些无状态的服务实际上是非常易于管理的。但是数据因为它的一些持久化的特征和它的一些有状态性，实际上非常难以实现零停机部署或者实现秒级切换等，因为要考虑到非常多的因素，比如像应用和数据库版本的匹配，比如像数据库数据的回滚等带来的一些问题。

对于数据管理我们提出来四个维度：

1、变更过程

传统企业里，数据这块内容非常核心，都是由一个专业的DBA的团队去试试数据的便变更，DBA也会作为持续交付中一个独立的环节，相当于我们前端的开发团队包括测试、部署环节，都有非常强的耦合和依赖，而且这些数据变更更多是依赖于文档来实现标准化。

随着这些自动化脚本能力体系的建设我们希望数据变更可以作为持续部署流水线中的环节，随应用的部署自动化的去完成。这里面就要求应用程序和数据库进行解耦，而且可以实施版本的匹配。

2、兼容回滚

核心是想去建立一个明确的恢复和回滚机制，并且尽量是使用一些自动化脚本的方式，来实现一些数据升级和回滚。

但实际上这里面有一个值得注意的点，我们要进行数据库回滚的时候，这里面数据的保存和牵引是要非常关注的，实际不管是做灰度发布或者蓝绿部署等，在这里面如果涉及到数据库的变更，还是会有一些短暂的（只读）期间等，来保证我们进行蓝绿切换的时候实现这样一个数据一致性的要求。

3、版本控制

同样是对于配置管理的一些要求，比如我们数据库的版本，还有变更的脚本，是否纳入变更管理的过程，是否触发了相应的一些代码review和持续集成、部署的环节，这实际上是在每一个持续交付的环节里都是共通的要求。

4、数据监控

去建立一些相应的监控体系，帮助我们定位数据变更的结果，来应对不同环境下的操作，同时可以监控一些异常的变更状态，来帮助我们做一些回滚或者决策。

度量与反馈

在刚才很多子模块里都提到了一些监控，对于度量与反馈体系，在讨论持续交付标准的时候也一度想过是不是需要把这样一个度量和反馈体系也独立出来。一个监控的体系，它也是需要去做端到端嵌入每一个持续交付环节里的，在这里我们还是把它保留在了持续交付的工程实践里，在敏捷开发管理的环节里也有一些这方面的体现。

度量指标

这个应该是我们谈到DevOps时经常会提到的一点，开发和运维的度量指标的不一致性，才导致我们交付软件过程是一个割裂和冲突的过程。

1、度量指标定义

对于度量指标来说，主要分为几类，一类是结果指标。在DevOps状态报告里也提出了四种两类的结果指标，去体现IT价值交付的生产力和质量水平。对于过程指标，实际上是嵌入到持续交付各个阶段里。对于探索性指标来说，更多的要去帮助我们发现识别一些潜在的问题，以及一些可实施改进的点。

说到这里，延伸一下，到底什么是一个团队，我们认为一个团队，团队中的所有人有一个相同的目标，往相同的方向去走，这样才实现了一个团队。

对于团队管理里面会有两种方式，一种是基于KPI的方式，另外一种是基于OKR的方式。当时我们在写这个标准的时候，怎么样去保证这样一个指标的有效性，提到了遵循SMART原则，SMART原则是五个英文单词首字母的缩写，也就是要保证指标是具体的、可衡量的、可到达的、其他目标相关的、有明确的截止时间的，通过这样五个维度来保证我们设定的指标是科学和有效的。

但是最近看到一篇文章提到，我们在制定KPI的时候，如果是按照SMART原则制定，因为我们在当初制定这样一些KPI指标的时候都是基于假设去做的，如果说基于一些假设来做到指标性的制定，实际上这些指标往往也是不可靠的，或者说存在很大变数的。

如果我们制定了一个非常严格的KPI，为了完成这些不可靠的指标，同时又没有一个对KPI进行灵活调整的机制，对于结果来说，我们去执行的手段和目标达到的愿景有可能是背道而驰的。对OKR来说，其实这是谷歌诞生出来的一种文化和价值观，它更多是关于一些目标和关键成果的考量，是帮助所有人思考沟通，来知道什么事情最重要，让大家对这些最重要的事情共同努力。

这也体现了我们要去实现什么样一些目标，我们就要制定一些相应的度量指标，对于度量指标的设立，尤其是跟人相关的，或者说有可能会影响行为的时候，我们要非常的慎重这样一些指标到底是不是合理的，到底是不是有益于我们去改变一些组织一些文化，来促进我们去做出一些正确的选择。

2、度量指标的类型

对于度量指标来说，它更多的初期会关注一些结果指标，这些结果指标也是我们在做DevOps转型或者做一些改进活动重点关注的点，就看看这些改进是不是达到了预期，是不是有效的改进。

3、度量数据的管理

数据需要去积累、去管理分析的，如果说我们整个度量没有去进行一个长期的收集，也很难基于一些历史性的数据做出一些分析和数据的挖掘。在研发过程中，研发的数据量是非常大的，如果说我们没有去关注这样的数据，其实数据就没有任何意义，对于数据的管理，随着我们成熟度的提升，我们也会逐渐去加强，去利用好这样一些研发过程一些数据。

4、度量指标更新

度量指标的建立，它往往也是基于一些价值的假设，这些假设有的是可以去证真的，有的可以证伪。对于度量指标的设立，它不应该是一成不变的，而且是需要根据一些价值的要求和一些组织的目标，来定期的更新、定期的变化，来建立一个完整的度量体系和度量框架，来帮助度量指标有一个合理的进入和退出的机制，这也保证我们可以建立良好的度量体系，来指导研发或者团队目标的达成。

度量驱动改进

如果说我们无法去度量一件事情，实际上我们就没有办法去客观评价这件事情，自然就没有办法去实现最终的持续改进。度量的目的就是持续改进，在整个度量与反馈的过程中，我们会关注报告生成方式还有它的有效性，包括它的覆盖范围和反馈改进的机制。

1、报告生成方式

报告生成方式不仅关注自动化程度，另外关注报告分类和分级，是否可以通过多个维度把很多的信息能够有效的去整理去体现。

2、报告有效性

数据的及时性、准确性和有效性非常重要，因为报告的数据往往是我们进行决策的一个重要的依据。

3、报告覆盖范围

我们希望软件交付的所有人员都可以理解我们的业务需求、目标，这样一些报告不应该局限在非常小部分的范围里，而是要覆盖更多的团队，让所有人受益于这样的信息共享。

4、反馈改进

所有报告发现的一些运用，落实到改进环里，需要建立这样一种机制，把报告的问题纳入到待办事项，作为后续持续改进部分中的一部分。同时对于研发过程，我们要预留一部分时间，专门去处理这样一些报告所体现出来的潜在的问题，并且把这样一些改进的结果作为企业级的知识体系进行积累和保留。

随着数据挖掘和大数据能力的提升，我们要进行跨组织的数据度量分析，来帮助我们进行重要的业务决策，来帮助组织持续改进价值交付的过程。

三、回顾和总结

我不想更多提这些实践和理论方面的内容，而是想给大家先讲一个故事这个故事的名字叫“人脑的自行车”，这是我前两天听张晓宇老师在线分享的时候提出的一个故事。

这个故事来源于乔布斯的一次访谈，乔布斯说在他小时候曾在一个叫做《科学美国人》的杂志上读过一篇文章，这篇文章对比了地球上各种不同物种的移动速率，比如像熊、星星和浣熊，包括水里的鱼和天上的鸟类，当然还包括人类自己。

通过分析每一个物种、每一公里消耗的能量，最后来进行一个排名，排名的结果是秃鹰获得了最终的胜利，它的移动效率是最高的，而作为万物之灵的人类则排在了倒数几位。

但是这个调查并没有结束，这个杂志又额外去测量了一下人类骑自行车的速率，结果令人非常震惊，人类骑自行车的速率远远把秃鹫甩在了身后，在排名上遥遥领先于其他所有的物种。

这个故事留下了一个非常深刻的印象，人类擅长发明一些工具，而工具赋予了我们很多奇妙的能力。人脑的自行车实际上来源于苹果之前的一条广告，说的就是计算机，他们将计算机比喻成人类头脑的自行车，也就是说坚信将来回顾人类历史的时候，计算机将是人类最伟大的一种发明。

再看一下持续交付体系，对于这样一个复杂的持续交付体系，我们同样需要创造性的发明一辆自行车，通过这辆自行车来实践持续交付，进而帮助业务实现最初的目标。提到这样一个工具，我们认为最合适的就是持续部署流水线，持续部署流水线将是未来持续部署平台也好还是研发平台也好，在其中的核心价值。

基于这种思考，社区也在总结持续交付最佳实践体系和业界最新技术的同时，联合业界的一些专家推出了端到端部署流水线2.0的产品，在这样一个产品解决方案里，其实我们并没有引入太多开发的工作量，而是使用了业界流行的主流开源工具以及一些比较普遍的商业工具，对这些工具基于持续集成的一些思想进行了有机的整合，并进行了一些良好的设计。

从而通过这样一个工具解决方案来展示我们去应用持续交付的时候会给业务的发布，会给价值交付的链条带来多么有效的效率提升。

这个工具在2017年11月的Jenkins用户大会上，由乐神正式对外公布，如果大家有兴趣，我们后续也会逐渐去公布更多的技术细节和解决方案，帮助大家在未来建设自己的持续交付平台和自己的部署流水线的时候有所借鉴和参考。

这是一个行业的标准，也是世界范围内第一个DevOps的标准，既然是一个行业标准，我们认为就应该有一个开放的心态，不应该是由小部分人去制定这样一些标准，而是欢迎更多的人加入进来。

所以对于持续交付领域，如果您有深刻的理解，有丰富的实践经验，自认为是这方面的专家或者愿意参与贡献在行业标准的一份力量，来和我们一起在DevOps道路上一路前行，那么您就是我们所需要的英雄。

也希望您扫描上边的二维码，我会把您拉入整个行业标准的讨论群里，跟各类精英进行深度交流，并获取DevOps标准的一些最新信息。

最后特别感谢我们专家团的成员，这样一个成体系的标准的诞生绝不是一个人所能实现的，而是要依赖于很多同事的贡献，他们在自己的运维工作里付出了很大的精力，投入到开源标准的工作里，在此也对所有参与这项工作的专家们表示由衷的感谢，也希望更多的人能加入到我们的行列里，共同打造一个属于我们自己、属于整个社区的DevOps开源体系标准。

今天的分享就到这里，感谢大家！