背景

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

當前現狀

融合時期保留了發布部署系統，業務調度，DB需求與執行平臺和配置中心，這就帶來兩個問題：

1. 運行環境不同，所有系統需要修改重編保證在新平臺的穩定運行

2. 發布部署系統等強依賴CMDB的設備與業務的關系，從而管控發布流程

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

1. CMDB

與其他互聯網公司類似，通過底層CMDB構建設備與業務、設備與人的關系，設備生命周期、生命狀態的記錄，進而以資源管理系統的角色提供信息給其他所有系統調用。對于CMDB數據的維護，我們通過多種系統與其聯動反向保證數據準確性，比如與RPM包發布的聯動：

因為融合前系統依賴的CMDB為業務型CMDB，因此我們重建時也以業務CMDB為目標。

2. 配置中心

配置中心為留存下來的重要系統，管理訪問路由和DB路由信息，負責負載均衡、業務容災、以及所有業務包的基礎配置、業務間調用、DB路由訪問與自動切換等配置信息的版本管理和下發、以及設備角色的管理，通過配置agent完成配置中心到目標機器內存的下發。大致架構圖如下圖所示：

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

3. 調度系統

負責對設備的命令執行和文件下發，其他系統任何的文件或者命令下發動作，都集中通過調度系統去處理，這樣做的好處就是可追蹤，權限可控且返回日志統一。比如DB需求自動執行平臺，需求者提出需求后，平臺初審完畢交由DBA審批，審批完畢后需求平臺將SQL打包為腳本，通過調度平臺傳遞到目的端執行，并返回結果。

4. 應用持續部署

應用部署我們采用的是RPM的方案，目前也是業界少有的采用開源包管理方案，主要的考慮點是：

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

2. 通過在spec文件中標注包所屬組的概念，可以很好地管控包發布權限

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

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

5. 質量監控平臺

GMS基礎監控平臺根據openfalcon開源修改，對實體機和docker進行基礎項、組件和自定義的監控告警，日志監控目前自研平臺，通過對日志的采集過濾和統計，接入GMS基礎監控平臺，對nginx日志進行監控，紅綠燈系統監控為業務維度的監控，通過集團的可用率上報細化到業務的健康狀態管理，模調系統借助配置中心的業務間調用關系完成調用鏈的梳理和調用環節的可用率統計。容量管理通過GMS基礎監控的數據，進行設備和業務維度的負載率計算和高低負載管理。

6. DB管理平臺

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

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

融合方案

業務整合以后，業務需要快速迭代，效率為先，通過對系統的依賴梳理，我們確定了從下而上先填補再擴充的方案。即從最底層的CMDB開始向上，填補掉現有系統強依賴的關鍵路徑，再去建設缺少部分。第一階段我們決定重建一個小型的CMDB，用于解決大多數留存系統的關鍵依賴;第二階段為確保留存系統正常運轉，以保證業務快速迭代上線;第三階段我們著重質量上的提升，下面對三個階段做簡單介紹：

第一階段：重建小型CMDB

關于CMDB系統，用途上通常分為兩層，面向基礎設施的資源管理系統和面向業務的資源管理系統，對于京東深圳業務部門主要偏向業務層，因此系統建設主要偏向面向業務，基礎設施層則由集團進行管理。為了快速匹配現有系統實現核心需求，CMDB的業務標示沿用之前方式，利用模塊樹進行管理，按照深圳業務三層模塊進行標示。如圖所示：

作為面向業務的資源管理，數據變動頻繁，可維護性非常重要，在業務部門沒有機房自動發現，拓撲獲取權限的情況下，主要通過資源共享來保證數據準確。通過對外提供API進行資源共享和維護，比如維護設備狀態，設備負責人數據用于監控系統的判定和推送;維護模塊環境屬性用于RPM包系統的包發布判定測試與IDC環境，便于發布的管控，從而反向保證數CMDB據的準確性。

目前CMDB管理23個屬性，包括設備屬性(IP，配置信息，機房)，設備與業務關系(業務模塊，所屬集群)，設備與人的關系(運維負責人，所屬研發)，設備生命狀態(維護，運營)，生命周期(流轉記錄)等，基本標示了當前設備的畫像。當然這里還需要與RPM包發布，配置中心結合起來，管理服務包與基礎包的信息等。

第二階段：確保留存系統正常運轉

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

dashboard如下：

目前我們也在考慮對現存RPM系統的改造，如今已經大規模應用docker，如何將包發布與docker充分結合，發揮docker快速交付的優勢是需要優化的地方。

第三階段：質量優化與提升

業務系統可用后，我們開始進行擴充，首先考慮提升質量，主要是建立一套自下而上的立體化監控，運維主要負責最低兩層的搭建并向上提供API。

任何監控，數據為先，因此著重匯聚各種數據來源，并進行整合，主要為CMDB、采集agent、配置中心調用關系、集團UMP數據上報點等四者進行關聯。

基礎設施層和基礎組件監控系統

各種考察之后采用了小米開源的openfalcon并進行了改造。改造點如下：

1. agent同時適配實體機與docker

2. 打通CMDB并新建API方便未來容量系統進行數據共享，打通自研的告警網關(郵件、短信、微信)

3. 將系統改造成主要面向應用/模塊的監控

4. 擴展服務組件監控的功能，對nginx，mysql，redis和其他自研組件做特別收集

5. 方便插件開發和使用

系統建設期間面臨的第一個問題就是京東當時正在大規模采用docker，這對于傳統的采集agent不再適用，為了避免不同類型設備割裂為不同系統的情況，對agent端進行了改造，采取相同匯報格式不同采集方式，鑒于對母機沒有權限下放，與南京云平臺合作，實體機采取傳統采集，docker采用api數據并整合，對二者監控項進行了統一，從而表現形式上實現了統一。

目前監控上報設備基礎監控項，比如CPU，內存，丟包率，重傳率，文件節點，coredump等，另外對服務組件有特殊的上報內容，比如nginx的nginx.conn.active， nginx.conn.reading等。

為了保證告警有效性，我們通過不同應用的個性化監控策略，維持每日基礎告警數在20-50之間，從而保證運維對告警的敏感度。下圖為dashboard：

如下圖按照模塊的綜合視圖，用戶在大批量的橫向對比中對數字的敏感度要高于圖線敏感度，因此我們將數字設為首屏，圖線作為第二入口提供趨勢的查看

下圖組件監控的部署流程，以nginx為例：

日志分析目前正在完善，由于架構特殊性，需要對nginx日志做二次處理，因此在收集端做了開發，消費者log-viewer采用多進程處理，便于錯誤日志過多時消息隊列擁塞，目前架構圖如下：

日志分析中的域名錯誤數監控：

應用層監控

通過紅綠燈系統來承擔，根據集團的UMP業務監控系統數據做了整合，直觀的按照紅黃綠三色做標示

接口層監控

接口層監控系統根據上文的配置中心，梳理出調用關系，再根據ump上報，計算出當前可用率

心得

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

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

運維系統的搭建過程是一個從運維到運營觀念轉變過程。

當通過標準化對具體的設備和抽象的業務進行規范，搭建起來基本的持續交付系統，采集到各項數據做監控之后，如何利用現有系統更進一步的提升效率，利用數據為業務提供更多的參考支持是更進一步需要思考的能力;比如如何利用RPM更進一步快速交付擴容讓開發滿意，如何更精細的收集日志分析數據使研發對自己的CGI使用有更多的了解，這些都是運維需要考慮的問題。

CMDB的分層解耦很重要

一定要把CMDB區分出基礎資源管理型CMDB和業務型CMDB，面向上層應用的CMDB可以脫離底層基礎資源層的CMDB而存在，通過自己的一套數據自動化發現和運維變更體系來完善CMDB數據。強依賴是上層運維管理平臺遷移的最大障礙。

自上而下的業務驅動產生需求和自下而上的系統建設分而治之

這一點在業務融合中非常明顯，當有一個相對成熟的中間系統時，如何才能保證系統穩定并以此為核心擴展，這一需求從上而下發生，并且需要建設者自下而上的建設。

每個系統都是一個資源池，通過系統關聯進行資源池共享才能盤活系統，保證系統高效準確的運轉，而不是淪落為一個工具平臺

系統建立起來后維護非常重要，加強系統間依賴是減輕系統維護的一個重要方式，也是盤活平臺的關鍵路徑，比如RPM系統如何與CMDB聯動，數據采集端的數據提供上來后，監控、容量管理、CMDB三者結合很容易為IT運營分析做支撐。

運維系統的設計多咨詢研發和業務產品經理

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

運維平臺建設也是一個迭代和演進的過程

如果沒有業務變更，就沒有此次平臺的迭代;如果沒有Docker快速的引入，就無需對RPM平臺進行演進。因此運維平臺本身也和業務技術架構一樣，隨著業務和技術的變化，本身也在強調適應性。

【編輯推薦】