2007 年:比利时,一个沮丧的独立IT咨询师

DevOps的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做**Patrick Debois,**他喜欢从各个角度研究IT组织。

2007 年,Patrick参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中,他负责测试和验证工作。所以他不光要和开发团队(Dev)一起工作,也要和运维团队(Ops)一起工作。他第一天在开发团队跟随敏捷的节奏,第二天又要以传统的方式像消防队员那样维护这些系统,这种在两种工作氛围的切换令他十分沮丧。

他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异:开发团队和运维团队生活在两个不同的世界,而彼此又坚守着各自的利益,所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者,他渐渐的明白如何在这种状况下改进自己的工作。

20086月:美国旧金山,第一届 Velocity 大会

2008 年,在美国加州旧金山,O’Reilly出版公司举办了一场名为Velocity的技术大会,这个大会的话题范围主要围绕Web应用程序的性能和运维展开。这个会议被设计用来分享和交换构建和运维Web应用的性能、稳定性和可用性上的最佳实践。

20088月:加拿大多伦多,Agile Conference 2008 大会埋下了DevOps的种子

同年 8月,在加拿大多伦多的 Agile Conference 2008(敏捷大会)上,一位名为 Andrew Shafer 的人提交了一个名为“Agile Infrastructure”的临时话题。由于对这个临时话题感兴趣的人不多,Andrew 认为没人会对如何 跨越 Dev 和 Ops 的鸿沟 这个话题感兴趣。所以当这个话题时间开始的时候,作为话题提交人的 Andrew 并没有出现。

但是话题开始的时候,仅有一个人出席。这个人就是上文提到的IT咨询师 Patrick 。Partrik 在这次会议上分享了自己的话题:**如何在运维工作中应用 Scrum 和其它敏捷实践。**他十分想把这些经历和别人分享。

最终,Patrick 在会议厅的走廊里找到了 Andrew,并进行了一场漫长的讨论。他们意识到在这次会议之外会有很多的人想要继续探讨这个广泛而又系统化的问题。

尽管在这次会议中,持续集成的流行已经使敏捷实践慢慢走向部署了。可是这仍然把运维工作和开发完全割裂开。于是他俩决定在 Google Group 上建立了一个 Agile System Adminstration 的讨论组继续这个话题。虽然有一些话题和参与者,但是访问者寥寥。

20096月:美国圣荷西,第二届 Velocity 大会上一个轰动世界的演讲

这一年的 Velocity 大会最大的亮点是一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲,几乎所有的和 DevOps 相关的资料都会把这个演讲作为 DevOps 的引用。这个演讲的内容可以作为 DevOps 萌发的标志。这个演讲提出了了 DevOps 的“一个中心,两个基本点”——以业务敏捷为中心,构造适应快速发布软件的工具(Tools)和文化(Culture)。

Patrick 在网上看到了这个视频后很兴奋,因为这就是他一直致力于的领域。于是他在Twitter 上问如何才能参加 Velocity 大会。

其中有个人回复: 嘿,Patrick,你想在比利时召开自己的 Velocity 吗?我们都会去参加,这一定会很棒。于是,Patrick 就想通过 Twitter 召集开发工程师和运维工程师在比利时举办一个类似于 Velocity 的大会。

2009 年 10 月:比利时根特,第一届 DevOpsDays

如果要召开一个会议,就得有一个名字。Patrick 首先就想到了Dev和Ops,由于这个会议会持续两天,所以他加上了 Days,于是就有了 DevOpsDays。由于 Twitter 上有140个字符的限制,因此他想用 DOD 作为 DevOpsDays 的缩写以提醒自己“死在交付上”(Dead On Delivery),但不知什么原因,最后没有这么做。

虽然这是一届“社区版 Velocity 大会”,但这届大会出乎意料的成功。人们从世界各地蜂拥而至,除了开发工程师和运维工程师,还有各种IT管理人员和工具爱好者。两天的会议已经结束后,参与 DevOpsDays 的人们把这次会议的内容带回到了世界各个角落。

然而, DevOpsDays 的讨论仍在 Twitter 上继续着。由于 Twitter 140个字符的限制,大家在 Twitter 上去掉了 DevOps 中的 Days,保留了 DevOps。于是, DevOps 这个称谓正式诞生。

2010 年:DevOpsDays 确立了 DevOps 的原则和方向

在第一届 DevOpsDays 之后,DevOps 的火种被吹到了世界的各个角落。2010年,在欧洲,北美洲,南美洲,大洋洲分别举办了各自的 DevOpsDays。

在 DevOpsDays 之后,DevOps 被越来越多的人所熟知并迅速得到了大多数人的认可。人们认为这正是IT部门的正确运作方式,DevOps 成为了一种促成开发运维合作的**运动。**人们在各种场所和活动中不断分享自己的经验和见解,并催生了很多工具和实践的产生。但是,每个人对 DevOps 的理解都有所不同,争议在所难免。

可以说,没有这一年的 DevOpsDays,DevOps 便只是昙花一现, 夭折在了比利时的某个酒店里。而这一年的 DevOpsDays,也是 DevOps 运动的立足和确立之年,DevOps 实践的原则和方向由此确立。

《持续交付》的作者 Jez Humble 参加了位于德国汉堡的第二届的 DevOpsDays 并做了 “持续交付”的演讲。从本质上说,《持续交付》中所提到的实践给 Patrick 和 Andrew 最初所遇到的问题给出了全面的解决方案。如果《持续交付》早两年问世,也许就没有 DevOps 了。然而,随着 DevOps 理念的传播和发展,DevOps 的概念的外延越来越广。DevOps 的内容已经超出了《持续交付》本身所涵盖的范畴。后来,Jez Humble 成为了《 DevOps Handbook 》的作者之一。

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

除了德国汉堡,远在大洋彼岸的美国加州的 Montain View 也举办了 DevOpsDays,这届 DevOps 可谓众星云集:

Patrick Debois, 从比利时来到了加州,作为基础设施即代码的出品人,把基础设施即代码正式纳入 DevOps。

Andrew Shafer, 作为 DevOps 文化的出品人,分别讨论了不同 IT 组织的管理和文化实践。

Gene Kim,《凤凰项目》和《DevOps Handbook》的合作者之一,讨论了 DevOps 在 Web 运维以外实践的可能性。

John Allspaw,在 Velocity 09 大会之后,离开了 Filcker,加入了 Etsy,讨论了 DevOps 文化相关的话题。

John Willis,《DevOps Handbook》的合作者之一。作为云计算和 DevOps 相关方面的出品人

Damon Edwards,DevOps 可视化的出品人,和 John Willis 一起在本次 DevOpsDays 之后提出了 CAMS 原则,并在 Jez Humble 提出 Lean 之后变成 CLAMS 原则,使之成为 DevOps 实践的指导原则。

Ernest Mueller 作为 The Agile Admin 博客的维护者,在参加了本次 DevOpsDays之后,发表了“ What is DevOps ”这篇文章。该文给出了详细 DevOps 的定义,并且依据敏捷的体系构造出了DevOps 的体系: 它包括一系列价值观、原则、方法、实践以及对应的工具。并且梳理了 DevOps 的历史和对DevOps 的一些误解。至此,DevOps 的原则和方向成型。

DevOps是敏捷运动在IT部门内的延伸

通过以上的历史我们可以看到,Patrick 最开始遇到的是IT部门内部在敏捷软件开发和传统系统维护之间的矛盾。这样的矛盾使他有了用敏捷来变革系统维护的想法,于是他采用 Scrum 和其它敏捷实践改进了运维工作

同时,远在美国Austin的几个Web工程师也有了类似的想法,因而产生了 The Agile Admin 博客。直到 Velocity 09 正式提出“ Dev and Ops Cooperation ”人们才意识到解决IT部门内部的这个矛盾带来的巨大价值。

解决这个矛盾的第一步,就是要统一价值观:运维工程师的工作的目标不仅仅是让Web站点稳定和高效,更需要支持业务的快速演化——这点是和敏捷软件开发的目标是一致的。

当我们重新回头看看敏捷宣言以及敏捷软件的12条原则。我们会发现,作为软件交付的流程末端,把Ops当做“客户”是十分合适的,当你把运维人员当做客户。在IT部门提升“个体和互动”,加强“客户合作”,一起“响应变化”,部署“工作的软件”实际上就得到了DevOps

知识共享许可协议

本作品采用知识共享署名-禁止演绎 4.0 国际许可协议进行许可。