DevOps詳解

最近我閱讀了不少有關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. 簡介
	1.1 管理信條
	1.2 一個典型的IT組織
	1.3 運維人員測挫敗感
	1.4 基礎架構自動化
	1.5 DevOps：僅此一次，一顆神奇的銀子彈
2. 基礎架構即代碼
	2.1 概述
	2.2 DevOps工具鏈
	2.3 收益
3. 持續交付
	3.1 從實踐中學習
	3.2 自動化
	3.3 更頻繁的部署
	3.4 持續交付的前提需求
	3.5 零停機部署
4. 協做
	4.1 混亂之牆
	4.2 軟件開發流程
	4.3 共享工具
	4.4 協同工做
5. 結論

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 awesome
else 
    # Do old, same as always stuff
end

或者若是要真對具體用戶實現相似目的：

if Feature.isEnabled('new_awesome_feature', current_user)
    # Do something new, cool and awesome
else 
    # Do old, same as always stuff
end 

摸黑啓動

摸黑啓動的目的在於經過生產環境進行負載模擬！

在測試環境中，一般很難爲軟件模擬出成百上千萬用戶規模的負載。

若是不進行切實的負載測試，就沒法知道基礎架構可否承受住最終面臨的壓力。

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

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）邁出的另外一步！

做者：Jerome Kehrli，閱讀英文原文：DevOps explained