【管理】DevOps的思考

DevOps是最近非常火的一个概念，谈IT流程建设不说点DevOps都不好意思和人打招呼。但是DevOps究竟是个什么东西，这个东西能不能用？怎么用？什么样的情况才叫做DevOps落地成功？对于这些问题的答案，虽然网上有铺天盖地的文章和教程，但是一般来说都是从理论或者方法论上去阐述，也有大厂的实施经历。个人就感觉这里的它山之石，很难攻玉了。最终还是得思考下DevOps的由来，综合自己所在企业的现实状况去考虑。

在这篇文章中，本人无意对DevOps从理论或者方法论上做说明和讲解，只是想综合自己工作过程中的一些现实情况，在解决和优化一些现实情况的过程中，接触到了DevOps这样一个概念，想试着在DevOps这条路上找到一些解决问题的可行性和落地方式。本文是基于这个目的来做的一些总结，提到的概念和方法不一定和网上其他的教程/文章描述的一样，我只是想提出我的理解，希望各位看客轻拍，可以留言或者私信交流。

一. DevOps作为一种软件开发手段和方法

先引用下百度百科上对DevOps的描述：“DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。”我对这句话的理解，就是利用各种技术和管理手段来使整个软件工程更加的高效。为了更好的理解这样一个概念。就有必要去了解下在DevOps出现之前，有哪些软件工程流程，为什么在当前的情况下，需要有DevOps的出现，才能更好的理解这些技术或者管理手段的目的和意义。

软件行业的江湖中一直流传着这样类型的传说，某位大神闭关若干月，凭借自己无上的神功，在车库/地下室等各种不同简陋的地点开发出牛逼的一塌糊涂的产品。行内的各位肯定对这样的传说并不陌生。但是我个人认为其中有夸大的成分，不可否认，某位大神可以凭借自己无上神功搭出产品的核心框架，但是最终成熟的商业产品肯定是需要一个稳定的团队，依靠可靠的流程手段来维持和推进，缺乏有效管理的产品会变成一个焦油坑(人月神话)。

那么，这样一个可靠的流程手段就是我们通常讲到的软件工程：

a. 最初的阶段，我们的软件产品只有有限的需求，业务对软件的依赖也不是那么的大，因此有相对较长的交付周期。对于这样的一个应用场景，就有了最初的瀑布模型：

瀑布模型为了保证整个软件可控，从而保证软件产品质量，对每个阶段进行管控，只有前一个阶段的输出稳定和质量过关后，才能进入下一个阶段。

这种模型在需求量相对简单和少的情况下，可以做到可控。但是随着社会的发展，各行各业对软件的依赖越来越大，各种复杂的业务都需要有软件的介入，复杂的业务场景，更短的开发周期，更频繁的业务场景变更，导致瀑布模型的开发模式无法保证有效和高质量的产品开发。因此我们需要有更好更适合的开发模型。

b. 最简单的，我们采用分而治之的方法，将整个软件需求拆分成若干个子集，将整个过程拆分成若干个迭代，每个迭代挑选出若干子集采用瀑布模型的方式进行开发。称之为迭代模型。

这样，可以保证在每个迭代开发周期中，形成一个可交付的产品子集，逐步增量的进行交付。

理论上讲，通过控制迭代的需求范围，迭代开发可以适用大多数软件开发场景了。但是随着互联网和移动业务的崛起，对于软件的更新/构建速度提出了前所未有的要求。在迭代开发中，每