DevOps 的定义

DevOps 这个词，是 Development 和 Operations 两个词的组合。

DevOps 的维基百科定义是这样的：DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
devops-define.jpg
从定义看来，这个定位有些抽象，但也可以理解它不是一个特定的软件、工具或平台的名字。

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

看完定义之后的第一反应就是，一头雾水，似懂非懂…

DevOps 是如何出现的？

2009年，Patrick Debois（DevOps之父）在提出 Dev 和 Ops 概念时的主要目的是如何在运维工作中应用 Scrum 和其它敏捷实践，为的是促成开发运维合作（打破开发和运维之间的部门墙）。

我们来看一个图，更好的理解一下 Dev 和 Ops 部门墙产生的原因。
image.png
传统的 Dev 和 Ops 的关注点不同，Dev 的关注点是如何开发测试交付新的功能，Ops 的关注点是保证站点的稳定和高性能。

梳理一下，软件开发流程的发展过程，回顾其中碰到的困难与相应的解决方案，有助于理解 DevOps 其产生的合理性。

传统软件的瀑布式开发流程

传统的软件开发流程是这样的：
image.png
软件开发人员 花费数周和数月编写代码，然后将代码交给 QA（质量保障）团队 进行测试，然后将最终的发布版交给 运维团队 去布署。所有的这三个阶段，即 开发 ， 测试 ， 布署 。

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

瀑布模型，简而言之，就是等一个阶段所有工作完成之后，再进入下一个阶段。

这种模型适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，轮流执行自己的职责即可。这样一个新产品从提出需求到上线需要经历很长时间，可能赶不上市场的变化。

而且实际场景中，项目不可能是单向运作的。客户也是有需求变化的。产品也是会有问题的，需要改进的。

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

于是研发人员探索一种新的开发方式——“敏捷开发（Agile Development）”。将大项目拆解成小项目，把大时间点变成小时间点，快速开发与测试，降低风险，提高效率。

敏捷式开发流程

敏捷开发在2000年左右开始被世人所关注，是一种能应对快速变化需求的软件开发能力。

其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点。

直观的比较：传统瀑布式开发 VS 敏捷式开发
image.png
敏捷开发大幅提高了开发团队的工作效率，让版本的更新速度变得更快。

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

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

原因很简单：搞运维的总是希望系统稳定、稳定、再稳定， 稳定压倒一切。所以他们从骨子里不想频繁地上线，那不是给自己找麻烦吗？

这恰恰和敏捷软件开发相反，敏捷就是要拥抱变化！

为了解决开发团队与运维团队之间的矛盾，DevOps 这个概念就被提出来了。

DevOps

敏捷的目的是为了打破产品和开发团队之间的部门墙，但是市场变化越来越快，需要更快的交付和反馈，所以只打破产品和开发部门部门墙还不够，现在需要将开发和运维运营也打通。

那么，所谓的 DevOps，是否就是 Dev + Ops，把两个团队合并，或者将运维划归开发这样的简单呢？
这个观点是不对的。这也是 DevOps 在实际中难以落地的主要原因。

思维转变

想要砸破开发与运维之间的“部门墙”，如果不能改变他们的观念（快速与稳定之间的观念矛盾），即使将员工放在一起，也不会产生火花，起不到产品交付效率和质量保障提升的效果。

想要将 DevOps 真正落地，首先第一点，是思维转变，也就是“洗脑”。不仅是运维的要洗，开发的也要洗。员工要洗，领导更要洗。

举例
开发团队向运维部门交付了一批新代码，这是一次重要的升级，部署进行得非常顺利，大家都很高兴。

可是一天后生产环境的 CPU 持续接近100%，有好几台服务器都 down 机了， 运维责问开发：“你们开发团队怎么搞的？ 新代码一上线 CPU 就100%！” 。

开发回怼：“我们在测试环境测试得非常充分，用户压力比生产环境大多了，代码坚如磐石，肯定是你们配置错了什么东西！”

“不可能，我们是严格按照你们要求的步骤来部署的，肯定是你们代码的问题！”

“那测试环境怎么就没有问题？”

运维和开发之间来回怼…

DevOps 希望的是：

  • 开发的工作目标不仅仅是高效完成用户需求的开发，更需要协助运维部署和优化；
  • 运维的工作目标不仅仅是让部署的系统稳定和高效，更需要了解业务，支持业务的快速演化；
  • 一个项目的开发、部署、维护，是开发和运维双方的事情，双方都要对业务负责，出了问题要通力合作，共同解决。

DevOps 并不仅仅是组织架构变革，更是企业文化和思想观念的变革。

流程转变

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

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

DevOps 的实施，促进开发和运维人员的沟通，增进彼此的理解。

在思维和流程改变的同时，想要充分落地DevOps，当然离不开软件和平台的支持。
image.png
上述这些关键要素里面，技术（工具和平台）是最容易实现的，流程次之，思维转变反而最困难。

换言之，DevOps考验的不仅是一家企业的技术，更是管理水平和企业文化。

对比其他开发流程

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期，而不仅限于开发阶段。
image.png
下面这张图，更明显地说明了DevOps所处的位置，还有它的价值：
image.png

小结

  • DevOps（Development 和 Operations 的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

  • 它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

  • DevOps不能简单认为是工具、方法、技能或组织结构，DevOps的框架结合所有这一切元素，去建立一个流水线的过程，使业务更快的运营并且更快地应对变化。

  • 衡量 DevOps 做得到底怎么样， 最重要的是我们无论用了什么工具、方法，如果最后没有减少需求从提出到上线，交付给用户使用的时间，那都是失败。

参考：https://mp.weixin.qq.com/s/UEcESUMunURa1p-iBrJ4cA 参考：https://www.yuque.com/xiongsanxiansheng/xu3l80/ny150b