1、雲時代的到來，我們是否需要審視CMDB的定位和作用？
【問題描述】目前是雲2.0時代，以應用為中心，容器技術的出現，讓我們不用關注我們的應用運行在什麼主機上，應用之間的訪問拓撲可以實時展示。在這個時代，CMDB是否還有存在的必要性？
這個話題值得探討。容器的出現，交付部署發生巨大改變，而且容器平臺本身集成或標配了配置中心、監控等許多組件。容器平臺本身提供了”一條龍服務“，取代了原本各種複雜林立的運維工具平臺，一統江湖。從這個意義上，原來CMDB的主數據價值是降低了。同時，容器自身也集成了一個CMDB。
另外一個方面，微服務化導致模塊間的運行關係複雜度大大提高，這或許是CMDB將來的一個方向。
CMDB是IT數據中心的軟資產，可以看成是資本，新技術重塑的業務肯定要從CMDB的環境中分離出去。就像銀行會計核心系統，會計準則是不會變，變的是周邊系統和資產放哪兒更合適？一個是技術主導，一個是信息資產。就看覆蓋面到什麼程度，就像雲環境下的虛擬化、Docker使用，總還有為數不少的環境要求bare metal box運行，甚至還有要求特殊系統的，諸如windows等。一個平臺或系統的存在與否，不是技術決定，也不是信息本身決定，而是所要生存的環境和用戶使用需求決定。
@匿名用戶：
在雲時代，對於CMDB的要求的迫切性更高了，更快的發佈，更容易的更迭，更加複雜的結構和更多的版本如果沒有相應的系統去管理，整個雲平臺系統會逐漸變得不可知和不可管理，而且雲平臺裡面不僅僅只有容器，還有虛擬機，裸設備以及各種最後的網絡環境存儲環境！
@asdf-asdf：
CMDB在裸金屬和VM時代對設備的全生命週期管理有著幾個數據消費用戶，在當前容器時代對實時數據的一致性對當前以配置穩定性為基礎的CMDB系統給出來挑戰，在以動態數據實時捕獲和以往CMDB數據集成方向，完成一個完整的數據業務中臺服務，使數據生產者能實時把數據推送到數據中臺，消費者可隨時發起數據消費，等待實時數據推送完成。對當前CMDB改造完成到數據中臺過度，使數據消費者能實時獲得所需要數據，並保證數據當前時間的一致性是為了CMDB或數據中臺系統的業務方向。
2、CMDB數據審計經常在企業推行不下去，考核往往形同虛設應該怎麼處理？
以往我們談到CMDB數據治理的主要印象是：配置流程規範+數據審計。從原理上，這是一種事後+上層控制的思路，策略上屬於下策：
第一，事後控制不如事前、事中控制。流程上看，末端來糾錯的成本肯定大於前期糾錯成本。
第二，上層集中控制成本很高。可以想象，審計出來的問題數據怎麼處理呢？真的考核到個人頭上，華為或者一些外企這類組織執行力強的公司可以長期實施，但在絕大部分公司政治環境生態中，領導們還不至於為了CMDB大動干戈，可能把審計出來的問題數據進行公示也無關痛癢。CMDB在很多情況下還無法達到像運維安全那樣形成公司上下共識，在強有力的管理要求下開展考核。要知道任何嚴密的組織結構都是需要一定能量來維持的，領導的權利支持、被管理者的抵制，需要的能量都是成本，而收益又是多少？
成本收益是有機體生存的底層策略之一。因此CMDB數據審計的思路應該是：通過流程設計想辦法調整流程約束的時間結構，讓數據檢查動作提前，提高用戶犯錯成本，同時轉移治理中的監督成本。舉個例子，某個流程要求設備到貨時某人某時刻錄入CMDB，但執行人可能偷懶或者真的遺忘了，事後審計雖然形成閉環但效率低。更優的流程設計是把設備初驗場景整合進流程裡，如果沒有錄入CMDB則無法初驗，流程在執行中就有人會跳出來拉響警報。請注意以往邏輯是業務先變更，再到CMDB登記，業務是因，CMDB是果。正確的思路把CMDB設計為某個業務活動的因，這樣數據質量可以得到極大改善。
傳統的數據審計模式還得有，但主要用來做存量數據基線盤點。考核責任人建議以產品為單位。考核手段儘量借力外部或現有的能量資源，譬如外部審計要求、安全要求、公司現有的獎勵評選等等。讓錯誤數據找得到責任人，同時讓責任人自己感到鴨梨山大。
3、針對CMDB的數據可視化，在數據庫上應如何選擇？
從複雜關係的展現上說，肯定圖數據庫來實現比較好。
從理論上，關係型數據庫也能實現多對多、一對多。只是要有中間表，有一定維護成本。深度路徑查詢肯定沒有圖數據庫的效率高，還有許多其他劣勢，也許圖數據庫是個趨勢，只是目前團隊學習成本較高。
我覺得，用圖數據庫新建CMDB的，除了專業廠商或技術能力強的互聯網公司，一般甲方公司恐怕暫時不會去嘗試自建使用。
4、CMDB建設過程中的痛苦：其它部門不配合，數據就很難準確？
【問題描述】CMDB建設過程中往往涉及很多部門。但是可能存在下面的情況：一線運維部門對CMDB需求緊迫，但是無法作為牽頭部門對整個數據中心的CMDB建設統領；管理條線部門本應統一規劃CMDB建設，但對具體需求不甚明確。所以，很容易造成各部門之間扯來扯去，CMDB卻無法落地的情況。
我們公司也經歷這個痛苦的過程，經常自嘲說：要憑一己之力對抗整個組織或流程，一不小心還成了背鍋俠。其原因在“CMDB能對目前運維帶來哪些收益以及推行的難點主要在哪方面”中提到過：CMDB建設者從長期、全局的視角來做配置管理工作，但造成各(ge)個(huai)部(gui)門(tai)短期成本提升，這對領導都是一件有難度的事，何況幾乎沒有什麼權利的CMDB團隊？
所以CMDB是很考驗管理能力的工作，當然我們也能通過這個過程獲得成長。如何去爭取和說服決策者（權利中心），如何各個場景分別突破形成利益捆綁從而降低管理成本，如何把責任明確提升用戶犯錯成本，都只能提個思路，各家公司實際情況都不同要靈活處理。總之，CMDB團隊應抱著招商引資的心態，向運維團隊去推銷、談合作。
企業對CMDB的定位不準確，高度不夠高。
5、經常面臨CMDB數據變更滯後於數據源的數據變更，如何變被動數據治理為主動數據治理？
【問題描述】目前我們平臺經常面臨CMDB數據變更滯後於數據源的數據變更，目前部分分類通過定時同步解決了該問題，但隨著分類越來越多，這一方法就變得成本很高，我的問題是如何變被動數據治理為主動數據治理？
從時間結構上看，CMDB和其他活動的因果關係分為兩種：
一種是先“變更”再更新CMDB，變更活動是“因”，CMDB是果。這種情況CMDB比較被動，你要麼要(gui)求(qiu)人家改你的CMDB，要麼想辦法通過數據發現自動捕捉人家的變化。
另一種是先更新CMDB，再實施變更。CMDB是因，變更活動是“果”。這種方法還有個好聽的叫法“配置驅動”，是一種配置中心化的軟件定義。從流程設計上，讓CMDB成為下游環節的依賴前提。從系統架構關係上，讓CMDB成為運維繫統的配置中心。需要提醒的是，這種方式並不一定要用戶在CMDB自身門戶中操作，完全可以在運維場景中，用戶直接在運維工具中，通過API間接維護和消費CMDB。用戶甚至感覺不到CMDB的存在。
第二種從策略上說肯定是最優的，變被動為主動。
我們實現比較簡單，所有的執行流程，如果涉及到配置對象的變動，最後執行流程得有一個動作，更新配置對象到CMDB中；
如交付10臺虛擬機，這10臺虛擬機完成初始化後，直接更新到CMDB對於的業務和模塊下面，強調流程的閉環。
6、CMDB能對目前運維帶來哪些收益？推行的難點主要在哪些方面？
這個問題背後其實是成本收益分析，商人腦袋很自然的就用這個模型來思考問題，但作為IT從業者往往會忽視。經歷了一些事後可能發現，原來一件正確的事不一定是適合的，所謂天時地利人和。
因此收益和難點（成本）這個問題很高明。
CMDB的核心收益是主數據庫帶來的較低的綜合成本。只不過結合不同場景，其價值又體現在安全內控管理（賬號、堡壘機、防火牆、漏洞補丁、合規檢查、IP端口）、監控告警、自動化運維、資產管理、資源交付、發佈管理、應急管理、ITIL流程管理、容量管理等具體領域。沒有主數據庫，上面這些工作都要自建配置庫，大型數據中心情況下整體成本會很高。
但主數據庫這種架構天然導致了推廣的悖論，因為人們總是對全局和個體、長期和短期之間糾結平衡，且整體上會朝著熵增的趨勢發展。CMDB建設者從長期、全局的視角來做配置管理工作，但造成各(ge)個(huai)部(gui)門(tai)短期成本提升，這對領導都是一件有難度的事，何況幾乎沒有什麼權利的CMDB團隊？換句話說，CMDB本身是一件短期成本高，但從全局和長期才能體現收益的事情，想想人們買保險的心情！
解決辦法我也上面一篇分享嘗試做了分析，歡迎大家一起交流。抽象的說就是：
1.要獲得高層權利支持
2.通過具體場景來落實收益
3.設法轉嫁和降低管理成本（蹭熱度，抱大腿；和其他系統、流程形成利益綁定；把要求納入現有獎懲考核）
4.提升用戶犯錯成本（以產品為單位明確責任人；流程自審計；公開審計結果）
7、CMDB建完後，如何保證數據的實時更新？相關的規章制度有哪些？
【問題描述】CMDB建好後，過一段時間後，數據就不是很準了。原因就是有很多操作，並沒有經過CMDB的環節。有沒有運維的標準流程，讓所有的操作都能通過CMDB？或者介紹一下貴單位在實際使用CMDB時的流程，保障CMDB中的數據永遠都是最新的？
數據自動發現肯定是第一選擇。對於無法自動發現的，要考驗流程管理水平。公司裡有很多規章制度，執行效果如何？大家心裡有數。個人淺見：規章制度都只是要求，是目標。目標的執行落地，要麼是自上而下的外部力量，要麼靠自下而上的內部力量。外部力量比如說領導重視、外部審計、公司考核制度，這些通常這些手段因為CMDB得不到上層重視落地效果不明顯。內部力量可能是主要的方向，比如說切合運維的場景驅動，還有我比較提倡的流程“自審計”。把錄入CMDB作為其他運維活動的依賴條件，像設備初驗、資源申請、主機上線、備份申請等等。利用“利益”把大家綁定起來，才能以最小的成本讓配置管理要求真正落地。
8、CMDB能解決服務器相關各類資產的準確性難題嗎？
【問題描述】服務器資產管理，目前還在用excel表格來管理，想上一套工具，但糾結在用資產管理工具還是用CMDB配置管理工具，感覺都能實現？又感覺都差點意思。
如果只是定位硬件設備的資產管理，資產管理工具還是CMDB都行。但一般企業發展下去都會走CMDB這條路來打通各種運維平臺和服務流程，從這個角度來說直接上CMDB綜合成本會更低。
數據準確性方面，硬件資產可以利用部分數據自動發現的手段獲得CPU、內存、存儲、HBA這類配置信息。但設備位置和序列號這個盤點用到的關鍵對應關係，如果沒有RFID這種手段的話，還是要靠流程來控制，這比較考驗流程設計水平了，需要和相關部門協調好，才能保證數據準確性。
9、如何從數據類型和過程拆解數據治理的邏輯，分而治之？
CMDB的數據可分為自動發現數據和人工錄入數據兩大類。第一策略是盡最大努力擴大自動發現範圍（因為自動發現的數據一定是最準確），降低配置管理的成本。常見的自動發現數據源有云管平臺、安全管理系統、網管平臺、負載均衡系統、帶外管理系統等，總之要團結一切能夠自動發現的力量。但接下來總要面對人工錄入數據，這裡用水池模型來解釋。要一個水池乾淨，一是保證流入的增量乾淨，二是淨化水池中的存量，三是要水循環流動起來。類似的，CMDB增量變更數據由場景流程來控制，存量數據靠數據資產明確屬主並提高犯錯成本。最後通過場景消費形成正反饋機制。三管齊下。
10、CMDB自動發現數據是否能夠自動更新？
【問題描述】自動發現數據是放入調和庫，還是直接更新？一般更新策略是什麼？有更新後是否對更新內容追蹤核實？
CMDB自動發現數據是否能夠自動更新，取決於你的業務需求；
如果你的CMDB供給給自動化操作的場景，CMDB發現的數據直接寫入到CMDB影響會很大；2.我們現在的做法是先放入到自動發現數據庫，人員審批後自動更新到CMDB；3.未來根據使用的情況，如果發現的數據都是可以直接更新的，我們可能會採取直接更新的策略。
樓上的回答很完善了，我也推薦針對重要的屬性，尤其是用於自動化運維的，採用先入調和庫，再通過人工審核後更新CMDB正式庫。從程序效率上，也是先全部入調和庫，再和正式庫比對會更可控一些。
閱讀更多 CIO之家 的文章
