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則需要變更的執行者、需求者參與，二者最后會貫穿整個鏈路。

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

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