關于DevOps的這些事
在2008年多倫多舉辦的敏捷大會中，Patrick DeBois 和AndrewClay Shafer 先生***提議討論“敏捷基礎架構”話題。接著Flickr的《每天部署10次》的分享橫空出世，它也激發了隨后2009年在比利時根特舉辦的首屆DevOps Days活動中，Patrick DeBois 先生***在公開場合提出“DevOps”這一名詞，“#DevOps Days” 在twitter上被簡寫為 “#DevOps” 。 此后，“DevOps”一詞隨即成為全球IT界大咖們在各種活動中熱議和討論的焦點話題。Patrick DeBois先生也隨之被全球IT大佬們譽為 “DevOps 之父”!
2010年在美國山景城(Mountain View) 舉辦的DevOps Days 年會活動中，Damon Edwards先生用一個縮寫“CAMS”詮釋了DevOps，即文化(Culture)、自動化(Automation)、測量(Measurement or Metrics)和分享(Sharing)。隨后Jez Humble先生將“L”精益 (Lean) 原則也加入其中，最終變成了CALMS。
- Culture(文化)- 是指擁抱變革，促進協作和溝通
- Automation(自動化)- 是指將人為干預的環節從價值鏈中消除
- Lean(精益)- 是指通過使用精益原則促使高頻率循環周期
- Metrics(指標)- 是指衡量每一個環節，并通過數據來改進循環周期
- Sharing(分享)- 是指與他人開放分享成功與失敗的經驗，并在錯誤中不斷學習改進
“CALMS”完全吻合Patrick DeBois先生所一向倡導的“DevOps is a human problem” (DevOps 是關于人的問題) 的理念 。
隨著國內BAT等互聯網巨頭的崛起，互聯網公司的開發運維經驗也越來越多的在國內的各種技術大會上傳播。從這兩年的技術活動日程中可以看出，國內互聯網從業人員也不約而同的用DevOps來定位和分享自己的優勢和經驗。他們是傳播和分享運維側DevOps實踐的先頭部隊。
Docker容器技術在最近三年中異軍突起，持續交付的技術門檻因此被降到***，軟件生產供應鏈的格局和效率被徹底提升;基于Docker的微服務架構實踐的熱度和成熟度也與日俱增。因此，國內的傳統企業紛紛試水DevOps和容器技術，在最近兩年的各種技術大會中，我們可以看到國內各個行業出現了在不同維度上的DevOps先行者。他們分享的主題大多集中在自動化運維、容器化和PaaS平臺的等項目經驗。
目前國內大部分企業慢慢地開始關注了DevOps，大型傳統企業也開始逐漸地從各個角度做試點和嘗試。試點的角度和方向各不相同，有的從底層基礎架構的容器化開始，有的從交付部署流水線的自動化開始;總的來說還處于初級的嘗試階段，還沒有大規模成體系的推廣。以上就是DevOps在國外的形成和推廣，以及國內的生根和蔓延的情況。
我把DevOps的按照不同的技術特征做了從到1.0 到2.0的時代劃分，并盡量通過以下維度比較與傳統方式的差異。
從國內眾多DevOps實踐中，我們能看到下面三個技術尤其重要和火熱：
容器：容器從根本上解決了軟件對環境的依懶性，解決了各個環境之間的差異問題;它可以加速部署的速度，提高部署的效率;降低部署的成本。容器技術是在Linux的基礎之上發展起來的，因此它本身的實施成本很低，就是在任何物理機和虛擬機的Linux操作系統上安裝Docker服務(僅幾十兆)就可以完成所有功能。在任何環境中實施Docker需要考慮好以下幾個因素：主機的計算資源特性和容器允許的資源需求相匹配(計算密集型、內存密集型、IO密集型等);容器網絡類型和服務路由的選型;容器鏡像倉庫的選擇等。
持續部署：這是所有企業普遍的短板，需要設計統一的自動化部署流水線作為軟件系統部署和更新的基礎設施。持續部署流水線底層是有Jenkins之類的工具來完成的，它能實現快速的、可重復使用的、適用于不同部署環境的發布流水線。所有服務都可以通過它實現各種風格的發布;這些發布風格中比較重要的兩種：藍綠部署和灰度發布。
微服務：為了解決傳統軟件所特有的巨石應用的缺陷，用微服務的思路，全面地重構巨石應用，全面的在新系統中應用這種架構。微服務架構是容器技術出現之后，有迅猛發展的一項軟件架構技術。它的松耦合和面向服務基礎架構的特性都是現代軟件和數據中心必備的特質。
以上三種技術相輔相成，有著比較深刻的關聯。首先微服務和持續部署各自解決了特別多的傳統IT的問題，這些問題都是長期以來制約企業業務發展的難題。容器技術由于它的快速、輕量、微服務化的天然特性，很好的從不同側面支持了持續交付和微服務架構。容器可以為持續交付提供彈性和高速的系統資源，環境管理和利用率提高了很多;容器的不可變性的特點也更好地支持了微服務架構。
企業實踐DevOps所需要參考的***實踐如下圖所示。
(上圖來源于：Exin DevOps白皮書)
敏捷管理：在產品的計劃、需求、設計和開發階段主要采用敏捷開發方法論。在這些階段中DevOps強調，設置合理的任務大小，從而確保能夠開展快速迭代和開發;強調持續集成的實施，通過CI提高軟件的質量和可用性;強調用更短的發布周期，增強反饋的數量和頻度。
持續交付：在開發和部署運營階段采用持續交付的方法自動化軟件系統的發布、變更和升級等工作。DevOps強調使用持續交付工具作為基礎架構盡可能的自動化手工部署工作。在研發階段就開始設計部署自動化的腳本，對其使用流水線工具來操作執行，并輔助自動化測試工具。通過嚴密的自動化測試方案，確保實現可以重復使用的自動化部署流水線。通過它的反復運作，提高部署的效率，降低部署的風險，提高部署的質量。
ITSM服務管理：DevOps強調從傳統的ITSM管理理念上升到關注業務持續性的輕量ITSM管理方法。運維人員在項目的早期要和開發、測試和部署人員充分地溝通和落實運維需求。確保在業務系統開發的初期，系統的業務持續性和可運維性等非功能性需求，都得到充分的落實和滿足。
精益管理：業務開發運維的整個生命周期中，以上三類工作實踐的所有工作活動中，都必須堅持貫徹精益的原則。DevOps特別強調的點包括：準時制業務流程、精益且無浪費的工作方法、單件流的運作流程、持續改進等。它的這些管理思路需要嚴格的落實到所有工作環節中。
由此可見DevOps在企業，特別是大規模傳統企業的落地和推廣還是比較復雜的。雖然相關的***實踐都是已經存在了很多年的;但是，通過DevOps的價值觀重構企業從研發到交付到運維的價值流談何容易。基于我10多年的ITSM項目經驗，我似乎感覺到DevOps不能單獨依靠自頂向下的推廣，當然高層領導的支持依然是重要的和必備的支持條件之一。更重要的可能是中層的帶動和底層的創新;借鑒生產制造業已經久經考驗的精益制造實踐也是勢在必行。總之DevOps運動會在近幾年給IT行業帶來較大影響。
【本文為51CTO專欄作者“劉征”的原創稿件，轉載請通過作者微信公眾號“DevOps教練”(MyDevOps)獲取授權】
