企業(yè)DevOps平臺(tái)架構(gòu)解析

1、 m鶴學(xué)吧企業(yè)DevOps平臺(tái)架構(gòu)解析7中廠匕耳建設(shè)冃景企業(yè)項(xiàng)目研發(fā)管理成本相當(dāng)之高，傳統(tǒng)的管理方式很難高效率、高質(zhì)量的進(jìn)行管理和把控如此之多的產(chǎn)品和項(xiàng)目。并且隨著虛擬化、容器云、微服務(wù)等技術(shù)的發(fā)展，應(yīng)用底層的運(yùn)行環(huán)境愈發(fā)多樣化，物理機(jī)、虛擬機(jī)、容器云三種異構(gòu)環(huán)境、移動(dòng)應(yīng)用、Springboot應(yīng)用、純前端應(yīng)用等數(shù)十個(gè)異構(gòu)應(yīng)用都需要通過一個(gè)平臺(tái)進(jìn)行統(tǒng)一的部署和管理。建設(shè)目標(biāo)簡單可以歸納為如下三點(diǎn)：通過DevOps平臺(tái)統(tǒng)一管理所有產(chǎn)品、項(xiàng)目，對(duì)團(tuán)隊(duì)、對(duì)人能進(jìn)行數(shù)字化的考核實(shí)現(xiàn)所有應(yīng)用的持續(xù)集成、100%自動(dòng)化部署，提升應(yīng)用的軟件交付效率在兩年內(nèi)，將目前部門的研發(fā)、測試、運(yùn)維發(fā)布的工作效率提升50

2、%。建設(shè)過程項(xiàng)目從2月初開始，到6月底上線交付。持續(xù)了5個(gè)月的時(shí)間。項(xiàng)目過程基于Scrum過程體系，以月迭代的方式侮個(gè)月發(fā)布一個(gè)版本。同時(shí)，基于MVP的理念，保證每個(gè)月上線的版本功能都是可用的，不斷的完善平臺(tái)能力。每個(gè)沖刺過程如下：Sprint1（2月份）：2月份主要進(jìn)行了整體需求分析，完成我們現(xiàn)有產(chǎn)品的上線，以產(chǎn)品的現(xiàn)有能力作為第一個(gè)MVP版本。Sprint2（3月份）：3月份交付了產(chǎn)品管理、項(xiàng)目管理、持續(xù)集成等能力，并且最重要的，結(jié)合萬達(dá)的流程和規(guī)范，打通持續(xù)交付的流水線。流水線從構(gòu)建開始，一直到上線部署，有了持續(xù)交付流水線，即使中間的一些環(huán)節(jié)（如測試環(huán)境）暫時(shí)無法做到完全的自動(dòng)化測試，但

3、是可以通過人工的參與，自動(dòng)與人工結(jié)合，至少保障了整個(gè)軟件交付過程便已經(jīng)通過平臺(tái)管理起來。后續(xù)便可以此流水線為基準(zhǔn)，不斷的完善中間環(huán)節(jié)的自動(dòng)化能力。Sprint3（4月份）：完善了度量優(yōu)化、部署、流水線協(xié)作看板等能力。在度量優(yōu)化模塊，結(jié)合萬達(dá)的度量點(diǎn)和度量考核規(guī)范，從多個(gè)維度和視角，不斷提升平臺(tái)的度量能力。在部署管理模塊，首先結(jié)合萬達(dá)的環(huán)境資源規(guī)范，對(duì)接其CMDB系統(tǒng)，在DEV/LAB/SIT/UAT/PRE/PROD六大環(huán)境的基礎(chǔ)上，統(tǒng)一納管所有項(xiàng)目的環(huán)境資源。結(jié)合部署規(guī)范（操作系統(tǒng)、部署用戶權(quán)限、目錄要求、數(shù)據(jù)庫版本、jdk版本、nginx版本等），定制出符合萬達(dá)要求的自動(dòng)化部署能力。在流水

4、線能力上，完善了兩個(gè)協(xié)作看板：產(chǎn)品發(fā)布看板、環(huán)境看板。產(chǎn)品發(fā)布看板以產(chǎn)品為主視角，可以直觀看到產(chǎn)品的每個(gè)版本到了持續(xù)交付的哪個(gè)環(huán)節(jié)。環(huán)境看板則是以環(huán)境為主視角，可以直觀看到每個(gè)環(huán)境下，有哪些產(chǎn)品版本在運(yùn)行。Sprint4（5月份）：5月份繼續(xù)豐富了一些尚未完善的能力，比如針對(duì)vue的代碼質(zhì)量掃描等（sonarqube目前并不支持對(duì)于vue的代碼質(zhì)量掃描）,比如一些平臺(tái)級(jí)的功能如角色權(quán)限的配置、首頁看板的定制、操作日志、密碼策略等等一些功能進(jìn)行了完善。到此整個(gè)平臺(tái)的全部功能就已經(jīng)完成交付。Sprint5（6月份）：6月份是上線試運(yùn)行階段，這個(gè)階段將20多個(gè)產(chǎn)品、30多個(gè)項(xiàng)目、50多個(gè)代碼庫都遷移

5、到平臺(tái)上統(tǒng)一管理，做到了100%的持續(xù)集成、測試環(huán)境的自動(dòng)化部署。并且在月尾的發(fā)布窗口，選擇了一個(gè)試點(diǎn)應(yīng)用成功通過平臺(tái)進(jìn)行發(fā)布上線。我們也是第一次嘗試月迭代的方式，所以這個(gè)對(duì)于我們而言也是很大的一個(gè)挑戰(zhàn)。在這個(gè)過程中，也在不斷的思考和改進(jìn)?？偨Y(jié)下一期的建設(shè)成果：實(shí)現(xiàn)40+微服務(wù)的的持續(xù)集成、自動(dòng)化部署基于Scrum體系，統(tǒng)一管理20+產(chǎn)品、30+項(xiàng)目統(tǒng)一持續(xù)交付流水線，9大環(huán)節(jié)，跨4大環(huán)境，驅(qū)動(dòng)開發(fā)、測試、質(zhì)量、運(yùn)維、管理等多個(gè)角色協(xié)作支撐PMO精益度量，多維度統(tǒng)計(jì)20+報(bào)表平臺(tái)架構(gòu)解析總體架構(gòu)解析從邏輯上我們把DevOps平臺(tái)劃分為三大領(lǐng)域：敏捷過程、持續(xù)交付、持續(xù)改進(jìn)。敏捷過程針對(duì)于軟件過

6、程進(jìn)行管理，包括產(chǎn)品、項(xiàng)目、團(tuán)隊(duì)、計(jì)劃、任務(wù)等，持續(xù)交付則關(guān)注從需求到上線交付的管理，包括持續(xù)集成、自動(dòng)化測試、自動(dòng)化部署、交付流水線等。持續(xù)改進(jìn)則體現(xiàn)了平臺(tái)的核心價(jià)值，不斷的度量和優(yōu)化軟件過程，為提升IT運(yùn)行效率打下堅(jiān)實(shí)的基礎(chǔ)。在上面三大領(lǐng)域的基礎(chǔ)上，又做了一些模塊拆分，平臺(tái)的邏輯架構(gòu)如下：軟件的整個(gè)生命周期可以從不僅僅是項(xiàng)目的生命周期，而是應(yīng)該也包括了產(chǎn)品的生命周期。在企業(yè)內(nèi)部，通常我們先決定做哪個(gè)產(chǎn)品，然后需求調(diào)研、版本劃分，確認(rèn)了具體版本要實(shí)現(xiàn)的需求范圍后，便可以組建項(xiàng)目進(jìn)行研發(fā)。研發(fā)完成進(jìn)行交付后，有進(jìn)入產(chǎn)品的線上運(yùn)營階段。直至產(chǎn)品下線。一個(gè)產(chǎn)品可以對(duì)應(yīng)多個(gè)項(xiàng)目，當(dāng)然，對(duì)于有些企業(yè)而

7、言，一個(gè)項(xiàng)目也是持續(xù)穩(wěn)定的維護(hù)一個(gè)產(chǎn)品。持續(xù)集成支持代餾咬時(shí)構(gòu)逢/日閻進(jìn).打逓評(píng)竦整鳳蔬耳iwnsts遡i1Androidhrtml持續(xù)集成模塊功能主要有代碼庫管理、構(gòu)建定義管理以及構(gòu)建實(shí)例管理等。在構(gòu)建定義管理模塊中，DevOps平臺(tái)將構(gòu)建任務(wù)分成了四種類型：編譯類任務(wù)：Maven、Ant、Gradle、純前端構(gòu)建等測試類任務(wù)：Sonarqube、Jmeter、Selenium等打包類任務(wù)：Npm、Archive、Docker等其他工具類任務(wù)：Copyfile、Shell、介質(zhì)提交到Nexus倉庫、介質(zhì)上傳二方庫等。在每個(gè)構(gòu)建定義上可以選擇若干個(gè)需要的構(gòu)建任務(wù)，通過原子步驟編排，組裝成一個(gè)完

8、整構(gòu)建流程。代碼提交時(shí)觸發(fā)構(gòu)建（支持gitlab、github、svn等常用代碼庫版本管理工具、日構(gòu)建等不同的構(gòu)建觸發(fā)策略等支撐了持續(xù)集成的完整鏈路打通。自動(dòng)化部署在自動(dòng)化部署模塊中，為了更好的與實(shí)際結(jié)合，我們將部署分為三個(gè)階段：設(shè)計(jì)、轉(zhuǎn)換、運(yùn)維。J*F冷止BFtfiWWt郵薯設(shè)計(jì)觀I轉(zhuǎn)換Anw比設(shè)計(jì)階段：將部署架構(gòu)分為三層部署裝配Assembly）、部署容器（Platform）、部署組件（Component）。部署裝配是對(duì)部署架構(gòu)的描述，由多個(gè)部署容器組成，每個(gè)部署容器由若干個(gè)部署組件組成。轉(zhuǎn)換階段：將部署架構(gòu)與部署策略（全新、藍(lán)綠、灰度、滾動(dòng)升級(jí)等）、資源（具體資源如物理機(jī)、虛擬機(jī)、容器、

9、組件配置參數(shù)（端口號(hào)、JVM參數(shù)、健康檢查url等、進(jìn)行結(jié)合，生成部署計(jì)劃，一鍵執(zhí)行自動(dòng)化部署。運(yùn)維階段：對(duì)于已部署的實(shí)例進(jìn)行運(yùn)維管理，包括啟動(dòng)、停止、重啟、修復(fù)、狀態(tài)檢查等等。持續(xù)交付流水線為什么需要持續(xù)交付流水線？舉個(gè)例子來說，我們常?？鄲雷罱K上線版本和系統(tǒng)集成測試環(huán)境不一致。這一般是因?yàn)樵谙到y(tǒng)集成測試完成后發(fā)現(xiàn)了問題，作了代碼變更但沒有重新構(gòu)建，而是直接在介質(zhì)里進(jìn)行了調(diào)整進(jìn)而發(fā)布上線。在持續(xù)交付流水線中是不允許這種情況出現(xiàn)的。所有上線入口一定是最初的構(gòu)建，所有的后續(xù)產(chǎn)物都是基于這一介質(zhì)，如果有變更必須重走流程。這樣可以保證發(fā)布的安全性和統(tǒng)一性，線上出現(xiàn)問題也是可以追溯的。當(dāng)然過程中的環(huán)境

10、可以配置人工介入或自動(dòng)執(zhí)行。發(fā)布流水線從構(gòu)建到生產(chǎn)部署共9大環(huán)節(jié)，涵蓋SIT/UAT/LAB/PROD四大環(huán)境。驅(qū)動(dòng)了開發(fā)、測試、質(zhì)量、運(yùn)維等多個(gè)角色的協(xié)作。在設(shè)計(jì)流水線能力時(shí)，我們主要考慮到幾點(diǎn):結(jié)合企業(yè)的不同交付流程，要能支持自定義的流程配置，要能支持多套流程配置流程的每一個(gè)環(huán)節(jié)都要支持自動(dòng)執(zhí)行的配置流程中每個(gè)環(huán)節(jié)的屬性和配置信息可以自定義，靈活擴(kuò)展6mcs.LKtw*毎輕蛍*電。疑駟丘K-迢U忙州gs即迢U總迤只Y毀、營迢U唄湘量、翟舅iwca。枷Y史、Ihs蠱閻lh眨hyZSMSISI、雷、皿ft、-s-sdoagv徉H+M映世V徉、Ih逼曼圳賽、Kw克w麗*置m、回呂EK坡、一匸Ms

11、 度量優(yōu)化精益運(yùn)營的基礎(chǔ)是度量，度量的三大維度：指標(biāo)、執(zhí)行監(jiān)控、預(yù)測。首先是明確指標(biāo)和執(zhí)行監(jiān)控，基于軟件全生命周期的度量過程中企業(yè)遇到的最大困難莫過于拿不到完整的數(shù)據(jù)，各個(gè)部門、各個(gè)流程、各個(gè)系統(tǒng)之間數(shù)據(jù)相互隔閡，信息很難流通，導(dǎo)致無法從整體的角度對(duì)軟件過程進(jìn)行度量。當(dāng)DevOps平臺(tái)能打通企業(yè)的軟件生產(chǎn)全生命周期時(shí)，數(shù)據(jù)的割裂性問題自然也就不存在。當(dāng)然，度量不僅僅是事后的統(tǒng)計(jì)分析，更應(yīng)該提供過程監(jiān)控的能力，在過程中，通過一些看板（比如任務(wù)看板、需求看板、發(fā)布看板）、趨勢(shì)圖（比如任務(wù)燃盡圖、bug燃盡圖）等，提前預(yù)知風(fēng)險(xiǎn)，規(guī)避風(fēng)險(xiǎn)，持續(xù)把控項(xiàng)目質(zhì)量和產(chǎn)品質(zhì)量。示例如下：m舞咽回顧一下前文的發(fā)布

12、流水線的介紹，其實(shí)這其中我們?cè)诮榻B時(shí)省略了大量的細(xì)節(jié)。比如，在開始構(gòu)建時(shí)是否要打一個(gè)Tag，此時(shí)針對(duì)構(gòu)建介質(zhì)產(chǎn)物是否不應(yīng)該是snapshot版本，而應(yīng)該是Stage預(yù)發(fā)版本。如果UAT等測試通過之后，這個(gè)介質(zhì)版本即為可發(fā)布版本，此時(shí)介質(zhì)需要轉(zhuǎn)移到Release版本的介質(zhì)倉庫。這就是一個(gè)完整的流程，也是需要加入到規(guī)范中去的。梳理企業(yè)的流程和規(guī)范是企業(yè)建設(shè)DevOps的前提，甚至即使不建設(shè)DevOps平臺(tái)，這也是一個(gè)必不可少的行為。只有統(tǒng)一了企業(yè)的流程和規(guī)范，才能建設(shè)出一個(gè)適用于企業(yè)的DevOps平臺(tái)，否則到最后，有可能會(huì)讓DevOps平臺(tái)脫離實(shí)際，導(dǎo)致沒有人會(huì)去使用。我們?cè)诮ㄔO(shè)過程中，每一個(gè)模塊

13、都需要結(jié)合萬達(dá)的流程規(guī)范以及我們的最佳實(shí)踐共同進(jìn)行建設(shè)，在前期，當(dāng)一些流程規(guī)范不是那么明確的時(shí)候，還需要一起討論，同時(shí)規(guī)范也不是一蹴而就的，實(shí)施過程中發(fā)現(xiàn)一些不合適的地方就需要進(jìn)行修改，這也就帶來了需求的反復(fù)的可能。以持續(xù)交付流水線為例，這個(gè)就需要結(jié)合萬達(dá)的環(huán)境、發(fā)布規(guī)范來定制流程，對(duì)于其他企業(yè)而言，持續(xù)交付流水線未必就是這樣的一個(gè)流程，有可能會(huì)少一些環(huán)境，也有可能多個(gè)預(yù)發(fā)環(huán)境，又或者會(huì)把這一個(gè)流水線拆分成多個(gè)流水線。難點(diǎn)2:異構(gòu)兼容期理機(jī)虔擬機(jī)r1L1畀構(gòu)應(yīng)用自動(dòng)化部憲框架福要支撐異構(gòu)環(huán)境、對(duì)于應(yīng)用運(yùn)行環(huán)境而言，需要同時(shí)支撐物理機(jī)、虛擬機(jī)、容器云、Android設(shè)備、IOS設(shè)備多種類型的環(huán)境

14、。而應(yīng)用本身又分為純前端應(yīng)用、SpringBoot應(yīng)用（FatJAR）、傳統(tǒng)應(yīng)用（WAR）、Android、IOS等各種類型。這就對(duì)自動(dòng)化部署框架提出了很高的要求，一套架構(gòu)要能同時(shí)支撐異構(gòu)應(yīng)用部署在異構(gòu)環(huán)境上。m吧以移動(dòng)應(yīng)用的自動(dòng)化部署為例，OS部署組件可以用來區(qū)分系統(tǒng)、computer可以用于校驗(yàn)機(jī)型。選擇部署資源時(shí)，從cmdb中導(dǎo)出項(xiàng)目的移動(dòng)設(shè)備資源，最后將應(yīng)用自動(dòng)化部署到移動(dòng)設(shè)備上。難點(diǎn)3:職能切面自動(dòng)化運(yùn)維平臺(tái)自動(dòng)化測統(tǒng)一監(jiān)控流程平臺(tái)試平臺(tái)平臺(tái)統(tǒng)一賬戶平臺(tái)RSBWIDevOps環(huán)境耳資源堂湮CMDB平旨kuberntesDevOps平臺(tái)建設(shè)之前，企業(yè)可能已經(jīng)有不少系統(tǒng)了，比如云資源管理

15、平臺(tái)、容器云云平臺(tái)、自動(dòng)化測試平臺(tái)、統(tǒng)一監(jiān)控平臺(tái)等等。那么很多時(shí)候一個(gè)困難點(diǎn)就在于DevOps的定位了,在測試的能力上QevOps平臺(tái)要不要完整的把測試的能力都管理起來呢？在自動(dòng)化部署的時(shí)候，要不要直接創(chuàng)建虛擬機(jī)對(duì)資源進(jìn)行操作呢？我們?cè)谌f達(dá)落地DevOps的過程中，也遇到了這些問題。我們認(rèn)為：DevOps無法讓每個(gè)人的工作都在上面，高級(jí)能力還是專人在專業(yè)系統(tǒng)上完成；如果專業(yè)系統(tǒng)足夠自動(dòng)和自助化，可考慮逐步納入DevOps平臺(tái)我們做的是工程效率平臺(tái)，不是給多個(gè)系統(tǒng)做個(gè)統(tǒng)一門戶本著這些理念我們就明確了對(duì)職能的切分。像對(duì)底層資源的管理是統(tǒng)一通過CMDB進(jìn)行管理DevOps只是進(jìn)行資源的申請(qǐng)與使用。在測試環(huán)節(jié)，則是對(duì)接自動(dòng)化測試平臺(tái)，將持續(xù)交付流水線中的測試環(huán)節(jié)拉起來，保障