什么是DevOps

今天就跟大家聊聊有關(guān)什么是DevOps，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

說起DevOps有多火，相信大家在每天的朋友圈中就能夠感受到。如此同時(shí)，另外一個(gè)佐證就是新鮮出爐的Gartner  2015 I&O Automation報(bào)告中，DevOps正處其技術(shù)發(fā)展曲線的在***點(diǎn)(如下圖)。

當(dāng)然，上面的圖也同樣說明DevOps在企業(yè)內(nèi)部落實(shí)還有很多路需要走，需要落實(shí)到企業(yè)日常IT系統(tǒng)的開發(fā)、測試和運(yùn)維，有效提升企業(yè)的IT服務(wù)能力。也正是因?yàn)槿绱?，現(xiàn)在很多人可能對(duì)于DevOps的理念仍然充滿懷疑。但是，不斷出現(xiàn)的成功案例還是讓大家對(duì)其充滿期待。為此，由Puppet  Labs領(lǐng)導(dǎo)的年度DevOps發(fā)展報(bào)告也希望能夠?qū)Υ诉M(jìn)行更全面分析和調(diào)研，其2014年DevOps發(fā)展報(bào)告則再次用具體調(diào)查數(shù)據(jù)揭示了組織績效、IT服務(wù)績效與DevOps實(shí)踐之間的關(guān)系。其中的核心觀點(diǎn)包括如下：

◆擁有強(qiáng)IT服務(wù)績效的企業(yè)通常會(huì)雙倍超過其市場及盈利目標(biāo)。

◆企業(yè)的IT服務(wù)績效和DevOps推崇的普遍實(shí)踐(如持續(xù)交付等)有非常明顯的正相關(guān)。例如，調(diào)查發(fā)現(xiàn)強(qiáng)IT服務(wù)績效的團(tuán)隊(duì)比較差I(lǐng)T服務(wù)績效團(tuán)隊(duì)的部署頻率要快30倍，變更失敗率要低50%。

由上可見，DevOps實(shí)踐對(duì)于提升企業(yè)IT服務(wù)能力是有明顯的正面作用，并且從實(shí)踐中也得到廣泛驗(yàn)證，值得企業(yè)關(guān)注和學(xué)習(xí)。

一、DevOps從哪里來? 

如果希望了解DevOps，就不可避免需要要展開這個(gè)詞中的兩個(gè)角色：Dev和Ops(注：這里的Dev包括我們常說的開發(fā)和測試人員，Ops則指服務(wù)運(yùn)維人員，更多時(shí)候特指生產(chǎn)環(huán)境的服務(wù)運(yùn)維人員)?；仡櫄v史，Dev和Ops這兩個(gè)角色從計(jì)算機(jī)誕生之日就已經(jīng)存在，而且在誕生之初它們本身就是一體的。在最早期，計(jì)算機(jī)的使用范圍非常有限。其硬件生產(chǎn)、軟件開發(fā)和日常運(yùn)維很多時(shí)候都是來自同樣人員或者團(tuán)隊(duì)。所以，Dev和Ops這兩個(gè)角色也就自然融合在一塊。

隨著計(jì)算機(jī)使用用途的擴(kuò)展，越來越多的行業(yè)開始使用計(jì)算機(jī)來提升效率。尤其是個(gè)人電腦(PC)的出現(xiàn)，讓計(jì)算機(jī)從傳統(tǒng)的計(jì)算領(lǐng)域大大拓展開來。于是，PC時(shí)代其就誕生了許多獨(dú)立的計(jì)算機(jī)軟硬件供應(yīng)商出現(xiàn)。進(jìn)入這個(gè)階段后，計(jì)算機(jī)軟硬件研發(fā)就會(huì)和最終使用者自然分離。當(dāng)企業(yè)普遍開始使用計(jì)算機(jī)及相關(guān)軟件來提升日常運(yùn)營效率時(shí)，會(huì)需要專職的IT系統(tǒng)運(yùn)維管理人員來保證其正常運(yùn)行，于是，最早期的專職運(yùn)維人員(也稱系統(tǒng)管理員)也就應(yīng)運(yùn)而生。

在這個(gè)階段，系統(tǒng)的研發(fā)人員(Dev)和運(yùn)維人員(Ops)其實(shí)是處在不同的組織中。他們之間的溝通和交互主要靠產(chǎn)品說明書，操作文檔以及付費(fèi)的Support完成。為保證企業(yè)內(nèi)IT系統(tǒng)的穩(wěn)定運(yùn)行，以O(shè)ps為中心的運(yùn)維管理體系(如ITIL)逐步形成。在這個(gè)時(shí)間段，企業(yè)運(yùn)維管理體系以服務(wù)企業(yè)內(nèi)部運(yùn)營為主，并不直接面對(duì)企業(yè)最終用戶。實(shí)際運(yùn)維過程則以保證系統(tǒng)穩(wěn)定為核心目標(biāo)，對(duì)于系統(tǒng)自身的迭代速度要求并不高。一個(gè)最明顯的例證就是這個(gè)時(shí)期軟件及系統(tǒng)的交付周期一般都是以年為單位(甚至于Windows則以三年為單位更新版本)。同時(shí)，由于這個(gè)階段的Dev和Ops完全分離在不同組織中，基本無法形成持續(xù)有效的溝通和交互，也就是無法相互了解。通常Ops團(tuán)隊(duì)對(duì)于軟件的設(shè)計(jì)及實(shí)現(xiàn)思路缺乏最基本的了解，而Dev團(tuán)隊(duì)對(duì)于Ops在實(shí)際運(yùn)維過程中的挑戰(zhàn)和問題也知之甚少。

隨著互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的出現(xiàn)，人們重要找到了一種更好的軟件及服務(wù)交付方式，即在線服務(wù)。在這種模式下，用戶無需再承擔(dān)軟件及服務(wù)的運(yùn)維工作，而是直接  “開箱即用”。系統(tǒng)的開發(fā)和運(yùn)維工作再次回到一個(gè)組織內(nèi)部，即在線服務(wù)提供商。但是，由于遺留系統(tǒng)(很多在線服務(wù)提供商在早期并沒有自研能力，而是采購?fù)獠考夹g(shù)來搭建自身服務(wù)系統(tǒng))及傳統(tǒng)運(yùn)維思路的影響，很多在線服務(wù)供應(yīng)商仍然是按照傳統(tǒng)模式組建自身的運(yùn)維團(tuán)隊(duì)。于是，很多組織內(nèi)部的運(yùn)維團(tuán)隊(duì)和研發(fā)團(tuán)隊(duì)雖然是在一個(gè)公司，也服務(wù)于同一個(gè)產(chǎn)品。但是他們?cè)诮M織架構(gòu)上仍然是獨(dú)立向上匯報(bào)。甚至，這種組織架構(gòu)在很多公司內(nèi)部還作為一種均衡各方勢力的法寶。由于這些原因，所有原來Dev和Ops相互分離而造成的問題并未由于他們重新回到一個(gè)組織內(nèi)而得到根本改觀。同樣存在內(nèi)Dev和Ops相互不了解，互不信任，上線流程異常緩慢等很多老問題。于是，人們就會(huì)思考一個(gè)問題：既然都在一個(gè)組織內(nèi)，而且是服務(wù)于同一個(gè)產(chǎn)品，為啥不能讓兩者走向融合，變成一個(gè)以給最終用戶交付***價(jià)值為目標(biāo)的團(tuán)隊(duì)呢?于是，DevOps思潮開始涌現(xiàn)，并從理論研究逐步成為目前非常主流的軟件生產(chǎn)方式。在這其中也誕生了很多非常優(yōu)秀的DevOps踐行者，如Facebook、Netflix等。

回顧發(fā)展歷史，我們可以看到隨著系統(tǒng)交付及使用方式的不斷演變，Dev和Ops兩者也經(jīng)歷了由合到分，又重新走向融合的過程。在其中可以看出，系統(tǒng)的生產(chǎn)方式其實(shí)和系統(tǒng)交付及使用方式息息相關(guān)。有什么樣的交付及使用方式，就會(huì)誕生與之匹配的系統(tǒng)生產(chǎn)方式。而現(xiàn)在，以互聯(lián)網(wǎng)和SaaS為代表的交付及使用方式已經(jīng)成為主流趨勢，與之相對(duì)應(yīng)的軟件生產(chǎn)方式也必然會(huì)向全新的DevOps方向發(fā)展。

二、DevOps包括什么? 

盡管DevOps在現(xiàn)在這個(gè)階段重新走向融合，但是這個(gè)階段的融合已經(jīng)和最早期Dev和Ops來著同一個(gè)團(tuán)隊(duì)有本質(zhì)的差別了。無論從系統(tǒng)的復(fù)雜程度，面對(duì)的用戶規(guī)模，還是采用軟件工程思路都有天壤之別。具體來說，個(gè)人認(rèn)為現(xiàn)在的DevOps應(yīng)該包括如下三個(gè)層面的內(nèi)容：

1.從組織文化角度上，DevOps應(yīng)該成為組織文化上的一個(gè)內(nèi)在要求。首先，企業(yè)關(guān)注的產(chǎn)出應(yīng)該轉(zhuǎn)向最終交付價(jià)值(即交付給最終用戶的產(chǎn)品功能、用戶體驗(yàn))以及響應(yīng)用戶和市場變化的能力。其次，企業(yè)需要從組織架構(gòu)上解決遺留下來的Dev和Ops隔離的狀態(tài)，為他們走向融合提供組織制度上的保障。***，DevOps文化強(qiáng)調(diào)跨部門協(xié)作和直接主動(dòng)溝通，而不是流程導(dǎo)向的流水線模式。總結(jié)來說，需要在組織內(nèi)部樹立“you  build it, you run it”的行為準(zhǔn)則。

2.從方法論角度上，DevOps包括一系列***化交付價(jià)值的***實(shí)踐。例如，持續(xù)交付來提高交付的頻率，保證Dev的每一個(gè)改進(jìn)能夠盡快交付給最終用戶，并能夠快速得到真實(shí)用戶的反饋，以便及時(shí)調(diào)整產(chǎn)品方向。持續(xù)構(gòu)建和自動(dòng)化測試保證Dev能夠盡快得到反饋，發(fā)現(xiàn)代碼中潛在的問題并及時(shí)修復(fù)。自動(dòng)化一切的原則盡可能避免人為失誤并且保證整個(gè)流程的高效，可重復(fù)。

3.從工具角度上，DevOps指一套適應(yīng)DevOps組織架構(gòu)需求，能夠幫助團(tuán)隊(duì)落實(shí)DevOps***實(shí)踐的工具。這其中包括代碼管理工具、持續(xù)構(gòu)建工具、代碼部署工具、系統(tǒng)監(jiān)控與運(yùn)維工具等。在工具選型中，用戶即可以基于開源軟件自己搭建，也可以考慮購買商業(yè)軟件(如FIT2CLOUD)來快速落地。

總結(jié)而言，DevOps團(tuán)隊(duì)需要在組織文化層面能夠得到保證和支持，團(tuán)隊(duì)成員能夠接受并踐行DevOps各種***實(shí)踐，并配套相應(yīng)工具幫助落實(shí)。只有這樣才能比較完整的落實(shí)DevOps實(shí)踐，并最終讓團(tuán)隊(duì)和業(yè)務(wù)都從中收益，***化交付給最終用戶的價(jià)值。而不是流于形式和炒作概念，并無法最終在實(shí)踐中見成效。

三、DevOps的抓手在哪里?

如果一個(gè)組織希望推進(jìn)DevOps實(shí)踐的落地，從哪里入手可能是很多組織內(nèi)一線經(jīng)理最為困惑的地方。網(wǎng)絡(luò)上關(guān)于DevOps的分享涉及的內(nèi)容非常多。那DevOps的抓手到底在哪里?來自Puppet  Labs 2015 DevOps發(fā)展報(bào)告的結(jié)論則能夠很好回答這個(gè)問題。其報(bào)告結(jié)論中包括如下觀點(diǎn)：

如果需要了解一個(gè)團(tuán)隊(duì)的DevOps狀況，只需要問一個(gè)簡單的問題，那就是“團(tuán)隊(duì)部署一次服務(wù)有多痛苦”。這個(gè)問題的答案會(huì)告訴你很多細(xì)節(jié)。

同樣，DevOps***的抓手也在于此。提高團(tuán)隊(duì)持續(xù)交付和部署的能力在絕大部分情況下都是落實(shí)DevOps實(shí)踐***突破口。在落實(shí)這個(gè)突破口時(shí)，團(tuán)隊(duì)需要關(guān)注如下幾點(diǎn)：

1.理清并打通團(tuán)隊(duì)從代碼到服務(wù)的整個(gè)通道最為關(guān)鍵。例如，下圖就是一個(gè)典型的從代碼到服務(wù)的通道。需要提高團(tuán)隊(duì)持續(xù)交付和部署的能力就體現(xiàn)在是否能夠打通這條通道，并讓其盡可能高效的運(yùn)轉(zhuǎn)。

在打通這個(gè)通道過程中，團(tuán)隊(duì)遇到的常見問題有以下幾點(diǎn)：

◆團(tuán)隊(duì)缺少基本的可落實(shí)部署規(guī)范(包括Artifact打包規(guī)范和部署流程規(guī)范)。規(guī)范是提高團(tuán)隊(duì)協(xié)作效率的重要一環(huán)。同時(shí)，這里的規(guī)范是必須要能夠落實(shí)到部署流程并能夠自動(dòng)化實(shí)施。如果團(tuán)隊(duì)在此沒有歷史成功經(jīng)驗(yàn)，建議直接采用已經(jīng)廣泛使用的現(xiàn)有規(guī)范(如AWS的CodeDeploy規(guī)范)加快落實(shí)。

◆團(tuán)隊(duì)缺少統(tǒng)一的制品庫管理。現(xiàn)實(shí)環(huán)境中，團(tuán)隊(duì)構(gòu)建出來的artifacts經(jīng)常直接存在FTP、共享目錄上，組織不規(guī)范而且也未集中管理。因此經(jīng)常出現(xiàn)選擇的版本不對(duì)，需要回滾時(shí)候沒有老版本，不同環(huán)境版本選擇錯(cuò)誤等一系列問題。建議團(tuán)隊(duì)建立統(tǒng)一的制品庫(例如開源的Nexsus，商業(yè)軟件Artifactory等)并直接對(duì)接構(gòu)建環(huán)境和部署系統(tǒng)。構(gòu)建時(shí)候自動(dòng)把構(gòu)建結(jié)果打包上傳到制品庫中，部署時(shí)從統(tǒng)一制品庫取部署包進(jìn)行部署。

◆團(tuán)隊(duì)缺少保證不同環(huán)境一致性的能力。如上圖所示，系統(tǒng)交付流程需要涉及到開發(fā)、測試、驗(yàn)收和生產(chǎn)環(huán)境(簡稱DTAP)，如何保證不同環(huán)境一致性并避免系統(tǒng)因環(huán)境不一致而導(dǎo)致事故是一個(gè)重要挑戰(zhàn)。一般來說，使用統(tǒng)一的基礎(chǔ)環(huán)境(如鏡像)加統(tǒng)一的部署流程及工具是保障環(huán)境一致性的關(guān)鍵所在。

2.關(guān)注團(tuán)隊(duì)部署效率并持續(xù)改進(jìn)是深入提高團(tuán)隊(duì)交付和部署能力的法寶。在打通從代碼到服務(wù)的通道后，團(tuán)隊(duì)整個(gè)交付能力會(huì)有一個(gè)質(zhì)的提升。但是如果需要深入、持續(xù)地提升團(tuán)隊(duì)交付能力，還需要持續(xù)關(guān)注團(tuán)隊(duì)部署效率，找出影響團(tuán)隊(duì)進(jìn)一步前行的潛在障礙，并有針對(duì)性改進(jìn)。在這個(gè)方面，Puppet  Labs 2015 DevOps報(bào)告提出了一個(gè)定量的分析模型非常有幫助。具體來說，這個(gè)定量分析模型由如下幾個(gè)關(guān)鍵指標(biāo)組成：

◆產(chǎn)出指標(biāo)：

○ 部署頻率(Deployment frequency)：團(tuán)隊(duì)代碼部署的頻率(包括所有環(huán)境的部署次數(shù))，一般以每天的部署次數(shù)計(jì)算。

○ 代碼上線延時(shí)(Deployment lead time)：代碼從提交到代碼庫到其上線運(yùn)行的時(shí)間間隔。

◆穩(wěn)定性指標(biāo)：

○ 服務(wù)平均恢復(fù)時(shí)間(Mean time to recover)：服務(wù)平均恢復(fù)時(shí)間。

○ 變更失敗率(Change fail rate)：變更失敗率。

通過關(guān)注上面這些指標(biāo)的變化趨勢，團(tuán)隊(duì)可以定量衡量整個(gè)應(yīng)用交付的效率和質(zhì)量，并能夠始終保證對(duì)于應(yīng)用交付的關(guān)注。當(dāng)然，為了更方便統(tǒng)計(jì)如上指標(biāo)，需要記錄團(tuán)隊(duì)所有的部署操作及結(jié)果，不過這應(yīng)該是一個(gè)好的部署系統(tǒng)需要支持的基本功能之一。

看完上述內(nèi)容，你們對(duì)什么是DevOps有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。