前两天在部门分享运维转型相关的主题,提到了DevOps,其实已经不算一个新词汇了,但是从他的由来,还可以了解一种新的思想,是怎样来演进的。
(原文链接:https://www.jianshu.com/p/f40209023006)
2007年:比利时,一个沮丧的独立IT咨询师
DevOps的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做Patrick Debois,他喜欢从各个角度研究IT组织。
2007年,Patrick参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中,他负责测试和验证工作。所以他不光要和开发团队(Dev)一起工作,也要和运维团队(Ops)一起工作。他第一天在开发团队跟随敏捷的节奏,第二天又要以传统的方式像消防队员那样维护这些系统,这种在两种工作氛围的切换令他十分沮丧。
他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异:开发团队和运维团队生活在两个不同的世界,而彼此又坚守着各自的利益,所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者,他渐渐的明白如何在这种状况下改进自己的工作。
2008年6月:美国旧金山,第一届Velocity大会和The Agile Admin博客
2008年,在美国加州旧金山,O'Reilly出版公司举办了一场名为Velocity的技术大会,这个大会的话题范围主要围绕Web应用程序的性能和运维展开。这个会议被设计用来分享和交换构建和运维Web应用的性能、稳定性和可用性上的最佳实践。
这一年是Velocity大会举办的第一年,这个大会吸引了来自Austin的几个系统管理员和开发人员。他们对大会中分享的内容十分激动,于是记录下了所有的演讲内容,并决定新开一个博客分享这些内容和自己的经验。他们同样也意识到敏捷在系统管理工作中的重要性。于是,一个名为The Agile Admin博客诞生了。
2008年8月:加拿大多伦多,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的讨论组继续这个话题。虽然有一些话题和参与者,但是访问者寥寥。
2009年6月:美国圣荷西,第二届Velocity大会上一个轰动世界的演讲
这一年的Velocity大会最大的亮点是一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲,几乎所有的和DevOps相关的资料都会把这个演讲作为DevOps的引用。这个演讲的内容可以作为DevOps萌发的标志。这个演讲提出了DevOps的“一个中心,两个基本点”——以业务敏捷为中心,构造适应快速发布软件的工具(Tools)和文化(Culture)。
Patrick在网上看到了这个视频后很兴奋,因为这就是他一直致力于的领域。于是他在Twitter上问如何才能参加Velocity大会。
其中有个人回复: 嘿,Patrick,你想在比利时召开自己的Velocity吗?我们都会去参加,这一定会很棒。
2009年10月:比利时根特,DevOpsDays和DevOps
于是,Patrick就想通过Twitter召集开发工程师和运维工程师在比利时举办一个类似于Velocity的大会。但如果要召开一个会议,就得有一个名字。Patrick首先就想到了Dev和Ops,由于这个会议会持续两天,所以他加上了Days,于是就有了DevOpsDays。由于Twitter上有140个字符的限制,因此他想用DOD作为DevOpsDays的缩写以提醒自己“死在交付上”(Dead On Delivery),但不知什么原因,最后没有这么做。
虽然这是一届“社区版Velocity大会”,但这届大会出乎意料的成功。人们从世界各地蜂拥而至,除了开发工程师和运维工程师,还有各种IT管理人员和工具爱好者。两天的会议已经结束后,参与DevOpsDays的人们把这次会议的内容带回到了世界各个角落。
然而, DevOpsDays的讨论仍在Twitter上继续着。由于Twitter140个字符的限制,大家在Twitter上去掉了DevOps中的Days,保留了DevOps。
于是, DevOps这个称谓正式诞生。
2010年:The Agile Admin博客发表“What is DevOps”
在DevOpsDays之后,DevOps被越来越多的人所熟知并迅速得到了大多数人的认可。人们认为这正是IT部门的正确运作方式,DevOps成为了一种促成开发运维合作的运动。人们在各种场所和活动中不断分享自己的经验和见解,并催生了很多工具和实践的产生。但是,每个人对DevOps的理解都有所不同,争议在所难免。
这些争议促社区统一化DevOps的见解的需要。于是The Agile Admin发表了“ What is DevOps ”这篇文章。该文给出了详细DevOps的定义,并且依据敏捷的体系构造出了DevOps的体系: 他包括一系列价值观、原则、方法、实践以及对应的工具。并且梳理了DevOps的历史和对DevOps的一些误解。
现在通过Google搜索DevOps,“ What is DevOps”仍然排在搜索结果的第二位(第一位是维基百科对DevOps的解释)。
2010年:德国汉堡,第二届DevOpsDays:对不起,《持续交付》来晚了
2010年,《持续交付》的作者Jez Humble参加了第二届的DevOpsDays并做了 “持续交付”的演讲。
从本质上说《持续交付》中所提到的实践给Patrick和Andrew最初所遇到的问题给出了最佳实践。如果《持续交付》早两年问世,也许不会出现 DevOps。然而,随着DevOps理念的传播,DevOps的概念的外延越来越广,已经超出了《持续交付》本身所涵盖的范畴。
“持续交付”是“持续集成”的延伸,而这点恰恰和2008年敏捷大会中的观念一致。但由于发生时间的先后关系,“持续交付”被看作是敏捷以及DevOps文化的产物。而今,持续交付仍然被作为DevOps的核心实践之一被广泛谈及。
结论:DevOps是敏捷在IT部门内的延伸
通过以上的历史我们可以看到,Patrick最开始遇到的是IT部门内部在敏捷软件开发和传统系统维护之间的矛盾。这样的矛盾使他有了用敏捷来变革系统维护的想法,于是他采用Scrum和其他敏捷实践改进了运维工作。
同时,远在美国Austin的几个Web工程师也有了类似的想法,因而产生了The Agile Admin博客。直到Velocity 09正式提出“Dev and Ops Cooperation”人们才意识到解决IT部门内部的这个矛盾带来的巨大价值。
解决这个矛盾的第一步,就是要统一价值观:运维工程师的工作的目标不仅仅是让Web站点稳定和高效,更需要支持业务的快速演化——这点是和敏捷软件开发的目标是一致的。
当我们重新回头看看敏捷宣言以及敏捷软件的12条原则。我们会发现,作为软件交付的流程末端,把Ops当做“客户”是十分合适的,当你把运维人员当做客户。在IT部门提升“个体和互动”,加强“客户合作”,一起“响应变化”,部署“工作的软件”实际上就得到了DevOps。
参考链接:
https://youtu.be/o7-IuYS0iSEhttp://conferences.oreilly.com/velocity/velocity2008/
http://conferences.oreilly.com/velocity/velocity2009/
https://www.devopsdays.org/
https://theagileadmin.com/what-is-devops/
近期热文:
《虚拟内存详解》