一、CMDB的本質(zhì)是什么？

之前很多人問我，CMDB到底是什么？我總是很難回答，因?yàn)檫@個(gè)東西有點(diǎn)抽象，你可以說它是一個(gè)存儲(chǔ)了IT運(yùn)維對象配置數(shù)據(jù)和關(guān)系的數(shù)據(jù)庫，但總感覺太low。

直到有一天，我看到一部名叫《太空旅客》的電影，這部電影講述了一群地球人乘坐一艘太空飛船遠(yuǎn)航到另一個(gè)星球殖民，期間飛船發(fā)生了故障，一對旅客合力拯救飛船的故事。這艘飛船是這樣的：

當(dāng)發(fā)生隕石撞擊后，電影迅速切換到總控中心的監(jiān)控畫面：

當(dāng)時(shí)我忽然有一種被電擊的感覺，這不就是CMDB嘛！

不過那時(shí)對這玩意也沒有一個(gè)標(biāo)準(zhǔn)叫法。就覺得這不僅僅是一個(gè)好看的飛船畫面，它包含了一些更深層的東西。直到近兩年，隨著IoT產(chǎn)業(yè)的發(fā)展，一個(gè)新詞頻繁的出現(xiàn)：數(shù)字孿生。聽到這個(gè)詞后，我腦海中忽然又浮現(xiàn)出太空旅客的飛船畫面，同時(shí)蹦出四個(gè)字母：CMDB。

這里簡單介紹一下什么是“數(shù)字孿生”？

所謂“數(shù)字孿生”，是指以數(shù)字化方式為現(xiàn)實(shí)對象創(chuàng)建虛擬模型，以模擬其在現(xiàn)實(shí)環(huán)境中的行為以及和其他對象的交互關(guān)系。這里說的現(xiàn)實(shí)對象包括設(shè)備、建筑、園區(qū)、軟件系統(tǒng)、業(yè)務(wù)流程等現(xiàn)實(shí)存在的物理或邏輯上的事物。

數(shù)字孿生由美國國防部提出，用于航空航天飛行器的健康維護(hù)與保障。在數(shù)字空間建立真實(shí)飛行器的模型，并通過傳感器實(shí)現(xiàn)與飛行器真實(shí)狀態(tài)完全同步，這樣每次飛行后，根據(jù)現(xiàn)有情況和過往載荷，及時(shí)分析評估是否需要維修，能否承受下次的任務(wù)載荷等。

數(shù)字孿生一般有四個(gè)特征：

同質(zhì)化

指現(xiàn)實(shí)對象和虛擬對象之間的數(shù)據(jù)不存在脫節(jié)或知識(shí)鴻溝

連接性

指通過傳感器實(shí)現(xiàn)數(shù)據(jù)從現(xiàn)實(shí)對象到虛擬對象的傳遞

可編程

指對虛擬對象的編程可影響到現(xiàn)實(shí)對象，以提升現(xiàn)實(shí)對象的可用性和性能

數(shù)字跟蹤

對現(xiàn)實(shí)對象或虛擬對象的任何操作都有數(shù)據(jù)日志，以便于跟蹤

而CMDB也完美的符合上面四個(gè)特征：

同質(zhì)化

指CMDB數(shù)據(jù)模型描述IT環(huán)境的能力。這里主要考驗(yàn)配置模型的設(shè)計(jì)粒度。理論上，當(dāng)CI模型的粒度足夠細(xì)，屬性足夠多，CI就和現(xiàn)實(shí)運(yùn)維對象完全一致了。但實(shí)際上需要平衡成本和效益。合理的做法是，我們的配置模型應(yīng)具備同質(zhì)化描述IT環(huán)境的能力，但在實(shí)施時(shí)不能一步到位，要根據(jù)需求和成本一點(diǎn)點(diǎn)做；

連接性

指CMDB數(shù)據(jù)應(yīng)該與IT環(huán)境是一致的，IT環(huán)境變化，CMDB數(shù)據(jù)也要自動(dòng)變化（在線CMDB）；

可編程

對CI的編程可觸發(fā)對現(xiàn)實(shí)IT環(huán)境的調(diào)整（比如重啟一個(gè)CI，現(xiàn)實(shí)服務(wù)器就重啟了），但這里需要實(shí)現(xiàn)CMDB與自動(dòng)化平臺(tái)、流程管控平臺(tái)的緊密結(jié)合；

數(shù)字跟蹤

對現(xiàn)實(shí)對象的任何操作都有日志記錄，這里指流程數(shù)據(jù)沉淀。

上面四個(gè)特征中，非常重要的是同質(zhì)化和連接性，是CMDB成功的基石。

這里的同質(zhì)化說的就是配置模型。配置模型的好壞決定了CMDB描述IT環(huán)境的基本能力。比如在某金融客戶項(xiàng)目中，我們在客戶領(lǐng)導(dǎo)和技術(shù)專家的設(shè)計(jì)成果基礎(chǔ)上，融合了行業(yè)優(yōu)秀的實(shí)踐，形成了具備客戶個(gè)性化特色的配置模型。總體上，IT資源被劃分為三個(gè)大的層次：應(yīng)用層、基礎(chǔ)資源層、基礎(chǔ)設(shè)施層。每一層都有特定的CI分類和關(guān)系，如下圖：

上述CI分類有兩種顏色，橙色和藍(lán)色，分別對應(yīng)核心模型和領(lǐng)域模型：

1.核心模型會(huì)被廣泛使用，所以要優(yōu)先落地并重點(diǎn)保障數(shù)據(jù)質(zhì)量。核心模型要小而美，要穩(wěn)定，因?yàn)閷ζ湫薷目赡苡绊懛秶容^大。

2.領(lǐng)域模型主要在各技術(shù)崗內(nèi)部使用，跨部門的數(shù)據(jù)共享需求不高，可由各技術(shù)管理崗自主建設(shè)和維護(hù)。這樣的好處是各崗位可根據(jù)自身管理需求靈活調(diào)整數(shù)據(jù)模型和內(nèi)容，提升大家使用CMDB的積極性。

配置模型相當(dāng)于CMDB的基因，它決定了CMDB同質(zhì)化描述現(xiàn)實(shí)IT環(huán)境的基本能力。但我們要也要清楚，基因并不是靜態(tài)的，它是不斷進(jìn)化的，所以在設(shè)計(jì)配置模型時(shí)，也不需要過度糾結(jié)，大方向正確即可，形成階段性成果后盡快投入實(shí)戰(zhàn)檢驗(yàn)。

有了好的配置模型，相當(dāng)于CMDB有了不錯(cuò)的基因，接下來要解決數(shù)據(jù)的連接線問題，通過不斷健身讓CMDB保持生命的活力。所謂連接性，就是數(shù)據(jù)要在線。如果數(shù)據(jù)不在線，完全依靠人工維護(hù)是不靠譜的，過幾天就不準(zhǔn)了。從行業(yè)實(shí)踐看，CMDB的數(shù)據(jù)連接性（或稱在線率）要超過60%才能活下來。

可是怎么解決數(shù)據(jù)在線率問題？ 物聯(lián)網(wǎng)好辦，弄一些傳感器實(shí)時(shí)上報(bào)數(shù)據(jù)就行了。但是IT環(huán)境比較麻煩，主要有三個(gè)方面的挑戰(zhàn)：

1.大部分IT對象不會(huì)主動(dòng)上報(bào)數(shù)據(jù)，需要探針掃描，這就需要開通賬號(hào)權(quán)限和網(wǎng)絡(luò)訪問策略，會(huì)涉及一些安全風(fēng)險(xiǎn)和性能隱患；

2.IT環(huán)境老變，新對象往往因?yàn)楦鞣N權(quán)限或網(wǎng)絡(luò)隔離原因而無法掃描到，需要通過運(yùn)營來持續(xù)提升自動(dòng)發(fā)現(xiàn)覆蓋率，所以涉及持續(xù)的成本投入；

3.另外還有很多管理信息（責(zé)任人、重要級別等）是無法通過掃描獲得的。

所以，CMDB的連接性不是上一個(gè)自動(dòng)發(fā)現(xiàn)工具，然后打一個(gè)響指就搞定了，如果真這么簡單，CMDB的失敗率就不至于這么高。

保障CMDB數(shù)據(jù)在線率是一個(gè)系統(tǒng)性工程，需要流程、CMDB、自動(dòng)化平臺(tái)、自動(dòng)發(fā)現(xiàn)平臺(tái)四者相互配合：

就自動(dòng)發(fā)現(xiàn)本身而言，應(yīng)該多策略、多方案并舉。我們知道，自動(dòng)發(fā)現(xiàn)本身除了實(shí)施成本外，還會(huì)涉及安全風(fēng)險(xiǎn)（開權(quán)限和網(wǎng)絡(luò)訪問策略）、性能風(fēng)險(xiǎn)（對被發(fā)現(xiàn)對象的性能可能有微小影響）和持續(xù)運(yùn)營投入（確保新增對象被及時(shí)發(fā)現(xiàn)），有沒有更好的方案來規(guī)避這些問題？

舉一個(gè)實(shí)際的例子：我們之前完成了DB自動(dòng)發(fā)現(xiàn)測試，能夠發(fā)現(xiàn)數(shù)據(jù)庫實(shí)例名、庫名、表空間、用戶等信息，基本滿足DBA組的需求。但要成功的發(fā)現(xiàn)這些DB，首先需要使用NMAP工具對全網(wǎng)掃描，根據(jù)端口特征識(shí)別哪些服務(wù)器上有DB，然后再用一個(gè)專用DB賬號(hào)執(zhí)行命令獲得數(shù)據(jù)。NMAP全網(wǎng)掃描和專用DB賬號(hào)這兩個(gè)事情就和安全部門掰扯了很長時(shí)間。后來DBA告訴我們，數(shù)據(jù)庫有一個(gè)專門的性能分析工具，里面有所有需要自動(dòng)發(fā)現(xiàn)的數(shù)據(jù)。我們?yōu)槭裁床恢苯幼鲆粋€(gè)集成接口，將數(shù)據(jù)拉過來就行了？所以在實(shí)施自動(dòng)發(fā)現(xiàn)時(shí)，要先調(diào)研目前是否已有更好的替代工具，我們的目的是提升數(shù)據(jù)連接性，要尋找風(fēng)險(xiǎn)和成本小、見效快的辦法，自動(dòng)發(fā)現(xiàn)只是其中一種技術(shù)手段，不要把手段當(dāng)成目的。

二、CMDB要解決什么問題？

CMDB能解決什么問題，網(wǎng)上有很多分享文章都有講，大家可以自行搜索了解。由于每個(gè)地方管理現(xiàn)狀、痛點(diǎn)不太一樣，所以對CMDB的具體用法也不一樣。在某金融客戶的實(shí)際項(xiàng)目中，基于客戶IT運(yùn)維管理現(xiàn)狀，在CMDB建設(shè)初期到底能解決什么問題？經(jīng)過前期的初步探討，我們覺得在建設(shè)初期可以考慮下面四個(gè)場景（注意，這些場景不需要有多么宏偉，初期可能只是解決一些小問題，并在此過程中持續(xù)優(yōu)化，讓CMDB逐步成長、成熟）：

1.網(wǎng)絡(luò)訪問策略查詢

網(wǎng)絡(luò)崗客戶告訴我們，應(yīng)用崗經(jīng)常找他們問某些IP的網(wǎng)絡(luò)訪問策略，這讓網(wǎng)絡(luò)崗很頭疼，因?yàn)榫W(wǎng)絡(luò)崗自己也不是特別清楚所有IP的訪問策略，往往需要登到防火墻上查一下。這種事情雖然小，但架不住多啊，很干擾正常的網(wǎng)絡(luò)運(yùn)維工作。有沒有可能自動(dòng)抓取防火墻策略，講數(shù)據(jù)解析出來入庫到CMDB中，這樣應(yīng)用崗直接去CMDB查就是了，不用老是麻煩網(wǎng)絡(luò)崗。

2.文件系統(tǒng)告警通知

主機(jī)崗客戶告訴我們，現(xiàn)在很多文件系統(tǒng)告警本來應(yīng)該是應(yīng)用崗處理。但因?yàn)楸O(jiān)控系統(tǒng)無法識(shí)別文件系統(tǒng)的負(fù)責(zé)人，所以一股腦兒都報(bào)給主機(jī)崗了。這就給主機(jī)崗增加了額外的信息傳遞成本，還增加了告警處理時(shí)間。能否通過CMDB，將文件系統(tǒng)責(zé)任人信息豐富給告警，讓告警及時(shí)傳遞給正確的人員？

3.服務(wù)請求數(shù)字化

所有IT資源的申請、安裝部署、遷移、卸載都要走服務(wù)請求流程。我們發(fā)現(xiàn)，很多配置信息都會(huì)在流程中聲明，但卻沒有和CMDB聯(lián)動(dòng)，這會(huì)導(dǎo)致流程操作記錄無法與CI關(guān)聯(lián)上，也就無法從CI角度回溯歷史工單。我們希望提升流程的數(shù)字化水平，將IT資源配置信息自動(dòng)沉淀到CMDB中。

4.監(jiān)控覆蓋率

監(jiān)控是另一個(gè)有趣的場景。目前的情況是，用戶通過服務(wù)請求完成資源申請和部署后，主機(jī)崗、應(yīng)用崗和數(shù)據(jù)庫崗還需要針對新部署的資源提交監(jiān)控申請，然后運(yùn)管崗負(fù)責(zé)監(jiān)控部署工作。這就有可能因?yàn)楦鞣N原因?qū)е卤O(jiān)控遺漏。而這種遺漏很難發(fā)現(xiàn)，因?yàn)檫\(yùn)管崗并不清楚目前IT環(huán)境中到底有哪些服務(wù)器、數(shù)據(jù)庫和中間件，根本無從統(tǒng)計(jì)監(jiān)控覆蓋率。能否通過CMDB解決這個(gè)隱患？比如讓CMDB定期輸出一份清單，告訴監(jiān)控系統(tǒng)新增了多少IT資源，更進(jìn)一步，未來是否可以將CMDB中新增的IT資源自動(dòng)同步給自動(dòng)化平臺(tái)，實(shí)現(xiàn)監(jiān)控的自動(dòng)部署？

上述四個(gè)場景是我們階段性調(diào)研的結(jié)果，未來可能有更多場景。不過，我們會(huì)發(fā)現(xiàn)上面四個(gè)場景都有一個(gè)共性，就是都在利用CMDB解決跨團(tuán)隊(duì)、跨工具的數(shù)據(jù)共享問題。這是CMDB的核心定位。