背景

幾年前運(yùn)維迎來業(yè)務(wù)上的一次融合，從而倒逼后端的IT能力進(jìn)行整合。因?yàn)橄到y(tǒng)間的依賴關(guān)系，另外運(yùn)行環(huán)境也有差別，導(dǎo)致系統(tǒng)遷移后無法使用，因此在不改變當(dāng)前發(fā)布模式的情況下，需要重建依賴的運(yùn)維平臺體系并進(jìn)行改造，需求由此而生并隨著業(yè)務(wù)發(fā)展向外擴(kuò)展。本文將帶大家去了解平臺從過去到現(xiàn)在，新的設(shè)計(jì)方案如何融合到現(xiàn)有體系中?重新設(shè)計(jì)后的平臺又帶來了什么樣的變化?在建設(shè)的過程中，團(tuán)隊(duì)又獲得了什么樣的心得和體驗(yàn)?

當(dāng)前現(xiàn)狀

融合時(shí)期保留了發(fā)布部署系統(tǒng)，業(yè)務(wù)調(diào)度，DB需求與執(zhí)行平臺和配置中心，這就帶來兩個(gè)問題：

1. 運(yùn)行環(huán)境不同，所有系統(tǒng)需要修改重編保證在新平臺的穩(wěn)定運(yùn)行

2. 發(fā)布部署系統(tǒng)等強(qiáng)依賴CMDB的設(shè)備與業(yè)務(wù)的關(guān)系，從而管控發(fā)布流程

因此為了保證業(yè)務(wù)能夠正常迭代，需要重建關(guān)鍵路徑，經(jīng)過兩年的努力，目前體系組成大致框架如下所示，部分是融合之前電商的系統(tǒng)，部分是新搭建的平臺：

1. CMDB

與其他互聯(lián)網(wǎng)公司類似，通過底層CMDB構(gòu)建設(shè)備與業(yè)務(wù)、設(shè)備與人的關(guān)系，設(shè)備生命周期、生命狀態(tài)的記錄，進(jìn)而以資源管理系統(tǒng)的角色提供信息給其他所有系統(tǒng)調(diào)用。對于CMDB數(shù)據(jù)的維護(hù)，我們通過多種系統(tǒng)與其聯(lián)動反向保證數(shù)據(jù)準(zhǔn)確性，比如與RPM包發(fā)布的聯(lián)動：

因?yàn)槿诤锨跋到y(tǒng)依賴的CMDB為業(yè)務(wù)型CMDB，因此我們重建時(shí)也以業(yè)務(wù)CMDB為目標(biāo)。

2. 配置中心

配置中心為留存下來的重要系統(tǒng)，管理訪問路由和DB路由信息，負(fù)責(zé)負(fù)載均衡、業(yè)務(wù)容災(zāi)、以及所有業(yè)務(wù)包的基礎(chǔ)配置、業(yè)務(wù)間調(diào)用、DB路由訪問與自動切換等配置信息的版本管理和下發(fā)、以及設(shè)備角色的管理，通過配置agent完成配置中心到目標(biāo)機(jī)器內(nèi)存的下發(fā)。大致架構(gòu)圖如下圖所示：

Configprocessor采用多線程模型，并行處理configagent和jsf的事務(wù)，用戶通過門戶輸入配置中心并提交至DB交由server讀取，agent與serer保持長連接，會定期發(fā)送本地共享內(nèi)存的時(shí)間戳到server，server判斷時(shí)間戳是否過時(shí)，過時(shí)則發(fā)送新的配置文件內(nèi)容到agent，agent將配置信息更新至共享內(nèi)存并刷新時(shí)間戳，另外server也會主動將配置信息下發(fā)至agent，共享內(nèi)存中維護(hù)互斥鎖，保證更新不沖突。此外配置中心還支持白名單功能，對配置進(jìn)行灰度。

3. 調(diào)度系統(tǒng)

負(fù)責(zé)對設(shè)備的命令執(zhí)行和文件下發(fā)，其他系統(tǒng)任何的文件或者命令下發(fā)動作，都集中通過調(diào)度系統(tǒng)去處理，這樣做的好處就是可追蹤，權(quán)限可控且返回日志統(tǒng)一。比如DB需求自動執(zhí)行平臺，需求者提出需求后，平臺初審?fù)戤吔挥蒁BA審批，審批完畢后需求平臺將SQL打包為腳本，通過調(diào)度平臺傳遞到目的端執(zhí)行，并返回結(jié)果。

4. 應(yīng)用持續(xù)部署

應(yīng)用部署我們采用的是RPM的方案，目前也是業(yè)界少有的采用開源包管理方案，主要的考慮點(diǎn)是：

1. RPM作為開源界通用的方案已經(jīng)非常成熟，開發(fā)可以自由在spec文件中安裝前，安裝后，卸載后等各階段的動作進(jìn)行定義

2. 通過在spec文件中標(biāo)注包所屬組的概念，可以很好地管控包發(fā)布權(quán)限

3. 通過在spec中定義Requires，可以方便的管理依賴關(guān)系，平臺不再維護(hù)復(fù)雜的包依賴。

目前研發(fā)通過JATS對C++包進(jìn)行編譯，然后通過RPM將編譯成功的二進(jìn)制文件進(jìn)行RPM包的打包，通過包發(fā)布對設(shè)備角色(dev，gamma，idc) 和人員(開發(fā)，測試，運(yùn)維)角色進(jìn)行定義并做相應(yīng)發(fā)布，管控發(fā)布流程。EOS則是運(yùn)營人員對頁面片和CDN的發(fā)布和回滾，通過配置中心區(qū)分設(shè)備角色，再進(jìn)行相應(yīng)頁面片文件的下發(fā)。安全掃描包括CGI，域名的掃描，定時(shí)發(fā)起線上漏洞掃描，保證業(yè)務(wù)安全。

5. 質(zhì)量監(jiān)控平臺

GMS基礎(chǔ)監(jiān)控平臺根據(jù)openfalcon開源修改，對實(shí)體機(jī)和docker進(jìn)行基礎(chǔ)項(xiàng)、組件和自定義的監(jiān)控告警，日志監(jiān)控目前自研平臺，通過對日志的采集過濾和統(tǒng)計(jì)，接入GMS基礎(chǔ)監(jiān)控平臺，對nginx日志進(jìn)行監(jiān)控，紅綠燈系統(tǒng)監(jiān)控為業(yè)務(wù)維度的監(jiān)控，通過集團(tuán)的可用率上報(bào)細(xì)化到業(yè)務(wù)的健康狀態(tài)管理，模調(diào)系統(tǒng)借助配置中心的業(yè)務(wù)間調(diào)用關(guān)系完成調(diào)用鏈的梳理和調(diào)用環(huán)節(jié)的可用率統(tǒng)計(jì)。容量管理通過GMS基礎(chǔ)監(jiān)控的數(shù)據(jù)，進(jìn)行設(shè)備和業(yè)務(wù)維度的負(fù)載率計(jì)算和高低負(fù)載管理。

6. DB管理平臺

深圳側(cè)DB層主要為mysql與redis，所以圍繞這兩個(gè)做了DB需求自動化執(zhí)行，備份中心和自研redis集群的實(shí)例管理。

下面針對這些平臺的搭建和改造歷程做下大致闡述：

融合方案

業(yè)務(wù)整合以后，業(yè)務(wù)需要快速迭代，效率為先，通過對系統(tǒng)的依賴梳理，我們確定了從下而上先填補(bǔ)再擴(kuò)充的方案。即從***層的CMDB開始向上，填補(bǔ)掉現(xiàn)有系統(tǒng)強(qiáng)依賴的關(guān)鍵路徑，再去建設(shè)缺少部分。***階段我們決定重建一個(gè)小型的CMDB，用于解決大多數(shù)留存系統(tǒng)的關(guān)鍵依賴;第二階段為確保留存系統(tǒng)正常運(yùn)轉(zhuǎn)，以保證業(yè)務(wù)快速迭代上線;第三階段我們著重質(zhì)量上的提升，下面對三個(gè)階段做簡單介紹：

***階段：重建小型CMDB

關(guān)于CMDB系統(tǒng)，用途上通常分為兩層，面向基礎(chǔ)設(shè)施的資源管理系統(tǒng)和面向業(yè)務(wù)的資源管理系統(tǒng)，對于京東深圳業(yè)務(wù)部門主要偏向業(yè)務(wù)層，因此系統(tǒng)建設(shè)主要偏向面向業(yè)務(wù)，基礎(chǔ)設(shè)施層則由集團(tuán)進(jìn)行管理。為了快速匹配現(xiàn)有系統(tǒng)實(shí)現(xiàn)核心需求，CMDB的業(yè)務(wù)標(biāo)示沿用之前方式，利用模塊樹進(jìn)行管理，按照深圳業(yè)務(wù)三層模塊進(jìn)行標(biāo)示。如圖所示：

作為面向業(yè)務(wù)的資源管理，數(shù)據(jù)變動頻繁，可維護(hù)性非常重要，在業(yè)務(wù)部門沒有機(jī)房自動發(fā)現(xiàn)，拓?fù)浍@取權(quán)限的情況下，主要通過資源共享來保證數(shù)據(jù)準(zhǔn)確。通過對外提供API進(jìn)行資源共享和維護(hù)，比如維護(hù)設(shè)備狀態(tài)，設(shè)備負(fù)責(zé)人數(shù)據(jù)用于監(jiān)控系統(tǒng)的判定和推送;維護(hù)模塊環(huán)境屬性用于RPM包系統(tǒng)的包發(fā)布判定測試與IDC環(huán)境，便于發(fā)布的管控，從而反向保證數(shù)CMDB據(jù)的準(zhǔn)確性。

目前CMDB管理23個(gè)屬性，包括設(shè)備屬性(IP，配置信息，機(jī)房)，設(shè)備與業(yè)務(wù)關(guān)系(業(yè)務(wù)模塊，所屬集群)，設(shè)備與人的關(guān)系(運(yùn)維負(fù)責(zé)人，所屬研發(fā))，設(shè)備生命狀態(tài)(維護(hù)，運(yùn)營)，生命周期(流轉(zhuǎn)記錄)等，基本標(biāo)示了當(dāng)前設(shè)備的畫像。當(dāng)然這里還需要與RPM包發(fā)布，配置中心結(jié)合起來，管理服務(wù)包與基礎(chǔ)包的信息等。

第二階段：確保留存系統(tǒng)正常運(yùn)轉(zhuǎn)

留存系統(tǒng)主要為配置中心和發(fā)布部署系統(tǒng)，篇幅所限這里只介紹RPM系統(tǒng)，目前系統(tǒng)完成打包，包信息登記，版本管理，發(fā)布與回滾，權(quán)限控制等動作，目前管理包1200余個(gè)，兩年時(shí)間中支持發(fā)布7w次， 很好地完成了日常包發(fā)布和緊急擴(kuò)容等需求，簡單架構(gòu)如下：

dashboard如下：

目前我們也在考慮對現(xiàn)存RPM系統(tǒng)的改造，如今已經(jīng)大規(guī)模應(yīng)用docker，如何將包發(fā)布與docker充分結(jié)合，發(fā)揮docker快速交付的優(yōu)勢是需要優(yōu)化的地方。

第三階段：質(zhì)量優(yōu)化與提升

業(yè)務(wù)系統(tǒng)可用后，我們開始進(jìn)行擴(kuò)充，首先考慮提升質(zhì)量，主要是建立一套自下而上的立體化監(jiān)控，運(yùn)維主要負(fù)責(zé)***兩層的搭建并向上提供API。

任何監(jiān)控，數(shù)據(jù)為先，因此著重匯聚各種數(shù)據(jù)來源，并進(jìn)行整合，主要為CMDB、采集agent、配置中心調(diào)用關(guān)系、集團(tuán)UMP數(shù)據(jù)上報(bào)點(diǎn)等四者進(jìn)行關(guān)聯(lián)。

基礎(chǔ)設(shè)施層和基礎(chǔ)組件監(jiān)控系統(tǒng)

各種考察之后采用了小米開源的openfalcon并進(jìn)行了改造。改造點(diǎn)如下：

1. agent同時(shí)適配實(shí)體機(jī)與docker

2. 打通CMDB并新建API方便未來容量系統(tǒng)進(jìn)行數(shù)據(jù)共享，打通自研的告警網(wǎng)關(guān)(郵件、短信、微信)

3. 將系統(tǒng)改造成主要面向應(yīng)用/模塊的監(jiān)控

4. 擴(kuò)展服務(wù)組件監(jiān)控的功能，對nginx，mysql，redis和其他自研組件做特別收集

5. 方便插件開發(fā)和使用

系統(tǒng)建設(shè)期間面臨的***個(gè)問題就是京東當(dāng)時(shí)正在大規(guī)模采用docker，這對于傳統(tǒng)的采集agent不再適用，為了避免不同類型設(shè)備割裂為不同系統(tǒng)的情況，對agent端進(jìn)行了改造，采取相同匯報(bào)格式不同采集方式，鑒于對母機(jī)沒有權(quán)限下放，與南京云平臺合作，實(shí)體機(jī)采取傳統(tǒng)采集，docker采用api數(shù)據(jù)并整合，對二者監(jiān)控項(xiàng)進(jìn)行了統(tǒng)一，從而表現(xiàn)形式上實(shí)現(xiàn)了統(tǒng)一。

目前監(jiān)控上報(bào)設(shè)備基礎(chǔ)監(jiān)控項(xiàng)，比如CPU，內(nèi)存，丟包率，重傳率，文件節(jié)點(diǎn)，coredump等，另外對服務(wù)組件有特殊的上報(bào)內(nèi)容，比如nginx的nginx.conn.active， nginx.conn.reading等。

為了保證告警有效性，我們通過不同應(yīng)用的個(gè)性化監(jiān)控策略，維持每日基礎(chǔ)告警數(shù)在20-50之間，從而保證運(yùn)維對告警的敏感度。下圖為dashboard：

如下圖按照模塊的綜合視圖，用戶在大批量的橫向?qū)Ρ戎袑?shù)字的敏感度要高于圖線敏感度，因此我們將數(shù)字設(shè)為首屏，圖線作為第二入口提供趨勢的查看

下圖組件監(jiān)控的部署流程，以nginx為例：

日志分析目前正在完善，由于架構(gòu)特殊性，需要對nginx日志做二次處理，因此在收集端做了開發(fā)，消費(fèi)者log-viewer采用多進(jìn)程處理，便于錯(cuò)誤日志過多時(shí)消息隊(duì)列擁塞，目前架構(gòu)圖如下：

日志分析中的域名錯(cuò)誤數(shù)監(jiān)控：

應(yīng)用層監(jiān)控

通過紅綠燈系統(tǒng)來承擔(dān)，根據(jù)集團(tuán)的UMP業(yè)務(wù)監(jiān)控系統(tǒng)數(shù)據(jù)做了整合，直觀的按照紅黃綠三色做標(biāo)示

接口層監(jiān)控

接口層監(jiān)控系統(tǒng)根據(jù)上文的配置中心，梳理出調(diào)用關(guān)系，再根據(jù)ump上報(bào)，計(jì)算出當(dāng)前可用率

心得

隨著進(jìn)入京東的體系之后，我們重新審視，如何用大電商平臺化的思維來持續(xù)優(yōu)化我們的平臺，比如說精細(xì)化的管理和監(jiān)控，持續(xù)交付Docker化。我們都知道目前京東是國內(nèi)Docker使用最兇猛的公司，Docker作為一種新的IT對象，對原有的持續(xù)部署、CMDB、監(jiān)控、數(shù)據(jù)分析等平臺都提出了新的體系和要求。

其實(shí)世界上最痛苦的事情就是莫過于做遺留系統(tǒng)整合的事情了，我們用一年多時(shí)間來完成了這次的整合、遷移和新業(yè)務(wù)上線。其中涉及到底層服務(wù)器數(shù)千臺，業(yè)務(wù)模塊300多個(gè)，應(yīng)用100多個(gè)的能力遷移，有挑戰(zhàn)，更是慢慢的收獲與心得。

運(yùn)維系統(tǒng)的搭建過程是一個(gè)從運(yùn)維到運(yùn)營觀念轉(zhuǎn)變過程。

當(dāng)通過標(biāo)準(zhǔn)化對具體的設(shè)備和抽象的業(yè)務(wù)進(jìn)行規(guī)范，搭建起來基本的持續(xù)交付系統(tǒng)，采集到各項(xiàng)數(shù)據(jù)做監(jiān)控之后，如何利用現(xiàn)有系統(tǒng)更進(jìn)一步的提升效率，利用數(shù)據(jù)為業(yè)務(wù)提供更多的參考支持是更進(jìn)一步需要思考的能力;比如如何利用RPM更進(jìn)一步快速交付擴(kuò)容讓開發(fā)滿意，如何更精細(xì)的收集日志分析數(shù)據(jù)使研發(fā)對自己的CGI使用有更多的了解，這些都是運(yùn)維需要考慮的問題。

CMDB的分層解耦很重要

一定要把CMDB區(qū)分出基礎(chǔ)資源管理型CMDB和業(yè)務(wù)型CMDB，面向上層應(yīng)用的CMDB可以脫離底層基礎(chǔ)資源層的CMDB而存在，通過自己的一套數(shù)據(jù)自動化發(fā)現(xiàn)和運(yùn)維變更體系來完善CMDB數(shù)據(jù)。強(qiáng)依賴是上層運(yùn)維管理平臺遷移的***障礙。

自上而下的業(yè)務(wù)驅(qū)動產(chǎn)生需求和自下而上的系統(tǒng)建設(shè)分而治之

這一點(diǎn)在業(yè)務(wù)融合中非常明顯，當(dāng)有一個(gè)相對成熟的中間系統(tǒng)時(shí)，如何才能保證系統(tǒng)穩(wěn)定并以此為核心擴(kuò)展，這一需求從上而下發(fā)生，并且需要建設(shè)者自下而上的建設(shè)。

每個(gè)系統(tǒng)都是一個(gè)資源池，通過系統(tǒng)關(guān)聯(lián)進(jìn)行資源池共享才能盤活系統(tǒng)，保證系統(tǒng)高效準(zhǔn)確的運(yùn)轉(zhuǎn)，而不是淪落為一個(gè)工具平臺

系統(tǒng)建立起來后維護(hù)非常重要，加強(qiáng)系統(tǒng)間依賴是減輕系統(tǒng)維護(hù)的一個(gè)重要方式，也是盤活平臺的關(guān)鍵路徑，比如RPM系統(tǒng)如何與CMDB聯(lián)動，數(shù)據(jù)采集端的數(shù)據(jù)提供上來后，監(jiān)控、容量管理、CMDB三者結(jié)合很容易為IT運(yùn)營分析做支撐。

運(yùn)維系統(tǒng)的設(shè)計(jì)多咨詢研發(fā)和業(yè)務(wù)產(chǎn)品經(jīng)理

這里的咨詢不只包括技術(shù)上的，也是使用上的，業(yè)務(wù)研發(fā)和產(chǎn)品經(jīng)理作為最靠近用戶的一端，對原型設(shè)計(jì)，系統(tǒng)使用上如何影響用戶比運(yùn)維要專業(yè)，何況運(yùn)維平臺的用戶也來自研發(fā)，一個(gè)對用戶方便的系統(tǒng)比較容易推廣使用，也容易受到反饋，當(dāng)然，記得任何系統(tǒng)都要把反饋入口放在顯眼位置：)

運(yùn)維平臺建設(shè)也是一個(gè)迭代和演進(jìn)的過程

如果沒有業(yè)務(wù)變更，就沒有此次平臺的迭代;如果沒有Docker快速的引入，就無需對RPM平臺進(jìn)行演進(jìn)。因此運(yùn)維平臺本身也和業(yè)務(wù)技術(shù)架構(gòu)一樣，隨著業(yè)務(wù)和技術(shù)的變化，本身也在強(qiáng)調(diào)適應(yīng)性。