DevOps的那些事儿——DevOps的前世今生

ServiceHot 旗下现产品有，ServiceHot ITSOM(IT服务运营管理平台)、ServiceHot ITSM(IT服务管理)、ServiceHot云宝箱，以及ServiceHot IT学院！欢迎登陆www.itsmcn.com 注册试用！

今天小编再给大家普及一下关于DevOps的知识~

顺便悄悄告诉大家： ServiceHot IT学院9月DevOps Master个人资格认证培训课程开始报名啦！

我们先来了解一下DevOps的前世今生吧：

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 上继续着。由于 Twitter 140个字符的限制，大家在 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的“前世今生”，DevOps发展至今，可以说还没有形成标准。所以，关于DevOps的说法也是各种各样。这样，对于想了解DevOps的人来说，就会产生较大的困惑。

DevOps的不同理解

我们从互联网上收集了10个DevOps的定义并专家的一些点评，希望能对要了解DevOps的人有所帮助~

1、DevOps=自动化运维（道听途说）

专家点评：这个定义太简单了，虽然我们经常听到这个说法（特别是做运维管理的人），但它真的不准确。

2、DevOps就是开发（Development）和运维（Operations）这两个领域的合并。（来自互联网）

专家点评：这个说法比较绝对，也比较片面，实践中也不太可行。

3、DevOps旨在将不同的社区，比如开发和运维社区，联合起来变成一个更有效率的整体。(来自《DevOps实践—驭DevOps之力强化技术栈并优化IT运行》一书）

专家点评：这个说法比上一种说法有了一点进步，但还是没有跳出开发和运维整合的圈子。

4、DevOps就是使用一些自动化工具解决开发人员、QA、运维人员之间那些磨磨叽叽的事。（来自简书）

专家点评：这个答案与前两个相比已经有了较大的进步，因为它提到了开发、QA和运维三方，还提到了自动化工具。但只靠自动化工具去解决“那些磨磨唧唧的事”，层次就有点低了，而且效果也不会很好。

5、DevOps是一套最佳实践方法论，旨在在应用和服务的生命周期中促进IT专业人员(开发人员、运维人员和支持人员)之间的协作和交流，最终实现：持续集成、持续部署、持续反馈。（来自知乎）

专家点评：这个定义一看就是熟悉ITIL的人写的，因为里面提到了最佳实践、生命周期等概念。定义中提到了协作和交流，但开发人员、运维人员和支持人员这个三方的说法有点不妥，运维和支持应该属于一类，缺了QA人员。

6、DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。（来自互联网）

专家点评：这个定义比较简洁，提到了文化、交流和协作、更快、质量更好、运动等关键词。但没有提到开发、QA和运维这三方，稍有遗憾。

7、DevOps一词的来自于Development和Operations的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。（来自InfoQ）

专家点评：这个定义其实我已经挑不出什么毛病，如果“沟通合作”的人员中加入QA人员就更好了。

8、DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。（来自维基百科）

专家点评：这个定义也很专业，基本上无懈可击。

9、DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。（来自百度百科）

专家点评：这个定义与上一个一样，也很完美。

10、DevOps是一组方法、过程与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。这种协作可以提高应用的开发速度，减少开发和运营之间的摩擦，从而快速部署软件或应用程序，并且可以快速检测。（对上面多个定义整合的结果）

专家点评：这是我最喜欢的DevOps定义，它的表达很准确，也很全面。

关于ServiceHot IT学院

ServiceHot IT 学院 DevOps金牌讲师：许峰



ServiceHot IT 学院 DevOps金牌讲师：刘征