1、DevOps的起源

上个世纪40年代，世界上第一台计算机诞生。计算机离不开程序（Program）驱动，而负责编写程序的人，被称为程序员（Programmer）。程序员在那时属于稀缺人才

随着科技的不断发展，PC和Internet陆续问世，我们进入了全民拥抱信息化的时代。越来越多的企业开始将计算机作为办公工具，以提高生产力。而个人用户也开始将计算机作为娱乐工具，用以改善生活品质

于是，计算机程序，开始变成了一门生意。程序逐步演进为软件（Software），变成产品

在软件行业里，程序员有了更专业的称谓，叫做软件开发工程师（Software Development Engineer），也就是我们常说的“码农”

我们知道，一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护

最初，程序比较简单，工作量不大，程序员一个人可以完成所有阶段的工作。随着软件产业的日益发展壮大，软件的规模也在逐渐变得庞大。软件的复杂度不断攀升。一个人已经Hold不住了，就开始出现了精细化分工

码农的队伍开始扩大，工种增加。除了软件开发工程师之外，又有了软件测试工程师，软件运维工程师

分工之后，传统的软件开发流程是这样的：

软件开发人员花费数周或数月编写代码，然后将代码交给QA（质量保障）团队进行测试，然后再将最终的发布版交给运维团队去布署。即三个阶段：开发、测试、布署

早期所采用的软件交付模型，称之为“瀑布（Waterfall）模型”

瀑布模型，简而言之，就是等一个阶段所有工作完成之后，再进入下一个阶段。这种模型适合条件比较理想化（用户需求明确、开发时间充足）的项目。大家按部就班，轮流执行自己的职责即可

但是，项目不可能是单向运作的。客户也是有需求变动的。产品也是会有问题的、需要改进的

随着时间推移，用户对系统的需求不断增加，与此同时，用户给的时间周期却越来越少。在这种情况下，大家发现，笨重迟缓的瀑布式开发已经不合时宜了

于是，软件开发团队引入了一个新的概念，那就是大名鼎鼎的“敏捷开发（Agile Development）”

敏捷开发是一种能应对快速变化需求的软件开发能力。简单来说，就是把大项目变成小项目，把大时间点变成小时间点

有两个词经常会伴随着敏捷开发出现，那就是CI和CD。CI是Continuous Integration（持续集成），而CD对应多个英文：Continuous Delivery（持续交付）或Continuous Deployment（持续部署）

CI/CD介绍见文章：传送门

美其名曰：“持续（Continuous）”，其实就是“加速——反复——加速——反复……”

敏捷开发大幅提高了开发团队的工作效率，让版本的更新速度变得更快

很多人可能会觉得：更新版本的速度快了，风险不是更大了吗？其实，事实并非如此

敏捷开发可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的版本变化是比较小的，风险会更小。即使出现问题，修复起来也会相对容易一些

虽然敏捷开发大幅提升了软件开发的效率和版本迭代速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈

运维工程师，和开发工程师有着完全不同的思维逻辑。运维团队的座右铭，很简单，就是“稳定压倒一切”。运维的核心诉求，就是不出问题

什么情况下最容易出问题？发生改变的时候最容易出问题。所以说，运维非常排斥“改变”。于是乎，矛盾就在两者之间集中爆发了

这个时候，DevOps就隆重登场了

2、什么是DevOps

DevOps，其实就是Development和Operations两个词的组合。维基百科词条定义是这样的：DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合

这个定义稍微有点抽象，但是并不难理解。反正它不是一个特定软件、工具或平台的名字

从目标来看，DevOps就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠

很多人可能觉得，所谓DevOps，不就是Dev+Ops嘛，把两个团队合并，将运维划归开发，不就完事了嘛？

注意，这个观点是不对的。这也是DevOps这些年一直难以落地的主要原因

想要将DevOps真正落地，首先第一点，是思维转变，也就是“洗脑”。DevOps并不仅仅是组织架构变革，更是企业文化和思想观念的变革。如果不能改变观念，即使将员工放在一起，也不会产生火花

除了“洗脑”之外，就是根据DevOps思想重新梳理全流程的规范和标准

在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议

DevOps的实施，促进了开发和运维人员的沟通，增进了彼此的理（感）解（情）

在思维和流程改变的同时，想要充分落地DevOps，当然离不开软件和平台的支持

技术（工具和平台）是最容易实现的，流程次之，思维转变反而是最困难的。换言之，DevOps考验的不仅是一家企业的技术，更是管理水平和企业文化

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期，而不仅限于开发阶段

下面这张图，更明显地说明了DevOps所处的位置，还有它的价值：

3、DevOps的发展现状

DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，为了在Twitter上更方便的传播，由DevOpsDays缩写为DevOps

目前，DevOps处于高速增长的阶段。尤其是在大企业中，DevOps受到了广泛的欢迎。如今，DevOps几乎已经成为了软件工程的代名词

4、DevOps与虚拟化、容器

近几年，云计算技术突飞猛进，大家应该对虚拟化、容器、微服务这些概念并不陌生。当我们提到这些概念的时候，也会偶尔提及DevOps

它们之间有什么关系呢？

其实很简单。设想一下，如果要对一项工作进行精细化分工，我们是对一个大铁块进行加工方便？还是拆成小块进行加工更加方便？结果是显而易见的

所谓“微服务”，就是将原来黑盒化的一个整体产品进行拆分（解耦），从一个提供多种服务的整体，拆成各自提供不同服务的多个个体

微服务架构下，不同的工程师可以对各自负责的模块进行全流程处理，例如开发、测试、部署、迭代

而虚拟化，其实就是一种敏捷的云计算服务。它从硬件上，将一个系统“划分”为多个系统，系统之间相互隔离，为微服务提供便利

容器就更彻底了，不是划分为不同的操作系统，而是在操作系统上划分为不同的“运行环境”（Container），占用资源更少，部署速度更快

虚拟化和容器为DevOps提供了很好的前提条件。开发环境和部署环境都可以更好地隔离，减小了相互之间的影响

参考文章：https://zhuanlan.zhihu.com/p/91371659