前言

今天我给大家分享的话题是 DevOps 的道法术器，这是由高效运维社区和DevOps时代社区联合发布的DevOps体系化实施框架，我们希望通过这个框架的发布，能够帮助业界朋友们更好实施和践行DevOps。

近几年比较流行的一个概念是VUCA，它描述了我们所处的环境所充满的易变性、不确定性、复杂性和模糊性。

在互联网行业工作比较久的朋友们，都应当很有体会。其实我们做任何软件的交付，最重要的是向用户交付价值，需要满足用户的需求。

但是在很多的项目、场景里面，我们会发现其实用户的需求本身是存在非常大的不确定性和易变性的。

当年乔布斯说过一句话，他说“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西”。但是大家都不是乔布斯，我们经常遇到的情况是什么？当我们没有发布产品之前，用户可能不知道自己需要什么；但是当我们发布产品以后，用户终于知道了自己不想要什么。因为客观规律是：人的认知是需要随着时间不断升级的，我们很难一次性把事情想清楚，是需要在不确定的环境中持续迭代的。

而作为软件的交付过程来讲，需求是源头，如果需求都是易变、不确定性的，那么整个交付过程会面临的复杂性、模糊性，以及各种挑战就更多了，所以我们认为VUCA是当前我们所处环境的新常态。

下面是一段很悲情的话：“我们不知道我们错在哪里，但是无论如何，我们输了”。这是诺基亚的前CEO在宣布被微软收购时，在最后一次公开演讲结尾所说的一句话。在VUCA的新常态中，如果我们不能很好地适应变化，很有可能我们就会很快丢失掉这个市场。

其实我们做IT的同学，我们非常比较勤奋的，我们不断地自我迭代和演进。我们正在经历一场IT的技术革命。

图中有一些不同的维度：

第一个维度是应用架构，多年前开发软件我们主要是单体应用，所有的内容跑再一个进程里面；然后逐步演变为N层的架构，把展示层、逻辑层、数据层做了很好的分离；这些年大家都在提微服务的架构，希望每个服务单一职责，服务之间能够很好的解耦，每个服务能够独立开发、测试、部署和发布。

第二个维度是部署打包的模式，从基于物理机部署到虚拟机，再到目前的容器。我们已经不再满足于交付一个可工作的软件，而是希望每次交付是可正常运行的系统。

第三个维度是应用的基础设施，以前我们关注数据中心，后来更多关注主机托管，现在更多关注是怎样将应用迁移到云上。

以上这些维度都是相关技术的演进路线。

那么反过来，对于软件交付管理的模式也在发生着很多的变化。早在上个世纪六、七十年代，那个时候提出的软件工程方法，是用一种结构性、系统化、重管控的流程和方法去控制整个软件交付的过程，后来到了互联网时代，以敏捷化、迭代式、增量化的交付逐步成为主流，这会让软件交付过程更快、更灵活。

到现在我们讲 DevOps，是希望通过研发和运维/运营的融合，在保证质量的前提下进一步提升交付效率，所有这些维度构成了一场IT的技术革命。

那么DevOps到底是不是一个很好的方向呢？我们找了一些比较权威的数据。

左边的图是Gartner发布的技术成熟度曲线，DevOps已经跨越顶点逐渐向实用性发展，就是说概念已经被大家认同了，下一步考虑的问题是如何更有效、高效地将DevOps实施落地。

右边的这个图是近期发布的2017年DevOps现状调查报告中的内容。图中显示，根据逐年的调查数据，会发现DevOps团队的比例从2014年的16%，涨到2015年的19%，然后是2016年的22%，一直到今年的27%。趋势已经非常明显，我们说DevOps的效果已逐步被大家认同，我们认为这的确是一个很好的实施方向。

DevOps相关的内容我其实也做过很多的分享。这里我想强调，我们认为DevOps不仅仅是一个技术噱头，不是一些技术人员的玩具，而是希望能贡献业务价值，助力业务成功。

左下角的数据展示出来， IT的企业交付能力分三个聚类。高效能企业的比低效能的企业，无论是在生产力还是稳定性上，都有数倍的提升。比如说高效能企业发布频率快几十倍，变更的失败率要低五倍，这些都是DevOps能够带给我们的一些好处。

谈到DevOps落地，我其实非常喜欢盲人摸象这张图。曾经碰到不少朋友更多关注是使用什么样的工具去实现DevOps。有些人关注自动化，包括自动化测试和自动化部署；有人说DevOps是组织文化，重点是开发和运维的协同；也有人说DevOps要关注小批量的交付。这些关注点都对，但是可能不够全面。

所以我们就提出 DevOps 道法术器四个层次。

“道” 是目标、价值观，对价值的定位。快速交付价值，灵活响应变化，这是从价值层面的追求，或者是从第一性原理的角度来讲，我们做这个事情最终目标是什么；

“法” 是实现价值观的战略、方法，这个层次的主要思路是全局打通敏捷开发和高效运维。

“术” 是战术、技术，最佳实践的层次，我们要系统化的应用有效的方法、合适的技术，很多最佳实践帮助我们实现 DevOps 。

“器” 是工具层次，主要思路是用工具提升效率，将复杂的问题简单化。因为上面的层次有了很好的技术和方法，我们最终要把它落地、固化到工具平台上，并且希望实现整个软件交付流程端到端相互融合和贯通。

道、法、术、器自上而下是系统思考的层次，自下而上是解决问题的层次。我认为 DevOps 的规划和实施可以用这四个层次来概括。

一、道

首先是 “道” 的层次，主要目标是快速交付价值和灵活响应变化。谈到敏捷，谈到 DevOps，可能第一个诉求就是要快速交付价值。在互联网的时代，交付的速度是非常关键的。

原来的瀑布模型需要等到最后一个环节实施完成才向用户交付价值，而敏捷和DevOps 倡导小批量、增量式的交付价值，这就使交付价值的速度、面向市场的频率得到大幅提升。

除此之外，还要关注什么？还要关注端到端的交付价值，这才是真正的交付价值。如果仅仅在开发、测试环节做局部的敏捷优化，而没有考虑到后续的多服务集成场景，以及每次迭代后发布和运维的场景，这样就没有真正做到端到端的价值交付，所以我们需要做的是打通整个 IT 交付的全链条。

在价值交付这个层次，我们最终希望达成一个目标，就是通过 DevOps 打造一条高度自动化的 IT 服务供应链，能够快速、高质量地交付用户的价值。 DevOps 创始导师 Patrick 先生来华时给了我们一些启示，如何做到开发和运维的有效融合。

第一个维度是自动化，比如通过基础设施即代码的方式，将交付扩展到生产的环境；

第二个维度是度量，从运维侧 一些日志，监控数据等相关信息给到开发侧，形成有效的反馈；

第三个维度是文化，建立责任共担的机制，促进合作；

第四个维度是共享，将运维侧获取到的知识注入到开发侧，比如把安全需求、监控需求等非功能需求，加入到产品的Backlog中；

这样从四个维度将开发和运维之间做更好的融合，以上这些是 “道” 的层次。

二、法

“法” 的层次，我们关注如何全局打通敏捷开发和高效运维。这里面谈到很多的方法，我认为 DevOps 是一个集大成者，是很多优秀的方法的集合体，但是要更关注全局的整体优化而不仅是某个局部的优化。

左侧这张图来自DevOps Master的知识体系，主要讲敏捷、持续交付、精益、ITSM这些方法的适用范围和相互关系。

敏捷重点关注从需求、开发到测试的范畴；持续交付重点关注工程实践的范畴；在运维侧还是应用 ITSM 的方法，但是重点要关注如何将流程自动化并提升效率；另外还有一个贯穿始终的精益思想，它是以上诸多方法的基石。

右侧这张图来自Jenkins的创始人KK，很好的说明了敏捷、持续集成、持续交付、持续部署这些不同方法的效用和边界在哪里，以及各种方法之间的区别和相互融合关系。

下面是 DevOps 结构化方程模型，这个模型也非常有价值。

实施 DevOps 的过程中，我们经常会关注很多具体方法或技术的实现，比如测试和部署的自动化、分支模型、持续集成、架构解耦、自组织团队等等，还包括精益产品管理相关的内容，比如小批量、实验、反馈等。

但是往往我们忽略了最左边的一个部分，这个部分是变革领导力。什么是变革领导力？

我的理解是从一个领导者的层面，如何构造一个良好的氛围，助力 DevOps 的变革。比如说需要在安全空间范围内倡导免责的文化，鼓励改进冒险的行为。其实所有的改进要从领导力的层面建立一个良好的氛围，并渗透到团队当中，当资源具备、氛围建立起来，再和具体的技术、方法、实践引入相匹配，相辅相成、共同作用才能把 DevOps 有效推进下去。

以上就是“法” 的层次，希望能给大家一些启示，但这部分还是偏理论一些，那么下面我们看看具体的技术和实践。

三、术

“术” 的层次的主要思路是系统的应用各类技术、指导原则和最佳实践。这个层次涵盖的内容就非常多了，我们可以通过一张图来展示。

首先把相关技术和最佳实践分为管理维度和工程维度两个部分。

管理维度主要关注管理的范畴，针对软件生命周期不同的阶段有不同的技术和实践。比如目标确定阶段，可以应用精益画布和影响地图的实践；在版本的确定阶段，可以应用用户故事地图和敏捷迭代管理的相关实践；在迭代实施阶段我们可以应用精益看板、每日站会、敏捷度量（燃尽图、累积流图、散点图...）等实践，以上这些技术和实践可以帮助我们管理整个软件研发的过程。

在工程维度也对应了很多的技术和实践，包括配置管理、自动化测试、持续集成、持续交付、灰度发布、持续监控等等。以上这些组成了我们 “术” 的层次，下面我们找一些重点的做下介绍。

3.1 管理维度

以下是用户故事地图，可以用来做产品规划和发布计划。

用户故事地图有助于看到产品的全貌，可以根据用户体验路径，将Product Backlog 从一维列表延展成二维的表格。那么如果横向画一条线出来，那么可以很清晰的生成一个MVP，可以明确产品的发布计划。

在敏捷中 Scrum 模型已经非常普遍，我这里不详细阐述。

这里重点关注敏捷度量，比如用燃起图度量整体进度；用累积流图度量各个阶段累积处理的需求数量，以及它们随时间的变化趋势，可以从中分析出前置时间、交付速率的数据，以及协作模式的改进机会；通过散点图可以关注整个的交付过程中，平均前置时间、收敛趋势，以及通过对离群点的分析，找到改进的机会。在敏捷项目管理过程中，善用数据度量，是持续改进的前提。

3.2 工程维度

下面来看一下工程维度的内容，首先是持续交付框架。

关于持续交付框架，我个人之前也分享过很多了，主要思路是以建设可靠、可重复的持续交付流水线为核心，配合以相关实践和技术的导入，让整个软件交付过程实现高度的自动化和自助化。

除了框架的指导，我们还有很多最佳实践的集合。

上图是持续交付的光谱图，发布频率从100天发布一次到一天发布多次，所采用的分支模型、测试模式、系统架构、发布模式、基础设施和数据库的管理模式，都会有很多的实践需要变化。

我认为作为我们从业者来讲，是非常好的指导和参考，如果希望将交付的频率变得更快，稳定性变得更高，需要把这些实践调整和落地。

下图是基础设施管理方式的演进，从管理服务器到自动化、配置化环境管理，到不可变服务器模式。

我们希望交付流程里面尽量少的注入风险，所以通过封装运行时环境，通过不可变服务器的模式降低风险，这也更符合持续交付中的单一制品原则。

上图描述的是架构解耦，单体的应用的交付过程很难快起来，只有把单体应用解耦为一系列的服务，每个服务能够独立的开发、测试和部署，这样整个系统的演进和交付的效率才能够提升。当然，根据逆康威定律，改变架构可以从改变组织架构开始，然后围绕团队边界进行架构，降低团队之间高带宽的通信。

四、器

“器” 是指工具的层次，工具需要把上面层次提到的方法、实践固化和落地。工具通用需要考虑很多维度，比如说管理维度、工程维度、基础设施维度，而最重要的，是要把这些工具做很好地联通和整合。

今年4月份，在 GOPS 全球运维大会深圳站上，我发布了全开源端到端交付流水线的1.0的版本。

当时的目标是希望从社区的角度，我们做一个解决方案提供给大家，从而帮助大家通过开源工具更好的把 DevOps 实现和落地。那么效果怎样呢？当时我们做了一个演示视频，介绍整个的流水线过程和实现细节。这个视频到现在已经累计播放超过3.5万次，我们觉得还是很欣慰的，希望社区能够帮助大家做一些事情。如果还没有看过的朋友，可以扫图中二维码看观看。

当然，我们也是在不断迭代和自我改进的，我们在 V1.0 版本的基础上进一步完善和优化，现在提出全开源端到端交付流水线 V2.0 版本。

新的版本希望覆盖更多场景，包括APP发布流程，支持多种语言，支持一些友好的商业工具，支持 Mesos & Marathon 的部署，支持虚拟主机自动化配置，支持一键式自动进行工具间的集成等，也希望能够适配更多的场景下的不同需求。

V2.0 版交付流水线的技术架构图

可以看到比上一个版本做了很多更新和完善，适配更复杂的场景。

在需求侧，我们引入 Jira 做敏捷项目管理，依然通过 Gitlab 进行代码托管，采用 Feature 分支的研发模型。使用 Jenkins 和 BlueOcean 做流水线的编排和展示，流水线分为提交阶段、验收阶段、准生产阶段和生产阶段。

在流水线中集成很多工具，包括 Maven 、 JUnit 、Sonar、Selenium、Jmeter、PACT、Appium等，镜像管理使用 Harbor ，但也支持其他镜像仓库。

部署上支持Ansible或SaltStack，容器集群可以兼容 K8S 或 Mesos + Marathon。所以这也是一个解决方案，希望能帮助大家更好地通过工具落地 DevOps 。

今天我们讲的是 DevOps 的道、法、术、器四个层次，希望大家做 DevOps 规划和实施不仅关注工具、实践，更要关注它的业务价值，自上而下的推动，自下而上的解决问题，希望以上这些内容能够帮助到大家。

原创：张乐

DevOps时代联合创始人，高效运维社区合伙人，DevOpsDays大会、GOPS全球运维大会金牌讲师。国内首批DevOps Master，前百度资深敏捷教练、架构师。超过十四年敏捷转型、工程效能提升和大型项目管理实践经验，曾主导数百人团队实施DevOps转型，在保证质量的前提下发布频率提高数倍。在百度任职期间作为持续交付方向负责人，成功主导了多个战略级产品的敏捷转型和DevOps体系建设。

前言

今天我给大家分享的话题是 DevOps 的道法术器，这是由高效运维社区和DevOps时代社区联合发布的DevOps体系化实施框架，我们希望通过这个框架的发布，能够帮助业界朋友们更好实施和践行DevOps。

近几年比较流行的一个概念是VUCA，它描述了我们所处的环境所充满的易变性、不确定性、复杂性和模糊性。

在互联网行业工作比较久的朋友们，都应当很有体会。其实我们做任何软件的交付，最重要的是向用户交付价值，需要满足用户的需求。

但是在很多的项目、场景里面，我们会发现其实用户的需求本身是存在非常大的不确定性和易变性的。

当年乔布斯说过一句话，他说“消费者并不知道自己需要什么，直到我们拿出自己的产品，他们就发现，这是我要的东西”。但是大家都不是乔布斯，我们经常遇到的情况是什么？当我们没有发布产品之前，用户可能不知道自己需要什么；但是当我们发布产品以后，用户终于知道了自己不想要什么。因为客观规律是：人的认知是需要随着时间不断升级的，我们很难一次性把事情想清楚，是需要在不确定的环境中持续迭代的。

而作为软件的交付过程来讲，需求是源头，如果需求都是易变、不确定性的，那么整个交付过程会面临的复杂性、模糊性，以及各种挑战就更多了，所以我们认为VUCA是当前我们所处环境的新常态。

下面是一段很悲情的话：“我们不知道我们错在哪里，但是无论如何，我们输了”。这是诺基亚的前CEO在宣布被微软收购时，在最后一次公开演讲结尾所说的一句话。在VUCA的新常态中，如果我们不能很好地适应变化，很有可能我们就会很快丢失掉这个市场。

其实我们做IT的同学，我们非常比较勤奋的，我们不断地自我迭代和演进。我们正在经历一场IT的技术革命。

图中有一些不同的维度：

第一个维度是应用架构，多年前开发软件我们主要是单体应用，所有的内容跑再一个进程里面；然后逐步演变为N层的架构，把展示层、逻辑层、数据层做了很好的分离；这些年大家都在提微服务的架构，希望每个服务单一职责，服务之间能够很好的解耦，每个服务能够独立开发、测试、部署和发布。

第二个维度是部署打包的模式，从基于物理机部署到虚拟机，再到目前的容器。我们已经不再满足于交付一个可工作的软件，而是希望每次交付是可正常运行的系统。

第三个维度是应用的基础设施，以前我们关注数据中心，后来更多关注主机托管，现在更多关注是怎样将应用迁移到云上。

以上这些维度都是相关技术的演进路线。

那么反过来，对于软件交付管理的模式也在发生着很多的变化。早在上个世纪六、七十年代，那个时候提出的软件工程方法，是用一种结构性、系统化、重管控的流程和方法去控制整个软件交付的过程，后来到了互联网时代，以敏捷化、迭代式、增量化的交付逐步成为主流，这会让软件交付过程更快、更灵活。

到现在我们讲 DevOps，是希望通过研发和运维/运营的融合，在保证质量的前提下进一步提升交付效率，所有这些维度构成了一场IT的技术革命。

那么DevOps到底是不是一个很好的方向呢？我们找了一些比较权威的数据。

左边的图是Gartner发布的技术成熟度曲线，DevOps已经跨越顶点逐渐向实用性发展，就是说概念已经被大家认同了，下一步考虑的问题是如何更有效、高效地将DevOps实施落地。

右边的这个图是近期发布的2017年DevOps现状调查报告中的内容。图中显示，根据逐年的调查数据，会发现DevOps团队的比例从2014年的16%，涨到2015年的19%，然后是2016年的22%，一直到今年的27%。趋势已经非常明显，我们说DevOps的效果已逐步被大家认同，我们认为这的确是一个很好的实施方向。

DevOps相关的内容我其实也做过很多的分享。这里我想强调，我们认为DevOps不仅仅是一个技术噱头，不是一些技术人员的玩具，而是希望能贡献业务价值，助力业务成功。

左下角的数据展示出来， IT的企业交付能力分三个聚类。高效能企业的比低效能的企业，无论是在生产力还是稳定性上，都有数倍的提升。比如说高效能企业发布频率快几十倍，变更的失败率要低五倍，这些都是DevOps能够带给我们的一些好处。

谈到DevOps落地，我其实非常喜欢盲人摸象这张图。曾经碰到不少朋友更多关注是使用什么样的工具去实现DevOps。有些人关注自动化，包括自动化测试和自动化部署；有人说DevOps是组织文化，重点是开发和运维的协同；也有人说DevOps要关注小批量的交付。这些关注点都对，但是可能不够全面。

所以我们就提出 DevOps 道法术器四个层次。

“道” 是目标、价值观，对价值的定位。快速交付价值，灵活响应变化，这是从价值层面的追求，或者是从第一性原理的角度来讲，我们做这个事情最终目标是什么；

“法” 是实现价值观的战略、方法，这个层次的主要思路是全局打通敏捷开发和高效运维。

“术” 是战术、技术，最佳实践的层次，我们要系统化的应用有效的方法、合适的技术，很多最佳实践帮助我们实现 DevOps 。

“器” 是工具层次，主要思路是用工具提升效率，将复杂的问题简单化。因为上面的层次有了很好的技术和方法，我们最终要把它落地、固化到工具平台上，并且希望实现整个软件交付流程端到端相互融合和贯通。

道、法、术、器自上而下是系统思考的层次，自下而上是解决问题的层次。我认为 DevOps 的规划和实施可以用这四个层次来概括。

一、道

首先是 “道” 的层次，主要目标是快速交付价值和灵活响应变化。谈到敏捷，谈到 DevOps，可能第一个诉求就是要快速交付价值。在互联网的时代，交付的速度是非常关键的。

原来的瀑布模型需要等到最后一个环节实施完成才向用户交付价值，而敏捷和DevOps 倡导小批量、增量式的交付价值，这就使交付价值的速度、面向市场的频率得到大幅提升。

除此之外，还要关注什么？还要关注端到端的交付价值，这才是真正的交付价值。如果仅仅在开发、测试环节做局部的敏捷优化，而没有考虑到后续的多服务集成场景，以及每次迭代后发布和运维的场景，这样就没有真正做到端到端的价值交付，所以我们需要做的是打通整个 IT 交付的全链条。

在价值交付这个层次，我们最终希望达成一个目标，就是通过 DevOps 打造一条高度自动化的 IT 服务供应链，能够快速、高质量地交付用户的价值。 DevOps 创始导师 Patrick 先生来华时给了我们一些启示，如何做到开发和运维的有效融合。

第一个维度是自动化，比如通过基础设施即代码的方式，将交付扩展到生产的环境；

第二个维度是度量，从运维侧 一些日志，监控数据等相关信息给到开发侧，形成有效的反馈；

第三个维度是文化，建立责任共担的机制，促进合作；

第四个维度是共享，将运维侧获取到的知识注入到开发侧，比如把安全需求、监控需求等非功能需求，加入到产品的Backlog中；

这样从四个维度将开发和运维之间做更好的融合，以上这些是 “道” 的层次。

二、法

“法” 的层次，我们关注如何全局打通敏捷开发和高效运维。这里面谈到很多的方法，我认为 DevOps 是一个集大成者，是很多优秀的方法的集合体，但是要更关注全局的整体优化而不仅是某个局部的优化。

左侧这张图来自DevOps Master的知识体系，主要讲敏捷、持续交付、精益、ITSM这些方法的适用范围和相互关系。

敏捷重点关注从需求、开发到测试的范畴；持续交付重点关注工程实践的范畴；在运维侧还是应用 ITSM 的方法，但是重点要关注如何将流程自动化并提升效率；另外还有一个贯穿始终的精益思想，它是以上诸多方法的基石。

右侧这张图来自Jenkins的创始人KK，很好的说明了敏捷、持续集成、持续交付、持续部署这些不同方法的效用和边界在哪里，以及各种方法之间的区别和相互融合关系。

下面是 DevOps 结构化方程模型，这个模型也非常有价值。

实施 DevOps 的过程中，我们经常会关注很多具体方法或技术的实现，比如测试和部署的自动化、分支模型、持续集成、架构解耦、自组织团队等等，还包括精益产品管理相关的内容，比如小批量、实验、反馈等。

但是往往我们忽略了最左边的一个部分，这个部分是变革领导力。什么是变革领导力？

我的理解是从一个领导者的层面，如何构造一个良好的氛围，助力 DevOps 的变革。比如说需要在安全空间范围内倡导免责的文化，鼓励改进冒险的行为。其实所有的改进要从领导力的层面建立一个良好的氛围，并渗透到团队当中，当资源具备、氛围建立起来，再和具体的技术、方法、实践引入相匹配，相辅相成、共同作用才能把 DevOps 有效推进下去。

以上就是“法” 的层次，希望能给大家一些启示，但这部分还是偏理论一些，那么下面我们看看具体的技术和实践。

三、术

“术” 的层次的主要思路是系统的应用各类技术、指导原则和最佳实践。这个层次涵盖的内容就非常多了，我们可以通过一张图来展示。

首先把相关技术和最佳实践分为管理维度和工程维度两个部分。

管理维度主要关注管理的范畴，针对软件生命周期不同的阶段有不同的技术和实践。比如目标确定阶段，可以应用精益画布和影响地图的实践；在版本的确定阶段，可以应用用户故事地图和敏捷迭代管理的相关实践；在迭代实施阶段我们可以应用精益看板、每日站会、敏捷度量（燃尽图、累积流图、散点图...）等实践，以上这些技术和实践可以帮助我们管理整个软件研发的过程。

在工程维度也对应了很多的技术和实践，包括配置管理、自动化测试、持续集成、持续交付、灰度发布、持续监控等等。以上这些组成了我们 “术” 的层次，下面我们找一些重点的做下介绍。

3.1 管理维度

以下是用户故事地图，可以用来做产品规划和发布计划。

用户故事地图有助于看到产品的全貌，可以根据用户体验路径，将Product Backlog 从一维列表延展成二维的表格。那么如果横向画一条线出来，那么可以很清晰的生成一个MVP，可以明确产品的发布计划。

在敏捷中 Scrum 模型已经非常普遍，我这里不详细阐述。

这里重点关注敏捷度量，比如用燃起图度量整体进度；用累积流图度量各个阶段累积处理的需求数量，以及它们随时间的变化趋势，可以从中分析出前置时间、交付速率的数据，以及协作模式的改进机会；通过散点图可以关注整个的交付过程中，平均前置时间、收敛趋势，以及通过对离群点的分析，找到改进的机会。在敏捷项目管理过程中，善用数据度量，是持续改进的前提。

3.2 工程维度

下面来看一下工程维度的内容，首先是持续交付框架。

关于持续交付框架，我个人之前也分享过很多了，主要思路是以建设可靠、可重复的持续交付流水线为核心，配合以相关实践和技术的导入，让整个软件交付过程实现高度的自动化和自助化。

除了框架的指导，我们还有很多最佳实践的集合。

上图是持续交付的光谱图，发布频率从100天发布一次到一天发布多次，所采用的分支模型、测试模式、系统架构、发布模式、基础设施和数据库的管理模式，都会有很多的实践需要变化。

我认为作为我们从业者来讲，是非常好的指导和参考，如果希望将交付的频率变得更快，稳定性变得更高，需要把这些实践调整和落地。

下图是基础设施管理方式的演进，从管理服务器到自动化、配置化环境管理，到不可变服务器模式。

我们希望交付流程里面尽量少的注入风险，所以通过封装运行时环境，通过不可变服务器的模式降低风险，这也更符合持续交付中的单一制品原则。

上图描述的是架构解耦，单体的应用的交付过程很难快起来，只有把单体应用解耦为一系列的服务，每个服务能够独立的开发、测试和部署，这样整个系统的演进和交付的效率才能够提升。当然，根据逆康威定律，改变架构可以从改变组织架构开始，然后围绕团队边界进行架构，降低团队之间高带宽的通信。

四、器

“器” 是指工具的层次，工具需要把上面层次提到的方法、实践固化和落地。工具通用需要考虑很多维度，比如说管理维度、工程维度、基础设施维度，而最重要的，是要把这些工具做很好地联通和整合。

今年4月份，在 GOPS 全球运维大会深圳站上，我发布了全开源端到端交付流水线的1.0的版本。

当时的目标是希望从社区的角度，我们做一个解决方案提供给大家，从而帮助大家通过开源工具更好的把 DevOps 实现和落地。那么效果怎样呢？当时我们做了一个演示视频，介绍整个的流水线过程和实现细节。这个视频到现在已经累计播放超过3.5万次，我们觉得还是很欣慰的，希望社区能够帮助大家做一些事情。如果还没有看过的朋友，可以扫图中二维码看观看。

当然，我们也是在不断迭代和自我改进的，我们在 V1.0 版本的基础上进一步完善和优化，现在提出全开源端到端交付流水线 V2.0 版本。

新的版本希望覆盖更多场景，包括APP发布流程，支持多种语言，支持一些友好的商业工具，支持 Mesos & Marathon 的部署，支持虚拟主机自动化配置，支持一键式自动进行工具间的集成等，也希望能够适配更多的场景下的不同需求。

V2.0 版交付流水线的技术架构图

可以看到比上一个版本做了很多更新和完善，适配更复杂的场景。

在需求侧，我们引入 Jira 做敏捷项目管理，依然通过 Gitlab 进行代码托管，采用 Feature 分支的研发模型。使用 Jenkins 和 BlueOcean 做流水线的编排和展示，流水线分为提交阶段、验收阶段、准生产阶段和生产阶段。

在流水线中集成很多工具，包括 Maven 、 JUnit 、Sonar、Selenium、Jmeter、PACT、Appium等，镜像管理使用 Harbor ，但也支持其他镜像仓库。

部署上支持Ansible或SaltStack，容器集群可以兼容 K8S 或 Mesos + Marathon。所以这也是一个解决方案，希望能帮助大家更好地通过工具落地 DevOps 。

今天我们讲的是 DevOps 的道、法、术、器四个层次，希望大家做 DevOps 规划和实施不仅关注工具、实践，更要关注它的业务价值，自上而下的推动，自下而上的解决问题，希望以上这些内容能够帮助到大家。

原创：张乐

DevOps时代联合创始人，高效运维社区合伙人，DevOpsDays大会、GOPS全球运维大会金牌讲师。国内首批DevOps Master，前百度资深敏捷教练、架构师。超过十四年敏捷转型、工程效能提升和大型项目管理实践经验，曾主导数百人团队实施DevOps转型，在保证质量的前提下发布频率提高数倍。在百度任职期间作为持续交付方向负责人，成功主导了多个战略级产品的敏捷转型和DevOps体系建设。