大型企業(yè)CMDB平臺建設(shè)方案

1、 大型企業(yè)CMDB平臺建設(shè)方案 【摘要】CMDB似乎是運維中永恒的老話題，方法論很多，落地卻發(fā)現(xiàn)理想與現(xiàn)實間存在巨大差距。本文試圖從各類復(fù)雜的解決方案背后尋找決定性的深層邏輯，將圍繞CMDB價值定位和數(shù)據(jù)治理兩個核心問題，揭示主數(shù)據(jù)庫這個全局動力與無序熵增這個內(nèi)在阻力間的矛盾，分析數(shù)據(jù)治理的政治因素和技術(shù)分解，提出CMDB建設(shè)的價值能力模型。問題的提出CMDB似乎是運維中永恒的老話題。多年來也形成了許多方法論，比如場景消費、應(yīng)用驅(qū)動等等，道理似乎都很對，一旦落地卻發(fā)現(xiàn)理想與現(xiàn)實間巨大的差距：技術(shù)之外，建設(shè)者們經(jīng)常要憑一己之力對抗整個組織或流程，一不小心還成了背鍋俠。比如很多公司上了配置審計制度

2、卻發(fā)現(xiàn)難以考核下去，還有諸如數(shù)據(jù)不準、更新不及時、配置自留庫、操作復(fù)雜、用戶抵制情緒，諸多問題揮之不去。項目最后不是縮水為資產(chǎn)管理系統(tǒng)，就是半死不活沒有生命力，處于失敗的邊緣。這些實際困難錯綜復(fù)雜，無從下手，我們該如何面對？本文試圖從各類復(fù)雜的解決方案背后尋找決定性的深層邏輯。下面將圍繞CMDB價值定位和數(shù)據(jù)治理兩個核心問題，揭示主數(shù)據(jù)庫這個全局動力與無序熵增這個內(nèi)在阻力間的矛盾，分析數(shù)據(jù)治理的政治因素和技術(shù)分解，提出CMDB建設(shè)的價值能力模型。產(chǎn)品價值的追問1、主數(shù)據(jù)庫CMDB因主數(shù)據(jù)庫而生，并非為ITIL而生。CMDB的意義看似已深入人心：趨勢分析、影響分析、根源診斷按理這么有價值的系統(tǒng)不

3、應(yīng)遇到太多阻力?。科鋵嵨覀儽弧芭渲霉芾怼边@些高大上的詞匯帶偏了。拋開傳統(tǒng)定義回歸本源，CMDB就是一個保管IT數(shù)據(jù)資產(chǎn)的主數(shù)據(jù)庫。為何稱之為數(shù)據(jù)資產(chǎn)而不是IT固定資產(chǎn)、無形資產(chǎn)，后面會討論，這里先談主數(shù)據(jù)庫。歷史上看，CMDB一詞源于ITIL，其上下文中CMDB表示IT環(huán)境的重要組件的授權(quán)配置，包含每個配置項的所有相關(guān)細節(jié)以及配置項之間重要關(guān)系細節(jié)的數(shù)據(jù)庫。而配置項(CI)可以定義為“正在(或?qū)⒁?受配置管理功能控制的基礎(chǔ)設(shè)施的一個組件”。瞧，多么有文化有內(nèi)涵??！但透過ITIL這個具體場景，本質(zhì)如下圖那樣CMDB為支撐ITSM大廈而建的主數(shù)據(jù)庫。其實這跟業(yè)務(wù)系統(tǒng)中的客戶主數(shù)據(jù)、產(chǎn)品主數(shù)據(jù)之類的

4、MDM沒什么區(qū)別，因此數(shù)據(jù)架構(gòu)治理中主數(shù)據(jù)領(lǐng)域遇到的種種困難問題，同樣發(fā)生在CMDB建設(shè)中。早期很多國內(nèi)公司和廠商是隨著ITIL的引入，把CMDB作為標準化產(chǎn)品一起引進產(chǎn)品體系。但國內(nèi)ITIL落地時主要也就變更、事件幾個流程真正在用，CMDB遇到了水土不服。當IT運維體系從小米加步槍變得越來越龐大復(fù)雜，監(jiān)控、自動化運維到DevOps、AIOPS處處離不開CMDB，大家驚呼：CMDB果真是一切運維的基礎(chǔ)！從這個演變過程看，CMDB還是那個描述IT資源的主數(shù)據(jù)系統(tǒng)，不過隨著時代發(fā)展，主數(shù)據(jù)的地位愈發(fā)重要，CMDB終被推上了風口。2、主數(shù)據(jù)庫必然產(chǎn)生到這里我們要冷靜下，美麗新世界還面臨許多挑戰(zhàn)。復(fù)盤

5、整個過程，為什么會有主數(shù)據(jù)這個東東？被譽為可能是人類最靠譜理論之一的熱力學(xué)第二定律，其熵增原理告訴我們，系統(tǒng)演化總是朝著混亂均衡的方向發(fā)展，這是內(nèi)在趨勢。我們眼睜睜開著設(shè)計之初簡潔優(yōu)雅的系統(tǒng)，逐步形成各種錯綜復(fù)雜的調(diào)用關(guān)系，數(shù)據(jù)不一致、變更影響復(fù)雜、系統(tǒng)不穩(wěn)定等現(xiàn)象隨之而來。請各位明白，這個過程是正常的，符合自然規(guī)律的。偉大的IT思想先驅(qū)們模仿生命熵減的演化特點，鍛造了面向?qū)ο蠛兔嫦蚍?wù)兩大武器，來解決IT系統(tǒng)架構(gòu)復(fù)雜性問題，其背后蘊藏一條重要原理：“高內(nèi)聚，低耦合”。這個原則配合遞歸同構(gòu)，形成了宇宙萬物最穩(wěn)定的結(jié)構(gòu)形式。日常生活中邊界問題、計劃與市場經(jīng)濟、金字塔與自服務(wù)、自治結(jié)構(gòu)均是其不同形

6、式的演繹。IT是業(yè)務(wù)的虛擬和抽象，業(yè)務(wù)世界的復(fù)雜和變化，對應(yīng)到IT架構(gòu)要實現(xiàn)兩個層面的解耦：一個是業(yè)務(wù)和技術(shù)的解耦，業(yè)務(wù)實現(xiàn)不再依賴于某種特定的技術(shù)，技術(shù)的變化對業(yè)務(wù)影響變小。另一個方面是操作方法和業(yè)務(wù)數(shù)據(jù)實體的解耦。因此才產(chǎn)生了SOA、微服務(wù)、對象建模、領(lǐng)域建模、主數(shù)據(jù)等頂層架構(gòu)設(shè)計。IT運維世界里的對象是如此龐大繁雜和多變，各個運維系統(tǒng)無力為繼來自主管理。必然產(chǎn)生一個系統(tǒng)，專門管理這些對象和關(guān)系，遵循領(lǐng)域建模和面向?qū)ο蠼Ｔ瓌t，采用SOA和主數(shù)據(jù)庫的架構(gòu)，從而讓各運維系統(tǒng)專注自己的業(yè)務(wù)。這個工具被人起了個名字叫CMDB。3、產(chǎn)生主數(shù)據(jù)庫的基本條件任何事物不是先驗的，盲目引入工具往往南橘北枳

7、。前面說到CMDB是對抗IT運維架構(gòu)復(fù)雜性的產(chǎn)物，因此當公司運維體系比較簡單，或者說還不成熟時，倉促上馬CMDB注定失敗。企業(yè)里一些原始管理手段的矛盾還沒爆發(fā)時，請嚴格控制項目范圍，擺正預(yù)期。要知道你的作戰(zhàn)對手有深厚的群眾基礎(chǔ)，生產(chǎn)力決定生產(chǎn)關(guān)系在這里同樣適用。雖然這些自建庫粗糙、數(shù)據(jù)孤立、不一致、總體維護成本偏高，但在特定管理水平下，卻野蠻生長而且有效。只有當公司運維復(fù)雜度提高，尤其是上了微服務(wù)、PAAS等運維對象復(fù)雜度大幅提升后，自給自足的配置孤島必然走向CMDB。全局角度，運維系統(tǒng)達到一定復(fù)雜度必然需要CMDB，但微觀角度，CMDB天然面臨巨大阻力，故應(yīng)自上而下推動。人類總是在全局和個體

8、、長期和短期之間糾結(jié)平衡。雖然從道理上都知道應(yīng)服從大局，但個體決策時是另外一番情景，讓我們換位思考下各個運維系統(tǒng)怎么想：從技術(shù)上，通過外部API調(diào)用遠沒有自己應(yīng)用直連數(shù)據(jù)庫來的方便。管理上，配置模型和數(shù)據(jù)維護的決定權(quán)上收到配置管理團隊，大部分修改變更還要經(jīng)過配置委員會和流程審批。因此自下而上來建設(shè)主數(shù)據(jù)一定會遇到強大阻力的。康威定律從另個角度可以驗證：組織架構(gòu)會決定團隊寫出的產(chǎn)品架構(gòu)。如果各運維系統(tǒng)開發(fā)團隊和CMDB團隊分屬不同組織，在推動配置庫集成這件事上一定會遇到正面或暗地里巨大的困難，尤其一些體制內(nèi)單位中，人是問題的關(guān)鍵。所以很多方法論中才強調(diào)，CMDB建設(shè)一定要獲得高層理解和支持。我們

9、應(yīng)跟管理層反復(fù)解釋這個邏輯，從公司整體運維架構(gòu)出發(fā)，利用組織強大的執(zhí)行力自上而下推動。CMDB遠不僅是個技術(shù)方案，更應(yīng)從組織和管理視角促進CMDB團隊和其他運維團隊的理解、支持和融合。4、主數(shù)據(jù)庫+場景模型CMDB價值的一只腳是主數(shù)據(jù)，另一只腳則是場景。主數(shù)據(jù)的道理我們可以跟管理者、架構(gòu)師溝通，但遇到具體的各個運維單位和工具時，我們面對的局面好比以一當十，要尋找每個對手的弱點逐個擊破。用戶會找出各種借口，或想保留數(shù)據(jù)的控制權(quán)，或因為原有習慣，或就是偷懶不配合。從個體角度看CMDB落地的關(guān)鍵是場景驅(qū)動，場景就是動力。常見有價值的場景包括：安全內(nèi)控管理（賬號、堡壘機、防火墻、漏洞補丁、合規(guī)檢查、I

10、P端口）、監(jiān)控告警、自動化運維、資產(chǎn)管理、資源交付、發(fā)布管理、應(yīng)急管理、ITIL流程管理、容量管理等。實踐經(jīng)驗來看，安全、監(jiān)控、應(yīng)用生命周期管理是三個動力最強的場景抓手，尤其要利用好像“護網(wǎng)行動”這類公司重大事件，將CMDB充分與領(lǐng)導(dǎo)要求、政策目標、安全事件等結(jié)合，手握“尚方寶劍”，勢不可擋！場景不僅體現(xiàn)在日常運維流程中，還體現(xiàn)在公司的各類運維工具中。如果CMDB是一家公司，它應(yīng)該同時面向B2C+B2B雙渠道業(yè)務(wù)。CMDB團隊應(yīng)抱著招商引資的心態(tài)，向運維工具的開發(fā)團隊去推銷、談合作。比如我司還沒統(tǒng)一運維門戶，CMDB產(chǎn)品團隊索性把前臺整合進自動化運維系統(tǒng)，最終實現(xiàn)產(chǎn)品和開發(fā)團隊層面的深度整合。

11、另一方面，利用公司技術(shù)架構(gòu)評審和創(chuàng)新項目評審等機遇，把CMDB集成要求明確列入評審打分項。下圖為場景工具集成效果圖：技術(shù)和運營，兩手都要硬產(chǎn)品價值方向明確后，如何實現(xiàn)價值就要看團隊能力了。模型中的能力分技術(shù)和運營兩部分，缺一不可。我司建設(shè)CMDB時沒有采購任何商業(yè)軟件，簡單介紹下使用開源產(chǎn)品的經(jīng)驗。開源工具的運用核心模塊采用CMDBuild，這是一款意大利團隊開發(fā)的開源CMDB產(chǎn)品，最新版本是3.0。之所以稱之為核心模塊，是因為產(chǎn)品化和個性化往往是對矛盾，尤其在國企環(huán)境中。我們用CMDBuild來做建模和后臺管理，由于它采用PostgreSQL數(shù)據(jù)庫，能很好實現(xiàn)對象繼承和變更軌跡。同時基于Po

12、stgreSQL強大的適應(yīng)性，可以跟各種工具靈活整合。比如通過kafka實現(xiàn)消息推送，把CMDB數(shù)據(jù)變動更及時推送給外圍訂閱系統(tǒng)。其原生模型具有全局唯一ID和時間戳，外部系統(tǒng)也很方便實現(xiàn)增量同步CMDB。我們放棄了CMDBuild自帶的數(shù)據(jù)同步工具，因為發(fā)現(xiàn)Kettle來做更穩(wěn)定和高效。Kettle的Insert/Update組件可以很好利用主鍵實現(xiàn)增量更新，不必每次采集清空目標表。此外Kettle作為專業(yè)的ETL工具同樣能實現(xiàn)強大的清洗轉(zhuǎn)換功能，是CMDB和外部數(shù)據(jù)批量同步的重要通道。我們自行重寫了前臺和REST接口。CMDBuild原生前臺用戶體驗一般，屬于典型后臺管理界面風格，且基于角色

13、的權(quán)限設(shè)計不夠靈活。如果公司有100個產(chǎn)品，就要設(shè)置100個角色，這是一場災(zāi)難。原生的REST接口中，所有外鍵屬性都是ID，為此要逐一轉(zhuǎn)換，前臺開發(fā)效率太低。用Django的ORM重寫了接口后，可以同時提供外鍵ID和屬性值，雖然運行效率有所降低，但極大提升了開發(fā)效率。數(shù)據(jù)治理的邏輯作為一個完整的CMDB產(chǎn)品團隊，運營包括推廣、集成、調(diào)研、數(shù)據(jù)治理等工作，這往往是IT工程師們并不擅長的領(lǐng)域，其中最困難就是數(shù)據(jù)治理了。這里先從從技術(shù)層面分解數(shù)據(jù)治理各個過程，分而治之。再討論數(shù)據(jù)變更環(huán)節(jié)的場景和流程問題。最后從政治層面探討數(shù)據(jù)治理“人”的因素，如果人不重視，職責不清，一切治理都無從做起。1、數(shù)據(jù)治理

14、拆解上圖解構(gòu)了解決數(shù)據(jù)治理問題的具體路徑：CMDB的數(shù)據(jù)可分為自動發(fā)現(xiàn)數(shù)據(jù)和人工錄入數(shù)據(jù)兩大類。第一策略是盡最大努力擴大自動發(fā)現(xiàn)范圍（因為自動發(fā)現(xiàn)的數(shù)據(jù)一定是最準確），降低配置管理的成本。常見的自動發(fā)現(xiàn)數(shù)據(jù)源有云管平臺、安全管理系統(tǒng)、網(wǎng)管平臺、負載均衡系統(tǒng)、帶外管理系統(tǒng)等，總之要團結(jié)一切能夠自動發(fā)現(xiàn)的力量。但接下來總要面對人工錄入數(shù)據(jù)，這里用水池模型來解釋。要一個水池干凈，一是保證流入的增量干凈，二是凈化水池中的存量，三是要水循環(huán)流動起來。類似的，CMDB增量變更數(shù)據(jù)由場景流程來控制，存量數(shù)據(jù)靠數(shù)據(jù)資產(chǎn)明確屬主并提高犯錯成本。最后通過場景消費形成正反饋機制。三管齊下。2、嵌入場景和流程設(shè)計場景

15、和流程是CMDB執(zhí)行階段重要環(huán)節(jié)，這里應(yīng)注意場景結(jié)合的空間結(jié)構(gòu)和流程約束的時間結(jié)構(gòu)。調(diào)整場景結(jié)合的空間結(jié)構(gòu)：傳統(tǒng)ITIL場景中配置項變更，一般是用戶到流程平臺或CMDB門戶中去維護，流程重，體驗差，導(dǎo)致數(shù)據(jù)質(zhì)量不佳。正確的設(shè)計思路是把CMDB的位置嵌入到用戶場景中最便捷的時間、地點中，降低數(shù)據(jù)消費門檻。因此CMDB應(yīng)重點建設(shè)實時接口或頁面API，以SOA方式嵌入到各種場景中，前端用戶甚至感受不到CMDB的存在。我們可以弱化CMDB自身門戶入口，成為純后端平臺，轉(zhuǎn)而從外部場景工具中引入流量。調(diào)整流程約束的時間結(jié)構(gòu)：流程的約束設(shè)計應(yīng)盡量從事后提前到事中解決。我們對用戶在場景中的配置管理要求，通常以

16、流程管控和數(shù)據(jù)審計的方式寫入制度規(guī)范中。制度一般會安排多個角色：CMDB配置經(jīng)理、CMDB維護人員、CMDB審計人員等等，興師動眾卻效果一般，尤其是體制內(nèi)的事后考核往往無法落實，難以有效保證數(shù)據(jù)質(zhì)量，我們推薦事中進行“自審計”。舉個例子，某個流程要求設(shè)備到貨時某人某時刻錄入CMDB，但執(zhí)行人可能偷懶或者真的遺忘了，事后審計雖然形成閉環(huán)但效率低。更優(yōu)的流程設(shè)計是把設(shè)備初驗場景整合進流程里，如果沒有錄入CMDB則無法初驗，流程在執(zhí)行中就有人會跳出來拉響警報。請注意以往邏輯是業(yè)務(wù)先變更，再到CMDB登記，業(yè)務(wù)是因，CMDB是果。正確的思路把CMDB設(shè)計為某個業(yè)務(wù)活動的因，這樣數(shù)據(jù)質(zhì)量可以得到極大改善

17、。下圖為部分流程樣例，把堡壘機申請、防火墻申請、設(shè)備部署、監(jiān)控接入等業(yè)務(wù)活動都設(shè)計為依賴CMDB數(shù)據(jù)。3、引入數(shù)據(jù)資產(chǎn)的理念資產(chǎn)是能夠給企業(yè)帶來經(jīng)濟利益的重要資源，數(shù)據(jù)中心最重要的資產(chǎn)是其資源結(jié)構(gòu)，CMDB則是管理這類資產(chǎn)的唯一工具。把CMDB地位意識提升到數(shù)據(jù)資產(chǎn)這個層次，是解決數(shù)據(jù)治理中重視不足、推諉扯皮常見問題的重要基礎(chǔ)。DAMA(國際數(shù)據(jù)管理協(xié)會)數(shù)據(jù)管理職能框架如下圖，涉及元數(shù)據(jù)建模、制度流程、安全審計等等多維度技術(shù)管理手段。這個龐大框架背后有一條關(guān)鍵定義：數(shù)據(jù)治理(DG，Data Governance)是指對數(shù)據(jù)資產(chǎn)的管理活動行使權(quán)力和控制的活動集合(規(guī)劃、監(jiān)控和執(zhí)行)。讓我們回到

18、問題之初：數(shù)據(jù)治理，治理什么？治理的對象是數(shù)據(jù)嗎？其實不然。運維過程中產(chǎn)生了諸如日志、監(jiān)控等大量數(shù)據(jù)，雖然是一種重要的電子化記錄，可以集中清洗并分析，卻并沒有治理的必要。因此，數(shù)據(jù)治理的對象必須是重要的數(shù)據(jù)資源，DAMA定義中稱之為“數(shù)據(jù)資產(chǎn)”可謂相當?shù)轿?。那么?shù)據(jù)中心的重要資產(chǎn)有哪些？除了傳統(tǒng)意義上開得見摸得著的機房、服務(wù)器、網(wǎng)絡(luò)硬件這類有型資產(chǎn)，更有價值的是廣義的無形資產(chǎn)。就如同數(shù)據(jù)和信息間的差別，孤立的人員、產(chǎn)品、主機、中間件、數(shù)據(jù)庫、應(yīng)用包、配置等這些資源只是數(shù)據(jù)，他們之間互相依賴支撐擬合形成的結(jié)構(gòu)關(guān)系才是有價值的信息。數(shù)據(jù)中心正是依靠它們撐起了外界所看到的一個個系統(tǒng)和一個個服務(wù)，像有

19、機體那樣對外界輸入進行處理并反饋，整個資源結(jié)構(gòu)保存在CMDB中。一個產(chǎn)品可以利用其CMDB中的信息在另一套環(huán)境中重建，災(zāi)難發(fā)生時甚至可以基于CMDB重建整個機房。資產(chǎn)是管理的起點，如果不了解管理對象，管理從何談起？前陣子微信上故宮的單院長火了一把，他上任伊始做的一件事是走遍故宮的1200座建筑9371間房間，盤點清楚1862690件（套）文物，搞清自己的資產(chǎn)是他管理的第一步。將軍帶兵打仗，首先要了解他的士兵、武器和補給。反觀數(shù)據(jù)中心的各層級管理者們，大家清楚數(shù)據(jù)中心的IT數(shù)據(jù)資產(chǎn)嗎？我們有多少設(shè)備、產(chǎn)品、服務(wù)？每個產(chǎn)品所用的主機、中間件、數(shù)據(jù)庫實例情況都掌握嗎？有那些關(guān)鍵業(yè)務(wù)流程涉及那些服務(wù)？

20、服務(wù)間調(diào)用關(guān)系拓撲是怎樣的？大部分企業(yè)管理在粗放階段，這些信息是模糊、分散的。梳理清這些數(shù)據(jù)資產(chǎn)是各層級管理者本職工作，而不能把CMDB當做替罪羊！我發(fā)現(xiàn)工作認真細致的團隊負責人，其團隊的配置數(shù)據(jù)質(zhì)量也往往較高。我們一定要向老板和部門領(lǐng)導(dǎo)們呼吁一個理念：CMDB不是要逃脫責任，但數(shù)據(jù)質(zhì)量更是全公司的責任！工作中有個負反饋循環(huán)：數(shù)據(jù)實際生產(chǎn)者埋怨數(shù)據(jù)不準而不愿意使用CMDB，CMDB因為沒人不用所以數(shù)據(jù)更加不準。引入數(shù)據(jù)資產(chǎn)概念后這個問題就明確了：資產(chǎn)要確權(quán)，資產(chǎn)歸誰，誰就要負責。事實上，產(chǎn)權(quán)問題是土地治理、國企治理等各種治理活動在人性層面的關(guān)鍵問題。4、 數(shù)據(jù)資產(chǎn)的抓手：產(chǎn)品運行配置基線上述理念具體落地時，我們以“產(chǎn)品運行配置基線”作為執(zhí)行的抓手，具體解決兩個問題：一是明確存量數(shù)據(jù)的責任人。二是起到“戶口登記”的基線作用。數(shù)據(jù)資產(chǎn)的概念比較虛，具體落地體現(xiàn)在讓CMDB在所有運維場景談到產(chǎn)品時占據(jù)人們的“第一聯(lián)想”。產(chǎn)品運行配置基線這和研發(fā)管理的配置基線有所不同，大家可參