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。

原创：顾宇

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。

原创：顾宇