道法术器 — DevOps 端到端部署流水线 V2.0

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

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

嘉宾演讲视频地址：suo.im/4ywEH3

摘要

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

VUCA新常态

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

IT的技术革命

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

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

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

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

更为重要的，软件交付管理的模式也在发生着不少的变化。早在上个世纪6、七十年代，那个时候提出的软件工程方法，是用一种结构性、系统化、重管控的流程和方法去控制整个软件交付的过程，后来到了互联网时代，以敏捷化、迭代式、增量化的交付逐步成为主流，这会让软件交付过程更快、更灵活。到如今咱们讲 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 的规划和实施能够用这四个层次来归纳。

1、道

应用性能、拓扑第三方组件；资源使用；异常堆栈；数据聚合、分析报警；自定义业务。

经常使用监控手段

首先是 “道” 的层次，主要目标是快速交付价值和灵活响应变化。谈到敏捷，谈到 DevOps，可能第一个诉求就是要快速交付价值。在互联网的时代，交付的速度很是关键。原来的瀑布模型须要等到最后一个环节实施完成才向用户交付价值，而敏捷和DevOps 倡导小批量、增量式的交付价值，这就使交付价值的速度、面向市场的频率获得大幅提高。

除此以外，还要关注什么？还要关注端到端的交付价值，这才是真正的交付价值。若是仅仅在开发、测试环节作局部的敏捷优化，而没有考虑到后续的多服务集成场景，以及每次迭代后发布和运维的场景，这样就没有真正作到端到端的价值交付，因此咱们须要作的是打通整个 IT 交付的全链条。
在价值交付这个层次，咱们最终但愿达成一个目标，就是经过 DevOps 打造一条高度自动化的 IT 服务供应链，可以快速、高质量地交付用户的价值。 DevOps 创始导师 Patrick 先生来华时给了咱们一些启示，如何作到开发和运维的有效融合。

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

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

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

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

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

2、法

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

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

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

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

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

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

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

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

以上就是“法” 的层次，但愿能给你们一些启示，但这部分仍是偏理论一些，那么下面咱们看看具体的技术和实践。

3、术

“术” 的层次的主要思路是系统的应用各种技术、指导原则和最佳实践。这个层次涵盖的内容就很是多了，咱们能够经过一张图来展现。

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

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

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

3.1管理维度

在敏捷中 Scrum 模型已经很是广泛，我这里不详细阐述。

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

3.2工程维度

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

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

除了框架的指导，咱们还有不少最佳实践的集合。

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

我认为做为咱们从业者来说，是很是好的指导和参考，若是但愿将交付的频率变得更快，稳定性变得更高，须要把这些实践调整和落地。

4、器

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

今年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 规划和实施不只关注工具、实践，更要关注它的业务价值，自上而下的推进，自下而上的解决问题。

今天的分享就到这里，谢谢你们！