IT管理方法不是一成不变的。如今，信息系统开发和运维所使用的方法明显区别于几十年前的。这些方法一直在演进，明天可能又会出现下一代基于新的知识、经验和技术的方法。大多数时候，管理方法会基于某些基本的原理和假定，打磨之前已有的模型并使之体系化，逐渐地演进。但是，时不时也会出现一些非连续的情况，个别领先组织在信息技术的有效与高效应用上，已经大步向前迈出了重要的步伐。
IT管理从聚焦于IT系统，转变为聚焦于IT服务的管理，就是一个很好的例子。如图1.1所示，从2000年左右开始，对于管理的认识变化，使得领先者赢得了重要的竞争优势。这些涌现出来的管理实践，被先行者成功采纳之后，成为了所谓的最佳实践.有些最佳实践进一步演进为被业界广泛接受的做法，甚至对行业标准产生了影响。当然，也有些组织并没有在工作中应用这些最佳实践或标准，因为在那个时候，并非所有的经济领域都显著依赖于IT。
图1.1 新实践的涌现与使用
我们以IT服务管理为例来看一看。在20世纪80年代，这样的想法开始出现：信息技术以服务的形式提供价值，并以流程的形式组织IT活动。有些欧洲公司成为先行者，他们发展出组织工作的新实践及解决管理问题的新方法。其中有些实践，例如服务台的引入、事件和问题的区分、IT基础设施变更的受控过程等，在2000～2001年的ITIL等重要出版物（那时ITIL代表IT基础设施库） 中清晰地阐述出来，使得这些实践得以进入最佳实践之列，开始引入它们的不光是领先者组织，也包括追随者。最终，在2002年，BS 15000-1:2002 即IT服务管理的首个标准发布，这为那些寻求构建一个连贯的IT服务管理系统的组织而言，建立了一个可以遵循的具体标准。也就是说，实践、出版物和标准，都未曾停止过发展的脚步，如图1.2所示。
图1.2 实践的发展
从敏捷软件开发中，也可以观察到类似的发展动态。然而，这次酝酿的革命所影响的范围，已经超出了软件开发本身，带来的影响面不亚于当年的ITSM。
如今，新涌现出来的实践，被打上DevOps（开发+运维）的标签。实际上，DevOps的内涵，如同ITIL超出“库”的概念以及COBIT超出受控对象的含义一样，已经大大超出其原始的含义。
这么说来，DevOps的现象值得研究。要想理解DevOps的完整要义，需要结合相关的背景来了解其思想连同与之关联的运动。
1.1 起源
一般认为，DevOps的出现源于两个因素：敏捷软件方法的广泛采用以及IT基础设施即程序代码的管理方式。我们分别来看一看。
1.1.1 敏捷软件开发方法
在20世纪末期，主流的软件开发方法是图1.3所示的所谓“瀑布模型”：顺序式执行预定义的阶段，每个阶段花很长时间，并以达成先前协商好的结果作为结束；很多时候，只有在前一个阶段已经完整且正式完工时，才能转移到下一个阶段。这个模型的另一个显著特征是，每个阶段所涉及的人员职能有专业化的分工：分析师、架构师、开发人员和测试人员等。
当开发的是功能可预先定义、对快速产品交付没有或很少有要求的大型信息系统时，这个模型能够确保我们创建高质量产品并进行有效与精细的成本控制。
然而，在20世纪90年代末期，随着互联网技术与Web编程的快速发展，瀑布模型的消极作用开始显现，影响到信息系统客户（内部或外部业务）与提供者（内部或外部软件开发者）之间的交互和理解。事实上，对业务客户的市场机会不断涌现，这要求团队能够快速发布（最多在几个月之内）新产品到市场上。然而，从项目启动到第一个可运行原型的典型开发闭环，可能要花6到18个月时间；而在大型企业中，甚至需要2到3年。此外，随着很多在之前并不为人知晓但有潜在前景的市场机会涌现，客户的需求在开发过程中很可能会发生变化，这样一来，要有效应对市场机会而不延误截止日期，且同时还不降低产品质量，就变得极为困难，如图1.4所示。
