作者 | 顾宇
编辑 | 木环软件开发上古时代 自开发自运维
历史要追溯到刚刚出现电子计算机的时期。那时第二次世界大战刚刚结束。计算机还只是大学，政府部门和科研单位的“秘密武器”。这时候计算机的使用和维护需要专人管理。软件开发还是少数人通过高学历才能够掌握的技能。软件开发的学习材料只有计算机设备厂商附送的使用手册。那时候并没有软件供应商，软件基本上都是随计算机附带的，具备基础的编程和计算功能。这时候的软件开发是为了解决特定领域的大规模计算问题。
早期的软件开发
在这个时期是没有 Dev 和 Ops 之分的，由于开发和运维都由同样的人包揽，维护自己开发的程序，也可以被看做是原始的 DevOps。这个时期的计算机系统和问题较简单，开发和维护并不复杂，无需进行专业区分。
桌面通用软件时代 软件成为了一门生意，出现了专业的软件开发工程师（Dev）随着计算机的成本不断下降，尤其是以IBM PC为代表微型计算机（ MicroComputer ）的广泛应用，使得人们开始采用计算机处理更加复杂的问题。从而对软件需求量越来越大。这时候就已经开始有以编写程序为生的计算机用户了。最早的时候，他们通过磁盘拷贝进行软件分发，某些介绍计算机用户的杂志成为了最初的软件市场。程序员通过磁盘向杂志社投稿，杂志社通过变卖杂志和软件获利。由于软件的边际生产成本几乎是0，因此软件开发慢慢变成一门很赚钱的生意。微软（Microsoft）就是这个时期的软件公司的杰出代表。
微软是软件开发专业化的最成功代表
随着计算机和软件的不断发展，当初为个人目的（Personal Purpose）所编写的软件渐渐的开始走通用化的产品路线，慢慢形成了独立售卖的软件产品。也产生了专业从事软件开发的公司，并逐渐成为一个产业。同时因为软件开发的专业性，出现了软件开发工程师（Software Developer，简称Dev）这个职业。
在这个时期，开发软件仍然是很昂贵的事情，企业要想开发软件几乎是不可能的事情。因此，大部分单位，组织和企业仍然通过购买的形式获得软件。随着微型计算机在企业各个方面的广泛应用，企业的计算机部门逐渐成为了负责软件采购以及软件基本操作的培训部门和计算机维护部门。
由于计算机在各行各业应用的加速发展，各种软件层出不穷，加之软件企业越来越多，企业的计算机部门不得不通过更广泛的学习了解技术的变化。
这个时候，Dev和Ops的矛盾，主要是快速增加的软件需求和慢速的软件供给不匹配的矛盾。所以，很多企业采用桌面通用软件解决各种专业的问题。例如Office系列软件产品在各种类型场景的广泛应用。
企业级定制化软件时代 企业级应用的快速发展，出现了专业的系统维护工程师（Ops）供需不匹配随之带来的问题是：无论企业买来多少软件，企业的信息化需要仍然无法被满足。一台台电脑成为了企业的信息孤岛，信息化仅仅解决了信息的归类和存储问题。信息没有在部门间有效的流动起来发挥更大的价值。
计算机网络的出现和应用消除了企业内部的信息孤岛。把不同软件中的信息统一的管理起来成为了新兴的课题。大型企业最先发现这些问题并且给出了最初的解决方案，使得企业级软件开发和系统集成（System Integration）慢慢成为了一个热门的领域。
但是这个领域面临的问题更加复杂，企业形态各异，应用软件五花八门，信息化程度差异性很大。此外，由于服务的用户规模更大，数据存储和运算规模也相应增长。
一方面，系统的集成要求有统一的软件基础设施。由于桌面应用开发的成本太高，差异性太大。直接导致了基于HTML这样的Web应用程序的发展，对应形成了管理Web应用的专业转件，WebLogic和WebSphare就是其中的佼佼者。软件的异构性促进了例如Tuxedo这样的中间件（MiddleWare）的发展。同时使Java这样的跨平台编程的发展。此外，数据的大规模存储导致了专用的数据库软件的发展，Oracle的数据库产品就是这方面的佼佼者。
运维需要管理很多的设备和应用
随着软硬件技术的发展，特别企业级应用开发的经验不断积累，设备的采购成本和软件的开发成本进一步降低。大型IT厂商，尤其是IBM，Cisco，Oracle和EMC开始瞄准企业级应用市场，推出了相应的企业级软硬件产品。使得企业级软件定制开发的成本不断下降。加之随着开发人员越来越多，开发成本逐渐降低，于是出现了企业定制化软件开发，出现了MIS和ERP这样的应用以及J2EE这样的企业级软件开发框架。
在这个过程中，IT运维的概念逐渐产生，维基百科上是这样定义IT运维（IT Operations）的：
IT Operations is responsible for the smooth functioning of the infrastructure and operational environments that support application deployment to internal and external customers, including the network infrastructure; server and device management; computer operations; IT infrastructure library (ITIL) management; and help desk services for an organization.
翻译成中文就是：
IT运维的责任是要为内部和外部客户的应用部署提供平滑的基础设施和操作环境，包括网络基础设施，服务器和设备管理，计算机操作，ITIL管理，甚至作为组织的IT帮助中心。由上可见，对于企业的IT部门来说，工作就不仅仅是维护计算机和网络这些设备了。还要包括运行在上面的软件系统，尤其是定制化的企业级软件产品。因此在软件交付的时候，甲方的时候就需要一系列的技术审查以确保乙方开发软件的质量，这就使得原本不需要关心软件是如何开发的企业IT部门提出了更高的要求。他们必须提升专业水准以应对这样的变化。同时需要重新思考整个IT部门的服务管理和设计。
随着IT部门知识和服务专业度的提升，促生出了了ITIL（Information Technology Infrastructure Library，信息技术基础设施库）这样的最佳实践库，也使系统维护（Ops）更加专业化，于是有了系统维护工程师这个职业。随着数据库和网络的使用，数据库管理员，网络管理员也进入了运维部门共同对组织的IT资产负责。
在这个时期，Dev和Ops的矛盾，主要是由Dev所代表的乙方和Ops所代表的甲方在定制化软件产品交付质量上的矛盾。
互联网软件时代 敏捷颠覆传统软件方法论随着企业级软件开发日趋完善和成熟，形成了以RUP（Rational Unified Process，Rational 统一软件开发过程）为代表的方法论。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。
后来，互联网企业的异军突起着实闪瞎了世界的眼睛。没有人想到原本用来进行国防和科研的广域网居然可以带来这么大的商业价值。人们发现，独立于企业的信息孤岛之外。还有整个社会的信息孤岛。因此，最初成功的互联网企业都是靠信息分类和信息检索起家的。例如：Yahoo，Google……
这些互联网公司的成功不断的颠覆了很多人习以为常的事情，特别是IT产业：
首先，相较于最多万人的用户访问规模，来自互联网的百万级甚至是亿级的访问规模是企业级应用不曾遇到过的。这对软件开发，计算设备管理，存储设备管理以及网络架构都带来了很大的挑战。
其次，企业级应用和互联网应用面对的问题是不一样的。根据“康威定理”：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。相较于有着清晰的等级和部门分工的组织来说，互联网产品的沟通结构更加复杂。
尤为重要的是敏捷软件开发，这一在企业级软件开发播下的种子，终于在互联网软件时代开花结果。
由于互联网软件的开发和维护由互联网企业自行承担。所以并没有甲方和乙方的矛盾。但是，开发和运维相互分离的工作流程和考核方式却沿用了下来，企业内部，部门职责之间的对立依然存在：
Dev的工作是给应用系统增加新的功能/修复软件的Bug，这一系列价值的产生是通过应用系统变更实现的。一般的组织会用代码/功能的贡献数量作为KPI作为考核的依据，以激励Dev的工作产出。
Ops的工作则是让应用系统保持稳定和高性能，即最大化缩短宕机时间并能够提升应用系统的性能，并以这两者作为Ops的KPI的考核指标。以激励Ops通过维护工作使应用系统能够按照预期稳定的产出价值。
由于互联网软件用户的组织更加离散和自由。并不像企业级用户那样受到约束而集中。因此，市场变化非常迅速，难以预测。这使得互联网软件产品的生存状态十分脆弱：
一方面，互联网软件必须通过频繁增加/修改功能来提升自身对市场的适应程度。因此，基于经验的重量级软件开发方法不再适用。取而代之的是强调适应性，拥抱变化的敏捷软件开发方法论。
另一方面，互联网软件的变更给带来的运维复杂度更加高昂，因为停机所带来的风险和损失都是难以度量的。因此，互联网软件有更加严格的交付标准，需要做更多的质量保证。而基于经验的系统运维实践并没有给出足够的方法以应对这种挑战。
因此，Dev和Ops的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。
DevOps缘起，十年前的困惑DevOps 的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做 Patrick Debois。
2007 年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中，他负责测试工作。因此他不光要和开发团队（Dev）一起工作，也要和运维团队（Ops）一起工作。他第一天在开发团队跟随敏捷的节奏，第二天又要以传统的方式像消防队员那样维护这些系统，这种在两种工作环境的切换令他十分沮丧。
他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异：开发团队和运维团队生活在两个不同的世界，而彼此又坚守着各自的利益，所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者，他开始思考如何用敏捷的方法论改进自己的工作。并且质疑现有流程的合理性。
DevOps是敏捷方法论向运维侧的延伸Patrick 最开始遇到的是IT部门内部在敏捷软件开发和传统系统维护之间的矛盾。这样的矛盾使他有了用敏捷方法论来改变现状的想法，于是他开始采用 Scrum 和其它敏捷实践改进运维工作。
Velocity 09 大会的举办成为DevOps运动发展的导火索，而最引人注目的则是名为 “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲。在这个演讲里，Filckr率先提出Dev和Ops的矛盾可以通过技术升级和文化构建来解决。
Patrick Debois 通过网络看到了这个视频，这让他十分振奋，因为这就是他一直以来所想要解决的问题。因此，他在网上策划举办类似于Velocity 09这样的大会。于是，第一次 DevOpsDays 大会应运而生。
在这届大会上，来自世界各地的爱好者带来了纷繁多样的话题。但是经过Patrick Debois的总结，他发现大家所讨论的DevOps有两个重要的特点，分别是：
DevOps是在业务、交付流程和运维之间增加了一个反馈环。
因为有了这样一个环节，可以通过提升软件质量以加速流程。
而要做到这两点，则需要从“工具”和“流程管理”上进行改变。一方面要通过合作打通部门墙，另一方面需要通过采用更先进的自动化和流程工具实现这些目标。
当我们重新回头看看敏捷宣言以及敏捷软件的12条原则。我们会发现，作为软件交付的流程末端，把运维部门当做“客户”是十分合适的，当你把运维人员当做客户。在IT部门内提升Dev和Ops的“个体和互动”，加强Dev和Ops的“客户合作”，一起“响应变化”，不断部署“工作的软件”，实际上就得到了DevOps。
持续交付是DevOps的最佳实践之一2006 年，Jez Humble，Chris Read和Dan North在Agile 2006大会上发表了一篇名为”持续部署“的文章。在后面的三年里，这一系列关于”持续部署“的文章成为了一本名为《持续交付》的书。书稿完成的那一年，刚好是 DevOpsDays 举办那一年。
《持续交付》讲述如何实现更快、更可靠、低成本的自动化软件交付，描述了如何通过增加反馈，并改进开发人员、测试人员、运维人员和项目经理之间的协作来达到这个目标。这恰恰和DevOps的目标一致。
如果《持续交付》早两年问世，也许不会出现 DevOps。然而，随着 DevOps 理念的传播，DevOps 的概念的外延越来越广，已经超出了《持续交付》本身所涵盖的范畴。
2010年，Jez Humble在第二届DevOpsDays的话题中做了”持续交付“的演讲。但由于发生时间的先后关系，“持续交付”被看作是DevOps 运动的产物。而今，”持续交付：扔作为DevOps的核心实践之一被广泛应用。