[[326934]]

備注：本文根據(jù)演講者視頻語音速記整理而成，如有圖文不妥，請(qǐng)以視頻為準(zhǔn)。

很高興能有機(jī)會(huì)跟大家一起來交流一下 CMDB 的建設(shè)。屏幕前的各位應(yīng)該都是運(yùn)維的伙伴，那么大家對(duì)于 CMDB 應(yīng)該都很有了解，我相信有10個(gè)人里面有9個(gè)人對(duì) CMDB 的理解是不同的，在平日里跟其他同事、同仁交流時(shí)，我們都會(huì)說 CMDB 可能就是應(yīng)用關(guān)系的一個(gè)記錄，一個(gè)應(yīng)用關(guān)系的庫；還有就是CMDB ，Configuration Management 就是一個(gè)配置管理，那配置到底包含什么關(guān)系？是不是需要包含一個(gè)全鏈路的東西，比如層應(yīng)用，應(yīng)用、數(shù)據(jù)庫、交換機(jī)是不是一個(gè)配置？還有物理機(jī)、虛擬機(jī)等我們是不是把它錄進(jìn)來。

也有朋友可能會(huì)很詫異，現(xiàn)在都已經(jīng)上云了，云上有這么多的資源管理控制臺(tái)，可以在生產(chǎn)虛擬機(jī)為這個(gè)instant去打標(biāo)簽，在我們需要用到它的時(shí)候，可以通過標(biāo)簽來搜索和定位應(yīng)用在哪個(gè)服務(wù)器上，這些我相信大家說的都是正確的，但隨著業(yè)務(wù)規(guī)模越來越大，CMDB的維度也是越來越多。CMDB可以是一個(gè)簡(jiǎn)單二維的統(tǒng)計(jì)表，也可以是一個(gè)多維立體覆蓋的模型，如果一開始沒有一個(gè)好的規(guī)劃，那做到后面 CMDB 是承受不了這樣的復(fù)雜性的。

不知道大家有沒有這樣的感覺，CMDB 剛開始的時(shí)候建的非常的順利，不管是從云上，我們把數(shù)據(jù)拉回來存在本地，還是我們自己拿一些 agent 去采一些虛擬機(jī)的數(shù)據(jù)。但隨著業(yè)務(wù)規(guī)模的不斷增加，隨著不斷把一些模型，比如說把一些關(guān)系加到 CMDB 里面去，到了這時(shí)會(huì)發(fā)現(xiàn)，我們的模型非常的復(fù)雜，而且根本就沒有辦法維護(hù)，這時(shí) CMDB 就變成了一個(gè)垃圾場(chǎng)。

今天要跟大家分享的是如何快速的打造一個(gè)能夠持久使用的 CMDB。相信聽過今天的三部曲之后，大家會(huì)有一個(gè)新的認(rèn)識(shí)。

首先我們還是回到概念上來，CMDB 是什么，為什么一定要建 CMDB？大家都知道工具是為了解決同一個(gè)反復(fù)的問題或反復(fù)的場(chǎng)景減少重復(fù)勞動(dòng)提高生產(chǎn)效率的產(chǎn)物，那么 CMDB 也是這樣。

我們來看一張圖，這張圖是我們現(xiàn)在的排障圖，因?yàn)殂y行有一些規(guī)定，沒辦法直接把行內(nèi)的截圖發(fā)出來，所以跟大家手繪一張。

首先從左上角開始，左上角是負(fù)載均衡的集群，這也是一個(gè)模型，這個(gè)負(fù)載均衡里面有寫集群的ID、域名以及運(yùn)維團(tuán)隊(duì)相關(guān)負(fù)責(zé)人，負(fù)載均衡下面是集群Member，這里面是集群成員，有端口號(hào)、IP，這個(gè) Member 會(huì)指到兩個(gè)OS節(jié)點(diǎn)上，兩個(gè)OS就是系統(tǒng)節(jié)點(diǎn)，這個(gè)節(jié)點(diǎn)的數(shù)據(jù)就記錄著系統(tǒng)IP地址，虛擬化的版本等系統(tǒng)級(jí)別的信息。

系統(tǒng)信息級(jí)別的上層是應(yīng)用實(shí)例，應(yīng)用實(shí)例會(huì)有應(yīng)用APPID，我們每一個(gè)應(yīng)用都會(huì)有獨(dú)立的ID，這個(gè)ID代表了這個(gè)應(yīng)用的畫像，這個(gè)ID是什么容器，是什么外部容器，它的語言、發(fā)布版本周期、發(fā)布變更窗口等等都是圍繞應(yīng)用的。

這一層就是我們的應(yīng)用了，應(yīng)用的上面，在這個(gè)地方就是APPID的模型，針對(duì)應(yīng)用產(chǎn)生兩個(gè)實(shí)例，它們帶有獨(dú)立的IP屬性，這個(gè)應(yīng)用就是我們的應(yīng)用畫像。

接著這個(gè)應(yīng)用右邊是數(shù)據(jù)庫集群，在CMDB里面我們作為一個(gè)服務(wù)對(duì)象承載，應(yīng)用使用服務(wù)，這是我們數(shù)據(jù)庫服務(wù)。數(shù)據(jù)庫服務(wù)里面會(huì)有集群的ID，數(shù)據(jù)庫的類型，數(shù)據(jù)庫的庫名以及維護(hù)的團(tuán)隊(duì)DBA，這個(gè)集群下掛了兩個(gè)數(shù)據(jù)庫實(shí)例，這兩個(gè)實(shí)例它們的區(qū)別是在于有一主一從，如果是MySQL的話，那么它們角色就是主從關(guān)系。

在這樣的排障圖情況下，假設(shè)今天有一個(gè)報(bào)警，紅色的地方報(bào)了數(shù)據(jù)庫集群，報(bào)了一個(gè)警，說這個(gè)數(shù)據(jù)庫集群有一個(gè)慢查詢，然后數(shù)據(jù)庫實(shí)例在組節(jié)點(diǎn)上面發(fā)現(xiàn)了DB的Session異常升高了，與此同時(shí)在我們OS的節(jié)點(diǎn)上，我們發(fā)現(xiàn)主機(jī)的 TIME_WAIT 數(shù)有增加，那在我們應(yīng)用實(shí)例里面，我們現(xiàn)在通過CAT埋點(diǎn)，我們可以拿到在代碼執(zhí)行過程當(dāng)中互相調(diào)用鏈的SLA的響應(yīng)時(shí)長(zhǎng)，對(duì)對(duì)方的SLA，在這個(gè)地方有一個(gè)報(bào)警，到現(xiàn)在有調(diào)用數(shù)據(jù)庫TIMEOUT，這是一個(gè)告警，告警最底層藍(lán)色的字體是CMDB源數(shù)據(jù)，我們把告警覆蓋上去，今天出來的告警覆蓋到這張圖上面，然后我們與此同時(shí)把變更的記錄覆上去，變更記錄是綠色的這邊，我給大家讀一下，變更信息：某年某月某日某個(gè)版本發(fā)生了變更，變更號(hào)。

如果排障的時(shí)候如果把這張圖放在外面的話，我們其實(shí)是很容易能判定出哪個(gè)應(yīng)用受到了什么影響，并且影響范圍是什么，可能是因?yàn)橛惺裁醋兏鼘?dǎo)致的。這個(gè)就是CMDB典型的場(chǎng)景。CMDB的數(shù)據(jù)遠(yuǎn)遠(yuǎn)不止這些，可以通過學(xué)習(xí)，通過分析，所有的數(shù)據(jù)都是覆蓋在CMDB之上的，所以CMDB源數(shù)據(jù)是一個(gè)非常重要的基礎(chǔ)數(shù)據(jù)，那如果說我們今天沒有CMDB，這些東西全部都在腦子里面，我知道某一個(gè)應(yīng)用它下面有幾臺(tái)機(jī)器，然后這個(gè)機(jī)器前面掛了一個(gè)F5，我知道它連著數(shù)據(jù)庫是什么，那如果說你所知道的這個(gè)東西擴(kuò)展到一千倍，你還會(huì)記得嗎？可能你的當(dāng)時(shí)腦子里是這個(gè)樣子的。

[[326935]]

一、建模階段

我相信剛剛這張圖已經(jīng)足以讓大家知道我們的 CMDB 有多大的用途。接下來我來告訴大家說一下CMDB的建設(shè)，CMDB的建設(shè)分三個(gè)階段，第一個(gè)階段是建模階段，我們來看一下這個(gè)模型，首先我們要確定一下，這個(gè)模型相對(duì)來說是一個(gè)比較簡(jiǎn)單的模型，這個(gè)有物理設(shè)備、OS、應(yīng)用模型，各自這邊會(huì)有物理模型、機(jī)柜、機(jī)房還有物理設(shè)備，網(wǎng)絡(luò)接口、網(wǎng)絡(luò)設(shè)備到物理設(shè)備，還有我們F5的集群，集群成員，物理的集群，到網(wǎng)絡(luò)設(shè)備。

我們剛剛看到這些集群里面，其實(shí)并不是所有的信息我們CMDB都會(huì)需要，哪些CMDB我們需要，首先第一個(gè)我們平時(shí)用得到，我們排障用得到的管理信息、狀態(tài)信息這部分是不可少，今天有一個(gè)報(bào)警必須找到，對(duì)不對(duì)？剛才說到管理信息，狀態(tài)信息這個(gè)東西也是不可少，因?yàn)镃MDB本身就是管理配置的生命周期，你所有的主機(jī)節(jié)點(diǎn)是不是上線、在維護(hù)中、帶部署了、在使用中，這些都需要有，是一個(gè)虛擬機(jī)的生命周期。不單單是虛擬機(jī)需要生命周期，包括我們的實(shí)例，包括我們的 DB，都可能拉入、拉出、維護(hù)或者是帶部署等等狀態(tài)，那這些狀態(tài)信息用來干什么？是用來告警抑制的時(shí)候或者是自動(dòng)上架，然后還沒有對(duì)外提供服務(wù)能力的時(shí)候，我們可以把這些告警給抑制掉，包括你今天正常計(jì)劃的拉入、拉出，這些原本是不需要發(fā)出告警的，所以我們要可以通過狀態(tài)的變化來把告警浸沒。

然后第二個(gè)就是我們是按照一個(gè)領(lǐng)域來劃分，我們?cè)诳匆幌逻@張圖，其實(shí)每一條線都是一個(gè)領(lǐng)域，所謂的領(lǐng)域就是相對(duì)來說，因?yàn)檫@個(gè)領(lǐng)域跟我們組織架構(gòu)有點(diǎn)關(guān)系，比如說設(shè)備組，它負(fù)責(zé)的領(lǐng)域就是機(jī)房機(jī)柜、物理設(shè)備；

網(wǎng)絡(luò)組負(fù)責(zé)網(wǎng)絡(luò)交換機(jī)、防火墻、代理、VPN等等網(wǎng)絡(luò)設(shè)備，所以它的領(lǐng)域網(wǎng)絡(luò)設(shè)備和網(wǎng)絡(luò)設(shè)備的端口，我們ADC的團(tuán)隊(duì)主要負(fù)責(zé)F5的，那么F5的領(lǐng)域包括物理集群、邏輯集群、member，這些都關(guān)聯(lián)到物理設(shè)備上。

下面是系統(tǒng)節(jié)點(diǎn)，系統(tǒng)節(jié)點(diǎn)也出現(xiàn)很多領(lǐng)域，比如說中間件的，Hadoop、ES、Kafka，主要是一些指Member等等這些，還有我們DB，DB實(shí)例、DB的集群、DB的實(shí)體，

最下面是我們的應(yīng)用，應(yīng)用運(yùn)維，有負(fù)責(zé)應(yīng)用領(lǐng)域，也有應(yīng)用實(shí)例、應(yīng)用集群、應(yīng)用畫像。

大家有沒有看到數(shù)據(jù)模型領(lǐng)域很多，但是彼此領(lǐng)域之間是沒有交際的，有沒有看到？領(lǐng)域和領(lǐng)域之間不會(huì)建立模型不會(huì)建立關(guān)系，它們的關(guān)系永遠(yuǎn)都是對(duì)應(yīng)到一個(gè)相對(duì)集中點(diǎn)，物理設(shè)備的，設(shè)備組所有領(lǐng)域信息都是歸結(jié)到物理設(shè)備上，網(wǎng)絡(luò)歸結(jié)到物理設(shè)備上，F(xiàn)5也是歸結(jié)到物理設(shè)備。

有人問F5的集群里面的Member是主機(jī)又不是物理設(shè)備，像主機(jī)節(jié)點(diǎn)我們?nèi)筷P(guān)聯(lián)到節(jié)點(diǎn)OS上，盡量我們把領(lǐng)域跟領(lǐng)域之間不作為互相交互，他們只關(guān)聯(lián)具體的三個(gè)大的模型上，這個(gè)有一個(gè)什么好處？我們?cè)趧傞_始的時(shí)候建數(shù)據(jù)的時(shí)候，可能數(shù)據(jù)量不是很多，服務(wù)器數(shù)量不是很多，那如果我上報(bào)一個(gè)虛擬機(jī)，我還要把應(yīng)用關(guān)系，還要把F5關(guān)系全部報(bào)給你可以嗎？可以，但是時(shí)間長(zhǎng)了，閉環(huán)會(huì)越來越重，就是越來越吃閉環(huán)，如果今天哪個(gè)流程出現(xiàn)問題的時(shí)候，你的數(shù)據(jù)就亂了，你根本沒有辦法去治理它，所以保證上傳的數(shù)據(jù)只是在這個(gè)領(lǐng)域內(nèi)部去做三層的結(jié)構(gòu)。

怎么理解內(nèi)部做三層結(jié)構(gòu)？我們舉個(gè)例子，我們拿網(wǎng)絡(luò)來舉例，網(wǎng)絡(luò)的是有一個(gè)網(wǎng)絡(luò)設(shè)備端口，網(wǎng)絡(luò)的設(shè)備端口一定是屬于某一個(gè)網(wǎng)絡(luò)設(shè)備的，那這個(gè)網(wǎng)絡(luò)設(shè)備和這個(gè)網(wǎng)絡(luò)設(shè)備端口是一個(gè)1比多對(duì)應(yīng)的集群關(guān)系，網(wǎng)絡(luò)只需要維護(hù)好自己的這一份數(shù)據(jù)，確保集群每個(gè)端口都會(huì)對(duì)應(yīng)一個(gè)集群，一個(gè)集群下就一定會(huì)有48個(gè)口，交換機(jī)48個(gè)口，它只要把這層數(shù)據(jù)關(guān)系關(guān)聯(lián)好，把網(wǎng)絡(luò)設(shè)備關(guān)聯(lián)到我們某一個(gè)物理設(shè)備上，因?yàn)檫@當(dāng)中是有CI號(hào)，每個(gè)設(shè)備都會(huì)有CI號(hào)，這是唯一的，所以一定不會(huì)關(guān)聯(lián)錯(cuò)，這個(gè)時(shí)候全都上報(bào)到CMDB，那CMDB接下來就可以做很多關(guān)系，只要有這一份關(guān)系，就可以透過這層關(guān)系幫你建出你的拓?fù)洹?/p>

就是我們剛剛看到這張圖，這張圖片所有的數(shù)據(jù)關(guān)系都是CMDB建出來的，所以在采集數(shù)據(jù)的時(shí)候，它們彼此之間其實(shí)是不知道關(guān)系的，明白嗎？只有自己的領(lǐng)域之間集群和Member這個(gè)之間是自己有關(guān)系，但是它不知道對(duì)應(yīng)的應(yīng)用是什么，F(xiàn)5不知道應(yīng)用是誰？剛不會(huì)知道下面數(shù)據(jù)庫關(guān)系是什么。

這個(gè)就是我們說的建模，為了要增大你數(shù)據(jù)靈活性和拓展性，所以我們必須要把模型變得更簡(jiǎn)單，關(guān)系變得更簡(jiǎn)單，把復(fù)雜的邏輯，復(fù)雜的數(shù)據(jù)關(guān)系帶到CMDB，這是一個(gè)大忌。

二、閉環(huán)

第二階段我們建完模之后要先做閉環(huán)，我們的閉環(huán)數(shù)據(jù)是非常重要，在CMDB里面沒有閉環(huán)這個(gè)數(shù)據(jù)就是不可信的，閉環(huán)是保證數(shù)據(jù)準(zhǔn)確性的基礎(chǔ)，閉環(huán)的方式可以通過強(qiáng)留層驅(qū)動(dòng)，可以通過服務(wù)目錄或者流程引擎。

那我們這邊簡(jiǎn)單說一下流程引擎的思想，一個(gè)用戶在訪問我們服務(wù)目錄的時(shí)候，會(huì)去訪問運(yùn)維的流程引擎，那之后運(yùn)維流程引擎下發(fā)所有任務(wù)讓自動(dòng)化工具系統(tǒng)去執(zhí)行，執(zhí)行完了之后這些工具系統(tǒng)會(huì)告訴自己的領(lǐng)域，因?yàn)檫@些工具都是領(lǐng)域內(nèi)部的自動(dòng)化工具，自己的領(lǐng)域都會(huì)收到相關(guān)的一些信息，比如說今天要做一個(gè)擴(kuò)容，虛擬機(jī)擴(kuò)容從2擴(kuò)變成4擴(kuò)，那這個(gè)流程下去之后就會(huì)下發(fā)到系統(tǒng)的領(lǐng)域，系統(tǒng)的領(lǐng)域知道我現(xiàn)在某一個(gè)虛擬機(jī)變成4擴(kuò)，它記錄數(shù)據(jù)并且上報(bào)，將增量的部分上報(bào)給CMDB，告訴CMDB現(xiàn)在我有一臺(tái)虛擬機(jī)，從2擴(kuò)變成了4擴(kuò)了，那么CMDB收到這部分?jǐn)?shù)據(jù)的時(shí)候，它能不能信？

CMDB 不能隨便的去更改我們庫里面的源數(shù)據(jù)，必須要有強(qiáng)流程的驅(qū)動(dòng)，所以在流程引擎在執(zhí)行的時(shí)候，會(huì)放給CMDB一條信息，告訴CMDB說接下來會(huì)有一個(gè)什么機(jī)器的，它的2擴(kuò)要變成4擴(kuò)，這個(gè)是通常我們說到CMDB B表，那領(lǐng)域上報(bào)就是一個(gè)C表，B表跟C表一參照，匹配上就是一個(gè)正常變更，我允許你變更數(shù)據(jù)，如果沒有匹配上，它上報(bào)的這條數(shù)據(jù)將會(huì)列入到異常上報(bào)數(shù)據(jù)，這個(gè)時(shí)候我們可以反過來去推行，說為什么今天2擴(kuò)會(huì)變成4擴(kuò)，是因?yàn)闆]有任何的變更驅(qū)動(dòng)來做這個(gè)事情了，這樣就形成了一個(gè)閉環(huán)。

我們先把這種閉環(huán)建立起來再去錄入CMDB數(shù)據(jù)，今天也許有些伙伴說，我今天只是想搜集一下服務(wù)器的數(shù)據(jù)，在云上可能我的拿一個(gè)API就把全量的數(shù)據(jù)拿過來，但是我們有沒有想過你今天拿全量的數(shù)據(jù)拿過來，接下來你在產(chǎn)一臺(tái)機(jī)器的時(shí)候，你的數(shù)據(jù)怎樣進(jìn)來？可能你需要定期不斷去拿API，不斷拿全量的數(shù)據(jù)，永遠(yuǎn)去覆蓋掉你的CMDB完整數(shù)據(jù)，那我覺得CMDB不應(yīng)該這樣做，它應(yīng)該去保留說你的所有變更記錄，CMDB里面的數(shù)據(jù)每一條變更記錄都是需要被保留審計(jì)的。

所以今天在云上面創(chuàng)立主機(jī)的時(shí)候，你要先想要你今天在創(chuàng)建這個(gè)主機(jī)的時(shí)候，怎么樣讓CMDB先知道這條信息，然后你在通過API的方式去拿到這臺(tái)消息上報(bào)的時(shí)候，那CMDB會(huì)對(duì)你已經(jīng)告訴它要更改的數(shù)據(jù)做一個(gè)修改，這個(gè)就是閉環(huán)。

閉環(huán)沒有建立起來，所有的數(shù)據(jù)都是不可信的，這是我們第二階段的閉環(huán)。

三、解決存量

第三階段是解決我們的存量，存量讓我們要改變一些思維的方式，首先，我們要相信領(lǐng)域，我們剛剛說這些搜集的數(shù)據(jù)，今天我們說按照組織架構(gòu)，有網(wǎng)絡(luò)組，網(wǎng)絡(luò)組可以提供權(quán)威的領(lǐng)域數(shù)據(jù)，如果今天團(tuán)隊(duì)規(guī)模比較小，沒有，那也沒有關(guān)系，我們就把它單獨(dú)看作是一個(gè)領(lǐng)域上報(bào)，這里有一個(gè)思維要轉(zhuǎn)變一下，我們盡量不要CMDB去下探，去拿它的東西，而是作為一個(gè)上報(bào)的過程，有什么好處？

第一個(gè)，你今天下探去拿東西的時(shí)候，你未必拿的全，第二個(gè)你的拿回來的東西，如果是CMDB去拿，你可能直接就進(jìn)庫了，如果是上報(bào)的方式，你把一個(gè)網(wǎng)絡(luò)領(lǐng)域單獨(dú)獨(dú)立出來，你可以對(duì)它整個(gè)生命周期做管理，因?yàn)槟愕谝淮文煤偷诙文枚荚谀憔W(wǎng)絡(luò)領(lǐng)域里面已經(jīng)感知到了，它不會(huì)撞了CMDB的數(shù)據(jù)，哪些東西需要上報(bào)到CMDB，是哪些有變化有增量的東西會(huì)上報(bào)到CMDB里面去，所以這樣的話CMDB就可以做到有一個(gè)更簡(jiǎn)單、可追溯、可校驗(yàn)的過程。所有的CMDB變更記錄一定要把它給記錄起來，每一條記錄的變更，誰來變更這些都是一個(gè)之后可回溯的關(guān)鍵方法。

那么解決存量我們還有一個(gè)問題要解決，我的分布是什么，我怎么知道你這個(gè)領(lǐng)域里面應(yīng)該有多少個(gè)機(jī)器，因?yàn)轭I(lǐng)域上報(bào)過來，你作為一個(gè)CMDB你接受領(lǐng)域上報(bào)的所有數(shù)據(jù)，你相信它是權(quán)威，我相信你的數(shù)據(jù)，但是我也要幫你做一個(gè)交叉比較，那怎么做交叉比較其實(shí)很簡(jiǎn)單，我們可以放一臺(tái)機(jī)器，拿一個(gè)主機(jī)來說，可以在某一個(gè)網(wǎng)段放一個(gè)機(jī)器，去全網(wǎng)掃，整個(gè)C端里面去掃所有的端口，去通過端口的特征來判斷它是一個(gè)什么樣的主機(jī)，是一個(gè)什么樣的設(shè)備，這是一種方式，還有一種方式我們自建IDC的，我們可以拿到整個(gè)交換機(jī) ARP 表，我們銀行現(xiàn)在主要是做TOP的架構(gòu)，柜頂一個(gè)，一行柜，然后會(huì)有一個(gè)匯聚，多個(gè)匯聚形成一個(gè)核心，所以我們?cè)诿總€(gè)柜頂上都可以找到ARP表，有了這些ARP表我就知道現(xiàn)在整個(gè)生產(chǎn)環(huán)境的分布有多大，這是一種探測(cè)的方法，不能單單靠我們領(lǐng)域上報(bào)過來的數(shù)據(jù)，我們還需要有自己幫助領(lǐng)域去加強(qiáng)去準(zhǔn)確它上報(bào)數(shù)據(jù)的覆蓋度。

那么接下來我們要說一個(gè)邏輯的交叉比對(duì)，是怎么樣子的？比如說我們今天上報(bào)物理機(jī)的過程當(dāng)中，現(xiàn)在有5臺(tái)物理機(jī)，這5臺(tái)物理機(jī)都是屬于EXS的系統(tǒng)，那么我要保證這5臺(tái)EXS的系統(tǒng)都能被我們虛擬機(jī)關(guān)聯(lián)上，我們?cè)茍F(tuán)隊(duì)會(huì)把所有虛擬機(jī)報(bào)上來，那所有的虛擬機(jī)是不是都落在這5臺(tái)上，如果都落在這5臺(tái)上沒有問題，如果沒有落上，我們看一看有某些物理機(jī)沒有被關(guān)聯(lián)上是因?yàn)樗鼪]有在使用中還是它漏報(bào)了，這是一種交叉比對(duì)的方式，不管是ARP表的比對(duì)還是交叉比對(duì)，乃至于今天到生產(chǎn)上找一臺(tái)機(jī)器，去用 TCPdump 找出上下游的關(guān)系，這也是一種方法。

可以找到在生產(chǎn)上所有活躍的IP，這些IP是不是所有活躍在CMDB當(dāng)中都被落到某一個(gè)對(duì)象里面去，這樣的方式就可以持續(xù)去做，需要有一個(gè)報(bào)表的體系去推動(dòng)數(shù)據(jù)的治理，因?yàn)槲覀兌贾?CMDB 這個(gè)東西數(shù)據(jù)準(zhǔn)確率是非常重要的一項(xiàng)，如果今天的數(shù)據(jù)準(zhǔn)確率不按照這個(gè)報(bào)表體系，每天每周去跟進(jìn)去處理的話，當(dāng)然你后面還要去建立一些像SLA處理及時(shí)率這些東西，來考核每個(gè)領(lǐng)域數(shù)據(jù)的準(zhǔn)確性，只有這樣我們的CMDB才能夠持續(xù)穩(wěn)健成長(zhǎng)。

那接下來我們要說在我們完成三階段，我們把CMDB建設(shè)起來了，但是我們最重要的環(huán)節(jié)就是剛剛說到，我們把CMDB的數(shù)據(jù)弄進(jìn)來之后，只能解決這個(gè)每一層的關(guān)系，現(xiàn)在還不具備通過一個(gè)機(jī)柜能夠知道DB相關(guān)信息，整天鏈都不知道。

那么接下來就是另外一個(gè)，當(dāng)我們完成 CMDB 構(gòu)建的時(shí)候，接下來要做關(guān)系了，如何構(gòu)建一個(gè)復(fù)雜的關(guān)系實(shí)現(xiàn)一個(gè)快速的檢索，我們看一下這套架構(gòu)圖，這個(gè)是我么CMDB，我們的源數(shù)據(jù)在這里，所有變更事件會(huì)推到 Kafka 隊(duì)列，所有變更事件，比如說今天進(jìn)來一條數(shù)據(jù)，這條數(shù)據(jù)產(chǎn)生變化，會(huì)把這些變化推到Kafka，F(xiàn)link 會(huì)經(jīng)過一段流程處理，然后加工，可以不加工，加工是業(yè)務(wù)需求，然后在這個(gè)當(dāng)成主要做一些格式，為了更好去檢索使用，然后就推到ES去了。

上面這條路能實(shí)現(xiàn)什么，上面這條路能夠?qū)崿F(xiàn)快速模糊查詢，我們可以輸入一個(gè)IP，可以輸入一個(gè)APPID，可以輸入一個(gè)CICODE，乃至于我今天輸入一個(gè)聯(lián)系人，我都可以去找到所有相關(guān)的信息，它雖然說還無法完成這個(gè)圖，但是至少可以有類似于百度的一些信息，你百度一個(gè)模糊查詢，我搜索一個(gè)人名，我是不是可以搜索到相關(guān)的管理員是他所有的模型記錄，在ES里面這個(gè)不難做到。

現(xiàn)在 CMDB 的模型大概是在30個(gè)左右，導(dǎo)到ES里面也是30張獨(dú)立的表，大概的字段是在700接近800個(gè)，全面索引，目前這個(gè)數(shù)據(jù)量在二三十萬條記錄這樣子，壓力也沒有壓力，ES集群也是用的虛擬機(jī)做的，也沒有什么特別厲害，因?yàn)镋S就擅長(zhǎng)做這件事情。

要實(shí)現(xiàn)這張圖，我們還需要借助于優(yōu)秀的東西叫做NEO4J，NEO4J 這個(gè)數(shù)據(jù)庫最近也是炒得比較火，我們從 Flink 拿一條數(shù)據(jù)進(jìn)入到NEO4J，原生的進(jìn)去，之前是什么關(guān)系我還是什么關(guān)系進(jìn)去，不加任何關(guān)聯(lián)關(guān)系，直接把這層的關(guān)系直接導(dǎo)入到 NEO4J 通過數(shù)據(jù)庫去變例出來，去能實(shí)現(xiàn)這樣的一張條，這樣藍(lán)色部分所有都是NEO4J可以搞定的事情，然后接下來我在把變更記錄往NEO4J里面導(dǎo)，把告警記錄往NEO4J里面導(dǎo)，所做出來就是一層一層帶著告警帶著源數(shù)據(jù)，帶著變更日志的信息了。

NEO4J 它的處理能力是比較高，處理十多個(gè)億這樣的關(guān)系節(jié)點(diǎn)也是非常的高效，我們的使用來說還是比較小的，也就幾十萬節(jié)點(diǎn)而已，大概在30萬關(guān)系左右進(jìn)入NEO4J。

總結(jié)

因?yàn)闀r(shí)間有限，沒辦法每個(gè)地方都展開精細(xì)的說明，再回顧一下今天的內(nèi)容，CMDB首先要有三個(gè)階段，第一個(gè)階段要建模，建的模型一定要夠簡(jiǎn)單，它的關(guān)系只關(guān)聯(lián)到 OS就夠了，領(lǐng)域跟領(lǐng)域之間不要做額外的關(guān)聯(lián)，關(guān)聯(lián) NEO4J 會(huì)幫我們輕松的搞定。

第二，要解決閉環(huán)的問題，因?yàn)殚]環(huán)是 CMDB 的基礎(chǔ)，必須先要有閉環(huán)然后才能得到增量，負(fù)責(zé)天天全量不行。

第三，是解決存量的問題，解決存量問題的時(shí)候，我們要記得一定要交叉比對(duì)，要對(duì)上報(bào)的數(shù)據(jù)持有懷疑，雖然說它是領(lǐng)域是權(quán)威數(shù)據(jù)，但是 CMDB 一定要對(duì)上報(bào)數(shù)據(jù)有懷疑，去發(fā)現(xiàn)，去想辦法去探測(cè)等等手段去幫助領(lǐng)域上報(bào)的數(shù)據(jù)做到更全、更準(zhǔn)。

有了這三步之后我們要持續(xù)做報(bào)表，將有問題的數(shù)據(jù)及時(shí)的拋出來，因?yàn)闀r(shí)間長(zhǎng)了之后對(duì)數(shù)據(jù)的治理難度很高，比如你今天做了一個(gè)變更，這個(gè)變更可能沒有及時(shí)更新上 CMDB，CMDB 第二天發(fā)現(xiàn)了，如果不報(bào)出來，過了三五天之后，這個(gè)數(shù)據(jù)的這條變更沒有人記得，也許它就在我們記錄變更表當(dāng)中，但是很難去找到它，大家可能想不到，所以要及時(shí)去處理，想盡一切辦法去推動(dòng)這個(gè)數(shù)據(jù)的整改和治理，CMDB建完之后可以通過ES來做檢索，可以通過NEO4J來做拓?fù)?，?dāng)中只需要 Kafka 把變更的數(shù)據(jù)持續(xù)往ES里面更新，CMDB進(jìn)ES的數(shù)據(jù)，可以原封不動(dòng)，一張模型一張表這樣導(dǎo)進(jìn)去，進(jìn)NEO4J的時(shí)候可以把 CMDB 的數(shù)據(jù)一個(gè)一個(gè)，原來的模型是怎樣就導(dǎo)進(jìn)去，不需要增加新的模型，NEO4J會(huì)為我們處理拓?fù)淠Ｐ汀?/p>

道家有個(gè)說法叫做萬變不離其宗，不管上層的邏輯做的多復(fù)雜，CMDB 永遠(yuǎn)保存住最原始的關(guān)系，這是最好的，這樣能保存它的擴(kuò)展和復(fù)雜度永遠(yuǎn)維持在一個(gè)相對(duì)穩(wěn)定的水平線上，那《道德經(jīng)》當(dāng)中也有一句話也是說過，萬物之始，大道至簡(jiǎn)，衍化至繁，咱們CMDB 也是如此。