DevOps的概念

       DevOps（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。它的出現是因爲軟件行業日益清晰地認識到：爲了按時交付軟件產品和服務，開發和運營工做必須緊密合做。   

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組織

因爲歷史的緣由（大部分運維人員來自硬件和電信業務領域），運維人員和開發者分屬不一樣的組織結構分支。開發者屬於研發部門，而運維人員大部分時候屬於基礎架構部門（或專門的運維部門）。

別忘了，他們有着不一樣的目的：

此外做爲旁註，這兩個團隊有時候會使用不一樣的預算來運營。開發團隊使用構建（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%）！

成功部署意味着軟件可以按照預期在生產環境中運行。未能成功部署意味着有東西出錯，可能須要進行必要的分析才能瞭解部署過程當中哪裏出錯，是否須要應用某種補丁，或須要修改某些配置。

所以讓這一切實現自動化並不惜一切代價避免手工操做彷佛是個好主意，對吧？

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

網絡巨頭們固然會經過新的方法和實踐及時知足本身的需求，他們早已開始構建本身的工程業務，而正是他們所確立的實踐逐漸衍生出當今咱們所熟悉的DevOps。

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

• Facebook有數千名開發和運維人員，成千上萬臺服務器。平均來講一位運維人員負責500臺服務器（還認爲自動化是可選的嗎？）他們天天部署兩次（環式部署，Deployment ring的概念）。
• Flickr天天部署10次。
• Netflix明確針對失敗進行各類設計！他們的軟件按照設計從最底層便可容忍系統失敗，他們會在生產環境中進行全面的測試：天天經過隨機關閉虛擬機的方式在生產環境中執行65000次失敗測試…… 並確保這種狀況下一切依然能夠正常工做。

他們這種作法祕密何在？

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

 

DevOps的共存主要是爲了擴展敏捷開發實踐，進一步完善軟件變動在構建、驗證、部署、交付等階段中的流動，同時經過軟件應用程序的全面全部權予力跨職能團隊完成從設計到生產支持等各環節的工做。

DevOps鼓勵軟件開發者和IT運維人員之間所進行的溝通、協做、集成和自動化，藉此有助於改善雙方在交付軟件過程當中的速度和質量。

DevOps團隊更側重於經過標準化開發環境和自動化交付流程改善交付工做的可預測性、效率、安全性，以及可維護性。理想狀況下，DevOps能夠爲開發者提供更可控的生產環境，幫助他們更好地理解生產基礎架構。

DevOps鼓勵團隊自主進行本身應用程序的構建、驗證、交付和支持。