DevOps體系解析與落地實(shí)踐

1、 DevOps體系解析與落地實(shí)踐目 錄 TOC o 1-3 h z u HYPERLINK l _Toc21984266 一、為什么需要DevOps？ PAGEREF _Toc21984266 h 3 HYPERLINK l _Toc21984267 二、DevOps如何落地？ PAGEREF _Toc21984267 h 6 HYPERLINK l _Toc21984268 三、唯品會(huì)實(shí)踐 PAGEREF _Toc21984268 h 7 HYPERLINK l _Toc21984269 01如何基于組件實(shí)施DevOps？ PAGEREF _Toc21984269 h 7 HYPERLINK

2、 l _Toc21984270 02如何控制風(fēng)險(xiǎn)？ PAGEREF _Toc21984270 h 10 HYPERLINK l _Toc21984271 03如何持續(xù)改進(jìn)？ PAGEREF _Toc21984271 h 12 HYPERLINK l _Toc21984272 四、總結(jié) PAGEREF _Toc21984272 h 12DevOps自從2009年誕生以來(lái)，經(jīng)過(guò)多年摸索開始逐步變成一種主流運(yùn)維模式。網(wǎng)上也有很多關(guān)于DevOps的討論，但大多數(shù)都停留在思想層面，真正可落地的方法并不多，本文作者對(duì)自身從業(yè)經(jīng)驗(yàn)和唯品會(huì)的落地實(shí)踐加以總結(jié)，希望給讀者一定的思考和幫助。需先明確幾個(gè)概念，后文

3、會(huì)用到。ITIL:一種以流程為基礎(chǔ)的運(yùn)維模式，基本思想是PDCA。服務(wù)：能夠獨(dú)立提供完整的一個(gè)或者多個(gè)功能模塊，這里特指業(yè)務(wù)研發(fā)編寫可上線運(yùn)行的代碼。組件：能夠獨(dú)立部署，但需要和其他組件聯(lián)合才能提供服務(wù)的基本單位。本文主要回答兩個(gè)方面問(wèn)題：1，為什么需要DevOps？2，DevOps如何落地？本文建議的閱讀者：有一定開發(fā)和運(yùn)維經(jīng)驗(yàn)的工程師，最好是經(jīng)歷過(guò)實(shí)際生產(chǎn)困難后面臨轉(zhuǎn)型困境的人員。一、為什么需要DevOps？在回答這個(gè)問(wèn)題之前，我們先了解一下什么是運(yùn)維模式。所有模式是對(duì)待人和事物的態(tài)度后得到的方法論，比如我對(duì)人性是持悲觀的態(tài)度，那么我就需要建立流程制度對(duì)人加以約束，使他們?cè)谧鍪聲r(shí)盡量減少自

4、己的主觀意志，客觀去完成所分配的任務(wù)。反之，如果我對(duì)人性持有樂(lè)觀態(tài)度，那么我可能更多地去激勵(lì)，讓人員發(fā)揮主觀能動(dòng)性，形成共同的價(jià)值觀、行為準(zhǔn)則，通過(guò)系統(tǒng)方式給予落地。這里需要注意的是：人是很復(fù)雜的動(dòng)物，往往不能單一而論，大多時(shí)需要兩者結(jié)合，合適自己的才是最好的。在流程約束上，目前做得最好的運(yùn)維模式是ITIL理論，它通過(guò)流程驅(qū)動(dòng)運(yùn)維落地，同時(shí)有很好的落地實(shí)踐，包括要建設(shè)哪些系統(tǒng)都有清晰的注明。我記得我第一次接觸ITIL理論時(shí)，驚為天人，因?yàn)樵趶?fù)雜運(yùn)維場(chǎng)景下能夠抽象出一套完善理論是一件很不容易的事。對(duì)于很多初成立的團(tuán)隊(duì)，我建議選擇這種模式作為伊始。ITIL的優(yōu)點(diǎn)除了上面易落地外還有以下原因，值得嘗

5、試：見效快，比如只需要建立一個(gè)變更流程，就能立即大幅度提升生產(chǎn)質(zhì)量。運(yùn)維部門主導(dǎo)，在ITIL模式下的絕大多數(shù)系統(tǒng)和流程只需要運(yùn)維部門實(shí)施即可，甚至最關(guān)鍵的CICD，ITIL體系也只關(guān)注于最后發(fā)布到生產(chǎn)那一塊。管理落地，流程落地的過(guò)程就是管理落地的過(guò)程，在這個(gè)過(guò)程中，管理者可以把自己的經(jīng)驗(yàn)和方法完整地實(shí)踐下來(lái)，可以最大屏蔽執(zhí)行者的差異。ITIL主要關(guān)注質(zhì)量和效率之間的質(zhì)量，兼顧效率。這句話的理解是，當(dāng)質(zhì)量和效率發(fā)生沖突時(shí)，ITIL會(huì)優(yōu)先保障質(zhì)量。所以當(dāng)要求效率優(yōu)先時(shí)，ITIL會(huì)比較困難，這也就為DevOps發(fā)展提供了空間。當(dāng)然ITIL本身也有其他問(wèn)題，比如流程反彈、邊際效益等，但由于不是本文重點(diǎn)

6、因此不展開講，如果想了解可以私信我。而DevOps模式的本質(zhì)是對(duì)開發(fā)、測(cè)試及運(yùn)維角色的分工挑戰(zhàn)。如果我們把重心放到最終產(chǎn)出物，即如何快速提供新服務(wù)給用戶時(shí)，就會(huì)遇到一個(gè)非常大的挑戰(zhàn)-開發(fā)、測(cè)試、運(yùn)維需要融為一體。讓以上三種角色協(xié)同其實(shí)不是一件容易的事情，因?yàn)槿降腒PI、行事風(fēng)格及語(yǔ)言體系并不相同，這就是我們常說(shuō)的那堵部門墻。舉個(gè)生產(chǎn)變更的例子：小D：業(yè)務(wù)研發(fā)小O：應(yīng)用運(yùn)維他們實(shí)施的是DO分離（DO分離也是一個(gè)很大的概念，如果以后有空，再單獨(dú)講），現(xiàn)在小D要做個(gè)變更需求，假設(shè)增加一個(gè)環(huán)境變量，用做代碼使用，他們實(shí)施的過(guò)程會(huì)是什么樣的呢？Step1，小D會(huì)提交一個(gè)變更需求申請(qǐng)，在申請(qǐng)中寫明要干什

7、么事情，然后經(jīng)過(guò)小D的上級(jí)審批，工單流轉(zhuǎn)到小O；Step2，小O收到申請(qǐng)，然后他需要寫變更執(zhí)行步驟，在寫的時(shí)候，他需要確認(rèn)一下業(yè)務(wù)影響，所以他線下找到小D問(wèn)為什么要這樣做;Step3，小D解答自己這么做的原因，并且貼出自己的代碼，說(shuō)明在哪里引用;Step4，在交流過(guò)程中小O發(fā)現(xiàn)一個(gè)額外步驟，既改完環(huán)境變量需要重啟應(yīng)用，而應(yīng)用重啟需要小D發(fā)布新的代碼，這時(shí)他告訴小D，變量更改完，下次你們發(fā)代碼后生效;Step5，幾輪后二者達(dá)成一致，小O開始做變更，做完后，等待小D驗(yàn)收;Step6，小D無(wú)法驗(yàn)收，因此要求代碼發(fā)布日那天，小O要在場(chǎng)，出現(xiàn)問(wèn)題及時(shí)回滾。這只是生產(chǎn)最平常也是最簡(jiǎn)單的一個(gè)變更場(chǎng)景。在這個(gè)

8、場(chǎng)景中有兩個(gè)問(wèn)題，其一，二者溝通的信息有效么？或者更進(jìn)一步說(shuō)，當(dāng)變更完成后，這次變更中所交流的所有信息對(duì)以后工作有促進(jìn)么？其二，這一件工作真的需要二者一起完成么？其實(shí)，答案都是否定的，很多在變更過(guò)程中的質(zhì)疑和溝通都是無(wú)效的，只不過(guò)二者所處的角色導(dǎo)致信息必須對(duì)稱才能做好一個(gè)變更，最后造成效率低下，解決溝通最優(yōu)的方式不是提升雙方技巧，而是舍棄溝通。如果，運(yùn)維能夠提供一個(gè)系統(tǒng)或者平臺(tái)，在上面設(shè)置好各種運(yùn)維場(chǎng)景，開發(fā)可以在上面可視化操作，那么則無(wú)需溝通，這也是很多人的思路，即系統(tǒng)化是落地DevOps的途徑。在這里，我復(fù)述一遍：DevOps的本質(zhì)是系統(tǒng)化，我個(gè)人比較認(rèn)同這個(gè)理念。但在實(shí)際操作中落地過(guò)程并

9、不順利，那么問(wèn)題來(lái)了，為什么都明白這個(gè)道理，但依然做不好DevOps？二、DevOps如何落地？事實(shí)上，DevOps的方法論并不清晰，其所有思想都停留在較為抽象的層面，系統(tǒng)化算是很好的一種落地思路，但是很多公司系統(tǒng)化后DevOps之路并不順利，究其原因，主要是沒(méi)有找到運(yùn)維和研發(fā)的切入點(diǎn)，導(dǎo)致無(wú)法羅列出所有運(yùn)維和研發(fā)的使用場(chǎng)景，最后只能不斷打補(bǔ)丁，疲于應(yīng)對(duì)，沒(méi)法持續(xù)改進(jìn)。CICD是一個(gè)很好的切入點(diǎn)，它是剛需，場(chǎng)景明確單一，同時(shí)也最大化解決開發(fā)痛點(diǎn)，利于推廣實(shí)施，網(wǎng)上也有很多討論，所以這個(gè)不是本文重點(diǎn)，大家自己去找即可，這里主要講在生產(chǎn)治理尤其是生產(chǎn)變更場(chǎng)景下的DevOps落地方案。請(qǐng)大家思考一個(gè)

10、問(wèn)題，在變更場(chǎng)景下，如果我們要找到一個(gè)開發(fā)和運(yùn)維都共同關(guān)心的事物，那是什么？不是代碼，代碼運(yùn)維并不關(guān)心，即使想關(guān)心，也是有心無(wú)力；不是操作系統(tǒng)，對(duì)于大多數(shù)研發(fā)而言，編寫代碼需要屏蔽底層差異，如果真的存在這類事物，那么只能是和代碼產(chǎn)生直接關(guān)系的組件，比如中間件Tomcat、緩存Redis、Mc、數(shù)據(jù)庫(kù)Mysql等，實(shí)際上絕大多數(shù)開發(fā)的變更需求也是圍繞這些組件實(shí)施的。這個(gè)很好理解，因?yàn)榇a層次變更開發(fā)可以自己掌控，只有這些直接關(guān)聯(lián)的組件需要運(yùn)維配合實(shí)施，因此做好這些組件的變更場(chǎng)景系統(tǒng)，則能滿足百分之九十以上的開發(fā)變更需求。三、唯品會(huì)實(shí)踐下面一部分將結(jié)合唯品會(huì)的實(shí)踐，來(lái)闡述如何去做。01如何基于組件

11、實(shí)施DevOps？首先，要指定組件的范圍，既找到上文我們所說(shuō)的和開發(fā)關(guān)聯(lián)密切的組件，每種組件抽象出操作集合，并把這些操作標(biāo)準(zhǔn)化和腳本化，如下圖：有了這些梳理，接下來(lái)就可以進(jìn)行系統(tǒng)建設(shè)，在系統(tǒng)劃分時(shí)，需要遵循以下兩個(gè)原則：其一，閉環(huán)原則，每個(gè)組件層面的操作是個(gè)封閉集合，既系統(tǒng)要能囊括這個(gè)組件變更的方方面面。其二，橫向抽象原則，對(duì)于各個(gè)組件共性方面進(jìn)行橫向抽象，用一個(gè)系統(tǒng)來(lái)完成。比如每個(gè)組件都會(huì)有配置文件的管理，這類就可以抽象出組件的配置中心平臺(tái)統(tǒng)一管理。接下來(lái)，以配置舉例，我們來(lái)看看是如何構(gòu)建這個(gè)系統(tǒng)的。Crab統(tǒng)一配置平臺(tái)是唯品會(huì)針對(duì)組件層面做的配置管理平臺(tái)，每一個(gè)組件都由代碼和配置兩部分組成

12、，我們操作最多的也是對(duì)這些配置的修改，但絕大多數(shù)配置是不需要修改的，也就是和應(yīng)用屬性無(wú)關(guān)。以tomcat為例，在眾多配置中，只有Server.xml和Context.xml需要進(jìn)行個(gè)性化設(shè)置，而在這些個(gè)性化設(shè)置里，也只有如下參數(shù)需要?jiǎng)討B(tài)調(diào)整，如下圖：Server.xml參數(shù)表Context.xml參數(shù)表Crab把這些參數(shù)進(jìn)行key值化，然后抽象出模板的概念。原理如下圖：其中有一些細(xì)節(jié)需要注意：key分為通用型和自定義型，通用型的key基本和業(yè)務(wù)無(wú)關(guān)，或者可以說(shuō)是標(biāo)準(zhǔn)化后的標(biāo)準(zhǔn)，例如服務(wù)的端口號(hào)，這些由運(yùn)維把控，全網(wǎng)生產(chǎn)統(tǒng)一，自定義型的key和業(yè)務(wù)相關(guān)，可以交由研發(fā)來(lái)掌控，當(dāng)然，這兩種類型的ke

13、y是可以互換的，然而由自定義向通用型過(guò)渡是一個(gè)比較麻煩的過(guò)程，要小心操作。某些場(chǎng)景下，key值會(huì)對(duì)應(yīng)多個(gè)value，例如同樣是php最大進(jìn)程數(shù)，物理機(jī)和容器是不同的，同一個(gè)應(yīng)用，在不同的IDC配置也會(huì)有不同，這些需要在渲染過(guò)程中加入下發(fā)者對(duì)象才能實(shí)現(xiàn)，這種特殊邏輯越少越安全。02如何控制風(fēng)險(xiǎn)？當(dāng)系統(tǒng)權(quán)限放開到業(yè)務(wù)開發(fā)時(shí)，面臨的最大問(wèn)題是風(fēng)險(xiǎn)失控，這里需要強(qiáng)調(diào)一點(diǎn)，DevOps并非不要流程，我看過(guò)很多DevOps體系喪失流程的概念，效率提升了，卻忘記了運(yùn)維三角型中運(yùn)維的及格線：質(zhì)量。唯品會(huì)的體系中是通過(guò)風(fēng)險(xiǎn)矩陣來(lái)控制變更風(fēng)險(xiǎn)的。我們發(fā)現(xiàn)每一次變更其實(shí)是由三部分構(gòu)成的:變更對(duì)象、操作類型及執(zhí)行變更

14、的人，但當(dāng)我們系統(tǒng)化后，變更執(zhí)行人的因素會(huì)變?nèi)鹾芏?，所以一個(gè)風(fēng)險(xiǎn)矩陣真正起作用的是變更對(duì)象是否是核心，操作過(guò)程是常規(guī)還是特殊，由歷史數(shù)據(jù)推斷操作的風(fēng)險(xiǎn)系數(shù)，這樣我們就得到一個(gè)變更風(fēng)險(xiǎn)矩陣，如下表：高風(fēng)險(xiǎn)的變更仍然需要人工審核介入，但審核的內(nèi)容由原來(lái)的執(zhí)行步驟轉(zhuǎn)變?yōu)樾枨笫欠窈侠硪约安僮鲿r(shí)間是否合理。ITIL的變更流程依然存在，只不過(guò)蛻化為第二層，對(duì)用戶不可見，蛻化后的系統(tǒng)結(jié)構(gòu)如下圖：03如何持續(xù)改進(jìn)？評(píng)價(jià)DevOps的指標(biāo)有兩個(gè)，一個(gè)是整個(gè)變更的平均完成時(shí)間，這個(gè)時(shí)間可以分為高風(fēng)險(xiǎn)，中風(fēng)險(xiǎn)和低風(fēng)險(xiǎn)三個(gè)緯度，我們目標(biāo)是降低低風(fēng)險(xiǎn)和中風(fēng)險(xiǎn)的變更時(shí)間，高風(fēng)險(xiǎn)一般不做時(shí)間要求。另外一個(gè)是研發(fā)的自助變更率，當(dāng)然，有些變更必須運(yùn)維才能完成，這類變更在統(tǒng)計(jì)時(shí)要排除在外。四、總結(jié)DevOps落地過(guò)程中最麻煩的是觀念轉(zhuǎn)變，既原來(lái)運(yùn)