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

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

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

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

當時我忽然有一種被電擊的感覺，這不就是CMDB嘛！

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

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

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

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

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

同質(zhì)化

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

連接性

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

可編程

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

數(shù)字跟蹤

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

而CMDB也完美的符合上面四個特征：

同質(zhì)化

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

連接性

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

可編程

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

數(shù)字跟蹤

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

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

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

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

1.核心模型會被廣泛使用，所以要優(yōu)先落地并重點保障數(shù)據(jù)質(zhì)量。核心模型要小而美，要穩(wěn)定，因為對其修改可能影響范圍比較大。

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

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

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

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

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

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

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

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

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

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

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

二、CMDB要解決什么問題？

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

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

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

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

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

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

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

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

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

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