關於DevOps 的那些事

本文關鍵詞：#DevOps# #DevOpsDays# #敏捷# #持續部署# #持續集成# #自動化# #精益# #CALMS#

我對DevOps的一個比較宏觀的總結。DevOps是孕育于敏捷社區，又反哺給整個IT技術行業的，是一次徹底而全面的技術和文化運動。本文從它的出處談起，一直描述到當前國內的現狀。最後總結了相關的核心技術和主要實踐。

DevOps簡史

在2008年多倫多舉辦的敏捷大會（Velocity Conf 2008 ）上，Patrick DeBois 和AndrewClay Shafer 先生首次提議討論「敏捷基礎架構」這個話題。在第二年的敏捷大會上有一個具有里程碑的意義技術分享，來自Flickr公司《每天部署10次》的分享，它激發了隨後Patrick DeBios在同年十月，在比利時的根特市舉辦的首屆DevOpsDays活動，這個活動是兩天的日程，為了大家方便在twitter上的傳播，人們把DevOpsDays這個詞簡寫為 「#DevOps」 。 此後，「DevOps」一詞問世了，這個詞所包含的理念和實踐一時在越來越廣大的人群中產生了共鳴，隨後成為全球IT界在各種大會和論壇里熱議和討論的焦點話題，很多大型IT論壇也都開設出了DevOps專題討論。這就是DevOps這個詞的由來。DevOpsDays活動隨後在Patrick DeBios等相關核心發起人的推動下，在全球範圍內蓬勃發展了起來。2010年在美國山景城(Mountain View) 舉辦的DevOpsDays 活動中，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 是關於人的問題) 的理念 。

DevOpsDays活動的現狀

從DevOps概念的產生，到如今它在全球範圍內的蔓延和認同，已經經歷了9個年頭的時間。它的火爆推廣也伴隨著IT行業的迅速變遷和發展，現在已經到了移動互聯網時代的後半場，國內的信息化建設已經完成了很多年；如今各行各業的企業也都亟待完成全方位的數字化轉型。IT信息技術的先進程度標誌著一個企業的核心能力，任何一個成功的企業，敏捷高效的軟體開發創新實力和IT管理綜合能力不只是門面而已，而是實實在在的市場競爭能力。DevOps倡導打敏捷、持續交付和ITIL三種實踐的組合拳，同時應用精益生產理念為基礎的管理思想，這正在逐漸地被廣泛的接受和認可。

在過去的幾年中，國內的各種IT大會也蓬勃發展，其中DevOps相關的專題和分會場也頗受人們的關注。各種雲計算、運維等IT技術的社交媒體也都非常重視DevOps這個話題的分享。一個專屬於DevOps社群的、國際性的、有影響力的DevOps大會正呼之欲出。在這樣的時代背景下DevOpsDays大會北京站在2017年的3月18日來到中國，在同年的8月18日上海，還要舉辦DevOpsDays Shanghai站的大會。

下面列舉一些DevOpsDays大會的相關數據，數據來源於DevOpsDays.org 網站。從2009年到2016年，已經在全球的61個城市/國家成功地舉辦了117場。

下圖是在過去九年中DevOpsDays大會在各個城市/國家的分布和舉辦次數。

今年也就是2017年預計舉辦30場，其中已經有18場確定了舉辦城市和日期；還有12個城市的召開日期待定；這不包括年內還可能會提出申辦的城市。以上數據的統計時間在2017年三月。

DevOps在國內的現狀

隨著國內BAT等互聯網巨頭的崛起，互聯網公司的開發運維經驗也越來越多的在國內的各種技術大會上傳播。從最近這兩年（2016年和2017年）的技術活動日程中可以看出，國內互聯網從業人員也不約而同的用DevOps來定位和分享自己的優勢和經驗。他們是傳播和分享運維側DevOps實踐的先頭部隊。

出了技術論壇的分享之外，很多線上線下的大會、論壇和討論組也都越來越熱議DevOps這一專題。國內其它相關流派的人群，例如敏捷和精益等，也對DevOps的蓬勃發展表示比較驚訝，DevOps與老牌的敏捷和精益等陣營也產生過一些爭論。但這一切的發生也都增加了人們對於DevOps的更深入的興趣。

在培訓認證這方面，Exin DevOps Master是一個國際認證的培訓；其它公司和組織也正在舉辦關於DevOps工具鏈的培訓，這些培訓則注重於技術實操，關注在構建端到端的流水線的搭建方面。從DevOps的職位招聘方面，可以看到DevOps工程師相關的職位越來越多了，在職位需求中DevOps這個技能成了加分項，DevOps相關工具的技能也或將成為簡歷的亮點。在IT行業內不管是開發還是運維團隊的人，都開始了學習和接受的過程。

據我觀察DevOps方面的廠商在最近3年呈現爆炸式的發展。我把他們分為三類：

1. 搭順風車型：主要是指所有CaaS容器雲平台廠商 。Docker是它是在DevOps的時代背景下產生的，是DevOps技術工具集里不可缺少的一員。國內這些廠商目前的數量在20左右，數目趨於穩定。由於今年（2017）Docker公司商業化版本和開源版本正式的劃分開來，這些公司的發展可能或多或少受到一些影響。
2. 直奔主題型：這類廠商專註於開發端到端的、用戶體驗良好的DevOps流水線平台，這些公司的創始人團隊多是來自於BAT公司，因此具有很好的DevOps實戰經驗，他們開發的產品在持續交付和流水線功能上恰好填補了當前企業在這個方面的工具和技術實踐的缺位。目前這類公司的數量還不多，數量呈上升趨勢。
3. BATH型：BAT大家都知道，這裡的H指的是華為，這些企業在DevOps平台方面都表現出積極的技術輸出的態勢。BAT是基於過去的互聯網運維的經驗做DevOps的產品化。華為是成了獨立的研發部門，招募業內這方面的精英前來助陣，打造出一方面可以自用，同時也可以商品化的DevOps產品。

目前國內大部分企業慢慢地開始關注了DevOps，大型傳統企業也開始逐漸地從各個角度做試點和嘗試。試點的角度和方向各不相同，有的從底層基礎架構的容器化開始，有的從交付部署流水線的自動化開始；總的來說還處於初級的嘗試階段，還沒有大規模成體系的推廣。

綜上所述，目前國內DevOps發展的階段還屬於起步階段。就像是ITIL/ITSM在2003年左右的狀態。由於DevOps是去中心化的，所以沒有唯一、權威的上游廠商的存在，各種理論實踐的爭執和PK都將終止與解決問題和提高效率的話題上，因此它具有百花齊放百家爭鳴的發展條件。個人認為DevOps的實施和落地也不會完全依賴於傳統的大型諮詢廠商的諮詢工作，由於它應該是在企業的內部，在內驅的作用下，自生長出來的；它必須是服務於企業的業務價值流的優化，加速業務價值產出的；而與之相關的工作和責任的擔當，外部力量是很難以等量替換和承擔的。

核心技術和工具

在談這個話題前先看一下DevOps相關工具集的全貌，如下圖所示：

最上面的箭頭流程圖表示了一個業務服務的全生命周期：開發協作、軟體構建、質量測試、交付部署和投產運維。前三個階段偏傳統開發組織的工作內容，後兩個階段基本可以和運維組織的工作對應上。在每個階段下可以看成是一個大分類，這些分類中還包含若干個小分類。這些工具可以粗放的劃分為商業軟體和開源軟體兩類；也可以分為SaaS服務類和企業內部部署型。大部分開源工具都有活躍的用戶社區和群眾基礎，這給企業入手這些工具帶來了很大的便利。在需要商業支持的場景里還可以選擇使用這些開源軟體的企業版。

Docker容器技術在最近三年中異軍突起，持續交付的技術門檻因此被降到最低，軟體生產供應鏈的格局和效率被徹底提升；基於Docker的微服務架構實踐的熱度和成熟度也與日俱增。因此，國內的傳統企業紛紛試水DevOps和容器技術，在最近兩年的各種技術大會中，我們可以看到國內各個行業出現了在不同維度上的DevOps先行者。他們分享的主題大多集中在自動化運維、容器化和PaaS平台的等項目經驗。

從國內眾多DevOps實踐中，我們能看到下面三個技術尤其重要和火熱：

1. 容器：容器從根本上解決了軟體對環境的依懶性，解決了各個環境之間的差異問題；它可以加速部署的速度，提高部署的效率；降低部署的成本。容器技術是在Linux的基礎之上發展起來的，因此它本身的實施成本很低，就是在任何物理機和虛擬機的Linux操作系統上安裝Docker服務（僅幾十兆）就可以完成所有功能。在任何環境中實施Docker需要考慮好以下幾個因素：主機的計算資源特性和容器允許的資源需求相匹配（計算密集型、內存密集型、IO密集型等）；容器網路類型和服務路由的選型；容器鏡像倉庫的選擇等。
2. 持續部署：這是所有企業普遍的短板，需要設計統一的自動化部署流水線作為軟體系統部署和更新的基礎設施。持續部署流水線底層是有Jenkins之類的工具來完成的，它能實現快速的、可重複使用的、適用於不同部署環境的發布流水線。所有服務都可以通過它實現各種風格的發布；這些發布風格中比較重要的兩種：藍綠部署和灰度發布。
3. 微服務：為了解決傳統軟體所特有的單體應用的缺陷，用微服務的思路，全面地重構巨石應用，全面的在新系統中應用這種架構。微服務架構是容器技術出現之後，有迅猛發展的一項軟體架構技術。它的松耦合和面向服務基礎架構的特性都是現代軟體和數據中心必備的特質。
   以上三種技術相輔相成，有著比較深刻的關聯。首先微服務和持續部署各自解決了特別多的傳統IT的問題，這些問題都是長期以來制約企業業務發展的難題。容器技術由於它的快速、輕量、微服務化的天然特性，很好的從不同側面支持了持續交付和微服務架構。容器可以為持續交付提供彈性和高速的系統資源，環境管理和利用率提高了很多；容器的不可變性的特點也更好地支持了微服務架構。

我把DevOps的按照不同的技術特徵做了從到1.0 到2.0的時代劃分，並盡量通過以下維度比較與傳統方式的差異。

總結

我比較認可和接受的企業實踐DevOps參考框架如下，其中包含了所需的最佳實踐，如下圖所示。

（上圖來源於：Exin DevOps白皮書）

下面簡要描述一下這四大支柱型最佳實踐

1. 敏捷管理：在產品的計劃、需求、設計和開發階段主要採用敏捷開發方法論。在這些階段中DevOps強調，設置合理的任務大小，從而確保能夠開展快速迭代和開發；強調持續集成的實施，通過CI提高軟體的質量和可用性；強調用更短的發布周期，增強反饋的數量和頻度。
2. 持續交付：在開發和部署運營階段採用持續交付的方法自動化軟體系統的發布、變更和升級等工作。DevOps強調使用持續交付工具作為基礎架構儘可能的自動化手工部署工作。在研發階段就開始設計部署自動化的腳本，對其使用流水線工具來操作執行，並輔助自動化測試工具。通過嚴密的自動化測試方案，確保實現可以重複使用的自動化部署流水線。通過它的反覆運作，提高部署的效率，降低部署的風險，提高部署的質量。
3. ITSM服務管理：DevOps強調從傳統的ITSM管理理念上升到關注業務持續性的輕量ITSM管理方法。運維人員在項目的早期要和開發、測試和部署人員充分地溝通和落實運維需求。確保在業務系統開發的初期，系統的業務持續性和可運維性等非功能性需求，都得到充分的落實和滿足。
4. 精益管理：業務開發運維的整個生命周期中，以上三類工作實踐的所有工作活動中，都必須堅持貫徹精益的原則。DevOps特彆強調的點包括：準時制業務流程、精益且無浪費的工作方法、單件流的運作流程、持續改進等。它的這些管理思路需要嚴格的落實到所有工作環節中。

由此可見DevOps在企業，特別是大規模傳統企業的落地和推廣還是比較複雜的。雖然相關的最佳實踐都是已經存在了很多年的；但是，通過DevOps的價值觀重構企業從研發到交付到運維的價值流談何容易。基於我的IT從業經驗，我似乎感覺到DevOps不能單獨依靠自頂向下的推廣，當然高層領導的支持依然是重要的和必備的支持條件之一。 可能還需要中層的帶動和底層的創新；借鑒生產製造業已經久經考驗的精益製造實踐也是勢在必行。總之DevOps運動會在近幾年給IT行業帶來較大影響。

本文轉載自我的博客：