引言
DevOps自從2009年誕生以來，經(jīng)過多年摸索開始逐步變成一種主流運(yùn)維模式。網(wǎng)上也有很多關(guān)于DevOps的討論，但大多數(shù)都停留在思想層面，真正可落地的方法并不多，本文作者對自身從業(yè)經(jīng)驗(yàn)和唯品會(huì)的落地實(shí)踐加以總結(jié)，希望給讀者一定的思考和幫助。
?在本文開始之前，需先明確幾個(gè)概念，后文會(huì)用到。
ITIL:一種以流程為基礎(chǔ)的運(yùn)維模式，基本思想是PDCA。
服務(wù)：能夠獨(dú)立提供完整的一個(gè)或者多個(gè)功能模塊，這里特指業(yè)務(wù)研發(fā)編寫可上線運(yùn)行的代碼。
組件：能夠獨(dú)立部署，但需要和其他組件聯(lián)合才能提供服務(wù)的基本單位。
?本文主要回答兩個(gè)方面問題：
1，為什么需要DevOps？
2，DevOps如何落地？
?本文建議的閱讀者：有一定開發(fā)和運(yùn)維經(jīng)驗(yàn)的工程師，最好是經(jīng)歷過實(shí)際生產(chǎn)困難后面臨轉(zhuǎn)型困境的人員。
為什么需要DevOps？
在回答這個(gè)問題之前，我們先了解一下什么是運(yùn)維模式。所有模式是對待人和事物的態(tài)度后得到的方法論，比如我對人性是持悲觀的態(tài)度，那么我就需要建立流程制度對人加以約束，使他們在做事時(shí)盡量減少自己的主觀意志，客觀去完成所分配的任務(wù)。反之，如果我對人性持有樂觀態(tài)度，那么我可能更多地去激勵(lì)，讓人員發(fā)揮主觀能動(dòng)性，形成共同的價(jià)值觀、行為準(zhǔn)則，通過系統(tǒng)方式給予落地。這里需要注意的是：人是很復(fù)雜的動(dòng)物，往往不能單一而論，大多時(shí)需要兩者結(jié)合，合適自己的才是最好的。
在流程約束上，目前做得最好的運(yùn)維模式是ITIL理論，它通過流程驅(qū)動(dòng)運(yùn)維落地，同時(shí)有很好的落地實(shí)踐，包括要建設(shè)哪些系統(tǒng)都有清晰的注明。我記得我第一次接觸ITIL理論時(shí)，驚為天人，因?yàn)樵趶?fù)雜運(yùn)維場景下能夠抽象出一套完善理論是一件很不容易的事。對于很多初成立的團(tuán)隊(duì)，我建議選擇這種模式作為伊始。ITIL的優(yōu)點(diǎn)除了上面易落地外還有以下原因，值得嘗試：
●見效快，比如只需要建立一個(gè)變更流程，就能立即大幅度提升生產(chǎn)質(zhì)量。
●運(yùn)維部門主導(dǎo)，在ITIL模式下的絕大多數(shù)系統(tǒng)和流程只需要運(yùn)維部門實(shí)施即可，甚至最關(guān)鍵的CICD，ITIL體系也只關(guān)注于最后發(fā)布到生產(chǎn)那一塊。
●管理落地，流程落地的過程就是管理落地的過程，在這個(gè)過程中，管理者可以把自己的經(jīng)驗(yàn)和方法完整地實(shí)踐下來，可以大屏蔽執(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本身也有其他問題，比如流程反彈、邊際效益等，但由于不是本文重點(diǎn)因此不展開講，如果想了解可以私信我。
而DevOps模式的本質(zhì)是對開發(fā)、測試及運(yùn)維角色的分工挑戰(zhàn)。如果我們把重心放到最終產(chǎn)出物，即如何快速提供新服務(wù)給用戶時(shí)，就會(huì)遇到一個(gè)非常大的挑戰(zhàn)--開發(fā)、測試、運(yùn)維需要融為一體。讓以上三種角色協(xié)同其實(shí)不是一件容易的事情，因?yàn)槿降腒PI、行事風(fēng)格及語言體系并不相同，這就是我們常說的那堵部門墻。
舉個(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í)施的過程會(huì)是什么樣的呢？
?Step1，小D會(huì)提交一個(gè)變更需求申請，在申請中寫明要干什么事情，然后經(jīng)過小D的上級審批，工單流轉(zhuǎn)到小O；
?Step2，小O收到申請，然后他需要寫變更執(zhí)行步驟，在寫的時(shí)候，他需要確認(rèn)一下業(yè)務(wù)影響，所以他線下找到小D問為什么要這樣做;
?Step3，小D解答自己這么做的原因，并且貼出自己的代碼，說明在哪里引用;
?Step4，在交流過程中小O發(fā)現(xiàn)一個(gè)額外步驟，既改完環(huán)境變量需要重啟應(yīng)用，而應(yīng)用重啟需要小D發(fā)布新的代碼，這時(shí)他告訴小D，變量更改完，下次你們發(fā)代碼后生效;
?Step5，幾輪后二者達(dá)成一致，小O開始做變更，做完后，等待小D驗(yàn)收;
?Step6，小D無法驗(yàn)收，因此要求代碼發(fā)布日那天，小O要在場，出現(xiàn)問題及時(shí)回滾。
這只是生產(chǎn)最平常也是最簡單的一個(gè)變更場景。在這個(gè)場景中有兩個(gè)問題，其一，二者溝通的信息有效么？或者更進(jìn)一步說，當(dāng)變更完成后，這次變更中所交流的所有信息對以后工作有促進(jìn)么？其二，這一件工作真的需要二者一起完成么？
其實(shí)，答案都是否定的，很多在變更過程中的質(zhì)疑和溝通都是無效的，只不過二者所處的角色導(dǎo)致信息必須對稱才能做好一個(gè)變更，最后造成效率低下，解決溝通最優(yōu)的方式不是提升雙方技巧，而是舍棄溝通。如果，運(yùn)維能夠提供一個(gè)系統(tǒng)或者平臺(tái)，在上面設(shè)置好各種運(yùn)維場景，開發(fā)可以在上面可視化操作，那么則無需溝通，這也是很多人的思路，即系統(tǒng)化是落地DevOps的途徑。
在這里，我復(fù)述一遍：DevOps的本質(zhì)是系統(tǒng)化，我個(gè)人比較認(rèn)同這個(gè)理念。但在實(shí)際操作中落地過程并不順利，那么問題來了，為什么都明白這個(gè)道理，但依然做不好DevOps？
DevOps如何落地？
事實(shí)上，DevOps的方法論并不清晰，其所有思想都停留在較為抽象的層面，系統(tǒng)化算是很好的一種落地思路，但是很多公司系統(tǒng)化后DevOps之路并不順利，究其原因，主要是沒有找到運(yùn)維和研發(fā)的切入點(diǎn)，導(dǎo)致無法羅列出所有運(yùn)維和研發(fā)的使用場景，最后只能不斷打補(bǔ)丁，疲于應(yīng)對，沒法持續(xù)改進(jìn)。CICD是一個(gè)很好的切入點(diǎn)，它是剛需，場景明確單一，同時(shí)也大化解決開發(fā)痛點(diǎn)，利于推廣實(shí)施，網(wǎng)上也有很多討論，所以這個(gè)不是本文重點(diǎn)，大家自己去找即可，這里主要講在生產(chǎn)治理尤其是生產(chǎn)變更場景下的DevOps落地方案。
請大家思考一個(gè)問題，在變更場景下，如果我們要找到一個(gè)開發(fā)和運(yùn)維都共同關(guān)心的事物，那是什么？
不是代碼，代碼運(yùn)維并不關(guān)心，即使想關(guān)心，也是有心無力；不是操作系統(tǒng)，對于大多數(shù)研發(fā)而言，編寫代碼需要屏蔽底層差異，如果真的存在這類事物，那么只能是和代碼產(chǎn)生直接關(guān)系的組件，比如中間件Tomcat、緩存Redis、Mc、數(shù)據(jù)庫Mysql等，實(shí)際上絕大多數(shù)開發(fā)的變更需求也是圍繞這些組件實(shí)施的。這個(gè)很好理解，因?yàn)榇a層次變更開發(fā)可以自己掌控，只有這些直接關(guān)聯(lián)的組件需要運(yùn)維配合實(shí)施，因此做好這些組件的變更場景系統(tǒng)，則能滿足百分之九十以上的開發(fā)變更需求。
唯品會(huì)實(shí)踐
下面一部分將結(jié)合唯品會(huì)的實(shí)踐，來闡述如何去做。
01
如何基于組件實(shí)施DevOps？
首先，要指定組件的范圍，既找到上文我們所說的和開發(fā)關(guān)聯(lián)密切的組件，每種組件抽象出操作集合，并把這些操作標(biāo)準(zhǔn)化和腳本化，如下圖：
有了這些梳理，接下來就可以進(jìn)行系統(tǒng)建設(shè)，在系統(tǒng)劃分時(shí)，需要遵循以下兩個(gè)原則：
其一，閉環(huán)原則，每個(gè)組件層面的操作是個(gè)封閉集合，既系統(tǒng)要能囊括這個(gè)組件變更的方方面面。
其二，橫向抽象原則，對于各個(gè)組件共性方面進(jìn)行橫向抽象，用一個(gè)系統(tǒng)來完成。比如每個(gè)組件都會(huì)有配置文件的管理，這類就可以抽象出組件的配置中心平臺(tái)統(tǒng)一管理。
接下來，以配置舉例，我們來看看是如何構(gòu)建這個(gè)系統(tǒng)的。
Crab統(tǒng)一配置平臺(tái)是唯品會(huì)針對組件層面做的配置管理平臺(tái)，每一個(gè)組件都由代碼和配置兩部分組成，我們操作最多的也是對這些配置的修改，但絕大多數(shù)配置是不需要修改的，也就是和應(yīng)用屬性無關(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ù)無關(guān)，或者可以說是標(biāo)準(zhǔn)化后的標(biāo)準(zhǔn)，例如服務(wù)的端口號，這些由運(yùn)維把控，全網(wǎng)生產(chǎn)統(tǒng)一，自定義型的key和業(yè)務(wù)相關(guān)，可以交由研發(fā)來掌控，當(dāng)然，這兩種類型的key是可以互換的，然而由自定義向通用型過渡是一個(gè)比較麻煩的過程，要小心操作。
●某些場景下，key值會(huì)對應(yīng)多個(gè)value，例如同樣是php大進(jìn)程數(shù)，物理機(jī)和容器是不同的，同一個(gè)應(yīng)用，在不同的IDC配置也會(huì)有不同，這些需要在渲染過程中加入下發(fā)者對象才能實(shí)現(xiàn)，這種特殊邏輯越少越安全。
02
如何控制風(fēng)險(xiǎn)？
當(dāng)系統(tǒng)權(quán)限放開到業(yè)務(wù)開發(fā)時(shí)，面臨的大問題是風(fēng)險(xiǎn)失控，這里需要強(qiáng)調(diào)一點(diǎn)，DevOps并非不要流程，我看過很多DevOps體系喪失流程的概念，效率提升了，卻忘記了運(yùn)維三角型中運(yùn)維的及格線：質(zhì)量。
唯品會(huì)的體系中是通過風(fēng)險(xiǎn)矩陣來控制變更風(fēng)險(xiǎn)的。我們發(fā)現(xiàn)每一次變更其實(shí)是由三部分構(gòu)成的:變更對象、操作類型及執(zhí)行變更的人，但當(dāng)我們系統(tǒng)化后，變更執(zhí)行人的因素會(huì)變?nèi)鹾芏啵砸粋€(gè)風(fēng)險(xiǎn)矩陣真正起作用的是變更對象是否是核心，操作過程是常規(guī)還是特殊，由歷史數(shù)據(jù)推斷操作的風(fēng)險(xiǎn)系數(shù)，這樣我們就得到一個(gè)變更風(fēng)險(xiǎn)矩陣，如下表：
高風(fēng)險(xiǎn)的變更仍然需要人工審核介入，但審核的內(nèi)容由原來的執(zhí)行步驟轉(zhuǎn)變?yōu)樾枨笫欠窈侠硪约安僮鲿r(shí)間是否合理。ITIL的變更流程依然存在，只不過蛻化為第二層，對用戶不可見，蛻化后的系統(tǒng)結(jié)構(gòu)如下圖：
03
如何持續(xù)改進(jìn)？
評價(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落地過程中最麻煩的是觀念轉(zhuǎn)變，既原來運(yùn)維的工作開發(fā)憑什么承擔(dān)，這就需要前期的宣導(dǎo)培訓(xùn)，最好是讓部分開發(fā)參與到前期DevOps系統(tǒng)需求中來，讓大家看到實(shí)實(shí)在在的好處，不能為了DevOps而DevOps。
DevOps和ITIL二者理念不同，但關(guān)注點(diǎn)相似，并不存在必須舍棄一種的說法，可以在質(zhì)量和效率之間選取平衡。如果說ITIL需要自上而下貫徹實(shí)施，那么DevOps則需要變更的執(zhí)行者、需求者參與，二者最后會(huì)貫穿整個(gè)鏈路。
最后，還是那句話，沒有好不好，只有合不合適，只有最合適的，才是最好的。
“唯技術(shù)”一檔專為唯品技術(shù)人發(fā)聲的公眾號
重慶分公司
重慶分公司
