本文轉自微信號EAWorld。掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！本文轉自微信號EAWorld。
目錄：
一、萬達DevOps平臺建設歷程
二、平臺架構解析
三、建設過程中的難點分享
四、總結
一、萬達DevOps平臺建設歷程
我們從2017年2月份開始幫助萬達網絡科技建設DevOps平臺，2017年6月份完成試運行上線交付。目前萬達網絡科技公共平臺研發中心的所有產品和項目都已經通過DevOps平臺管理起來，實現了全面的持續集成、持續交付等能力，並持續進行過程度量和改進，不斷提升IT運行效率。
建設背景
萬達網科成立後，業務需求處於一個飛速增長的階段，在短時間內已經發展到將近30個產品、40個項目，管理成本相當之高，傳統的管理方式很難高效率、高質量的進行管理和把控如此之多的產品和項目。並且隨着虛擬化、容器雲、微服務等技術的發展，應用底層的運行環境愈發多樣化，物理機、虛擬機、容器雲三種異構環境、移動應用、Springboot應用、純前端應用等數十個異構應用都需要通過一個平臺進行統一的部署和管理。
建設目標簡單可以歸納爲如下三點：
1.通過DevOps平臺統一管理所有產品、項目，對團隊、對人能進行數字化的考覈
2.實現所有應用的持續集成、100%自動化部署，提升應用的軟件交付效率
3.在兩年內，將目前部門的研發、測試、運維發佈的工作效率提升50%。
建設過程
項目從2月初開始，到6月底上線交付。持續了5個月的時間。項目過程基於Scrum過程體系，以月迭代的方式，每個月發佈一個版本。同時，基於MVP的理念，保證每個月上線的版本功能都是可用的，不斷的完善平臺能力。每個衝刺過程如下：
Sprint1（2月份）：2月份主要進行了整體需求分析，完成我們現有產品的上線，以產品的現有能力作爲第一個MVP版本。
Sprint2（3月份）：3月份交付了產品管理、項目管理、持續集成等能力，並且最重要的，結合萬達的流程和規範，打通持續交付的流水線。流水線從構建開始，一直到上線部署，有了持續交付流水線，即使中間的一些環節（如測試環境）暫時無法做到完全的自動化測試，但是可以通過人工的參與，自動與人工結合，至少保障了整個軟件交付過程便已經通過平臺管理起來。後續便可以此流水線爲基準，不斷的完善中間環節的自動化能力。
Sprint3（4月份）：完善了度量優化、部署、流水線協作看板等能力。在度量優化模塊，結合萬達的度量點和度量考覈規範，從多個維度和視角，不斷提升平臺的度量能力。在部署管理模塊，首先結合萬達的環境資源規範，對接其CMDB系統，在DEV/LAB/SIT/UAT/PRE/PROD六大環境的基礎上，統一納管所有項目的環境資源。結合部署規範（操作系統、部署用戶權限、目錄要求、數據庫版本、jdk版本、nginx版本等），定製出符合萬達要求的自動化部署能力。在流水線能力上，完善了兩個協作看板：產品發佈看板、環境看板。產品發佈看板以產品爲主視角，可以直觀看到產品的每個版本到了持續交付的哪個環節。環境看板則是以環境爲主視角，可以直觀看到每個環境下，有哪些產品版本在運行。
Sprint4（5月份）：5月份繼續豐富了一些尚未完善的能力，比如針對vue的代碼質量掃描等（sonarqube目前並不支持對於vue的代碼質量掃描），比如一些平臺級的功能如角色權限的配置、首頁看板的定製、操作日誌、密碼策略等等一些功能進行了完善。到此整個平臺的全部功能就已經完成交付。
Sprint5（6月份）：6月份是上線試運行階段，這個階段將20多個產品、30多個項目、50多個代碼庫都遷移到平臺上統一管理，做到了100%的持續集成、測試環境的自動化部署。並且在月尾的發佈窗口，選擇了一個試點應用成功通過平臺進行發佈上線。
我們也是第一次嘗試月迭代的方式，所以這個對於我們而言也是很大的一個挑戰。在這個過程中，也在不斷的思考和改進。
總結下一期的建設成果：
1.實現40+微服務的的持續集成、自動化部署
2.基於Scrum體系，統一管理20+產品、30+項目
3.統一持續交付流水線，9大環節，跨4大環境，驅動開發、測試、質量、運維、管理等多個角色協作
4.支撐PMO精益度量，多維度統計20+報表
二、平臺架構解析
總體架構解析
從邏輯上我們把DevOps平臺劃分爲三大領域：敏捷過程、持續交付、持續改進。
敏捷過程針對於軟件過程進行管理，包括產品、項目、團隊、計劃、任務等，持續交付則關注從需求到上線交付的管理，包括持續集成、自動化測試、自動化部署、交付流水線等。持續改進則體現了平臺的核心價值，不斷的度量和優化軟件過程，爲提升IT運行效率打下堅實的基礎。
在上面三大領域的基礎上，又做了一些模塊拆分，平臺的邏輯架構如下：
DevOps平臺劃分爲領域層、基礎服務層、工具層三層。工具層封裝了一些開源工具，提供基礎能力。服務層在此基礎上封裝的一些基礎服務，如編譯、部署、代碼管理等。領域層主要包括項目管理、產品管理、構建、部署、交付流水線、度量優化等模塊。底層運行環境支撐物理機、虛擬機、容器雲平臺。
產品管理&項目管理
軟件的整個生命週期可以從不僅僅是項目的生命週期，而是應該也包括了產品的生命週期。在企業內部，通常我們先決定做哪個產品，然後需求調研、版本劃分，確認了具體版本要實現的需求範圍後，便可以組建項目進行研發。研發完成進行交付後，有進入產品的線上運營階段。直至產品下線。一個產品可以對應多個項目，當然，對於有些企業而言，一個項目也是持續穩定的維護一個產品。
持續集成
持續集成模塊功能主要有代碼庫管理、構建定義管理以及構建實例管理等。在構建定義管理模塊中，DevOps平臺將構建任務分成了四種類型：
編譯類任務：Maven、Ant、Gradle、純前端構建等
測試類任務：Sonarqube、Jmeter、Selenium等
打包類任務：Npm、Archive、Docker等
其他工具類任務：Copyfile、Shell、介質提交到Nexus倉庫、介質上傳二方庫等。
在每個構建定義上可以選擇若干個需要的構建任務，通過原子步驟編排，組裝成一個完整構建流程。代碼提交時觸發構建（支持gitlab、github、svn等常用代碼庫版本管理工具）、日構建等不同的構建觸發策略等支撐了持續集成的完整鏈路打通。
自動化部署
在自動化部署模塊中，爲了更好的與實際結合，我們將部署分爲三個階段：設計、轉換、運維。
設計階段：將部署架構分爲三層：部署裝配（Assembly）、部署容器（Platform）、部署組件(Component)。部署裝配是對部署架構的描述，由多個部署容器組成，每個部署容器由若干個部署組件組成。
轉換階段：將部署架構與部署策略（全新、藍綠、灰度、滾動升級等）、資源（具體資源如物理機、虛擬機、容器）、組件配置參數（端口號、JVM參數、健康檢查url等）進行結合，生成部署計劃，一鍵執行自動化部署。
運維階段：對於已部署的實例進行運維管理，包括啓動、停止、重啓、修復、狀態檢查等等。
持續交付流水線
爲什麼需要持續交付流水線？舉個例子來說，我們常常苦惱最終上線版本和系統集成測試環境不一致。這一般是因爲在系統集成測試完成後發現了問題，作了代碼變更但沒有重新構建，而是直接在介質裏進行了調整進而發佈上線。在持續交付流水線中是不允許這種情況出現的。所有上線入口一定是最初的構建，所有的後續產物都是基於這一介質，如果有變更必須重走流程。這樣可以保證發佈的安全性和統一性，線上出現問題也是可以追溯的。當然過程中的環境可以配置人工介入或自動執行。
發佈流水線從構建到生產部署共9大環節，涵蓋SIT/UAT/LAB/PROD四大環境。驅動了開發、測試、質量、運維等多個角色的協作。
在設計流水線能力時，我們主要考慮到幾點：
結合企業的不同交付流程，要能支持自定義的流程配置，要能支持多套流程配置
流程的每一個環節都要支持自動執行的配置
流程中每個環節的屬性和配置信息可以自定義，靈活擴展
流程以構建開始，讓buildNumber貫穿整個流程，方便追根溯源
要有一個看板，直觀的看到整個產品的版本目前到了流程的哪個環節，是SIT還是UAT，結果如何
要有一個看板，直觀的看到每個環境下，有哪些介質在運行
以這些爲基礎準則，我們底層基於了我們的BPS流程引擎，支撐流程的自定義和擴展。並且，針對於每個環節，都可以配置前置後置事件、人工執行還是自動執行，責任人等。整個流水線從構建開始，保證全局介質唯一，避免人爲修改介質導致的生產介質不可追溯。
在交付看板上，環境看板和發佈看板如下
度量優化
精益運營的基礎是度量，度量的三大維度：指標、執行監控、預測。首先是明確指標和執行監控，基於軟件全生命週期的度量過程中企業遇到的最大困難莫過於拿不到完整的數據，各個部門、各個流程、各個系統之間數據相互隔閡，信息很難流通，導致無法從整體的角度對軟件過程進行度量。當DevOps平臺能打通企業的軟件生產全生命週期時，數據的割裂性問題自然也就不存在。當然，度量不僅僅是事後的統計分析，更應該提供過程監控的能力，在過程中，通過一些看板（比如任務看板、需求看板、發佈看板）、趨勢圖（比如任務燃盡圖、bug燃盡圖）等，提前預知風險，規避風險，持續把控項目質量和產品質量。
示例如下：
三、建設過程中的難點
難點1：統一流程和規範
回顧一下前文的發佈流水線的介紹，其實這其中我們在介紹時省略了大量的細節。比如，在開始構建時是否要打一個Tag，此時針對構建介質產物是否不應該是snapshot版本，而應該是Stage預發版本。如果UAT等測試通過之後，這個介質版本即爲可發佈版本，此時介質需要轉移到Release版本的介質倉庫。這就是一個完整的流程，也是需要加入到規範中去的。
梳理企業的流程和規範是企業建設DevOps的前提，甚至即使不建設DevOps平臺，這也是一個必不可少的行爲。只有統一了企業的流程和規範，才能建設出一個適用於企業的DevOps平臺，否則到最後，有可能會讓DevOps平臺脫離實際，導致沒有人會去使用。
我們在建設過程中，每一個模塊都需要結合萬達的流程規範以及我們的最佳實踐共同進行建設，在前期，當一些流程規範不是那麼明確的時候，還需要一起討論，同時規範也不是一蹴而就的，實施過程中發現一些不合適的地方就需要進行修改，這也就帶來了需求的反覆的可能。以持續交付流水線爲例，這個就需要結合萬達的環境、發佈規範來定製流程，對於其他企業而言，持續交付流水線未必就是這樣的一個流程，有可能會少一些環境，也有可能多個預發環境，又或者會把這一個流水線拆分成多個流水線。
難點2：異構兼容
對於應用運行環境而言，需要同時支撐物理機、虛擬機、容器雲、Android設備、IOS設備多種類型的環境。而應用本身又分爲純前端應用、SpringBoot應用（Fat JAR）、傳統應用（WAR）、Android、IOS等各種類型。這就對自動化部署框架提出了很高的要求，一套架構要能同時支撐異構應用部署在異構環境上。
以移動應用的自動化部署爲例，os部署組件可以用來區分系統、computer可以用於校驗機型。選擇部署資源時，從cmdb中導出項目的移動設備資源，最後將應用自動化部署到移動設備上。
難點3：職能切面
DevOps平臺建設之前，企業可能已經有不少系統了，比如雲資源管理平臺、容器云云平臺、自動化測試平臺、統一監控平臺等等。那麼很多時候一個困難點就在於DevOps的定位了，在測試的能力上，DevOps平臺要不要完整的把測試的能力都管理起來呢？在自動化部署的時候，要不要直接創建虛擬機對資源進行操作呢？我們在萬達落地DevOps的過程中，也遇到了這些問題。我們認爲：
DevOps無法讓每個人的工作都在上面，高級能力還是專人在專業系統上完成；
如果專業系統足夠自動和自助化，可考慮逐步納入DevOps平臺
我們做的是工程效率平臺，不是給多個系統做個統一門戶
本着這些理念，我們就明確了對職能的切分。像對底層資源的管理，是統一通過CMDB進行管理，DevOps只是進行資源的申請與使用。在測試環節，則是對接自動化測試平臺，將持續交付流水線中的測試環節拉起來，保障整個流水線的完整。在對已部署應用的監控，可以對接企業的統一監控平臺進行健康監控。
四、總結
雖然目前DevOps平臺已經完成初步交付，並且已經將所有的產品、項目統一通過平臺進行了管理。但是這僅僅做到了敏捷過程和持續交付。在持續改進領域還是有不少工作持續去做的，平臺目前在度量優化部分的能力還是稍顯不足，如何能完成最初的目標：”在兩年內提升IT運營效率50%“。還需要更加豐富、更加可量化的一些統計分析數據來支撐。而這，也是我們認爲DevOps最核心的價值，致力於提升企業IT運營效率。
關於作者
王海龍
現任普元信息高級研發工程師，畢業於華東師範大學，曾參與和負責銀聯Paas雲平臺項目、興業銀行CAP4J項目、交通銀行信用卡中心統一監控平臺項目、神華災備雲平臺、萬達DevOps平臺等項目。
關於EAWorld
微服務，DevOps，元數據，企業架構原創技術分享，EAii（Enterprise Architecture Innovation Institute）企業架構創新研究院旗下官方微信公衆號。
掃描下方二維碼，關注成功後，回覆“普元方法+”，將會獲得熱門課堂免費學習機會！
微信號：EAWorld，長按二維碼關注。
