1.2.1 DevOps的起源
1．原始的DevOps
提起DevOps，不得不说DevOps的载体——程序。
在计算机刚出现的时候，软件开发只是少数人的“特权”，在此期间，从业者具备高学历的特征。在那个时期，只有 “程序”（program），没有“软件”（software），因此，当时编写程序的人员被称为“程序员”（programmer）。学习编程的基本材料只是计算机设备厂商附送的产品使用手册。因此，一些企业只能先购买设备，再自己培养编程人才。图 1-2中的女人是格蕾丝·霍珀（Grace Hopper），她是编程界的传奇人物。（图1-2引自《宽带：创造互联网的女性的不朽故事》。）
在计算机发展的早期，最先购买计算机的是科研单位、军队、政府，以及少数大型企业。它们组建了新的部门，如信息技术部（IT department），或者称为信息化办公室（IT office）。在中国，有些单位直接将这类部门称为“电脑部”。这类部门专门管理计算机，并且组织成员学习软件编程技术，利用程序帮助其他部门解决相关问题。这是IT运维的雏形。在这个时期，没有Dev和Ops之分，它们统称为programmer。由于这个时期的开发工作和运维工作由同一批人来做，即自己维护自己开发的程序，因此我们可以将这种形式看作原始的DevOps。在这个时期，计算机系统和出现的问题较简单，开发和维护并不复杂，无须进行专业分工。
2．Dev的出现
随着计算机的成本不断下降，尤其是以IBM PC为代表的微型计算机（micro computer）的普及，企业开始大规模使用计算机进行办公。由于软件开发人员的数量仍然很少，加之需求旺盛，因此专业软件开发人员的人工成本依然高昂。随着软件的扩展，当初为个人目的（personal purpose）而开发的软件渐渐开始走通用化的路线，慢慢形成了软件产品。接着，专门从事软件开发的公司出现，并逐渐形成了一个产业。与此同时，软件开发工程师（Developer，简称Dev）出现。
在这个时期，软件开发仍然是一个专业人员从事的工作，企业的IT部门开发软件的成本依然很高。于是，大部分单位、组织和企业通过购买的形式获得软件。IT部门逐渐成为负责信息化采购和软硬件基本操作培训的部门。此外，由于信息化加速，针对各个行业的软件层出不穷，加之从事软件开发的企业越来越多，因此IT部门不得不通过更广泛的学习来了解技术的变化。
3．Ops的出现
随之而来的问题是，无论企业购买多少软件，仍然无法完全满足企业的信息化需求。计算机中的数据成为企业的信息“孤岛”。虽然软件解决了信息的分析和存储问题，但只是实现了无纸化办公，没有让部门间的信息有效流动起来。一些大型企业最先发现这些问题并且给出了最初的解决方案，这使得企业级软件开发和系统集成（system integration）逐渐成为一个热门领域。企业级软件系统的显著特点是通过计算机网络解决了企业内部的信息“孤岛”问题，但这样的系统无法在PC上运行，因为需要专业的工作站、服务器和网络设备。企业的IT部门理所当然地承担了对这些设备的管理职责。
随着软硬件技术的发展，特别是针对企业级应用开发的经验不断积累，设备的采购成本和软件的开发成本进一步降低。一些大型IT厂商开始瞄准企业级应用市场，如IBM、Oracle和EMC相继推出了相应的产品。这使得定制化软件开发的成本不断下降。随着软件开发人员越来越多，开发成本逐渐降低，于是出现了企业定制化软件开发，同时出现了MIS和ERP这样的应用，以及J2EE这样的企业级软件开发框架。
在这个过程中，IT运维的概念逐渐产生。IT运维（IT operation）的职能是为内部和外部客户的应用部署提供平滑的基础设施和操作环境，包括网络基础设施、服务器和设备管理，计算机操作，ITIL管理，以及作为组织的IT帮助中心。对于企业的IT部门，其职能不仅是维护计算机和网络设备，还要维护运行在这些设备上的软件系统，尤其是定制化的企业级软件产品。因此，在企业定制化软件从乙方交付甲方时，就需要一系列的技术审查以确保质量，这就对原本不需要关心软件是如何开发的企业的IT部门提出了更高的要求。企业的IT部门必须提高专业技能水平以应对这样的变化。同时，企业的IT部门需要重新思考整个IT部门的服务的管理和设计。随着IT部门在知识和服务专业度方面的提升，催生出了ITIL（Information Technology Infrastructure Library，信息技术基础设施库）这样的最佳实践库，使得“系统维护工程师”（Ops）更加专业。在这个时期，Dev和Ops的矛盾主要体现在由Dev所代表的乙方和由Ops所代表的甲方在定制化软件产品交付质量上的要求不一致。
4．DevOps被正式推出
随着企业级软件开发日趋完善和成熟，形成了以RUP（Rational Unified Process，Rational统一软件开发过程）为代表的方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级方法（也称为厚方法学），因此，特别适合大型软件团队开发大型项目。后来，随着互联网企业的成功，不断颠覆很多人过往的认知，对IT产业影响很大。
首先，相较于最多万人的用户访问规模，来自互联网的千万级甚至亿级的访问规模是以前企业级应用不曾面临的。这给软件开发、主机管理和网络架构带来了很大挑战。
其次，企业级应用和互联网应用面对的问题是不一样的。“康威定理”中提到：设计系统的组织产生的设计和架构等价于组织间的沟通结构。相较于有清晰等级和部门分工的组织，互联网产品的沟通结构更加复杂。
此外，互联网应用由互联网企业自开发、自维护。从表面上来看，虽然没有了甲方和乙方之分，但开发和运维相互分离的工作流程和考核方式在沿用，职能上的对立依然存在。Dev的职能是给应用系统增加新的功能和修复软件的bug，这一系列价值的产生是通过应用系统变更实现的。一般的组织会用代码/功能的贡献数量作为业绩考核的依据，以激励Dev的工作产出。Ops的职能则是让应用系统保持稳定和高性能，即在最大程度上缩短“死”机时间并能够提升应用系统的性能，同时，将这两点作为Ops的考核指标（KPI），以激励Ops通过维护工作使应用系统能够按照预期稳定地产出价值。
而市场环境的瞬息万变和资本的集中化使得互联网软件产品的生存状态非常脆弱。一方面，快速变化的市场难以预测。因此，基于经验的重量级软件开发方法不再适用，取而代之的是强调适应性、拥抱变化的敏捷方法。互联网软件必须通过频繁增加/修改功能来提升自身对市场的适应程度。另一方面，互联网软件的变更给企业带来的风险和损失是难以度量的。因此，互联网软件有更加严格的交付标准，需要做更多的质量保证。而基于经验的系统运维实践并没有给出足够的方法来应对这种挑战。因此，在这个时期，Dev和Ops的主要矛盾是面向适应的敏捷软件交付和面向经验的传统运维之间的矛盾。
1.2.2 DevOps的发展路径
DevOps的发展路径如图1-3所示。
图1-3
对于DevOps的历史，我们要从比利时的一个IT咨询师说起。这位名为Patrick Debois的IT咨询师喜欢从多种角度研究IT组织。2007年，Patrick Debois参与了比利时政府的一个下属部门的大型数据中心迁移项目。在这个项目中，他负责测试和验证工作。因此，他不但需要和开发团队（Dev）一起工作，而且需要和运维团队（Ops）一起工作。于是，他第一天在开发团队以敏捷的节奏工作，第二天在运维团队以传统的方式维护这些系统。这种在两种工作氛围来回切换的方式令他非常沮丧。他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异。开发团队和运维团队“生活”在两个不同的“世界”，而彼此又坚守着各自的利益，因此，这两者在工作上经常发生冲突。作为一个敏捷的拥护者，他渐渐明白了如何在这种状况下改进自己的工作方式。
2008年6月，在美国加利福尼亚州的旧金山市，O’Reilly公司举办了一场名为Velocity的技术会议。这场会议主要围绕Web应用程序的性能和运维话题展开。这场会议被设计用来分享构建和运维Web应用时性能、稳定性和可用性方面的最佳实践。这场会议吸引了来自奥斯汀（Austin）的几个系统管理员和开发人员。他们对会议中分享的内容感到非常激动，于是记录了所有的演讲内容，并决定新开一个博客以分享这些内容和自己的经验。他们同样意识到敏捷在系统管理工作中的重要性。于是，一个名为The Agile Admin的博客诞生了。
2008年8月，在加拿大多伦多市召开的Agile Conference 2008（敏捷会议2008）上，Andrew Shafer提交了一个名为“Agile Infrastructure”的临时话题。由于对这个临时话题感兴趣的人不多，Andrew Shafer认为没人会对如何跨越Dev和Ops之间的鸿沟这个话题感兴趣。于是，当开始讨论这个话题的时候，作为话题提交人的Andrew Shafer并没有出现，仅有一个人出席，这个人就是上文提到的IT咨询师Patrick Debois。Partrik Debois在这次会议上分享了自己的话题：如何在运维工作中应用Scrum和其他敏捷实践。他特别想把这些经历和别人分享。后来，Patrick Debois在会议厅的走廊里找到了Andrew Shafer，并与他进行了一场漫长的讨论。他们意识到，在这次会议之后，会有很多人想要继续探讨这个广泛而又系统化的话题。在召开这次会议时，尽管持续集成的流行已使敏捷实践慢慢走向落地，但是这仍然把运维工作和开发工作完全割裂。于是，他们决定在Google Group上建立一个名为Agile System Adminstration的讨论组并继续讨论这个话题。虽然在这个讨论组中有一些话题和参与者，但是访问者寥寥。
在2009年6月召开的第二届Velocity会议上，最大的亮点是一个题为10 Deploys Per Day: Dev and Ops Cooperation at Flickr的演讲。后来，几乎所有与DevOps相关的资料都会引用这个演讲的内容。这个演讲的内容可以被视为DevOps萌发的标志。在这个演讲中，提出了关于DevOps的“一个中心，两个基本点”，即以业务敏捷为中心，构造适应快速发布软件的工具（tool）和文化（culture）。Patrick Debois在网络上看到了这个演讲的视频，感到很兴奋，因为这就是他一直致力于研究的领域。于是，他在Twitter上询问如何才能参加Velocity会议。其中有个人回复：嗨，Patrick，你想在比利时召开自己的Velocity吗？我们都会去参加，这一定会很棒。
于是，Patrick Debois就想通过Twitter召集开发工程师和运维工程师在比利时举办一个类似Velocity的会议。如果要召开一个会议，就得有一个会议名字，Patrick Debois首先想到了Dev和Ops，加上这个会议持续两天，因此他加上了Days，于是有了DevOpsDays这个会议名称。由于Twitter对发布的内容有140个字符的限制，因此他想用DOD作为DevOpsDays的缩写以提醒自己“死在交付上”（Dead On Delivery），但不知什么原因，最后他没有这样做。虽然这是一届社区版“Velocity会议”，但这次会议出乎意料地获得了成功。2009年10月，人们从世界各地蜂拥而至，除开发工程师和运维工程师以外，还有IT管理人员和工具爱好者等。两天的会议结束后，参与DevOpsDays的人把这次会议的内容带回到世界各个角落。虽然会议已经结束，但关于DevOpsDays的讨论仍在Twitter上继续。由于Twitter对发布的内容有140个字符的限制，因此大家在Twitter上讨论时去掉了Days，只保留了DevOps。于是，DevOps这个称谓正式诞生了。
2010年，在第二届DevOpsDays会议之后，DevOps被越来越多的人熟知并迅速得到了大多数人的认可。很多人认为这正是IT部门的正确运作方式，DevOps成为了一种促成开发部门和运维部门合作的运动。很多人在不同的场所和活动中分享自己的经验和见解，并催生了很多工具和实践。但是，每个人对DevOps的理解不同，争议在所难免。这些争议促使DevOps社区（如Cloud & DevOps World、Continuous Lifecycle和DevOps Days）统一DevOps见解。于是，在The Agile Admin上，发布了一篇名为What is DevOps的文章。该文给出了详细的DevOps的定义，并且依据敏捷的体系构造了DevOps的体系：它包括一系列价值观、原则、方法、实践，以及对应的工具。该文同时梳理了DevOps的历史并对DevOps的一些误解进行了澄清。现在，我们通过Google搜索DevOps，会发现What is DevOps仍然排在搜索结果的第二位（第一位是维基百科对DevOps的解释）。
2010年，《持续交付：发布可靠软件的系统方法》的作者Jez Humble参加了第二届DevOpsDays会议并做了关于“持续交付”的演讲。从本质上来说，《持续交付：发布可靠软件的系统方法》中提到的一些论点和实践能够解决Patrick Debois和Andrew Shafer所遇到的问题。如果《持续交付：发布可靠软件的系统方法》早两年问世，也许不会出现DevOps。然而，随着DevOps理念的传播，DevOps的概念的外延越来越广，已经超出了《持续交付：发布可靠软件的系统方法》本身所涵盖的范畴。“持续交付”是“持续集成”的延伸，而这点恰恰和2008年召开的敏捷会议中提到的观点一致。但由于发生时间的先后关系，“持续交付”被视为敏捷和DevOps文化的产物。至今，持续交付仍然作为DevOps的核心实践而被广泛谈及。
2015年是DevOps落地实践的转折点，也是DevOps的中国年。随着中国经济的腾飞，信息技术得到了蓬勃发展，因此，很多创新技术在中国企业落地和实践，取得了很好的效果并得到了权威总结。
2015年6月，中国信息通信研究院组织国内头部互联网企业进行DevOps标准的雏形《互联网应用运维框架及能力模型》的编写，并在2016年将DevOps能力上升到技术运营层面，并形成DevOps正式标准《研发运营一体化（DevOps）能力成熟度模型》。在该标准中，明确了研发运营一体化在IT软件及相关服务的研发和交付过程中，将应用的需求、开发、测试、部署和运营统一，基于整个组织的协作和应用架构的优化，实现敏捷开发、持续交付和应用运营的无缝集成。在保证稳定的同时，帮助企业提升IT效能，快速交付高质量的软件和服务，灵活应对快速变化的业务需求和市场环境。
DevOps标准的立项过程如图1-4所示。
图1-4
2018年7月16～27日，在瑞士日内瓦举办了ITU-T（国际电信联盟）Study Group13 Future networks (& cloud)全会，来自多个国家或地区的90多名代表参与了此次会议。由中国信息通信研究院主导的DevOps国际标准项目成功立项，立项名称：“Cloud computing- Requirements for cloud service development and operation management”。这是由中国信息通信研究院主导立项的首个DevOps国际标准，是在国际标准中将云计算开发运维实践上升到国际产业和生态来共同推动DevOps标准全球化的重要里程碑。
1.2.3 DevOps的发展特点
通过DevOps的发展趋势，我们发现其呈现3种鲜明的发展特点，分别是思想和文化的变革，聚焦能力的变革，以及技术传播的变革。
1．思想和文化的变革
在DevOps的发展趋势中，思想和文化有一种明显的上升态势，从技术载体文化到工程师文化，最终到组织文化。尤其在2009年的Velocity会议上，提出“一个中心，两个基本点”的概念，更是强调了DevOps发展过程中的关键要素，即思想和文化的重要性，而这种思想和文化的变革，更是体现在思想的延伸，以及价值观的支撑层面。
回顾软件发展的管理模式，在传统瀑布管理模式下，开发、测试和运维分属不同的部门，部门之间存在厚厚的部门“墙”，下一个环节的动作必须要等到上一个环节全部完成才能进行。到后来的敏捷时代，也主要是打通了开发和测试的部门“墙”，采用迭代的方式，测试驱动开发，这是技术载体文化到工程师文化的延展。
比较上述两种模式，我们会发现，传统瀑布管理模式注重在交付范围不变的情况下，通过计划驱动修改交付的时间和协调资源来完成交付。而敏捷是在资源、时间不变的情况下，通过价值驱动更改交付范围。在这个范围内，已经初步具备价值交付的相关特性。因此，工程师文化已经相对局限，更为全局的组织文化和价值观需要更为宏观的体现。
2．聚焦能力的变革
在能力聚焦阶段，程序由服务能力到快速交付能力，再到后续的价值交付能力，最终到价值输出能力，体现了聚焦的锚定。
在现阶段，绝大多数企业的DevOps实践在于软件快速交付和系统稳定运营。团队共享面向客户的价值和集成目标，同时共担质量责任。但是，DevOps并不会取代敏捷，而是对敏捷的补充。它通过消除浪费和简化部署等思想，实现持续交付的目标。DevOps是集大成者，它并不制造概念，而是将很多理念和实践进行整合，是真正打通端到端交付的方法体系。
在下一个阶段，快速交付需要延伸至技术运营，交付的根本体现在对企业发展的支撑能力，一切不能量化的支撑能力都不能称为价值输出。
在聚焦能力层面，DevOps不断以端到端的传播方式来体现，在IT组织内部，端到端地进行资源输出，端到端地进行持续部署，端到端地进行价值输出；在IT组织外部，面向用户进行服务，面向客户传递价值，面向其他职能组织提供产品和运营反馈。
3．技术传播的变革
DevOps的发展过程其实就是敏捷思想从软件开发端（Dev）到系统维护端（Ops）的延伸。“Dev”是开发人员的简称，但在真正的实践中，意味着更广泛的“参与开发产品”的所有人，包括产品人员、质量人员和其他工种人员。“Ops”也是一个总括术语，泛指系统工程师、系统管理员、操作人员，发布工程师、数据管理员（DBA）、网络工程师和安全专家等维护支撑类工种人员。职能的变化带来了技术传播的变革。
随着微服务、容器和云技术的成熟，DevOps在技术传播中，从强调资源交付、敏捷交付到持续集成、持续部署和持续交付，再到端到端的价值交付，技术的赋能更为明显。尤其在万物互联的时代，即人与人连接，人与物连接，以及物与物连接的信息时代，需求关系的转变，让业务变得越来越复杂，系统功能越来越多。因此，DevOps的技术传播和IT技术架构的革新形成良性循环，技术的赋能也不断呈现上升趋势，不同业态和规模的DevOps实现也变得规范化和标准化。
