DevOps有多火，當下已不用更多的描述，只看看每天的朋友圈就會有一個所以然。與此同時，根據Gartner最新出爐的2015 I&O Automation報告，DevOps同樣正處其技術發展曲線的最高點。
然而不可否認的是，這同樣也說明DevOps真正落地企業內部實踐仍然有很長的路要走，其中就包括了企業日常IT系統的開發、測試和運維，從而顯著地提升企業的IT服務能力。也正是因為如此，現在很多人可能對于DevOps的理念任然充滿懷疑，然而不斷出現的成功案例還是讓大家對其充滿期待。
為此，由Puppet Labs領導的年度DevOps發展報告也希望能夠對此進行更全面地分析和調研，其2014年DevOps發展報告則再次用具體調查數據揭示了組織績效、IT服務績效與DevOps實踐之間的關系。其中的核心觀點包括如下：
擁有強IT服務績效的企業通常會雙倍超過其市場及盈利目標；
企業的IT服務績效和DevOps推崇的普遍實踐（如持續交付等）有非常明顯的正相關。例如，調查發現強IT服務績效的團隊比較差IT服務績效團隊的部署頻率要快30倍，變更失敗率要低50%。
由上可見，DevOps實踐對于提升企業IT服務能力是有明顯的正面作用，并且從實踐中也得到廣泛驗證，值得企業關注和學習。
一、DevOps從哪里來？
如果希望了解DevOps，就不可避免需要切分這個詞中的兩個角色：Dev和Ops（注：這里的Dev包括常說的開發和測試人員，Ops則指服務運維人員，更多時候特指生產環境的服務運維人員）。回顧歷史，Dev和Ops這兩個角色從計算機誕生之日就已經存在，而且在誕生之初它們本身就是一體的。在最早期，計算機的使用范圍非常有限。其硬件生產、軟件開發和日常運維很多時候都是來自同樣人員或者團隊。所以，Dev和Ops這兩個角色也就自然融合在一塊。
隨著計算機使用用途的擴展，越來越多行業開始采購計算機來提升效率，其中個人電腦（PC）的出現則讓計算機從傳統的計算領域向外延伸到各行各業。于是，PC時代其就誕生了許多獨立的計算機軟硬件供應商。而步入這個階段后，計算機軟硬件研發就會和最終使用者自然分離。當企業普遍開始使用計算機及相關軟件來提升日常運營效率時，通常會需要專職的IT系統運維管理人員來保證其正常運行，于是最早期的專職運維人員（也稱系統管理員）應運而生。在這個階段，系統的研發人員（Dev）和運維人員（Ops）其實是處在不同的機構中，他們之間的溝通和交互主要靠產品說明書、操作文檔以及付費的Support完成。為保證企業內IT系統的穩定運行，以Ops為中心的運維管理體系（如ITIL）逐步形成。在這個時間段，企業運維管理體系以服務企業內部運營為主，并不直接面對企業最終用戶。實際運維過程則以保證系統穩定為核心目標，對于系統自身的迭代速度要求并不高。一個最明顯的例證就是這個時期軟件及系統的交付周期一般都是以年為單位（甚至那個時候的Windows版本更新甚至以3年記）。同時，由于這個階段的Dev和Ops完全分離在不同組織中，基本無法形成持續有效的溝通和交互，從而也無法相互了解。通常Ops團隊對于軟件的設計及實現思路缺乏最基本的了解，而Dev團隊對于Ops在實際運維過程中的挑戰和問題也知之甚少。
隨著互聯網和移動互聯網的出現，人們終于找到了一種更好的軟件及服務交付方式，即在線服務。在這種模式下，用戶無需再承擔軟件及服務的運維工作，而是直接“開箱即用”。系統的開發和運維工作再次回到一個組織內部，即在線服務提供商。但是，由于遺留系統（很多在線服務提供商在早期并沒有自研能力，而是采購外部技術來搭建自身服務系統）及傳統運維思路的影響，很多在線服務供應商仍然是按照傳統模式組建自身的運維團隊。于是，很多組織內部的運維團隊和研發團隊雖然是在一個公司，也服務于同一個產品，但是他們在組織架構上仍然是獨立向上匯報。甚至，這種組織架構在很多公司內部還作為一種均衡各方勢力的法寶。基于這些原因，那些因Dev和Ops相互分離而造成的問題并未由于他們重新回到一個組織內而得到根本改觀。同樣存在Dev和Ops相互不了解，互不信任，上線流程異常緩慢等眾多老問題。于是，人們就會思考一個問題：既然都在一個組織內，而且是服務于同一個產品，為啥不能讓兩者走向融合，變成一個以給最終用戶交付最大價值為目標的團隊呢？于是，DevOps思潮開始涌現，并從理論研究逐步成為目前非常主流的軟件生產方式。在這其中也誕生了很多非常優秀的DevOps踐行者，如Facebook、Amazon、Netflix等。
回顧整個發展過程，我們可以看到隨著系統交付及使用方式不斷變化，Dev和Ops兩者也經歷了由合到分，又重新走向融合的過程。從中可以看出，系統的生產方式其實和系統交付及使用方式息息相關。有什么樣的交付及使用方式，就會誕生與之匹配的系統生產方式。而現在，以互聯網和SaaS為代表的交付及使用方式已經成為主流趨勢，與之相對應的軟件生產方式也必然會向全新的DevOps方向發展。
二、DevOps包括什么？
盡管DevOps在現在這個階段重新走向融合，但是這個階段的融合已經和最早期Dev和Ops來自同一個團隊有著本質的差別。無論從系統的復雜程度，面對的用戶規模，還是采用軟件工程思路都有天壤之別。具體來說，個人認為現在的DevOps應該包括如下三個層面的內容：
從組織文化角度上，DevOps應該成為組織文化上的一個內在要求。首先，企業關注的產出應該轉向最終交付價值（即交付給最終用戶的產品功能、用戶體驗）以及響應用戶和市場變化的能力。其次，企業需要從組織架構上解決遺留下來的Dev和Ops隔離的狀態，為他們走向融合提供組織制度上的保障。最后，DevOps文化強調跨部門協作和直接主動溝通，而不是流程導向的流水線模式。總結來說，需要在組織內部樹立“you build it, you run it”的行為準則。
從方法論角度上，DevOps包括一系列最大化交付價值的最佳實踐。例如，持續交付來提高交付的頻率，保證Dev的每一個改進能夠盡快交付給最終用戶，并能夠快速得到真實用戶的反饋，以便及時調整產品方向。持續構建和自動化測試保證Dev能夠盡快得到反饋，發現代碼中潛在的問題并及時修復。自動化一切的原則盡可能避免人為失誤并且保證整個流程的高效，可重復。
從工具角度上，DevOps指一套適應DevOps組織架構需求，能夠幫助團隊落實DevOps最佳實踐的工具。這其中包括代碼管理工具、持續構建工具、代碼部署工具、系統監控與運維工具等。在工具選型中，用戶即可以基于開源軟件自己搭建，也可以考慮購買商業軟件（如FIT2CLOUD）來快速落地。
總結而言，DevOps團隊需要在組織文化層面能夠得到保證和支持，團隊成員能夠接受并實行DevOps各種最佳實踐，并配套相應工具幫助落實。只有這樣才能比較完整的落實DevOps實踐，并最終讓團隊和業務都從中收益，最大化交付給最終用戶的價值，而不是流于形式和炒作概念。
三、DevOps的抓手在哪里？
如果一個組織希望推進DevOps實踐的落地，從哪里入手可能是很多組織內一線經理最為困惑的地方。網絡上關于DevOps的分享涉及的內容非常多，而每一點似乎實施起來都不是特別容易。那DevOps的抓手到底在哪里？來自Puppet Labs 2015 DevOps發展報告的結論則能夠很好地回答這個問題。其報告結論中包括如下觀點：
如果需要了解一個團隊的DevOps狀況，只需要問一個簡單的問題，那就是“團隊部署一次服務有多痛苦”。這個問題的答案會告訴你很多細節。
同樣，DevOps最好的抓手也在于此。提高團隊持續交付和部署的能力在絕大部分情況下都是落實DevOps實踐最好突破口。在落實這個突破口時，團隊需要關注如下幾點：
1. 理清并打通團隊從代碼到服務的整個通道最為關鍵，例如，下圖就是一個典型的從代碼到服務的通道。需要提高團隊持續交付和部署的能力就體現在是否能夠打通這條通道，并讓其盡可能高效地運轉。
在打通這個通道過程中，團隊遇到的常見問題有以下幾點：
a. 團隊缺少基本的可落實部署規范（包括Artifact打包規范和部署流程規范）。規范是提高團隊協作效率的重要一環。同時，這里的規范是必須要能夠落實到部署流程并能夠自動化實施。如果團隊在此沒有歷史成功經驗，建議直接采用已經廣泛使用的現有規范（如AWS的CodeDeploy規范）加快落實。
b. 團隊缺少統一的制品庫管理。現實環境中，團隊構建出來的artifacts經常直接存在FTP、共享目錄上，組織不規范而且也未集中管理。因此經常出現選擇的版本不對，需要回滾時候沒有老版本，不同環境版本選擇錯誤等一系列問題。建議團隊建立統一的制品庫（例如開源的Nexsus，商業軟件Artifactory等）并直接對接構建環境和部署系統。構建時候自動把構建結果打包上傳到制品庫中，部署時從統一制品庫取部署包進行部署。
c. 團隊缺少保證不同環境一致性的能力。如圖所示，系統交付流程需要涉及到開發、測試、驗收和生產環境（簡稱DTAP），如何保證不同環境上一致性并避免系統因環境不一致而導致事故是一個重要挑戰。一般來說，使用統一的基礎環境（如鏡像）加統一的部署流程及工具是保障環境一致性的關鍵所在。
2. 關注團隊部署效率并持續改進是深入提高團隊交付和部署能力的法寶。在打通從代碼到服務的通道后，團隊整個交付能力會有一個質的提升。但是如果需要深入、持續地提升團隊交付能力，還需要持續關注團隊部署效率，找出影響團隊進一步前行的潛在障礙，并有針對性改進。在這個方面，Puppet Labs 2015 DevOps報告提出了一個定量的分析模型非常有幫助。具體來說，這個定量分析模型由如下幾個關鍵指標組成：
● 產出指標：
○ 部署頻率（Deployment frequency）：團隊代碼部署的頻率（包括所有環境的部署次數），一般以每天的部署次數計算。
○ 代碼上線延時（Deployment lead time）：代碼從提交到代碼庫到其上線運行的時間間隔。
● 穩定性指標：
○ 服務平均恢復時間（Mean time to recover）：服務平均恢復時間。
○ 變更失敗率（Change fail rate）：變更失敗率。
通過關注上面這些指標的變化趨勢，團隊可以定量衡量整個應用交付的效率和質量，并能夠始終保證對于應用交付的關注。當然，為了更方便統計如上指標，需要記錄團隊所有的部署操作及結果，不過這應該是一個好的部署系統需要支持的基本功能之一。
四、寫在最后
如本文開篇的Gartner技術發展曲線所示，目前DevOps實踐已經進入高度關注期，但離全面鋪開還有一定時間距離。不過這也恰恰是愿意革新的團隊開始嘗試的好時機。現如今，企業的IT服務能力已經成為核心競爭力之一，能夠快速適應這個變化并積極提升企業IT服務能力的組織必將在激烈的市場競爭中占有優勢。所以，企業需要行動起來，積極擁抱這一新型生產方式，讓那些由此實踐獲得的高效IT研發運維效率的事情不再僅僅是“別人家的故事”。
關于作者：
徐桂林，當前在FIT2CLOUD負責公司的技術布道和生態合作。在此之前先后供職于意法半導體、Autodesk和阿里云。徐桂林熱衷于云計算（尤其是公有云IaaS平臺），有過多年云計算生產環境工作經歷，是較早在國內分享云計算實踐經驗的作者之一。
京公網安備 11010502049343號