# 2\.1 DevOps 的起源與定義

**有關 DevOps 的起源**

DevOps 的起源和發展歷程可追溯至 2007 年，當時比利時的一位 IT 顧問 [Patrick Debois](https://twitter.com/patrickdebois?lang=zh-Hant), 他興趣是從各角度研究 IT 組織。在參與為比利時政府的一個大型資料中心遷移的項目提供諮詢，主要負責這次遷移的測試與驗證工作。所以需要跟開發團隊與運維團隊一起協同工作。時常某一天要在開發團隊跟隨敏捷的節奏，過幾天又要以傳統瀑布的形式去逐步維護這些系統。\
看到這兩個團隊的運作方式之間的顯著差異時，兩個團隊在不同的世界裡，但彼此又堅守著各自的利益，所以在這之間工作時到處都是衝突。這促使他開始尋求解決方案。

<圖2-1> 過往組織內開發團隊和 IT 運維團隊之間隔閡與衝突。

**2008 年 8 月** , 在多倫多的 Agile Conference 上，一位開發者 Andrew Shafer 提出一個名為 " **Agile Infrastructure**" 的話題，這是DevOps的早期形式。當時只有 Debois 參加這話題。他倆在走廊裡，就私下的進行漫長的討論。也就是因為有這次對話，之後他倆就決定了在 Google Group 上建立了一個 Agile System Administration 的討論組繼續討論下去。然後兩人決定新開一個部落格來紀錄這些內容跟自己的經驗，於是乎一個名為 [The Agile Admin](https://theagileadmin.com/) 的部落格就此誕生。

2009 年 6 月，Debois 在比利時觀看了 O'Reilly Velocity'09 大會的直播。會中最引人注目的是 John Allspaw 和 Paul Hammond 的演講，主題為 "[Flickr 如何實現每日 10 次以上部署：開發與運維協作](https://youtu.be/LdOe18KhtT4)"。這一方法在當時被視為創新和前衛。他們著重於開發和運維團隊之間的緊密合作，這是快速且可靠部署的關鍵。演講中，他們介紹了大量使用自動化工具和監控系統來支持高頻率部署，並提出了特徵標誌（feature flag）的概念，以便在執行環境中安全測試和部署。此外，他們強調應對故障的重要性，包括避免指責文化和加強團隊間溝通。他們指出，開發和運維團隊間的相互理解、尊重以及共享責任和目標對於支持這種敏捷和協作的工作方式至關重要。

此次演講後來成為許多與 DevOps 相關資料的引用來源。其核心觀點是以業務敏捷為中心，建立快速發佈服務的能力和文化。

在觀看了 Velocity'09 大會的直播後，Debois 深受啟發，相信還有其他人也有類似的想法。他隨即在 Twitter 上詢問如何能參加 Velocity 大會。有人回應他，為何不在比利時舉辦自己的類似會議？受此啟發，Debois 在比利時創辦了自己的研討會，邀請開發（Dev）和運維（Ops）人員共同探討協作方法及基礎設施管理，並重新思考團隊合作方式。最初，他想將會議命名為 DevOpsDays，因為會議持續兩天。但由於當時 Twitter 的字數限制為每條訊息 140 字，為了在每條推文中儘可能包含更多信息，他將標籤 #devopsdays 縮短為 #devops，意外地創造了 “DevOps” 這一詞彙。

<圖2-2> 開發和運維團隊間應相互理解、尊重，緊密合作進而打造出合乎DevOps的文化。

2010 年，隨著第一屆 DevOpsDays 的成功舉辦，DevOps 這一概念開始被廣泛認可，逐漸成為 IT 部門合作的典範。在這一背景下，《The Agile Admin》部落格發表了一篇題為 "[What is DevOps](https://theagileadmin.com/what-is-devops/)" 的文章，深入解釋了 DevOps 的含義。該文將 DevOps 定義為一種促進開發與運維合作的運動，並基於敏捷方法提出了一套完整的 DevOps 體系，涵蓋價值觀、原則、方法、實踐及相關工具。

**DevOps的定義**

[What is DevOps](https://theagileadmin.com/what-is-devops/) 這篇文章就給了我們很好的方向來理解。

> DevOps 是一種實踐，涉及運營和開發工程師共同參與整個服務生命周期，從設計、開發到部署和運營支持。其特點在於運維人員使用與開發人員相同的技術進行系統工作，而開發人員則注重創建適應運營環境的優質程式和架構。

更深入點來看，其實圍繞他的討論含蓋了很多領域，所以它對不同人會有不同的意義︰

1. **價值觀**︰在敏捷宣言中得到了有效的捕捉，關注於持續地向客戶交付完整有價值的服務，來完成客戶的需求，而不僅僅是一個可執行的軟體。並重視團隊間的互動超過流程和工具，呼應了開發團隊與運維團隊的合作重要性。

2. **原則**︰沒有統一標準，但常見的有CAMS，下一個小節會介紹。也有人覺得是IaC（Infrastructure as Code）或各種XX as Code。但Debois則覺得應該要將敏捷的原則擴展到系統和運營上，而不只是程式碼提交的層面上。

3. **方法**︰借鑒敏捷運動的方法，如Scrum，看板等。甚至開發團隊比較常聽到的測試左移、左移可觀測性等策略。

4. **實踐**︰眾所周知的包括CI（持續整合）和CD（持續佈署），甚至是可觀測性工程中常提到的對pipeline進行遙測管理，核對運行環境持續檢測和監控的方案。

5. **工具**︰範圍廣泛，不同領域有不同選擇。工具本身不直接實現 DevOps，但有助於促進相關方法和實踐。

> DevOps常以8字環（或稱為無限循環符號）的形式出現表達，代表了 DevOps 的持續改進和迭代的理念。這個符號強調了開發（Dev）和運營（Ops）之間的緊密合作和無縫整合，以及這種合作如何在整個軟件交付過程中不斷循環和改進。
在 8 字環中，左半部分通常代表開發（Dev），包括規劃、程式碼設計、構建和測試；右半部分代表運營（Ops），包括部署、運行、監控和反饋。

<圖2-3> DevOps的8字環，以及中各階段常見的工具類型。

文章中特別強調了 DevOps 的三個主要實踐領域：

1. **基礎設施自動化（Infrastructure Automation）**：通過自動化提高效率和準確性。

2. **持續交付（Continuous Delivery）**：快速且可靠地將軟件部署到營運環境。

3. **網站可靠性工程（Site Reliability Engineering）**：不僅包括系統的運維、監控和編排，還涉及從一開始就設計出易於測試與操作的系統，本書的後半段重點會著重在此介紹。

這篇文章為 DevOps 的理解和實踐提供了清晰的框架，儘管人們對於 DevOps 的具體定義仍有不同見解，爭議在所難免。

隨著 DevOps 的普及，許多組織紛紛採納了 DevOps 的實踐方法。這一趨勢不僅改變了組織的工作方式，也對就業市場產生了顯著影響。根據 2018 年 LinkedIn 的統計，DevOps 工程師成為了招聘最多的職位之一。雖然 DevOps 定義上是一組能力和文化的實踐，但這一工作模式的迅速普及使得許多工程師開始將自己重新定位為 DevOps 工程師。這一現象反映出市場對 DevOps 專業人才的強烈需求，即使這個職稱並不總是代表著真正的 DevOps 實踐能力。