你應該知道的DevOps

https://kb.cnblogs.com/page/567947/

最近我閱讀了很多有關DevOps的文章，其中一些非常有趣，然而一些内容也很欠考慮。貌似很多人越來越堅定地在DevOps與

chef

、

puppet

或Docker容器的熟練運用方面劃了等号。對此我有不同看法。DevOps的範疇遠遠超過puppet或Docker等工具。

　　這樣的看法甚至讓我感覺有些氣憤。DevOps在我看來極為重要，過去15年來，我一直在大型機構，主要是大型金融機構中從事工程業務。DevOps是一種非常重要的方法論，該方法将解決一些最大型問題的基本原則和實踐恰如其分地融為一體，很好地解決了此類機構的軟體開發項目中一種最令人感覺悲涼的失敗要素：開發者和運維人員之間的混亂之牆。

　　請不要誤會我的這種觀點，除了某些XP實踐，大部分此類大型機構對靈活開發方法論的運用還有很長的路要走，同時還有很多其他原因會導緻軟體開發項目的失敗或延誤。

　　但在我看來，混亂之牆目前依然是他們所面臨的最令人沮喪、最浪費時間、同時也相當愚蠢的問題。

　　與其獨自生悶氣，我覺得不如說點更實在的東西，寫一篇盡可能精準的文章，向大家介紹DevOps到底是什麼，能為我們帶來什麼。長話短說，DevOps并不是某一套工具。DevOps是一種方法論，其中包含一系列基本原則和實踐，僅此而已。而所用的工具（或者說“工具鍊”吧，畢竟用于為這些實踐提供支援的工具集有着極高的擴充性）隻是為了對這樣的實踐提供支援。

　　最終來說，這些工具本身并不重要。相比兩年前，目前的DevOps工具鍊已經産生了翻天覆地的變化，可想而知，兩年後還會産生更大的差異。不過這并不重要。重要的是能夠合理地了解這些基本原則和實踐。

　　本文并不準備介紹某些工具鍊，甚至完全不會提到這些工具。網上讨論DevOps工具鍊的文章已經太多了。我想在本文中談談最基本的原則和實踐，它們的主要目的，畢竟這些才是對我而言最重要的。

　　DevOps是一種方法論，歸納總結了面臨獨一無二的機遇和強有力需求的網絡巨頭們，結合自身業務本質構思出全新工作方式的過程中所采用的實踐，而他們的業務需求也很直接：以史無前例的節奏對自己的系統進行演進，有時候可能還需要以天為機關對系統或業務進行擴充。

　　雖然DevOps對初創公司來說很明顯是不可或缺的，但我認為那些有着龐大的老式IT部門的大企業才是能從這些基本原則和實踐中獲得最大收益的。本文将試圖解釋得出這個結論的原因和實作方法。

　　本文的部分内容已釋出為Slideshare示範幻燈片，可在這裡浏覽：http://www.slideshare.net/JrmeKehrli/devops-explained-72091158

　　1. 簡介

　　DevOps所關注的不是工具本身，也不是對chef或Docker的掌握程度。DevOps是一種方法論，是一系列可以幫助開發者和運維人員在實作各自目标（Goal）的前提下，向自己的客戶或使用者傳遞最大化價值及最高品質成果的基本原則和實踐。

　　開發者和運維人員之間最大的問題在于：雖然都是企業中大型IT部門不可或缺的，但他們有着截然不同的目的（Objective）。

　　開發者和運維人員之間目的上的差異就叫做混亂之牆。下文會介紹這個概念的準确定義，以及為什麼我認為這種狀況很嚴峻并且很糟糕。

　　DevOps是一種融合了一系列基本原則和實踐的方法論（并從這些實踐中派生出了各種工具），意在幫助這些人員向着一個統一的共同目的努力：盡可能為公司提供更多價值。

　　令人驚奇的是，這個問題竟然有一個非常簡單的“銀子彈”：讓生産端變得靈活起來！

　　而這恰恰正是DevOps所要達成的唯一目标！

　　但在進一步讨論這一點之前，首先需要談談其他幾件事。

　　1.1 管理信條

　　IT管理這場戰争的原動力到底是什麼？換句話說，在軟體開發項目中，管理工作首要的，以及最重要的目的是什麼？

　　有什麼想法嗎？

　　我來提供一個線索吧：在建立一家初創公司時，最重要的事情是什麼？

　　當然是要加快上市時間（TTM）！

　　上市時間（即TTM）是指一件産品從最初的構思到最終可供使用者使用或購買這一過程所需要的時間。對于産品很快會過時的行業，TTM是一個非常重要的概念。

　　在軟體工程方面，所采用的方法、業務，以及具體技術幾乎每年都會變化，因而TTM就成了一個非常重要的KPI（關鍵績效名額）。

　　TTM通常也會被叫做前置時間（Lead Time）。

　　第一個問題在于，（很多人認為）在開發過程中TTM和産品品質是兩個對立的屬性。在下文可以看到，改善品質（進而提高穩定性）是運維人員的目的，而開發者的目的在于降低前置時間（進而提高TTM）。

　　請容我來解釋一下。

　　IT組織或部門通常會通過兩個關鍵的KPI進行評估：軟體本身的品質，因而需要盡可能減少缺陷的數量；此外還有TTM，因而需要将業務構想（通常由業務使用者提供）變為最終成果，并以盡可能快的速度提供給使用者或客戶。

　　這裡的問題在于，大部分情況下這兩個截然不同的目的是由兩個不同團隊提供支援的：負責建構軟體的開發者，以及負責運作軟體的運維人員。

　　1.2 一個典型的IT組織

　　在組織内部負責管理重要IT部門的典型IT組織通常看起來是這樣的：

　　主要由于曆史的原因（大部分運維人員來自硬體和電信業務領域），運維人員和開發者分屬不同的組織結構分支。開發者屬于研發部門，而運維人員大部分時候屬于基礎架構部門（或專門的運維部門）。

　　别忘了，他們有着不同的目的：

　　此外作為旁注，這兩個團隊有時候會使用不同的預算來營運。開發團隊使用建構（Build）預算，運維團隊使用營運（Run）預算。不同的預算，對控制權越來越高的需求，以及企業IT成本的縮水，這些因素結合在一起會進一步放大兩個團隊各自目的的對立性。

　　（依本人愚見，時至今日，随着人與人之間無時無刻随時随地進行的互動，以及由不同目的推動着企業和社會進行數字化轉型，IT預算方面古老的“規劃/建構/運作”架構已經不那麼合理了，不過這又是另一回事了。）

　　1.3 運維人員測挫敗感

　　接下來看看運維人員，一起看看典型的運維團隊把大部分時間都花在哪裡了：

（來源：Study from Deepak Patil [Microsoft Global Foundation Services] in 2006, via James Hamilton [Amazon Web Services]

　　生産團隊有将近一半（47%）的時間花在了與部署有關的工作中：

• 執行實際的部署工作，或
• 修複與部署工作有關的問題

　　這樣的KPI其實相當瘋狂，但實際上我們早就應該采納。實際上早在40年前，計算機科學的“原始時代”就已湧現出運維團隊，當時計算機主要運用在工業界，運維人員需要手工運作大量指令來執行自己的任務。為了履行職責，他們已經習慣于按照清單運作各種各樣的指令或手工流程。

　　突然有一天他們終于意識到自己“總在做着相同的事情”，然而長達四十多年的工作過程中卻幾乎沒人考慮過變革。

　　考慮到這一點你會發現，實在是太瘋狂了。平均來說，運維人員将近一半的時間都在處理與部署有關的任務！

　　為了改變這種狀況，必須考慮到兩個最關鍵的需求：

1. 通過自動化部署将目前這種手工任務所需的時間減少31%。
2. 通過産業化措施（類似于通過XP和靈活實作的軟體開發産業化）将需要處理的與這些部署有關的問題減少16%。

　　1.4 基礎架構自動化

　　在這方面也有一個相當富有啟發性的統計結果：

　　以手工操作的數量所表示的成功部署機率。

　　這些統計告訴我們：

• 隻需手工運作5條指令的情況下，成功部署的機率就已跌至86%。
• 如需手工運作55條指令，成功部署的機率将跌至22%。
• 如需手工運作100條指令，成功部署的機率将趨近于0（僅2%）！

　　成功部署意味着軟體能夠按照預期在生産環境中運作。未能成功部署意味着有東西出錯，可能需要進行必要的分析才能了解部署過程中哪裡出錯，是否需要應用某種更新檔，或需要修改某些配置。

　　是以讓這一切實作自動化并不惜一切代價避免手工操作似乎是個好主意，對吧？

　　那麼行業裡這方面的現狀是怎樣的：

（來源：IT Ops & DevOps Productivity Report 2013 - Rebellabs ）

　　（說實話，這個統計資訊比較老了，是2013年的結果，相信現在的結果會有所不同）

　　然而這也可以讓我們明确的知道，在基礎架構自動化方面我們還有多遠的路要走，并且DevOps的基本原則和實踐依然是那麼的重要。

　　網絡巨頭們當然會通過新的方法和實踐及時滿足自己的需求，他們早已開始建構自己的工程業務，而正是他們所确立的實踐逐漸衍生出當今我們所熟悉的DevOps。

　　看看這些網絡巨頭們在這方面目前所處的位置吧，舉幾個例子：

• Facebook有數千名開發和運維人員，成千上萬台伺服器。平均來說一位運維人員負責500台伺服器（還認為自動化是可選的嗎？）他們每天部署兩次（環式部署，Deployment ring的概念）。
• Flickr每天部署10次。
• Netflix明确針對失敗進行各種設計！他們的軟體按照設計從最底層即可容忍系統失敗，他們會在生産環境中進行全面的測試：每天通過随機關閉虛拟機的方式在生産環境中執行65000次失敗測試…… 并確定這種情況下一切依然可以正常工作。

　　他們這種做法秘密何在？

　　1.5 DevOps：僅此一次，一顆神奇的銀子彈

　　他們的秘密很簡單：将靈活擴充至生産端：

　　DevOps的共存主要是為了擴充靈活開發實踐，進一步完善軟體變更在建構、驗證、部署、傳遞等階段中的流動，同時通過軟體應用程式的全面所有權予力跨職能團隊完成從設計到生産支援等各環節的工作。

　　DevOps鼓勵軟體開發者和IT運維人員之間所進行的溝通、協作、內建和自動化，借此有助于改善雙方在傳遞軟體過程中的速度和品質。

　　DevOps團隊更側重于通過标準化開發環境和自動化傳遞流程改善傳遞工作的可預測性、效率、安全性，以及可維護性。理想情況下，DevOps可以為開發者提供更可控的生産環境，幫助他們更好地了解生産基礎架構。

　　DevOps鼓勵團隊自主進行自己應用程式的建構、驗證、傳遞和支援。

　　那麼核心原則到底是什麼？

　　下文将介紹最重要的三大基本原則。

　　2. 基礎架構即代碼

　　人總會犯錯，因為人腦實在是不擅長處理重複性的任務，相比Shell腳本，人類的速度實在是太慢了。畢竟我們都是人類，是以有必要像處理代碼那樣考慮和處理有關基礎架構的概念！

　　基礎架構即代碼（IaC）是大部分通用DevOps實踐的前提要求，例如版本控制、代碼審閱、持續內建、自動化測試。這一概念涉及計算基礎架構（容器、虛拟機、實體機、軟體安裝等）的管理和供應，以及通過機器可處理的定義檔案或腳本對其進行的配置，互動式配置工具和手工指令的使用已經不合時宜了。

　　這一原則對DevOps的重要性怎麼強調都不為過，它可以真正将軟體開發相關的實踐應用給伺服器和基礎架構。

　　雲計算使得複雜的IT部署可以繼續效仿傳統實體拓撲。我們可以相對輕松地對複雜虛拟網絡、存儲和伺服器的建構實作自動化。伺服器環境的方方面面，上至基礎架構下至作業系統設定，均可編碼并存儲至版本控制倉庫。

　　2.1 概述

　　以非常概括的方式來看，基礎架構和運維所需實作的自動化程度可通過下圖這種架構來表示：

　　上述架構圖中作為示例的工具主要面向不同層的建構工作，實際上DevOps工具鍊的作用遠不止如此。

　　我覺得在這裡可以略微深入地談談DevOps的工具鍊了。

　　2.2 DevOps工具鍊

　　DevOps實際是一種文化上的變遷，代表了開發、運維、測試等環節之間的協作，是以DevOps工具是非常多種多樣的，甚至可以由多種工具組成一個完整的DevOps工具鍊。此類工具可以應用于一種或多種類别，并可展現出軟體開發和傳遞過程的不同階段：

• 編碼：代碼開發和審閱，版本控制工具、代碼合并工具
• 建構：持續內建工具、建構狀态統計工具
• 測試：通過測試和結果确定績效的工具
• 打包：成品倉庫、應用程式部署前暫存
• 釋出：變更管理、釋出審批、釋出自動化
• 配置：基礎架構配置和部署，基礎架構即代碼工具
• 監視：應用程式性能監視、最終使用者體驗

　　雖然可用工具有很多，但其中一些環節是組織内部應用DevOps工具鍊不可或缺的。

　　諸如Docker（容器化）、Jenkins（持續內建）、Puppet（基礎架構建構）、Vagrant（虛拟化平台）等常用、廣泛使用的工具都是2016年的DevOps熱門工具。

　　基礎架構元件的版本控制、持續內建和自動化測試

　　基礎架構的版本控制能力（而非基礎架構的建構腳本或配置檔案）及對其進行自動化測試的能力極其重要。

　　DevOps最終會将30年前軟體工程領域所采用的同一套XP實踐帶至生産端。

　　此外基礎架構元素應該能向軟體傳遞物一樣進行持續內建。

　　2.3 收益

　　DevOps的收益有很多，包括但不限于：

• 可重複性與可靠性：時至今日，建構生産用計算機隻需要運作腳本或必要的puppet指令即可。通過恰當地使用Docker容器或Vagrant虛拟機，隻需運作一條指令即可配置好包含作業系統層以及所需軟體和配置的生産用計算機。當然，随着各種變更或軟體開發、持續內建，并自動測試，這套建構腳本或機制也會進行持續內建。

  最終幸虧有了XP或靈活，我們在軟體開發端所使用的同一套實踐也能讓運維端獲益。

• 生産力：一鍵部署，一鍵供應，一鍵建立新環境……整個生産環境可以通過一條指令或一鍵點選的方式建立。這樣的一條指令也許會運作長達數小時，但在這過程中運維人員可以從事其他更有趣的工作，而無需等待一條指令執行完畢後繼續輸入下一條指令，畢竟這樣的過程有時候可能需要花費幾天時間才能完成……
• 恢複時間！：一鍵點選即可恢複生産環境，就是這麼簡單。
• 確定基礎架構的同質：徹底避免運維人員每次建構環境或安裝軟體時最終獲得的結果與預期有所差異，這是確定基礎架構絕對同質（Homogeneous）并且可再現的唯一可行方法。以此為基礎，通過對腳本或Puppet配置檔案使用版本控制機制，我們甚至可以重建出與上周、上個月，或軟體特定版本釋出時完全一緻的生産環境。
• 維持整齊劃一的标準：基礎架構标準甚至可以不複存在，代碼本身就是标準。
• 讓開發者自行完成大部分工作：如果開發者自己突然可以在自己的基礎架構上一鍵點選重建生産環境，他們也就可以自行完成很多與生産環境有關的任務，例如更好地了解生産失敗，提供更恰當的配置，實作部署腳本等。

　　這隻是我個人感覺IaC可提供的部分收益，相信還有很多其他收益。

　　3. 持續傳遞

　　持續傳遞是一種可以幫助團隊以更短的周期傳遞軟體的方法，該方法確定了團隊可以在任何時間釋出出可靠的軟體。該方法意在以更快速度更高頻率進行軟體的建構、測試和釋出。

　　通過對生産環境中的應用程式進行更高頻次的增量更新，這種方法有助于降低傳遞變更過程中涉及的成本、時間和風險。足夠簡單直接并且可重複的部署流程對持續傳遞而言至關重要。

　　注意：持續傳遞 ≠ 持續部署 - 有時候很多人會把持續傳遞誤認為成持續部署。持續部署是指每個變更可以自動部署到生産環境。持續傳遞是指團隊確定每個變更可以部署至生産環境，但也許并不需要實際部署，這通常可能是出于業務方面的原因。隻有成功實作持續傳遞的前提下，才能進行持續部署。

　　持續傳遞的主要想法在于：

• 部署越頻繁，對部署流程就會越熟悉，自動化機制就能獲得更好的結果。如果同一件事每天需要執行3次，很快你将變的無比娴熟，但很快也會因為日複一日解決同樣的問題而感到厭煩。
• 部署越頻繁，所部屬的變更集就越微不足道，而這些微不足道的内容最有可能出錯，甚至可能導緻丢失對整個變更集的控制力。
• 部署越頻繁，TTR（修複／解決所需時間）名額就會越出色，從業務使用者處獲得有關功能的各類回報的速度越快，作出改進以便完美滿足對方需求的過程也會越簡單（這方面TTR與TTM其實非常相似）。

（來源：Ops Meta-Metrics: The Currency You Pay For Change ）

　　但持續傳遞并不僅僅是盡可能頻繁地建構可釋出、生産就緒版本的軟體産品那麼簡單。持續傳遞包含3個關鍵實踐：

• 從實踐中學習
• 自動化
• 更頻繁的部署

　　3.1 從實踐中學習

　　持續傳遞的關鍵在于要能從實踐中學習。真理并不存在于開發團隊中，而在于業務使用者中。然而無論花多長時間，沒人能真正清楚地表達自己的想法，或者将自己的想法用清晰的文檔概括出來。也正是是以，靈活方法論強調将功能提供給使用者，并不惜一切代價從使用者處獲得盡可能多的回報。

　　持續傳遞與持續部署類似，需要盡可能減少前置時間，這也是盡快從使用者處獲得“真理”的關鍵。

　　但真理絕對不會來自正規形式的使用者回報。我們絕不能盡信自己的使用者或寄希望于通過正規形式的回報了解使用者。我們隻能相信自己的度量。

　　癡迷于度量是精益創業（Lean Startup）活動中一個重要的概念，但這一概念對DevOps同樣重要。我們應該度量一切！确定最恰當的度量名額可以讓團隊了解某種方法最終能否成功或失敗，了解怎樣做可以獲得更好的結果，以及哪些最成功的做法同時也蘊含着一定的風險。為了幫助團隊做出更明智的決策，在确定要衡量的名額時，一定要抱着“甯多勿少”的原則。

　　不需要“考慮”，隻需要“知道”！“知道”的唯一方法就是度量，度量一切：響應時間、使用者思考時間、展示次數、API調用次數、點選率等，但這些并非需要度量的全部。找出所有能讓你更進一步了解使用者對功能看法的度量名額，對所有這些名額進行度量！

　　這種方法可以表示為如下形式：

　　3.2 自動化

　　自動化已經在上文

2. 基礎架構即代碼

一節進行了讨論。

　　在這裡我想強調的是，在沒有将與基礎架構有關的所有供應和任務實作妥善、全面的自動化之前，持續傳遞根本無從談起。

　　這一點很重要，是以有必要再重複一遍：環境的搭建和生産就緒版本軟體的部署隻需要一鍵點選，隻需要運作一條指令，整個過程應該自動完成。否則根本無法設想能一天多次部署同一個軟體。

　　在下文的

3.5 零停機部署

一節中，還将介紹有助于自動化傳遞的其他重要技術。

　　3.3 更頻繁的部署

　　DevOps的信條在于：

　　“越是困難的事，需要更頻繁地進行！”

　　靈活思維中，困難任務更要迎難而上，更頻繁地去做，這中想法非常重要。

　　自動化測試、重構、資料庫遷移、面向客戶的産品規格、規劃、釋出 - 所有這些活動都要盡可能頻繁地進行。

　　原因主要有三點：

1. 首先，随着要做的工作量逐漸增加，這些任務也會變的愈加困難，但如果能拆解為小塊，則會變的相對容易些。

   以資料庫遷移為例：一些涉及大量表的大規模資料庫遷移工作很麻煩，容易出錯。但如果一次隻遷移一部分，則可以相對較容易地成功完成整個遷移任務。此外還可以輕松地将多個小規模的遷移任務安排成一定的序列，在将一個艱難的大任務拆解為一系列容易實作的小目标後，處理起來就簡單多了。（這也是資料庫重構的本質）

2. 第二個原因在于回報。大部分靈活思維關注的是設定回報環路，借此讓我們更快速地學習了解。回報已經是極限程式設計（Extreme Programming）中一個非常重要，蘊含巨大價值的概念。在諸如軟體開發等複雜流程中，我們需要更頻繁地檢查自己的最新進展，并進行必要的糾正。為此我們必須盡一切可能建立回報環路，并提高回報的頻率，這樣才能更快速地酌情做出調整。

3. 第三個原因是實踐。對于任何活動，越頻繁地從事就越能獲得完善。實踐可以幫助我們理清整個流程，讓我們更熟悉代表有事情出錯的征兆。隻要認真琢磨自己從事的工作，就能提煉出近一步完善所需的實踐。

   對于軟體開發，也有可能實作一定程度的自動化。一旦有人将某件事做了多次，就可以更容易地确定該如何進行自動化，更重要的是，這樣的人在對這些事情實作自動化方面将有更大的動機。此時自動化尤為重要，因為可以加快速度并降低出錯的機率。

　　那麼這就産生了一個問題：使用DevOps方法時，該選擇怎樣的傳遞頻率？

　　這個問題沒有标準答案，而是取決于産品、團隊、市場、公司、使用者、運維需求等各種因素。

　　我認為最佳答案應該是：如果不能實作至少每兩周一次傳遞，或在沖刺階段結束時傳遞，那麼連靈活都談不上，DevOps又從何談起呢？

　　DevOps鼓勵我們盡可能頻繁的傳遞。在我看來，你需要對團隊進行教育訓練，讓他們能夠做到盡可能頻繁的傳遞。我在我的團隊中使用的一種較為可行的方法是在QA環境中每天傳遞兩次。傳遞過程是完全自動化的：每天兩次，中午和午夜各一次，計算機啟動起來，建構軟體元件，運作內建測試，建構并啟動虛拟機，部署軟體元件，對其進行配置，運作功能測試等。

　　3.4 持續傳遞的前提需求

　　在改為使用持續傳遞方式之前，需要滿足哪些要求？

　　我草拟的需求清單如下：

• 對軟體元件的開發和平台的供應和設定進行持續內建。
• TDD - 測試驅動的開發。這一點還有待商榷……但始終還是需要面對：TDD是目前唯一能通過單元測試對代碼和分支進行可接受程度覆寫的方法（單元測試使得問題的修複過程比內建測試或功能測試容易很多）。
• 代碼審閱！至少要進行代碼審閱……如果能進行結對程式設計（Pair programming）當然就更好了。
• 軟體的持續審計 - 例如使用Sonar。
• 在生産級環境實作功能測試的自動化。
• 更強大的非功能測試自動化（性能、可用性等）。
• 獨立于目标環境的自動化打包和部署。

　　另外在管理重大功能和演進時，還需要具備健全的軟體開發實踐，例如零停機部署技術。

　　3.5 零停機部署

　　“零停機部署（ZDD）可在不中斷現有服務的情況下部署新版系統。”

　　通過ZDD方式部署應用程式時，可在確定使用者不會遭遇應用程式停機的前提下将新版應用引入生産環境。從使用者和公司的角度來看，這應該是最佳部署方式，因為可以在不造成任何中斷的情況下引入新功能并修複Bug。

　　下文将介紹4種技術：

1. 功能開關（Feature Flipping）
2. 摸黑啟動（Dark launch）
3. 藍／綠部署（Blue/Green Deployment）
4. 金絲雀釋出（Canari release）

　　功能開關

　　功能開關可供我們在軟體運作過程中啟用／禁用相應的功能。這種技術其實非常容易了解和使用：為生産版本提供一個能徹底禁用某項功能的配置，并隻在對應功能徹底完工可以正常工作後才将該屬性激活。

　　舉例來說，若要将某個應用程式内的一個功能全局禁用或激活：

if Feature.isEnabled('new_awesome_feature')    # Do something new, cool and awesomeelse     # Do old, same as always stuffend      

　　或者如果要真對具體使用者實作類似目的：

if Feature.isEnabled('new_awesome_feature', current_user)    # Do something new, cool and awesomeelse     # Do old, same as always stuffend       

　　摸黑啟動

　　摸黑啟動的目的在于通過生産環境進行負載模拟！

　　在測試環境中，通常很難為軟體模拟出成百上千萬使用者規模的負載。

　　如果不進行切實的負載測試，就無法知道基礎架構能否承受住最終面臨的壓力。

　　此時并不需要模拟負載，而是可以實際部署這樣的功能，然後看看在不影響可用性的前提下到底會發生什麼。

　　Facebook将這種做法稱之為功能的“摸黑啟動”。

　　假設我們要将一個有5億使用者使用的靜态搜尋字段變成一個包含自動補全功能的字段，借此讓使用者可以更快速獲得搜尋結果。為該功能建構一個Web服務，并且希望模拟所有使用者同時輸入文字，向該Web服務生成大量請求的場景。

　　此時即可通過摸黑啟動政策為現有表單添加一個隐藏的背景程序，通過該程序将輸入的搜尋關鍵字發送給新增的自動補全服務，并自動發送多次。

　　就算新增的Web服務徹底崩潰了，也不會造成任何實質損害。網頁上可以完全忽略伺服器錯誤。而就算該服務崩潰了，我們至少還可以對該服務進行優化和完善，直到能承受如此大量的負載。

　　這就等于在現實世界中進行了一次負載測試。

　　藍／綠部署

　　藍／綠部署是指為下一版産品建構另一個完整的生産環境。開發和運維團隊可以在這個單獨的生産環境中放心地建構下一版産品。

　　當下一版産品全部完成後，可以修改負載均衡器的配置，以透明的方式将使用者自動重定向至新釋出的下一版。

　　随後可将上一版的生産環境回收，用于建構下下一版的産品。

　　以此類推。

（來源：Les Patterns des Géants du Web – Zero Downtime Deployment ）

　　這是一種相當有效簡單的方法，但問題在于這種方式需要雙倍的基礎架構以及更多的伺服器等。

　　假設一下Facebook希望将包含成千上萬台伺服器的環境“照原樣再來一套”……

　　其實還有更好的方法。

　　金絲雀釋出

　　從本質來看，金絲雀釋出與藍／綠部署非常類似，但無需準備額外的一套生産環境。

　　這種方式的目标在于以增量的方式将使用者切換至新版本：随着越來越多的伺服器從目前版本遷移至下一版，相同比例的使用者也會被同時遷移。

　　通過這種方式，每個生産環境都能獲得與負載需求相比對的伺服器數量。

　　首先，隻将少量伺服器和少部分使用者遷移至下一版，借此還可以在無須冒險影響所有使用者的前提下對新版進行測試。

　　當所有伺服器最終從目前版遷移至下一版後，釋出工作已經完成，又可以從頭開始準備下下一版了。

（來源：Les Patterns des Géants du Web – Zero Downtime Deployment ）

　　4. 協作

　　靈活軟體開發破除了需求分析、測試和開發之間的一些隔閡。部署、運維和維護等其他活動與軟體開發過程中的其他環節也存在類似的分隔。DevOps方法意在破除所有這些隔閡，鼓勵開發和運維人員之間的協作。

　　如果沒有培養出正确的文化，就算有最棒的工具，DevOps對你而言也不過是另一個熱門詞彙罷了。

　　DevOps文化的主要特征在于開發和運維角色之間日益增加的協作。這是一種在團隊内部以及組織層面上很重要的文化變遷，通過這樣的變遷才能促進更好的協作。

　　這種方式解決了一個非常重要的問題，而這個問題完全可以用下面這個網絡流行話來展現：

（來源：DevOps Memes @ EMCworld 2015 ）

　　團隊合作對DevOps是如此的重要，大部分方法論所要實作的最終目标總的來說可以通過兩個C來實作：協作（Collaboration）和溝通（Communication）。雖然單純做到這些距離真正的DevOps工作環境還有很大的差距，但任何公司隻要能堅持這兩個C，就等于邁出了最正确的第一步。

　　但為什麼會那麼難做到？

　　4.1 混亂之牆

　　因為有一堵混亂之牆：

　　在傳統開發周期中，開發團隊将新釋出的軟體“隔牆扔給”運維人員，意味着自己的工作已經順利完成。

　　運維人員接手開發者的成果，準備開始進行部署。運維人員手工修改由開發者提供的部署腳本，當然更多時候這些腳本都是運維人員自己維護的。

　　運維人員還需要手工修改配置檔案，以反映生産環境的需求，而生産環境往往與開發或QA環境有很大差異。

　　就算最理想的情況，運維人員可能隻是做了一些在上一個環境中已經做過的重複工作，而最糟糕的情況，可能會引入或發現新的Bug。

　　随後IT運維團隊開始讨論他們所認為的，目前最正确的部署流程，然而由于開發和運維在腳本、配置、流程，甚至環境等方面的差異，基本上等同于要從零開始将所有工作重新執行一遍。

　　當然這一過程中不可避免會遇到問題，他們聯系開發者希望進行排錯。運維稱開發者提供的代碼本身有問題，開發者則回應稱代碼在自己的環境中一切正常，是以錯誤肯定源自運維端。

　　由于配置、檔案位置，以及面臨這種狀态所執行的操作與自己的預期等因素存在較大差異，開發者甚至很難對這樣的問題進行診斷。變更視窗留下的時間所剩無幾，當然也沒什麼足夠靠譜的方法将環境復原至上一個正常狀态。

　　那麼原本應該一帆風順的部署過程，為什麼最後卻變成了“衆志成城”的應急演習？必須經曆大量指責和錯誤才能最終讓生産環境恢複可用狀态？

　　這種情況經常發生，經常！

　　DevOps來救場了

　　通過在共同的業務目的情境中讓開發和運維角色與流程變的一緻，DevOps有助于促進IT的統一。開發和運維都需要明确，自己是統一業務流程的一份子。DevOps思維確定了無論組織結構是怎樣的，個體決策與行為需要盡力為統一的業務流程提供支援和促進作用。

　　亞馬遜CTOWerner Vogel甚至在2014年說過：

　　“誰開發，誰運作。”

　　4.2 軟體開發流程

　　下圖簡要描述了靈活軟體開發流程通常的樣子。

　　最開始，業務代表與産品負責人以及架構團隊合作定義軟體，這一過程可能會使用Story Mapping和使用者故事，或者使用更完整的規範。

　　随後開發團隊通過短暫的開發沖刺開發出軟體，并在每個沖刺結束後将生産就緒版本的軟體釋出給業務使用者，進而收集回報并盡可能頻繁地調整方向。

　　最後，經曆過每個新的裡程碑後，将軟體部署給整個業務線更廣泛的使用者群體。

　　DevOps造成的最大挑戰在于需要了解運維人員是軟體的另一個使用者群體！是以他們也應該被全面納入軟體開發流程中。

　　在預定的時間裡，運維應該給出自己的非功能需求，就如同業務使用者給出自己的功能需求一樣。開發團隊應該按照同等程度的重要性和優先級處理這種非功能需求。

　　在實作的過程中，運維應該持續提供回報和非功能測試規範，就像業務使用者針對功能特性提供回報一樣。

　　最後，運維和業務使用者一樣，成為了軟體的使用者。

　　通過采用DevOps方法，運維可以全面融入軟體開發流程中。

　　4.3 共享工具

　　在傳統的大型企業中，運維團隊和開發團隊分别使用專用的，沒有什麼交集的工具集。

　　運維人員通常并不想了解開發團隊所使用的SCM系統以及持續內建環境。他們認為這些并非自己的本職工作，害怕自己在觸及這些系統後會被開發者的各種請求所淹沒。畢竟他們為了照料生産系統就有忙不完的工作了。

　　另一方面，開發者通常無法通路生産系統的日志和監視日志，有時這是因為沒有這樣的意願，有時則是因為制度或安全方面的顧慮。

　　這種狀況需要改變！DevOps應運而生。

　　這個目标其實很難實作。舉例來說，出于制度或安全方面的原因，日志可能會被實時匿名化，同時需要對監管工具進行必要的保護，以避免未經教育訓練或本應被禁止的開發者更改生産環境的配置。是以實作這一目标需要付出大量時間和成本資源。但這樣做所能獲得的收益遠大于所需進行的投入，這種方法對整個公司的投資回報非常明顯。

　　4.4 協同工作

　　DevOps的一種基本哲學是認為，開發者和運維人員必須定期進行密切的合作。

　　這就意味着他們必須将對方視作重要的利益相關者，并積極主動地尋求合作。

　　受到XP實踐中“現場客戶”的啟發，靈活開發者受此激勵可以與業務進行更緊密的合作，自律的靈活者還可以更進一步将這樣的實踐運用給更廣泛的利益相關者，例如可以讓開發者與所有其他相關者進行合作，包括運維和支援人員。

　　這是一條雙行道：運維和支援人員也必須願意與開發者進行密切的合作。

　　此外還可以通過協作：

• 讓運維人員參與靈活儀式（每日Scrum、沖刺規劃、再次沖刺等）
• 讓開發者參與生産環境的推出任務
• 在開發和運維之間打造統一的持續改進目标

　　5. 結論

　　DevOps是一次革命，主要是為了消除擁有大規模IT部門的大型企業中，開發團隊和運維團隊之間由于曆史原因産生的隔閡與孤立所造成的混亂現狀。

　　在我15年的職業生涯中，2/3的時間就職于此類大行機構，其中大部分是金融機構，每天我都在見證者這堵混亂之牆的存在。例如我經常會聽到這樣的說法：

• “在我的Tomcat上工作很正常，很抱歉，但我完全不懂你所用的Websphere，幫不上你了。”（開發者說）
• “我們真的不能從生産資料庫中給你提取這張表，裡面包含了與客戶有關的機密資料。”（運維人員說）

　　每天都會遇到其他很多類似的對話……天天如此！

　　好在DevOps日漸成熟，越來越多傳統企業也在開始逐漸走上正途，開始接受DevOps的原則和實踐。但還有很多企業無動于衷。

　　那麼對于那些小規模的，開發和運維職能之間通常不會産生那麼大分歧的企業呢？

　　這樣的企業應用DevOps原則和實踐，例如自動化部署、持續傳遞和功能開關，一樣能獲益匪淺。

　　我認為DevOps原則可以總結為：

　　DevOps實際上是向着大規模靈活（Scaling Agility）邁出的另一步！