本文經授權轉載簡書作者：顧宇

原文：http://www.jianshu.com/p/c6573e63c752

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。

原文作者：顧宇