【乾貨】DevOps的演進與落地價值

DevOps是當前IT領域最熱門的話題之一，瞭解、掌握、應用DevOps對於提高軟件交付與管控具備重要的意義。然而時至今日DevOps尚無統一的定義。

本文主要從業務及IT的發展對DevOps的誕生背景、定義演進以及落地價值等方面進行了分析和闡述，以期對DevOps的內涵進行探討。

DevOps在2009年提出以來，已經走過了十個年頭。近幾年來，DevOps的熱度呈快速上漲趨勢，從DORA的年度報告也能夠看出來，到2018年底全球主要行業的DevOps的應用程度已達到30%，上升勢頭迅猛。

然而，時至今日，對於DevOps仍沒有一個準確的定義，這對於咱們理解DevOps，或者說在落地DevOps的過程當中會帶來不小的困擾，各方都有本身的理解。那麼，DevOps的內涵到底是什麼呢？咱們指望從DevOps的發展背景、定義演進以及落地價值等方面進行一次探討。

DevOps發展背景

業務發展對軟件的依賴

民用軟件系統的應用崛起於上個世紀八十年代， 2000年後蓬勃發展，其中，做爲重要組成部分的軟件系統，逐漸深刻到社會的每個角落，從總體的發展過來來看，業務與軟件系統的關係可分爲三個階段。

輕度依賴

在這個階段主要出如今早期，軟件系統主要解決業務中重複多或計算量大的問題，支撐範圍主要侷限在業務中的某一過程或環節。或者說，在這個階段，業務離開了軟件系統也能開展，軟件對業務來講不是必選項，軟件功能的更新頻率能夠是數天乃至數月、年。

重度依賴

隨着業務的發展，業務的關聯性與複雜度提升後，業務徹底依賴人工完成已經成爲不可能。到這個時期，軟件系統成爲業務的核心支撐，業務的開展已經離不開軟件系統，但尚可接受短暫的非服務期存在，軟件功能的更新頻率被要求在數天、月。

徹底依賴

隨着軟件服務深刻社會各個角落，社會生活的衣、食、住、行、用都依賴於軟件系統，從某一領域或應用來講，軟件系統相對於業務已經進入了主導階段，軟件系統必須提供365*7*24的服務，任何中斷服務可能都會帶來極大的經濟或社會損失，軟件功能的更新頻率必須控制在數天、小時、分鐘。

IT管理與研發模式演進

IT管理與研發模式的演進，與IT對業務的響應效率密不可分，大體可分爲三個階段；

「穩態」模式

傳統穩態模式的管理上，業務、研發、測試、運維依次分階段管理，各階段的人員只需關注本階段內部的相關內容便可，研發以系統軟件包交付爲目標；總體結構以下圖所示：

在研發模式上，以瀑布模型爲主要特色，其優點是各階段劃分比較清晰、總體成本較低，但迭代速度較慢，其在業務對軟件輕度依賴階段適用性較好。

「穩態+敏捷」模式

隨着業務對軟件依賴程度的提升，傳統模式下軟件的迭代效率成爲了一個阻礙業務發展的主要問題點，因而針對軟件研發過程最耗時的開發過程出現了一系列的優化措施，敏捷研發是其表明。這個時期的IT管理模式變成了「穩態+敏捷」的模式，研發仍舊以系統軟件包交付爲目標，以下圖所示：

固然，在這個時期，針對各階段的效率提高也進行得如火如荼，出現了了一大批針對不一樣階段提速的工具軟件，以下圖所示：

「敏態」模式

當業務對軟件系統徹底依賴時，IT管理與研發模式就須要進入「敏態」模式了。而這個模式也就是咱們今天時常提起的DevOps。在這個模式下，研發交付目標再也不是系統軟件包，而是面向業務的服務能力，以下圖所示：

因爲業務與軟件的關係愈來愈緊密，研發的交付已經由原來的面向軟件包產品，而轉向面向業務須要的服務能力，然而，這種服務能力也是涉及多個方面，下面咱們從DevOps的定義發展，來看看DevOps的內容豐富過程。

DevOps定義演進

「穩態+敏捷」模型只能實現局部效率提高，而DevOps那麼惟一的途徑就是從總體上進行優化和提高，使整個研運過程造成一個有機的總體。從2009年提出依賴，DevOps的內涵也在進行着不斷的發展與豐富，咱們先看一下不一樣時期的定義。

• 2009年10月，【Patrick Debois】DevOps（英文Development和Operations的組合）是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協做與整合。
  

• 2010年5月，DevOps是一個重要的理論，它經過敏捷、精益等在方法、在一個傳統的組織中，把獨立的部門協同在一塊兒實現跨部門集成，創建更加緊密的多部門協做。DevOps不只僅關注軟件部署這一技術問題，它是考慮部門與部門之間溝通和協做的管理方法。
  

• 2014年12月 DevOps是一種軟件開發方法，它強調軟件開發人員和信息技術人員之間的溝通、協做和集成。
  

• 2015年11月 DevOps是一種文化、運動或實踐，它強調軟件開發人員和其餘信息技術人員的協做和溝通，同時強調自動化軟件交付和基礎設施變動的過程。
  

• 2018年AWS DevOps定義:DevOps是一組實踐，目的是在確保高質量的狀況下，快速地把變動導入到生產環境。
  

咱們把不一樣時期的定義整理爲一個時間軸，並作一些關鍵字抽取：

能夠看出針對DevOps的定義，隨着時間的推移，DevOps的內涵在不斷豐富，已經從最初一組過程、方法與系統的組合簡的單定義，發展爲一套有理論、有方法、有文化、有實踐的體系。

DevOps體系與傳統模式是有着本質的不一樣的，主要體如今如下幾個方面：

組織方式不一樣

DevOps中強調以項目或產品的一體化管理爲基本管理模式，從而消除傳統模式下分階段任務管理與執行，經過管理模式的調整，消除傳統模式下不一樣階段的銜接問題。

關注重點不一樣

DevOps是以最終向業務的服務能力交付爲目標，而不是傳統模式下分階段任務交付爲目標。

提高維度不一樣

DevOps關注軟件系統的整個生命週期，是從總體上提高軟件交付的質量與效率，而不單隻關注某一個階段的提高，各階段的提高能夠更加的有機協同。

管控深度不一樣

DevOps強調全程監控，全程度量，經過技術手段透明化軟件交付的全程，包括過程與結果，而傳統模式下過程數據缺少，難以進行有效的過程度量與分析。

效益效果不一樣

DevOps支持針對交付過程的持續優化，經過度量數據分析能夠快速定位交付過程的問題與努力方向，支持持續科學的優化提高，傳統模式難以作到。

DevOps落地價值

DevOps的定義演進以及與傳統模式的對比，能夠看出DevOps體系自己系統化、總體性的設計思想，其既包括了軟件全生命週期的系統化考慮，也包括了了IT管理的多方訴求，DevOps的落地涉及DevOps平臺的建設、流程體系建設、人員賦能、標準規範等多個方面，其能夠爲帶來以下方面的提高。

業務響應能力提高

DevOps的落地，在提高效率的同時能夠提高交付的質量，自動化程度的提高能夠提高對業務需求迭代的響應能力，研運吞吐量能夠獲得幾何級的提高。

研發交付規範提高

不一樣項目或產品的研發團隊，在同一套平臺上開展研發交付活動，經過平臺預先制定的流程、規則等約束不一樣研發團隊的交付活動，從而實現研發交付規範與標準的統一，實現企業級的優化提高與改進。

研發交付效率提高

經過針對研發交付過程當中的環境準備、編譯構建、代碼質量檢查、系統測試、軟件部署等過程的自動化實現，下降人工操做或等待人工操做時間，全面提高研發交付過程的自動化水平，提高研發交付效率。

研發交付質量提高

研發交付質量的從現有的部署結果質量保障，延伸到源代碼質量保障、測試覆蓋度保障等過程，從而實現從源代碼到部署全過程的質量檢查與提高，全鏈路提高研發交付質量

研發交付管控提高

針對研發交付的需求、開發、測試、發佈和部署等過程，進行全面的數據化和度量，針對重點關注指標創建質量門禁，從而實現自動化的技術管控，結合已有的行政管控，由單一的結果管控，實現研發交付「過程+結果」管控，提高管控力度。

研發交付持續優化

基於DevOps平臺，經過流水線過程數據收集，以及進一步的度量分析，實現研發交付過程的持續優化，既包括DevOps平臺的優化，也包括研發交付流程、標準規範等方面的優化。

總結

DevOps的演進簡單來講就是從一項技術到文化的構建與實踐；從可有可無到依賴；從業務的局部到所有。而DevOps的落地價值實現於研、運的整合而且提高對業務需求的響應。趨勢已成，只願你們都能共襄盛舉。

做者：黃全中