DevOps的演变历程，有价值的模型！

任何事物的诞生、发展和消亡都是由所处社会阶段决定的，软件开发方法也是一样。现在我们津津乐道的 DevOps，也有其自己的起源和诞生的前提条件，今天我带领你追本溯源，一起找一找 DevOps 兴起的历史根源。

当谈到 DevOps，就不得不提的两个词是：精益和敏捷。精益软件开发和敏捷软件开发是 DevOps 发展的两大基础。DevOps 不仅对这两大基础进行了扩展，还引入了很多重要而有用的原则。

因此，在一些人眼中，DevOps 是敏捷的一部分，其实这样的理解是错误的。DevOps 并不从属于敏捷，事实上它更像是在精益和敏捷经验基础上发展出的新生儿，是在前人经验上发展，与时俱进的产物。

精益软件开发

精益开发，源自精益生产。精益生产是一组原则指导，主要应用在质量、速度和客户关系。

2003年，由Mary 和 Tom Poppendieck编写的 《精益软件开发：软件开发管理者的敏捷工具箱》一书问世，该书次把精益思想映射到软件开发中。在2006年，作者在第二本书 《实施精益软件开发：从概念到价值实践》 中进一步完善了这种映射，并定义了 7 项原则：消除浪费、内建质量、创建知识、推迟决策、快速交付、对人尊重、整体优化。

消除浪费是精益思想的精髓所在。在精益生产领域，一共定义了 7 种浪费，分别对比软件开发中节点。

• 库存——未完成的工作。未完成的工作是指一切已经开始但还未完成的东西。可能是还未编码实现的需求，还未进行测试、部署的代码，未完成的工作不能给终客户带来价值，但资源已经被消耗了。

• 过度处理——不必要的流程。不必要的流程是纯粹的浪费，没有增加任何价值。不必要的流程包括没有达成任何产出的过程，编写没有人读的文档，没有效果的汇报，可以自动化但却还是以手工处理的任务等

• 过度生产——额外的特性。额外的特性是指用户没有明确的需求。每一行代码都是有成本的，因此，用户不需要的功能就不要创建它

• 运输——传递。传递是指中间交付物从一个阶段传递到下一个阶段。比如用户故事从业务人员传递到开发人员，系统设计从架构师传递到开发人员等。每次传递都会有知识丢失，因此要尽可能避免传递。

• 等待——延迟。延迟是指在任何环节中的等待，等待就会影响开发进度。与等待相关的延迟有：等待决策、等待资源分配或释放等。

• 移动——任务切换。任务切换是指在不同事情之间来回进行切换。每次切换都需要重新回忆之前任务的上下文，浪费大量时间。相信这个大家都深有体会。

• 缺陷——缺陷。缺陷在制造业和软件产品中都存在的。缺陷会导致返工，返工是没有增加任何价值的，是严重的浪费。

敏捷软件开发

20 世纪中，软件开发方法中被广泛采用的是瀑布模型，将软件开发过程分解为一系列依次完成的单独阶段，包括需求、设计、实现、测试、部署和运维。整个开发过程就像瀑布一样，依次向下经过这些阶段。每个阶段都有一个开始点和结束点，上一个阶段结束后，便进入到下一个阶段，一旦进入到下一个阶段，就不能再回到上一个阶段。

这种模型的一个前提是需求不再发生变化，每个阶段通过文档进行流转，这也就导致了采用瀑布模型开发的软件项目存在大量的问题，比如进度超期、预算超支、不符合用户需求、需求中途被取消等。

这些问题比较的程序员应该都遇到过。这是因为软件开发本身是一个高度动态的过程，软件开发过程中的变化是不可避免的。比如：

在需求阶段，由于用户也不知道他们想要什么，而这必然会带来需求的改变；

在编码阶段，可能会发现设计有问题需要重新设计；

在测试阶段，可能会发现代码逻辑有问题需要重新修改；

而这必然导致要返回到上一个阶段或上上一个阶段进行返工修复，这些在瀑布模型下是不允许的或者成本是非常高的。

瀑布模型的软件开发导致了项目失败率高、软件质量低下和客户满意度低。

20 世纪 90 年代，人们对瀑布模式的软件开发方法越来越不满意。这种情况下，诞生了其他一些软件开发方法，包括极限编程（XP）、Scrum 方法、动态系统开发方法（DSDM）、水晶方法（Crystal）， 以及特征驱动开发（Feature Driven Development，FDD） 等。这些方法有很多相同之处，都是希望能够解决软件开发中遇到的问题。

DevOps兴起

享受到了敏捷方法带来的好处，极大地提高了软件的交付速度。但是在有些企业里，在采用敏捷软件开发方法后的实际效果并没有达到预期。

这并不是说敏捷方法不好，问题的关键在于敏捷所涉及的代码开发阶段只是软件端到端价值交付链中的一环。

在实际开发过程中，开发之前还有需求收集、分析、拆解、设计等环节，在开发之后还有编译、构建，及将制品部署到测试环境、生产环境等环节。只有部署到生产环境交付给用户使用，用户将使用效果反馈给开发人员，这才算是一个软件开发周期的完成。

快速部署到生产环境这个环节在很多企业里也是很难实现的。因为，在大多数企业中服务器等硬件基础设施还相对薄弱，多是陈旧的老机器，新采购的预算申请较难且周期长。

这种情况，我是深有体会，在我之前的经历的一家国企里，一个项目预算流程走了长达半年时间。在这种情况下，为了准备一套测试环境短则数周，长则数月。这些问题严重阻碍了软件向测试环境和生产环境部署的效率。同时，为了保证生产环境的稳定性，运维部门的原则是能不变更就不变更。所有的这些问题，都使敏捷开发的收益难以有效体现出来。

随着虚拟机和云计算技术的快速发展，提供 IT 基础设施的方式方法被彻底改变了。资源被池化，可以根据自己的需求动态分配物理资源，用完即可回收。基于基础设施即代码（Infrastructure as Code，IaC） 的管理方式，我们只需要编写程序代码，就可以创建基础设施。同时，基础设施也能像代码一样进行管理，进行版本控制、变更追溯、回滚等操作。如今，Docker、K8s 等容器技术的兴起，更进一步提高了实施基础设施的效率。

终，敏捷软件开发方法的广泛普及，以及IT 基础设施即代码（IaC）的管理方式的出现，推动了IT管理方式的变革，这项运动被冠以"DevOps"之名。

DevOps是一场运动，是推动企业内部IT管理方式变革的运动。

DevOps是一个实践，包含了业界广泛采用的、卓有成效的软件开发方法。

DevOps是一个思想，是对精益和敏捷思想的演进，并应用到IT端到端的价值链中。

DevOps 缺少一个清晰的定义，每个人对 DevOps 的理解也都不一样。正如下面这张盲人摸象图，很形象地说明了当前大多数人对 DevOps 理解的现状。

总之，DevOps 是抽象的，不是具体的；是全局的，不是局部的；DevOps 告诉我们要做什么（What），但没告诉我们要如何做（How）。因为对于一个企业，IT 管理方式的变革跟企业内部的文化、流程、技术关系密切。当企业在应用DevOps的时候，要结合企业现状，有针对性的，制定适合企业内部的应用方案，切勿盲目追求，为了做而做。

DevOps的兴起并席卷全球，是因为 DevOps 的确为我们带来了好处，解决了企业面临的现实问题。“缩短市场响应时间”“减少技术债务”和“消除脆弱性”是 DevOp 着手处理的主要任务。这三个任务中任何一个的改进，都能为企业的业务带来明显的优势。

相关文章