CMDB是一個較為老生常談的問題，這一概念在很早時期就已經(jīng)引入了國內(nèi)，縱觀運維數(shù)字化轉型的整個發(fā)展過程， CMDB的建設是每個企業(yè)都必經(jīng)的重要階段。早期的CMDB往往只是為了提供運維流程的支撐，數(shù)據(jù)準確性得不到保障，運維依賴程度低，常常會出現(xiàn)“建而無用”等情況。然而隨著數(shù)字化轉型的不斷推進，運維需要更高質量的數(shù)據(jù)，運維平臺需要更高效可靠的支撐，CMDB作為運維基石是重中之重，也需要進一步的“修煉”！

那么在實際落地建設過程中，可視、可用、可信、可靠的CMDB怎么打造？企業(yè)又該如何“修煉”面向消費的運維高質量CMDB呢？本文帶您一探究竟！

01. CMDB的常見場景與痛點

CMDB建設過程中，企業(yè)通常會遇到一些困境，同時由于企業(yè)里面不同角色對CMDB的訴求各不相同，CMDB對于不同的視角下的痛點也是不一樣的。

1）企業(yè)建設CMDB的“三重困境”

① 消費場景的局限

早期CMDB前期建設時，并沒有以應用為中心的概念，運維人員與運維管理者往往關注在IT“資產(chǎn)”上

“有沒有相應的IT資產(chǎn)？資產(chǎn)在什么位置？其運行情況如何？現(xiàn)有的業(yè)務依賴哪些資產(chǎn)？”等等一系列問題。

而隨著運維場景的不斷豐富與建設，越來越多的消費需求不斷迸發(fā)，比如說需要對監(jiān)控系統(tǒng)進行故障影響分析、對大屏數(shù)據(jù)進行聚合與展示時，以“資產(chǎn)”為中心的CMDB由于前期設計就沒有考慮到數(shù)據(jù)間的關聯(lián)關系，導致數(shù)據(jù)消費問題非常難以解決。

② 架構設計的局限

當前期CMDB建設沒有被定義為整個企業(yè)的運維主數(shù)據(jù)時，各個部門都在單打獨斗的建立自己的CMDB供自己使用，導致企業(yè)內(nèi)各式各樣的煙囪式的系統(tǒng)建設，帶來數(shù)據(jù)分散、數(shù)據(jù)質量低、數(shù)據(jù)維護工作量大等問題，難以統(tǒng)一去治理。

③ 流程管理的局限

管理流程上的局限通常更多會影響到數(shù)據(jù)的質量問題，如果沒有有效的管理流程以及自動化能力，那么就相當于CMDB的數(shù)據(jù)僅僅只是從線下的表格搬到了線上工具里，甚至與一個在線的EXCEL表格是沒有太大區(qū)別的，仍然需要運維人員花費大量的時間去收集真實環(huán)境的數(shù)據(jù)導入到CMDB中去，這樣的數(shù)據(jù)質量是存疑的。

同時對于運維人員來說，每天的工作并沒有什么變化，這樣的CMDB的建設帶來的管理成本是遠遠大于價值收益的。

2）三類運維角色視角

① 企業(yè)管理者視角

企業(yè)管理者更多會從全局和成本的角度去關心CMDB能夠提供的價值。通常會考慮以下幾類問題：CMDB建設成本是否合理？資源使用率如何？是否可以承載消費場景需求？是否兼容新架構、異構化等，以確保企業(yè)業(yè)務運行所依賴的IT對象管理足夠全面、足夠規(guī)范和合理。

② 運維管理者視角

對于運維管理者或者運維經(jīng)理等角色，更關心CMDB落地為企業(yè)帶來的價值，CMDB建設是一個長期的過程，運維管理者需要讓這一高成本建設，能夠合理的使用起來，保證數(shù)據(jù)的準確性，提供業(yè)務價值。

③ 運維工程師視角

作為真正使用CMDB的運維工程師，更關注在于CMDB產(chǎn)品設計的體驗，是否足夠方便、快捷，能不能減少運維工作量，從實際工作的角度出發(fā)去考慮。

02. CMDB落地常見問題

大部分的企業(yè)基本都做過了CMDB的建設，除了以上在各個場景的困境之外，在落地建設的時候，通常也會遇到各類問題，結合嘉為多年幫助企業(yè)建設CMDB的經(jīng)驗，我們總結并列舉了以下六個問題，與大家深入分析CMDB在落地時的一些相對典型的難點。

1）靈活性不足

有一部分企業(yè)在早期是通過引進國外的CMDB，這類CMDB更加偏向于某一領域，例如側重于網(wǎng)絡領域的，亦或是側重于資產(chǎn)領域的，在實際產(chǎn)品中，靈活性可以從兩個方面去判斷：

• 模型定義是否靈活
• 屬性定義是否靈活

隨著業(yè)務發(fā)展，IT環(huán)境日益復雜，IT對象種類繁多，CMDB是否足夠靈活，是否支持自定義擴展，是否適配新的技術，能否對新對象進行納管，對企業(yè)長期建設發(fā)展是非常重要的。

2）自動化不足

顧名思義也就是指整個配置數(shù)據(jù)自動化維護的程度不足，在以往建設過的客戶中，我們發(fā)現(xiàn)許多客戶的CMDB數(shù)據(jù)新增、更新、刪除都是通過人工收集，再去CMDB做導入。實際上這不僅僅讓運維人員維護數(shù)據(jù)的成本很高，同時數(shù)據(jù)的的準確性也無法得到保障，并且有一部分高頻變化的數(shù)據(jù)例如容器化數(shù)據(jù)等，十分難以通過人工去保證。

• 對于傳統(tǒng)對象，自動化不足嚴重影響維護成本和數(shù)據(jù)準確性
• 對于容器化對象、云對象，變更更頻繁，自動化不足嚴重影響數(shù)據(jù)準確性

3）權限管控不足

近年來，對于金融、運營商等行業(yè)，權限審計、合規(guī)審計等的要求越來越嚴格，在這種日漸趨嚴的安全制度下，對整個CMDB的設計提出了更高的要求，能否滿足細顆粒度、精細化的權限管控將直接影響整個CMDB在企業(yè)落地的效果。

4）業(yè)務價值體現(xiàn)不足

主要還是體現(xiàn)在早期以“資產(chǎn)”為中心的CMDB中，由于無法呈現(xiàn)IT對象與業(yè)務之間的關系，不能夠有效支撐判斷IT對象對業(yè)務的影響，同時無法感知業(yè)務下的資源總體情況，CMDB模型設計層面如果無法支持端到端，沒有完整的拓撲呈現(xiàn)的話，是沒辦法隨著運維自動化、智能化的發(fā)展去體現(xiàn)它作為IT運維平臺的基石的價值的。

5）數(shù)據(jù)質量不足

數(shù)據(jù)質量不足目前也是令許多企業(yè)非常頭疼的問題之一，由于數(shù)據(jù)填充度低、關鍵關聯(lián)關系缺失、數(shù)據(jù)填充及設計缺乏統(tǒng)一規(guī)范，導致CMDB后期規(guī)模越來越大時，就像一張網(wǎng)，幾十萬的實例、上百萬的關聯(lián)關系在這張網(wǎng)上錯綜復雜，運維人員開始無法感知到CMDB數(shù)據(jù)質量的問題，同時也不能夠保證當前所定義的指標是否能夠真正的幫助運維人員去解決數(shù)據(jù)質量的問題。

6）消費場景不足

這類問題通常與前期建設的目標和思路會有一些關系，如果在建設初期基本是“空想”式建設，沒有考慮清楚面向什么消費對象，支撐內(nèi)部什么工具，建設起來以后發(fā)現(xiàn)除了帶來維護成本，沒有太大的價值。

CMDB建設有兩大核心，模型設計的是否合理，是否真正以“消費”來驅動，這是一大核心，第二個核心就是數(shù)據(jù)治理和運營體系。

所以消費場景其實會很大程度影響到模型設計，而嘉為藍鯨CMDB就是基于消費去驅動，在設計模型時的思路并不傾向于建設一個“大而全”的CMDB，而更加傾向于“小而美”的有價值的CMDB。以此建設的CMDB才能夠為消費人員所用，為業(yè)務帶來價值，才能夠避免出現(xiàn)“建而無用”的問題。

03. CMDB的常見常見與痛點

談完了CMDB建設的困境痛點與典型問題，那么大家可能會問：到底運維高質量CMDB應該如何打造呢？

我們以嘉為藍鯨CMDB為例，總結以下“1個基本功、4大修煉法寶”，來幫助企業(yè)梳理清楚CMDB的設計思路，正確打造適合企業(yè)環(huán)境，能夠帶來價值的高質量CMDB。

1）基本功修煉：

嘉為藍鯨配置管理中心，提供自動化、平臺化、高性能、場景化的產(chǎn)品架構方案。

• 自動化：提供自動化發(fā)現(xiàn)能力，減少人工維護的成本投入，同時提升數(shù)據(jù)準確性。
• 平臺化：提供可靈活自定義的配置建模平臺，以應對隨IT運維不斷發(fā)展而帶來的環(huán)境變化。
• 高性能：支持千萬級的海量數(shù)據(jù)納管，滿足支撐大規(guī)模IT運維環(huán)境的訴求。
• 場景化：在平臺化的基礎之上，構建面向不同角色、不同場景的管理訴求，應用視角的CMDB、基礎架構視角的CMDB、資產(chǎn)視角的CMDB、行業(yè)特定場景的CMDB等。

2）修煉法寶一：模型最佳實踐、靈活建模、屬性級權限

• 提供通用性、行業(yè)性模型規(guī)劃設計最佳實踐
• 支持對象、屬性、關聯(lián)的自定義擴展，可靈活基于企業(yè)實際情況進行調整
• 基于abac的權限設計，支持實例、屬性顆粒度的權限管控，滿足不同企業(yè)組織架構下的配置Owner的權限分配

3）修煉法寶二：獨有的配置數(shù)據(jù)維護“三視角”體驗

基于CMDB本身，結合實踐經(jīng)驗，面向不同運維角色提供不同的數(shù)據(jù)維護，提升不同視角下的用戶體驗。

• 業(yè)務應用視角：面向運維管理員，提供業(yè)務拓撲形式數(shù)據(jù)維護界面，幫助把握全局。

• 基礎軟件資源視角：面向DBA、中間件運維人員，提供實例列表，便于數(shù)據(jù)錄入、維護等。

• 基礎設施（IDC）視角：面向基礎架構人員，提供IDC視角，幫助IDC運維人員維護數(shù)據(jù)。

4）修煉法寶三：自動化發(fā)現(xiàn)、采集

• 提供開箱即用內(nèi)置插件100+，覆蓋基礎軟件、主機、基礎架構、基礎設施等各個運維層面40多種對象，1000+屬性 。
• 提供良好的可擴展性，以滿足客戶特有對象的覆蓋，包括與監(jiān)控系統(tǒng)、網(wǎng)管系統(tǒng)等第三方數(shù)據(jù)源的集成對接。
• 全新升級的配置發(fā)現(xiàn)4.X版本，可支撐每日千萬級的數(shù)據(jù)自動化錄入CMDB。

5）修煉法寶四：運營分析與持續(xù)改進

基于PDCA建立數(shù)據(jù)治理閉環(huán)，輔以自動化技術手段，持續(xù)保證數(shù)據(jù)質量。

04. 精選Q&A

答：維護數(shù)據(jù)一般有幾種方式，第一種就是直接在CMDB上新建，第二種就是導入，第三種是通過API形式錄入，第四種就是自動發(fā)現(xiàn)與采集。至于4種方式里面企業(yè)主要選擇哪些，根據(jù)企業(yè)現(xiàn)狀會有一些不同占比。但從數(shù)據(jù)治理的角度來講，我們需要盡可能采取自動化的維護，以及與流程進行聯(lián)動的方式。

Q2：CMDB只記錄資源靜態(tài)數(shù)據(jù)嗎？是否會記錄并實時更新資源狀態(tài)？如部分主機變配過程中，資源狀態(tài)一直在變化，CMDB會實時更新嗎？

答：CMDB是不同于監(jiān)控，首先我們不建議在CMDB中存放變化頻率很高的數(shù)據(jù)，就比如監(jiān)控的性能指標數(shù)據(jù)等，但如果說有一些過程狀態(tài)類的數(shù)據(jù)，例如主機有上架、下架、維修、出庫等生命周期狀態(tài)，是可以放入到CMDB中去納管的。

但這個數(shù)據(jù)我們不建議人工來維護，最好是定義其中一些關鍵的狀態(tài)，并通過與IT運維流程平臺做關聯(lián)，當流程中完成相應的工單審批以后，狀態(tài)就隨之發(fā)生改變，從而去維護這類數(shù)據(jù)。

Q3：配置發(fā)現(xiàn)有沒有考慮支持數(shù)據(jù)刪除和更新關聯(lián)關系？云資源在做日常維護時，人工維護工作量太大，同時云資源刪除后是否可通過自動化的手段體現(xiàn)在CMDB中？

答：這個目前是支持的，嘉為藍鯨配置發(fā)現(xiàn)無論是從IT對象、從云平臺還是從其他系統(tǒng)對接去做數(shù)據(jù)采集時，一定會與CMDB的數(shù)據(jù)做對比，對比過程中會產(chǎn)生相應的結果例如刪除數(shù)據(jù)、創(chuàng)建數(shù)據(jù)、修改數(shù)據(jù)，那么同時與之相應關聯(lián)關系也會有刪除關聯(lián)、創(chuàng)建關聯(lián)以及修改關聯(lián)等，目前都是支持這些功能的。

Q4：企業(yè)版CMDB有模型管理設置只讀、讀寫權限功能嗎？

答：藍鯨配置平臺只包含一個平臺層的PaaS產(chǎn)品，企業(yè)版本身并不包含該功能。但嘉為藍鯨CMDB除了配置平臺以外，還會提供兩個上層SaaS，一個是配置管理中心，一個是配置發(fā)現(xiàn)，在這兩個SaaS中會相應提供該功能。