在2008年多倫多舉辦的敏捷大會(huì)中，Patrick DeBois 和AndrewClay Shafer 先生***提議討論“敏捷基礎(chǔ)架構(gòu)”話題。接著Flickr的《每天部署10次》的分享橫空出世，它也激發(fā)了隨后2009年在比利時(shí)根特舉辦的首屆DevOps Days活動(dòng)中，Patrick DeBois 先生***在公開(kāi)場(chǎng)合提出“DevOps”這一名詞，“#DevOps Days” 在twitter上被簡(jiǎn)寫(xiě)為 “#DevOps” 。 此后，“DevOps”一詞隨即成為全球IT界大咖們?cè)诟鞣N活動(dòng)中熱議和討論的焦點(diǎn)話題。Patrick DeBois先生也隨之被全球IT大佬們譽(yù)為 “DevOps 之父”!

2010年在美國(guó)山景城(Mountain View) 舉辦的DevOps Days 年會(huì)活動(dòng)中，Damon Edwards先生用一個(gè)縮寫(xiě)“CAMS”詮釋了DevOps，即文化(Culture)、自動(dòng)化(Automation)、測(cè)量(Measurement or Metrics)和分享(Sharing)。隨后Jez Humble先生將“L”精益 (Lean) 原則也加入其中，最終變成了CALMS。

• Culture(文化)- 是指擁抱變革，促進(jìn)協(xié)作和溝通
• Automation(自動(dòng)化)- 是指將人為干預(yù)的環(huán)節(jié)從價(jià)值鏈中消除
• Lean(精益)- 是指通過(guò)使用精益原則促使高頻率循環(huán)周期
• Metrics(指標(biāo))- 是指衡量每一個(gè)環(huán)節(jié)，并通過(guò)數(shù)據(jù)來(lái)改進(jìn)循環(huán)周期
• Sharing(分享)- 是指與他人開(kāi)放分享成功與失敗的經(jīng)驗(yàn)，并在錯(cuò)誤中不斷學(xué)習(xí)改進(jìn)

“CALMS”完全吻合Patrick DeBois先生所一向倡導(dǎo)的“DevOps is a human problem” (DevOps 是關(guān)于人的問(wèn)題) 的理念 。

隨著國(guó)內(nèi)BAT等互聯(lián)網(wǎng)巨頭的崛起，互聯(lián)網(wǎng)公司的開(kāi)發(fā)運(yùn)維經(jīng)驗(yàn)也越來(lái)越多的在國(guó)內(nèi)的各種技術(shù)大會(huì)上傳播。從這兩年的技術(shù)活動(dòng)日程中可以看出，國(guó)內(nèi)互聯(lián)網(wǎng)從業(yè)人員也不約而同的用DevOps來(lái)定位和分享自己的優(yōu)勢(shì)和經(jīng)驗(yàn)。他們是傳播和分享運(yùn)維側(cè)DevOps實(shí)踐的先頭部隊(duì)。

Docker容器技術(shù)在最近三年中異軍突起，持續(xù)交付的技術(shù)門(mén)檻因此被降到***，軟件生產(chǎn)供應(yīng)鏈的格局和效率被徹底提升;基于Docker的微服務(wù)架構(gòu)實(shí)踐的熱度和成熟度也與日俱增。因此，國(guó)內(nèi)的傳統(tǒng)企業(yè)紛紛試水DevOps和容器技術(shù)，在最近兩年的各種技術(shù)大會(huì)中，我們可以看到國(guó)內(nèi)各個(gè)行業(yè)出現(xiàn)了在不同維度上的DevOps先行者。他們分享的主題大多集中在自動(dòng)化運(yùn)維、容器化和PaaS平臺(tái)的等項(xiàng)目經(jīng)驗(yàn)。

目前國(guó)內(nèi)大部分企業(yè)慢慢地開(kāi)始關(guān)注了DevOps，大型傳統(tǒng)企業(yè)也開(kāi)始逐漸地從各個(gè)角度做試點(diǎn)和嘗試。試點(diǎn)的角度和方向各不相同，有的從底層基礎(chǔ)架構(gòu)的容器化開(kāi)始，有的從交付部署流水線的自動(dòng)化開(kāi)始;總的來(lái)說(shuō)還處于初級(jí)的嘗試階段，還沒(méi)有大規(guī)模成體系的推廣。以上就是DevOps在國(guó)外的形成和推廣，以及國(guó)內(nèi)的生根和蔓延的情況。

我把DevOps的按照不同的技術(shù)特征做了從到1.0 到2.0的時(shí)代劃分，并盡量通過(guò)以下維度比較與傳統(tǒng)方式的差異。

從國(guó)內(nèi)眾多DevOps實(shí)踐中，我們能看到下面三個(gè)技術(shù)尤其重要和火熱：

容器：容器從根本上解決了軟件對(duì)環(huán)境的依懶性，解決了各個(gè)環(huán)境之間的差異問(wèn)題;它可以加速部署的速度，提高部署的效率;降低部署的成本。容器技術(shù)是在Linux的基礎(chǔ)之上發(fā)展起來(lái)的，因此它本身的實(shí)施成本很低，就是在任何物理機(jī)和虛擬機(jī)的Linux操作系統(tǒng)上安裝Docker服務(wù)(僅幾十兆)就可以完成所有功能。在任何環(huán)境中實(shí)施Docker需要考慮好以下幾個(gè)因素：主機(jī)的計(jì)算資源特性和容器允許的資源需求相匹配(計(jì)算密集型、內(nèi)存密集型、IO密集型等);容器網(wǎng)絡(luò)類型和服務(wù)路由的選型;容器鏡像倉(cāng)庫(kù)的選擇等。

持續(xù)部署：這是所有企業(yè)普遍的短板，需要設(shè)計(jì)統(tǒng)一的自動(dòng)化部署流水線作為軟件系統(tǒng)部署和更新的基礎(chǔ)設(shè)施。持續(xù)部署流水線底層是有Jenkins之類的工具來(lái)完成的，它能實(shí)現(xiàn)快速的、可重復(fù)使用的、適用于不同部署環(huán)境的發(fā)布流水線。所有服務(wù)都可以通過(guò)它實(shí)現(xiàn)各種風(fēng)格的發(fā)布;這些發(fā)布風(fēng)格中比較重要的兩種：藍(lán)綠部署和灰度發(fā)布。

微服務(wù)：為了解決傳統(tǒng)軟件所特有的巨石應(yīng)用的缺陷，用微服務(wù)的思路，全面地重構(gòu)巨石應(yīng)用，全面的在新系統(tǒng)中應(yīng)用這種架構(gòu)。微服務(wù)架構(gòu)是容器技術(shù)出現(xiàn)之后，有迅猛發(fā)展的一項(xiàng)軟件架構(gòu)技術(shù)。它的松耦合和面向服務(wù)基礎(chǔ)架構(gòu)的特性都是現(xiàn)代軟件和數(shù)據(jù)中心必備的特質(zhì)。

以上三種技術(shù)相輔相成，有著比較深刻的關(guān)聯(lián)。首先微服務(wù)和持續(xù)部署各自解決了特別多的傳統(tǒng)IT的問(wèn)題，這些問(wèn)題都是長(zhǎng)期以來(lái)制約企業(yè)業(yè)務(wù)發(fā)展的難題。容器技術(shù)由于它的快速、輕量、微服務(wù)化的天然特性，很好的從不同側(cè)面支持了持續(xù)交付和微服務(wù)架構(gòu)。容器可以為持續(xù)交付提供彈性和高速的系統(tǒng)資源，環(huán)境管理和利用率提高了很多;容器的不可變性的特點(diǎn)也更好地支持了微服務(wù)架構(gòu)。

企業(yè)實(shí)踐DevOps所需要參考的***實(shí)踐如下圖所示。

(上圖來(lái)源于：Exin DevOps白皮書(shū))

敏捷管理：在產(chǎn)品的計(jì)劃、需求、設(shè)計(jì)和開(kāi)發(fā)階段主要采用敏捷開(kāi)發(fā)方法論。在這些階段中DevOps強(qiáng)調(diào)，設(shè)置合理的任務(wù)大小，從而確保能夠開(kāi)展快速迭代和開(kāi)發(fā);強(qiáng)調(diào)持續(xù)集成的實(shí)施，通過(guò)CI提高軟件的質(zhì)量和可用性;強(qiáng)調(diào)用更短的發(fā)布周期，增強(qiáng)反饋的數(shù)量和頻度。

持續(xù)交付：在開(kāi)發(fā)和部署運(yùn)營(yíng)階段采用持續(xù)交付的方法自動(dòng)化軟件系統(tǒng)的發(fā)布、變更和升級(jí)等工作。DevOps強(qiáng)調(diào)使用持續(xù)交付工具作為基礎(chǔ)架構(gòu)盡可能的自動(dòng)化手工部署工作。在研發(fā)階段就開(kāi)始設(shè)計(jì)部署自動(dòng)化的腳本，對(duì)其使用流水線工具來(lái)操作執(zhí)行，并輔助自動(dòng)化測(cè)試工具。通過(guò)嚴(yán)密的自動(dòng)化測(cè)試方案，確保實(shí)現(xiàn)可以重復(fù)使用的自動(dòng)化部署流水線。通過(guò)它的反復(fù)運(yùn)作，提高部署的效率，降低部署的風(fēng)險(xiǎn)，提高部署的質(zhì)量。

ITSM服務(wù)管理：DevOps強(qiáng)調(diào)從傳統(tǒng)的ITSM管理理念上升到關(guān)注業(yè)務(wù)持續(xù)性的輕量ITSM管理方法。運(yùn)維人員在項(xiàng)目的早期要和開(kāi)發(fā)、測(cè)試和部署人員充分地溝通和落實(shí)運(yùn)維需求。確保在業(yè)務(wù)系統(tǒng)開(kāi)發(fā)的初期，系統(tǒng)的業(yè)務(wù)持續(xù)性和可運(yùn)維性等非功能性需求，都得到充分的落實(shí)和滿足。

精益管理：業(yè)務(wù)開(kāi)發(fā)運(yùn)維的整個(gè)生命周期中，以上三類工作實(shí)踐的所有工作活動(dòng)中，都必須堅(jiān)持貫徹精益的原則。DevOps特別強(qiáng)調(diào)的點(diǎn)包括：準(zhǔn)時(shí)制業(yè)務(wù)流程、精益且無(wú)浪費(fèi)的工作方法、單件流的運(yùn)作流程、持續(xù)改進(jìn)等。它的這些管理思路需要嚴(yán)格的落實(shí)到所有工作環(huán)節(jié)中。

由此可見(jiàn)DevOps在企業(yè)，特別是大規(guī)模傳統(tǒng)企業(yè)的落地和推廣還是比較復(fù)雜的。雖然相關(guān)的***實(shí)踐都是已經(jīng)存在了很多年的;但是，通過(guò)DevOps的價(jià)值觀重構(gòu)企業(yè)從研發(fā)到交付到運(yùn)維的價(jià)值流談何容易。基于我10多年的ITSM項(xiàng)目經(jīng)驗(yàn)，我似乎感覺(jué)到DevOps不能單獨(dú)依靠自頂向下的推廣，當(dāng)然高層領(lǐng)導(dǎo)的支持依然是重要的和必備的支持條件之一。更重要的可能是中層的帶動(dòng)和底層的創(chuàng)新;借鑒生產(chǎn)制造業(yè)已經(jīng)久經(jīng)考驗(yàn)的精益制造實(shí)踐也是勢(shì)在必行。總之DevOps運(yùn)動(dòng)會(huì)在近幾年給IT行業(yè)帶來(lái)較大影響。

【本文為51CTO專欄作者“劉征”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)“DevOps教練”(MyDevOps)獲取授權(quán)】

戳這里，看該作者更多好文