DevOps前世今生之DevOps编年史

本文转载自:http://www.jianshu.com/u/66fea2f123be 作者:admin


作者简介:

顾宇,ThoughtWorks高级咨询师,9年工作经验。加入ThoughtWorks之前曾参与中国移动,中国联通省级BOSS系统以及呼叫中心系统的研发、实施和割接。担任过售前,项目经历,维护工程师和开发工程师等职务。拥有丰富的大型系统开发以维护的实战经验。

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

DevOps 的历史要从一个比利时的独立IT咨询师说起。这位咨询师的名字叫做Patrick Debois,他喜欢从各个角度研究IT组织。2007 年,Patrick 参与了比利时一个政府下属部门的大型数据中心迁移的项目。在这个项目中,他负责测试和验证工作。所以他不光要和开发团队(Dev)一起工作,也要和运维团队(Ops)一起工作。他第一天在开发团队跟随敏捷的节奏,第二天又要以传统的方式像消防队员那样维护这些系统,这种在两种工作氛围的切换令他十分沮丧。他意识到开发团队和运维团队的工作方式和思维方式有巨大的差异:开发团队和运维团队生活在两个不同的世界,而彼此又坚守着各自的利益,所以在这两者之间工作到处都是冲突。作为一个敏捷的簇拥者,他渐渐的明白如何在这种状况下改进自己的工作。

Time 2:2008 年 6 月
美国 - 旧金山,第一届 Velocity 大会和 The Agile Admin 博客

2008 年,在美国加州旧金山,O’Reilly 出版公司举办了一场名为 Velocity 的技术大会,这个大会的话题范围主要围绕 Web 应用程序的性能和运维展开。这个会议被设计用来分享和交换构建和运维 Web 应用的性能、稳定性和可用性上的最佳实践。这一年是 Velocity 大会举办的第一年,这个大会吸引了来自 Austin 的几个系统管理员和开发人员。他们对大会中分享的内容十分激动,于是记录下了所有的演讲内容,并决定新开一个博客分享这些内容和自己的经验。他们同样也意识到敏捷在系统管理工作中的重要性。于是,一个名为 The Agile Admin 博客诞生了。

Time 3: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  的讨论组继续这个话题。虽然有一些话题和参与者,但是访问者寥寥。

Time 4: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 吗?我们都会去参加,这一定会很棒。

Time 5:2009 年 10 月
比利时 - 根特,DevOpsDays 和 DevOps

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

虽然这是一届“社区版 Velocity 大会”,但这届大会出乎意料的成功。人们从世界各地蜂拥而至,除了开发工程师和运维工程师,还有各种IT管理人员和工具爱好者。两天的会议已经结束后,参与 DevOpsDays 的人们把这次会议的内容带回到了世界各个角落。然而, DevOpsDays 的讨论仍在 Twitter 上继续着。由于 Twitter 140个字符的限制,大家在 Twitter 上去掉了 DevOps 中的 Days,保留了 DevOps。于是, DevOps 这个称谓正式诞生。

Time 6: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 的解释)。

Time 7: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。


从传统IT部署到云,人肉运维已经是过去式,云上运维该怎么开展?尤其是云2.0时代,运维已经向全局化、流程化和精细化模式转变。与此同时,人工智能的发展,“威胁论”也随之袭来——运维是不是快要无用武之地了?如何去做更智能的活?4月20日晚2017运维/Devops在线技术峰会告诉你!免费!有料!快点这里报名()

时间: 2017-03-23

DevOps前世今生之DevOps编年史的相关文章

每月亿行代码、全球数万研发,落地DevOps的协同平台DevCloud

为什么传统开发模式存在问题? 在信息化企业的这条路上,我们已经走得很远了,从少数单机到集群的规模壮大;软件生态也不断丰富完善,从底层系统到上层的业务分析,ERP ,数据库等自研定或是第三方应用.正式因为有了这些IT 基础,云计算也开始生根发芽. 越来越多的社会业务依赖着IT 技术,IT 技术工作者们也越来越期望自己的产品可以更快地响应社会不断变化的需求.首个软件公司的诞生已经过去了七十年,技术日新月异,业务发展迅速的公司也逐渐发现传统开发模式已经不再适用了.市场机遇不断扩大,企业业务需求相应增加

关于DevOps你必须知道的11件事

关于作者 Gene Kim在多个角色上屡获殊荣:CTO.研究者和作家.他曾是Tripwire的创始人 并担任了13年的CTO.他写过两本书,其中包括<The Visible Ops Handbook>,目前他正在编写<The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win>和<DevOps Cookbook>.Gene是 IT运维的超级粉丝,痴迷于改进运维流程--在不影响当

DevOps是一种文化,不是角色!

本文讲的是DevOps是一种文化,不是角色![编者的话]越来越多的企业开始推行DevOps,不过DevOps不是简单的开发运维组织的合并,不是单纯的工具链的整合贯通,更不是某种角色,而是一种文化层面的变革.本文从多个角度阐述了DevOps,并且介绍了一些应该考虑的方面以及实用的最佳实践. [3 天烧脑式容器存储网络训练营 | 深圳站]本次培训以容器存储和网络为主题,包括:Docker Plugin.Docker storage driver.Docker Volume Pulgin.Kubern

DevOps 发展融合运维可视化

DevOps,是开发(Development)和运维(Operations)的组合,代表一种文化.运动或实践,旨在促进软件交付和基础设施变更软件开发人员(Dev)和 IT 运维技术人员(Ops)之间的合作和沟通.它的目的是构建一种文化和环境使构建,测试,发布软件更加快捷,频繁和可靠. 现在2016年 DevOps 逐渐成为主流,来自云端.移动和社会等基本需求的驱动将促使越来越多的公司认识到采用 DevOps 最佳实践可能获得的文化.性能和经济效益. 精简灵活的公司已经在过去几年感受到了 DevO

报名还来得及!运维人的痛点,以及如何转型,尽在今晚——2017运维/Devops在线技术峰会

策划.准备和等待了两个月,2017运维/Devops在线技术峰会直播的"正日子"终于来了. 怀着激动,以及期待大家有所得的心情,我们将和你一起度过这个难忘的"升级"之晚. 今晚的日程 当然,如果你现在还没报名,现在还来得及--这是大会官网,戳此进入报名 报名用户,可以在会后第一时间得到所有学习资料,包括全部视频和PPT. 以下是本次在线技术峰会的背景: 近几个月,运维事件频发.从"炉石数据被删"到"MongoDB遭黑客勒索",

DevOps和持续交付

小编说:DevOps 领域在近年来变得流行而普遍.由开发(developers)和运维(operations)组成的"共同协作",归根结底,就是为了提高产品质量. 本文选自<DevOps实践>,透过本文您将了解如何在大规模敏捷背景和不同的敏捷开发周期中使用DevOps. DevOps简介 在定义上,DevOps是一个涵盖着几条线的领域.它既非常实用又贴近实践.但与此同时,你需要了解的不仅有技术背景,还有非技术的文化方面. DevOps由开发(developments)和运维

DockOne微信分享(一零五):度量驱动的DevOps转型

本文讲的是DockOne微信分享(一零五):度量驱动的DevOps转型[编者的话]虚拟化,容器化,云计算,自动化为DevOps运动提供了底层技术支持,新的工具链和技术栈的采用进一步降低了DevOps的技术门槛,越来越多的企业纷纷开始自己的DevOps转型之路,然而-- 本次分享我们将会讨论到: DevOps以及企业DevOps转型的现状 为什么我们需要在DevOps转型中强调度量 如何实现度量驱动的DevOps转型 DevOps转型中的其它实践 Wiki上讲:DevOps(Development

企业运营对 DevOps 的 “傲慢与偏见”

[写在前面]笔者曾帮助多家大型企业深入了解 DevOps,帮助他们理解如何改善服务交付能力.这些公司大多听说过 DevOps,也在四处寻求一个策略来采用 DevOps 方法,从而进一步占领市场,提升产品质量.出于各种原因,并非所有人都信任 DevOps.有些人觉得 DevOps 只不过给开发者改善产品提供了一个途径而已,还有的人觉得 DevOps 是一堆悦耳的空头支票,甚至有人认为 DevOps 根本无法采用,因为其所在领域所必须的自动化工具根本不存在. 以下为原文编译内容. 通常在企业里,运维

CA Technologies调查显示:中国大陆领跑DevOps实施

由CA Technologies最新开展的调查显示,中国大陆组织DevOps采用率(83%)在参与调查的16个国家和地区中位居首位,但在已采用DevOps的组织中,只有15% 达到了"DevOps大师"级别.调查还发现,"完善的战略和目标"."安全与合规性措施"和"相关IT知识与技能"等9大因素是成功实施DevOps的重要保障,并能够帮助组织将业务增长的可能性提高两倍. 完美实施DevOps的九大因素 这项名为"拼装