1.2　DevOps的誕生

1.2.1　DevOps的歷史

所有關于DevOps的故事都會提起一個名字：Patrick Debois。他最早在比利時根特市發起了DevOpsDays活動，被稱為“DevOps之父”。DevOps的歷史也從他開始講起。

沮喪和失望引發的思考

2007年，Patrick Debois受比利時政府部門的委托，協助某部門的一個大型數據中心進行遷移工作，負責認證和驗證測試，因此他需要協調開發（Dev）和運維（Ops）團隊的工作。這顯然不是一份輕松的工作，采用敏捷開發的開發團隊和采用傳統運維模式的運維團隊仿佛生活在兩個世界，不同的工作方式像是一堵墻，這使得在兩個團隊之間來回切換的Patrick非常沮喪和失望，也讓Patrick開始思考是否有方式可以解決這個問題。

第一屆Velocity大會和The Agile Admin博客

2008年，O'Reilly公司在美國加州舊金山舉辦了第一屆Velocity技術大會，討論的主題是“Web應用程序的性能和運維”。大會吸引了來自奧斯汀的幾個系統管理員和開發者，他們對大會分享的內容十分感興趣，并共同開設了一個名為The Agile Admin的博客，以分享敏捷開發在系統管理工作中的應用和實踐。

Agile Conference 2008

2008年8月，敏捷大會（Agile Conference 2008）在加拿大多倫多舉辦，軟件工程師Andrew Shafer提交了一個名為“Agile Infrastructure”的臨時話題，但對這個話題感興趣的人并不多。所以，這個話題開始時僅有一個人出席，就是Patrick。Partrik在這次會議上分享了自己的想法，即“如何在運維工作中應用Scrum（迭代式增量軟件開發過程）和其他敏捷實踐”，十分想把這些經歷進行分享。

最終，Patrick與Andrew進行了一場漫長的討論后，他們意識到，在這次會議之外會有很多的人想繼續探討這個廣泛而又系統化的問題，隨后在谷歌小組（Google Group）上建立了Agile System Administration討論組，來討論這個話題。最初雖然有一些話題和參與者，但是訪問者依舊寥寥無幾。

一個影響深遠的演講

2009年6月，第二屆Velocity大會如期舉行，最大的亮點就是John Allspaw和Paul Hammond分享了一個名為“10+ Deploys Per Day ：Dev and Ops Cooperation at Flickr”的演講。此后，幾乎關于DevOps的資料都會引用這個演講。他們提出的“以業務敏捷為中心，構造適應快速發布軟件的工具（Tools）和文化（Culture）”的觀點非常準確地描述了DevOps的理念，哪怕當時DevOps這個名詞還未誕生。

Patrick也在網上看到了這個演講視頻，在推特（Twitter）上詢問如何才能參加Velocity大會。而Paul直接回復：“嘿，Patrick，你想在比利時召開自己的Velocity嗎？我們都會去參加，這一定會很棒。”

DevOpsDays和DevOps的誕生

于是乎，“社區版Velocity大會”就由Patrick在推特（Twitter）上進行了召集，于同年10月30日在比利時召開。關于會議的名稱，Patrick首先就想到了Dev和Ops，而這個會議持續兩天，所以他加上了“Days”，于是就有了“DevOpsDays”。

這屆大會非常成功，眾多開發和運維工程師、IT管理人員和工具愛好者從世界各地蜂擁而至。兩天的會議結束后，參與DevOpsDays的人們把這次會議的內容帶向了全世界。

在推特（Twitter）上，關于DevOpsDays的討論越來越多。由于推特（Twitter）的140個字符的限制，大家在推特（Twitter）上去掉了DevOps中的Days，保留了DevOps。

于是，“DevOps”這個稱謂正式誕生。

What is DevOps

自DevOpsDays開始，越來越多的人認為DevOps將是IT部門正確的運作方式，而DevOps成為了一種促成開發與運維相結合的運動。各種各樣、不同職責、不同背景的人不斷地在各種場合分享自己關于DevOps的實踐經驗和理解，由此還催生了很多工具和實踐。但隨之而來的是，由于每個人對DevOps的理解不同，關于DevOps而產生的爭議和沖突也越來越多。

于是，The Agile Admin發表了What is DevOps（什么是DevOps）的文章，給出了DevOps的詳細定義，并且依據敏捷的體系構造出了DevOps體系，包括一系列價值觀、原則、方法、實踐和對應的工具，并梳理了DevOps的歷史和對DevOps的一些誤解。

《持續交付》問世

2010年，在第2屆DevOpsDays上，《持續交付》的作者Jez Humble做了關于“持續交付”的演講。針對Patrick和Andrew最初遇到的問題，書中提到的實踐給出了最佳實踐。也有人說，如果《持續交付》早兩年問世，也許就不會出現DevOps。然而，隨著DevOps理念的傳播，DevOps概念的外延越來越廣，已經超出了《持續交付》涵蓋的范疇。

“持續交付”是“持續集成”的延伸，而這恰恰與2008年敏捷大會中的觀念一致。但由于發生時間的先后關系，“持續交付”被看成敏捷開發和DevOps文化的產物。而今，持續交付仍然作為DevOps的核心實踐之一被廣泛談及。

《鳳凰項目》發布

2013年，由Gene Kim、Kevin Behr、George Spafford共同完成的《鳳凰項目》發布，并大受歡迎。這是DevOps的一個標志性事件，因為它以小說的形式向讀者介紹了DevOps的理念。故事講述了一個虛構的IT經理Bill Palmer臨危受命，在未來董事的幫助和自己“三步工作法”理念的支撐下，最終挽救了一家具有悠久歷史的汽車配件制造商的故事。

DevOps從小眾走向主流

2016年，Garter預測DevOps將從小眾戰略過渡到主流戰略。當年，全球2000強企業中有四分之一的企業采用了DevOps戰略。

DevOps之年和中國DevOps元年

Forester Research稱2017年為“DevOps之年”，同時報告說，有高達50％的組織正在實施DevOps。同年，DevOpsDay Beijing成功舉辦，2017年成為“中國DevOps元年”。

DevOpsDay在中國

2018年，北京、上海、深圳成功舉辦了DevOpsDay；同年，美國安排了30余場DevOpsDay活動。DevOps的理念在全球迅速推廣，其中不斷有基礎設施團隊和運維團隊提出了更多有關DevOps的倡議，越來越多的組織和企業開始采用DevOps。

【小結】通過DevOps的歷史可以看到，DevOps誕生至今依舊保持著非常旺盛的生命力，依舊有眾多的企業和工程師基于自己的實踐經驗不斷提出不同的倡議，從而解決開發（Dev）與運維（Ops）之間的矛盾。

1.2.2　DevOps的優勢

DevOps的優勢很大程度體現在組織層面的協作和溝通上，實踐DevOps的團隊可以更快、更好地工作，簡化事件響應，并改善團隊之間的協作和溝通。

1.速度

DevOps高速運轉，可以更快速地針對用戶進行創新、更好地適應不斷變化的市場，同時更有效地推動業務成果。DevOps模式能夠幫助開發人員和運維團隊實現這些目標。例如，微服務和持續交付能夠讓團隊充分掌控服務，然后更快速地發布更新。

2.快速交付

DevOps提高了發布的頻率和速度，以便更快速地進行創新并完善產品。發布新功能和修復錯誤的速度越快，就越能快速地響應用戶需求并建立競爭優勢。持續集成和持續交付是自動執行軟件發布流程（從構建到部署）的兩項實踐經驗。

3.可靠性

DevOps確保應用程序更新和基礎設施變更的品質，以便在保持最終用戶優質體驗的同時，更加快速、可靠地進行交付；使用持續集成和持續交付等實踐經驗來測試每次變更是否安全，以及能夠正常運行；監控和日志記錄實踐經驗能夠幫助實時了解當前的性能。

4.規模

DevOps可以用于大規模運行、管理軟件的基礎設施及開發流程；自動化和一致性可在降低風險的同時，有效管理復雜或不斷變化的系統。例如，“基礎設施即代碼”有助于通過一種可重復且更有效的方式來管理部署、測試和生產環境。

5.增強合作

建立一個適應DevOps文化模式的更高效的團隊，強調主人翁精神和責任感。開發人員和運維團隊密切合作，共同承擔諸多責任，并將各自的工作流程相互融合。這有助于提升效率、節約時間（例如，縮短開發人員和運維團隊之間的交接時間，編寫將運行環境考慮在內的代碼）。

6.安全性

在快速運轉的同時保持控制力和合規性。利用自動實施的合規性策略、精細控制和配置管理技術，可以在不犧牲安全性的前提下采用DevOps模式。例如，“基礎設施即代碼”和“策略即代碼”可以大規模定義并追蹤合規性。

【小結】DevOps更多強調人與人、開發與運維之間的通力合作，共同探索出一條符合自己團隊安全、高效的DevOps模式。團隊在進行DevOps轉型時需要把握核心目標，切勿照本宣科，不要為了實現DevOps而做DevOps。