1.2　DevOps的诞生

1.2.1　DevOps的历史

所有关于DevOps的故事都会提起一个名字：Patrick Debois。他最早在比利时根特市发起了DevOpsDays活动，被称为“DevOps之父”。DevOps的历史也从他开始讲起。

沮丧和失望引发的思考

2007年，Patrick Debois受比利时政府部门的委托，协助某部门的一个大型数据中心进行迁移工作，负责认证和验证测试，因此他需要协调开发（Dev）和运维（Ops）团队的工作。这显然不是一份轻松的工作，采用敏捷开发的开发团队和采用传统运维模式的运维团队仿佛生活在两个世界，不同的工作方式像是一堵墙，这使得在两个团队之间来回切换的Patrick非常沮丧和失望，也让Patrick开始思考是否有方式可以解决这个问题。

第一届Velocity大会和The Agile Admin博客

2008年，O'Reilly公司在美国加州旧金山举办了第一届Velocity技术大会，讨论的主题是“Web应用程序的性能和运维”。大会吸引了来自奥斯汀的几个系统管理员和开发者，他们对大会分享的内容十分感兴趣，并共同开设了一个名为The Agile Admin的博客，以分享敏捷开发在系统管理工作中的应用和实践。

Agile Conference 2008

2008年8月，敏捷大会（Agile Conference 2008）在加拿大多伦多举办，软件工程师Andrew Shafer提交了一个名为“Agile Infrastructure”的临时话题，但对这个话题感兴趣的人并不多。所以，这个话题开始时仅有一个人出席，就是Patrick。Partrik在这次会议上分享了自己的想法，即“如何在运维工作中应用Scrum（迭代式增量软件开发过程）和其他敏捷实践”，十分想把这些经历进行分享。

最终，Patrick与Andrew进行了一场漫长的讨论后，他们意识到，在这次会议之外会有很多的人想继续探讨这个广泛而又系统化的问题，随后在谷歌小组（Google Group）上建立了Agile System Administration讨论组，来讨论这个话题。最初虽然有一些话题和参与者，但是访问者依旧寥寥无几。

一个影响深远的演讲

2009年6月，第二届Velocity大会如期举行，最大的亮点就是John Allspaw和Paul Hammond分享了一个名为“10+ Deploys Per Day ：Dev and Ops Cooperation at Flickr”的演讲。此后，几乎关于DevOps的资料都会引用这个演讲。他们提出的“以业务敏捷为中心，构造适应快速发布软件的工具（Tools）和文化（Culture）”的观点非常准确地描述了DevOps的理念，哪怕当时DevOps这个名词还未诞生。

Patrick也在网上看到了这个演讲视频，在推特（Twitter）上询问如何才能参加Velocity大会。而Paul直接回复：“嘿，Patrick，你想在比利时召开自己的Velocity吗？我们都会去参加，这一定会很棒。”

DevOpsDays和DevOps的诞生

于是乎，“社区版Velocity大会”就由Patrick在推特（Twitter）上进行了召集，于同年10月30日在比利时召开。关于会议的名称，Patrick首先就想到了Dev和Ops，而这个会议持续两天，所以他加上了“Days”，于是就有了“DevOpsDays”。

这届大会非常成功，众多开发和运维工程师、IT管理人员和工具爱好者从世界各地蜂拥而至。两天的会议结束后，参与DevOpsDays的人们把这次会议的内容带向了全世界。

在推特（Twitter）上，关于DevOpsDays的讨论越来越多。由于推特（Twitter）的140个字符的限制，大家在推特（Twitter）上去掉了DevOps中的Days，保留了DevOps。

于是，“DevOps”这个称谓正式诞生。

What is DevOps

自DevOpsDays开始，越来越多的人认为DevOps将是IT部门正确的运作方式，而DevOps成为了一种促成开发与运维相结合的运动。各种各样、不同职责、不同背景的人不断地在各种场合分享自己关于DevOps的实践经验和理解，由此还催生了很多工具和实践。但随之而来的是，由于每个人对DevOps的理解不同，关于DevOps而产生的争议和冲突也越来越多。

于是，The Agile Admin发表了What is DevOps（什么是DevOps）的文章，给出了DevOps的详细定义，并且依据敏捷的体系构造出了DevOps体系，包括一系列价值观、原则、方法、实践和对应的工具，并梳理了DevOps的历史和对DevOps的一些误解。

《持续交付》问世

2010年，在第2届DevOpsDays上，《持续交付》的作者Jez Humble做了关于“持续交付”的演讲。针对Patrick和Andrew最初遇到的问题，书中提到的实践给出了最佳实践。也有人说，如果《持续交付》早两年问世，也许就不会出现DevOps。然而，随着DevOps理念的传播，DevOps概念的外延越来越广，已经超出了《持续交付》涵盖的范畴。

“持续交付”是“持续集成”的延伸，而这恰恰与2008年敏捷大会中的观念一致。但由于发生时间的先后关系，“持续交付”被看成敏捷开发和DevOps文化的产物。而今，持续交付仍然作为DevOps的核心实践之一被广泛谈及。

《凤凰项目》发布

2013年，由Gene Kim、Kevin Behr、George Spafford共同完成的《凤凰项目》发布，并大受欢迎。这是DevOps的一个标志性事件，因为它以小说的形式向读者介绍了DevOps的理念。故事讲述了一个虚构的IT经理Bill Palmer临危受命，在未来董事的帮助和自己“三步工作法”理念的支撑下，最终挽救了一家具有悠久历史的汽车配件制造商的故事。

DevOps从小众走向主流

2016年，Garter预测DevOps将从小众战略过渡到主流战略。当年，全球2000强企业中有四分之一的企业采用了DevOps战略。

DevOps之年和中国DevOps元年

Forester Research称2017年为“DevOps之年”，同时报告说，有高达50％的组织正在实施DevOps。同年，DevOpsDay Beijing成功举办，2017年成为“中国DevOps元年”。

DevOpsDay在中国

2018年，北京、上海、深圳成功举办了DevOpsDay；同年，美国安排了30余场DevOpsDay活动。DevOps的理念在全球迅速推广，其中不断有基础设施团队和运维团队提出了更多有关DevOps的倡议，越来越多的组织和企业开始采用DevOps。

【小结】通过DevOps的历史可以看到，DevOps诞生至今依旧保持着非常旺盛的生命力，依旧有众多的企业和工程师基于自己的实践经验不断提出不同的倡议，从而解决开发（Dev）与运维（Ops）之间的矛盾。

1.2.2　DevOps的优势

DevOps的优势很大程度体现在组织层面的协作和沟通上，实践DevOps的团队可以更快、更好地工作，简化事件响应，并改善团队之间的协作和沟通。

1.速度

DevOps高速运转，可以更快速地针对用户进行创新、更好地适应不断变化的市场，同时更有效地推动业务成果。DevOps模式能够帮助开发人员和运维团队实现这些目标。例如，微服务和持续交付能够让团队充分掌控服务，然后更快速地发布更新。

2.快速交付

DevOps提高了发布的频率和速度，以便更快速地进行创新并完善产品。发布新功能和修复错误的速度越快，就越能快速地响应用户需求并建立竞争优势。持续集成和持续交付是自动执行软件发布流程（从构建到部署）的两项实践经验。

3.可靠性

DevOps确保应用程序更新和基础设施变更的品质，以便在保持最终用户优质体验的同时，更加快速、可靠地进行交付；使用持续集成和持续交付等实践经验来测试每次变更是否安全，以及能够正常运行；监控和日志记录实践经验能够帮助实时了解当前的性能。

4.规模

DevOps可以用于大规模运行、管理软件的基础设施及开发流程；自动化和一致性可在降低风险的同时，有效管理复杂或不断变化的系统。例如，“基础设施即代码”有助于通过一种可重复且更有效的方式来管理部署、测试和生产环境。

5.增强合作

建立一个适应DevOps文化模式的更高效的团队，强调主人翁精神和责任感。开发人员和运维团队密切合作，共同承担诸多责任，并将各自的工作流程相互融合。这有助于提升效率、节约时间（例如，缩短开发人员和运维团队之间的交接时间，编写将运行环境考虑在内的代码）。

6.安全性

在快速运转的同时保持控制力和合规性。利用自动实施的合规性策略、精细控制和配置管理技术，可以在不牺牲安全性的前提下采用DevOps模式。例如，“基础设施即代码”和“策略即代码”可以大规模定义并追踪合规性。

【小结】DevOps更多强调人与人、开发与运维之间的通力合作，共同探索出一条符合自己团队安全、高效的DevOps模式。团队在进行DevOps转型时需要把握核心目标，切勿照本宣科，不要为了实现DevOps而做DevOps。