運維DevOps體系解析與落地實踐

DevOps自從2009年誕生以來，經過多年摸索開始逐步變成一種主流運維模式。網上也有很多關於DevOps的討論，但大多數都停留在思想層面，真正可落地的方法並不多，本文作者對自身從業經驗和唯品會的落地實踐加以總結，希望給讀者一定的思考和幫助。

☛在本文開始之前，需先明確幾個概念，後文會用到。

ITIL:一種以流程為基礎的運維模式，基本思想是PDCA。

服務：能夠獨立提供完整的一個或者多個功能模組，這裡特指業務研發編寫可上線執行的程式碼。

元件：能夠獨立部署，但需要和其他元件聯合才能提供服務的基本單位。

☛本文主要回答兩個方面問題：

1，為什麼需要DevOps？

2，DevOps如何落地？

☛本文建議的閱讀者：有一定開發和運維經驗的工程師，最好是經歷過實際生產困難後面臨轉型困境的人員。

在回答這個問題之前，我們先了解一下什麼是運維模式。所有模式是對待人和事物的態度後得到的方法論，比如我對人性是持悲觀的態度，那麼我就需要建立流程制度對人加以約束，使他們在做事時儘量減少自己的主觀意志，客觀去完成所分配的任務。反之，如果我對人性持有樂觀態度，那麼我可能更多地去激勵，讓人員發揮主觀能動性，形成共同的價值觀、行為準則，透過系統方式給予落地。這裡需要注意的是：人是很複雜的動物，往往不能單一而論，大多時需要兩者結合，合適自己的才是最好的。

在流程約束上，目前做得最好的運維模式是ITIL理論，它透過流程驅動運維落地，同時有很好的落地實踐，包括要建設哪些系統都有清晰的註明。我記得我第一次接觸ITIL理論時，驚為天人，因為在複雜運維場景下能夠抽象出一套完善理論是一件很不容易的事。對於很多初成立的團隊，我建議選擇這種模式作為伊始。ITIL的優點除了上面易落地外還有以下原因，值得嘗試：

●見效快，比如只需要建立一個變更流程，就能立即大幅度提升生產質量。

●運維部門主導，在ITIL模式下的絕大多數系統和流程只需要運維部門實施即可，甚至最關鍵的CICD，ITIL體系也只關注於最後釋出到生產那一塊。

●管理落地，流程落地的過程就是管理落地的過程，在這個過程中，管理者可以把自己的經驗和方法完整地實踐下來，可以最大遮蔽執行者的差異。

ITIL主要關注質量和效率之間的質量，兼顧效率。這句話的理解是，當質量和效率發生衝突時，ITIL會優先保障質量。所以當要求效率優先時，ITIL會比較困難，這也就為DevOps發展提供了空間。當然ITIL本身也有其他問題，比如流程反彈、邊際效益等，但由於不是本文重點因此不展開講，如果想了解可以私信我。

而DevOps模式的本質是對開發、測試及運維角色的分工挑戰。如果我們把重心放到最終產出物，即如何快速提供新服務給使用者時，就會遇到一個非常大的挑戰--開發、測試、運維需要融為一體。讓以上三種角色協同其實不是一件容易的事情，因為三方的KPI、行事風格及語言體系並不相同，這就是我們常說的那堵部門牆。

舉個生產變更的例子：

☛小D：業務研發

☛小O：應用運維

他們實施的是DO分離（DO分離也是一個很大的概念，如果以後有空，再單獨講），現在小D要做個變更需求，假設增加一個環境變數，用做程式碼使用，他們實施的過程會是什麼樣的呢？

☛Step1，小D會提交一個變更需求申請，在申請中寫明要幹什麼事情，然後經過小D的上級審批，工單流轉到小O；

☛Step2，小O收到申請，然後他需要寫變更執行步驟，在寫的時候，他需要確認一下業務影響，所以他線下找到小D問為什麼要這樣做;

☛Step3，小D解答自己這麼做的原因，並且貼出自己的程式碼，說明在哪裡引用;

☛Step4，在交流過程中小O發現一個額外步驟，既改完環境變數需要重啟應用，而應用重啟需要小D釋出新的程式碼，這時他告訴小D，變數更改完，下次你們發程式碼後生效;

☛Step5，幾輪後二者達成一致，小O開始做變更，做完後，等待小D驗收;

☛Step6，小D無法驗收，因此要求程式碼釋出日那天，小O要在場，出現問題及時回滾。

這只是生產最平常也是最簡單的一個變更場景。在這個場景中有兩個問題，其一，二者溝通的資訊有效麼？或者更進一步說，當變更完成後，這次變更中所交流的所有資訊對以後工作有促進麼？其二，這一件工作真的需要二者一起完成麼？

其實，答案都是否定的，很多在變更過程中的質疑和溝通都是無效的，只不過二者所處的角色導致資訊必須對稱才能做好一個變更，最後造成效率低下，解決溝通最優的方式不是提升雙方技巧，而是捨棄溝通。如果，運維能夠提供一個系統或者平臺，在上面設定好各種運維場景，開發可以在上面視覺化操作，那麼則無需溝通，這也是很多人的思路，即系統化是落地DevOps的途徑。

在這裡，我複述一遍：DevOps的本質是系統化，我個人比較認同這個理念。但在實際操作中落地過程並不順利，那麼問題來了，為什麼都明白這個道理，但依然做不好DevOps？

事實上，DevOps的方法論並不清晰，其所有思想都停留在較為抽象的層面，系統化算是很好的一種落地思路，但是很多公司系統化後DevOps之路並不順利，究其原因，主要是沒有找到運維和研發的切入點，導致無法羅列出所有運維和研發的使用場景，最後只能不斷打補丁，疲於應對，沒法持續改進。CICD是一個很好的切入點，它是剛需，場景明確單一，同時也最大化解決開發痛點，利於推廣實施，網上也有很多討論，所以這個不是本文重點，大家自己去找即可，這裡主要講在生產治理尤其是生產變更場景下的DevOps落地方案。

請大家思考一個問題，在變更場景下，如果我們要找到一個開發和運維都共同關心的事物，那是什麼？

不是程式碼，程式碼運維並不關心，即使想關心，也是有心無力；不是作業系統，對於大多數研發而言，編寫程式碼需要遮蔽底層差異，如果真的存在這類事物，那麼只能是和程式碼產生直接關係的元件，比如中介軟體Tomcat、快取Redis、Mc、資料庫Mysql等，實際上絕大多數開發的變更需求也是圍繞這些元件實施的。這個很好理解，因為程式碼層次變更開發可以自己掌控，只有這些直接關聯的元件需要運維配合實施，因此做好這些元件的變更場景系統，則能滿足百分之九十以上的開發變更需求。

下面一部分將結合唯品會的實踐，來闡述如何去做。

首先，要指定元件的範圍，既找到上文我們所說的和開發關聯密切的元件，每種元件抽象出操作集合，並把這些操作標準化和指令碼化，如下圖：

有了這些梳理，接下來就可以進行系統建設，在系統劃分時，需要遵循以下兩個原則：

其一，閉環原則，每個元件層面的操作是個封閉集合，既系統要能囊括這個元件變更的方方面面。

其二，橫向抽象原則，對於各個元件共性方面進行橫向抽象，用一個系統來完成。比如每個元件都會有配置檔案的管理，這類就可以抽象出元件的配置中心平臺統一管理。

接下來，以配置舉例，我們來看看是如何構建這個系統的。

Crab統一配置平臺是唯品會針對元件層面做的配置管理平臺，每一個元件都由程式碼和配置兩部分組成，我們操作最多的也是對這些配置的修改，但絕大多數配置是不需要修改的，也就是和應用屬性無關。以tomcat為例，在眾多配置中，只有Server.xml和Context.xml需要進行個性化設定，而在這些個性化設定裡，也只有如下引數需要動態調整，如下圖：

▲Server.xml參數列

▲Context.xml參數列

Crab把這些引數進行key值化，然後抽象出模板的概念。原理如下圖：

其中有一些細節需要注意:

●key分為通用型和自定義型，通用型的key基本和業務無關，或者可以說是標準化後的標準，例如服務的埠號，這些由運維把控，全網生產統一，自定義型的key和業務相關，可以交由研發來掌控，當然，這兩種型別的key是可以互換的，然而由自定義向通用型過渡是一個比較麻煩的過程，要小心操作。

●某些場景下，key值會對應多個value，例如同樣是php最大程式數，物理機和容器是不同的，同一個應用，在不同的IDC配置也會有不同，這些需要在渲染過程中加入下發者物件才能實現，這種特殊邏輯越少越安全。

當系統許可權放開到業務開發時，面臨的最大問題是風險失控，這裡需要強調一點，DevOps並非不要流程，我看過很多DevOps體系喪失流程的概念，效率提升了，卻忘記了運維三角型中運維的及格線：質量。

唯品會的體系中是透過風險矩陣來控制變更風險的。我們發現每一次變更其實是由三部分構成的:變更物件、操作型別及執行變更的人，但當我們系統化後，變更執行人的因素會變弱很多，所以一個風險矩陣真正起作用的是變更物件是否是核心，操作過程是常規還是特殊，由歷史資料推斷操作的風險係數，這樣我們就得到一個變更風險矩陣，如下表：

高風險的變更仍然需要人工稽核介入，但稽核的內容由原來的執行步驟轉變為需求是否合理以及操作時間是否合理。ITIL的變更流程依然存在，只不過蛻化為第二層，對使用者不可見，蛻化後的系統結構如下圖：

評價DevOps的指標有兩個，一個是整個變更的平均完成時間，這個時間可以分為高風險，中風險和低風險三個緯度，我們目標是降低低風險和中風險的變更時間，高風險一般不做時間要求。另外一個是研發的自助變更率，當然，有些變更必須運維才能完成，這類變更在統計時要排除在外。

DevOps落地過程中最麻煩的是觀念轉變，既原來運維的工作開發憑什麼承擔，這就需要前期的宣導培訓，最好是讓部分開發參與到前期DevOps系統需求中來，讓大家看到實實在在的好處，不能為了DevOps而DevOps。

DevOps和ITIL二者理念不同，但關注點相似，並不存在必須捨棄一種的說法，可以在質量和效率之間選取平衡。如果說ITIL需要自上而下貫徹實施，那麼DevOps則需要變更的執行者、需求者參與，二者最後會貫穿整個鏈路。

最後，還是那句話，沒有好不好，只有合不合適，只有最合適的，才是最好的。

“唯技術”一檔專為唯品技術人發聲的公眾號