内容来源：2017年8月18日，DevOps时代联合发起人张乐在“DevOpsDays 【主会场】”进行《DevOps 道法术器及全开源端到端部署流水线 2.0发布》演讲分享。IT 大咖说（WeChat_ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：4497 | 4分钟阅读

观看嘉宾演讲视频回放及PPT，请点击：http://t.cn/EwBQxt9

嘉宾简介

摘要

DevOps独立顾问、DevOps时代联合创始人张乐为我们带来DevOps 道法术器及端到端部署流水线V2.0的分享。

VUCA新常态

在移动互联网时代和即将到来的人工智能时代，我们所处的商业格局和企业生态充满了易变性、不确定性、复杂性和模糊性，企业的创新能力依赖于能够频繁地从真实用户那里得到对商业假设的有效验证，胜出者的特点是拥有快速交付价值、灵活应对变化的能力。

IT的技术革命

IT行业一直都在不断地自我迭代、持续演进，我们正在经历一场IT的技术革命。

从应用架构的角度，多年前开发软件，可能就是一个单体式的应用，所有的东西全部在运行一个进程里面。后来我们有了分层架构，把展示层、逻辑层、数据层做了很好的分离。近两年我们在提微服务的架构，希望每个服务能够单一职责，服务之间能够很好的解耦，每个服务都能够独立地设计开发、测试和上线。

部署和打包的模式也发生了很大的变化。从基于物理机部署到基于虚拟机，再到现在很多应用运行在容器里。我们交付过程的产出已经不再满足于交付一个可工作的软件，而是希望每次交付都是一个可正常运行的系统，这是一个本质上的变化。

从应用的基础设施来讲，我们原来关注的是数据中心，到后来我们更多关注的是主机托管，现在我们更关注如何在云上把应用正常、高效、稳定的运行起来。

更为重要的，软件交付管理的模式也在发生着很多的变化。早在上个世纪六、七十年代，那个时候提出的软件工程方法，是用一种结构性、系统化、重管控的流程和方法去控制整个软件交付的过程，后来到了互联网时代，以敏捷化、迭代式、增量化的交付逐步成为主流，这会让软件交付过程更快、更灵活。到现在我们讲 DevOps，是希望通过研发和运维/运营的融合，在保证质量的前提下进一步提升交付效率。

所有以上这些维度构成了一场IT的技术革命。

DevOps已成为发展趋势

从Gartner的IT成熟度曲线图可以看出，DevOps已经跨越了概念认知的顶点，逐步向深化应用去发展。也就是说它在概念上得到了认同，需要考虑的问题就是如何更高效地落地实施。

在今年发布的《2017年DevOps现状调查报告》中显示，根据几年的调查数据统计趋势发现，DevOps团队比例已经从2014年的16%提升到2015年的19%，2016年提升到22%，今年已经达到了27%，也就是说已经成为事实上的技术趋势。

DevOps强调为业务目标服务

DevOps不是技术噱头和工程师的工具箱，更需要面向业务目标，助力业务成功。DevOps需要有效应对VUCA 挑战，高效、高质量交付价值，快速、灵活响应变化。

谈到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管理维度

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

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

3.2工程维度

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

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

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

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

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

四、器

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

今年4月份，我发布了全开源端到端交付流水线的1.0的版本。当时的目标是希望从社区的角度，我们做一个解决方案提供给大家，从而帮助大家通过开源工具更好的把 DevOps 实现和落地。那么效果怎样呢？当时我们做了一个演示视频，介绍整个的流水线过程和实现细节。这个视频到现在已经累计播放超过4.5万次，我们觉得还是很欣慰的，希望社区能够帮助大家做一些事情。

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

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

可以看到比上一个版本做了很多更新和完善，适配更复杂的场景。在需求侧，我们引入 Jira 做敏捷项目管理，依然通过Gitlab进行代码托管，采用 Feature 分支的研发模型。使用 Jenkins 和 BlueOcean 做流水线的编排和展示，流水线分为提交阶段、验收阶段、准生产阶段和生产阶段。

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

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

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

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