Bob, Richard一起去趟慕尼黑的新天鵝堡。新天鵝堡是巴伐利亞國王路德維希二世出資建造的“夢幻城堡”，工程耗時17年，壯麗無比。據說迪士尼的LOGO就是以天鵝堡為模板設計的。

新天鵝堡

我們一行人都是第一次前往，從蘇黎世到天鵝堡全程223公里，路程雖不長，但沿途路況復雜。我們在鄉間小道中穿行（瑞士稱“國道”），七彎八拐，還要穿越瑞德邊境，中途甚至一度起霧下暴雨，嚴重時連道路都看不清。但我們從未擔心迷路，果然，經過2小時50分鐘的車程，我們順利到達目的地。你猜我們是如何做到的？是的，因為Google Maps。

左邊多毛的手臂就是Bob，不要被他干擾，請將注意力要放在中間的地圖

Google Maps極大的方便了現代人的出行，通過集成地理數據、衛星定位、實時路況和導航計算等數據和功能，人們可以精確知道自己在地圖上的位置以及與目的地之間的路線和路況，人們可以去任何自己想去的地方，不論之前有沒有去過。Google Maps甚至重新定義了地圖，地圖不再是出行前的輔助規劃工具，而是行駛過程中的實時監控工具，甚至每天上下班，人們也會打開Google Maps，查看實時路況以便及時調整行駛路線。這種對地圖的高頻使用在十年前是無法想象的。那時，由于紙質地圖的信息非常有限，對出行幫助并不大。信圖不如信人，只有老司機清楚哪里道路狹窄、哪里容易擁堵、哪里路滑，所以驅車遠行必須找到老司機引路。

幕后英雄

Google Maps解放了人們對老司機的強烈依賴，不過，在享受Google Maps帶來的巨大便利的同時，你知道Google Maps的幕后英雄是誰嗎？是GeoDB，它精確的記錄了每個城市、街道、建筑以及山川、河流的經緯度坐標和海拔，這些數據被稱為Geo Data。

Geo Data晦澀難懂，所以早期GeoDB的消費場景很少，Geo供應商的日子也很難過。Google Maps將晦澀難懂的Geo Data變得簡單直觀，降低了信息的理解門檻，從而使每一個普通老百姓都能夠消費這些數據，一下子盤活了很多GeoDB，Geo供應商的日子也好了起來。

咦，聽這話風好像又要說CMDB了？是的，從數據形態來看，CMDB和GeoDB 非常相似，GeoDB記錄的是事物的經緯度等地理數據，CMDB則記錄了CI的各種技術和管理屬性數據，但是由于晦澀的數據格式、低頻的消費場景，讓配置管理團隊的日子也很不好過。如何更好的發揮配置數據的價值？這個問題折騰了我十年，從國內折騰到海外，感覺真是古今中外的未解難題。

CMDB的困局

CMDB缺乏消費場景，其中常見原因是“數據不準”。因此，為了提升數據質量，我們引入了大量的管控流程、審計制度和自動發現手段，但結果往往事倍功半。其實，在非云化環境下，配置數據做到完全準確是不可能的。但是，CMDB一定要完全準確才能用嗎？GeoDB也不完全準確（否則Google Maps就不會有一個數據異常的反饋界面了），但并不影響人們的使用和反饋熱情。

我覺得要破解CMDB的困局，還是要以終為始的看問題。雖然寬泛的說，我們構建CMDB是為了給其他流程提供精準的數據支持，但實際上主要的初衷還是希望通過CI數據還原IT架構，幫助IT團隊更好的識別系統組件的依賴關系，從而更好的進行故障診斷、變更發布、容量規劃、安全控制等日常運維管理事務。從這個“終”來看，可視化對CMDB是至關重要的。如果無法有效可視化，猶如脫離了Google Maps的GeoDB，數據再準又能怎樣？

CMDB的破局

他山之石可以攻玉。CMDB要破局，除了死磕數據質量這條路外，還可以借鑒Google Maps的路子：以場景為驅動，以可視為手段，通過構建IT架構地圖來充分體現和發揮CMDB的數據價值，并通過建立場景化的消費反饋機制，不斷完善數據質量。具體有三個實施重點：面向場景的數據可視、面向場景的自動發現、面向場景的消費反饋。

1

面向場景的數據可視

可視化在CMDB誕生之初就有了。大家經常見到的畫面可能是這樣的：

很虐心吧？這種視圖呈現的對象粒度太細、太復雜、且脫離了具體的使用場景，因此沒有實用價值。Google Maps抓住“出行”這個高頻的場景，綜合利用各種可視化手段和數據分析能力，如：路況地圖、街景地圖、線路規劃等等，準確命中出行痛點，并被市場認可。

那么問題來了，到底什么是場景？IT管理領域又有哪些場景？

簡單說來，場景是一組“人、事、物”的組合，是特定的人對特定的物完成一系列的管理動作。面向場景的可視化，就是要深入分析人和事的需求，并在此基礎上對物以及物之間的關系做可視化。

在IT管理領域，我們常見的場景包括：架構師針對某套應用規劃架構、運維人員針對某個系統進行容量分析、運維人員對某套系統進行端到端監控和故障診斷、機房管理員對機房進行容量規劃、機房管理員對新設備進行上架規劃等等。下面是針對各個場景的可視化案例：

上述管理場景都是一些日常事務性的場景，其實還有一類容易被忽略，但可能更加重要的場景，那就是“知識傳承”。

還記得前文提到過十年前我們對老司機的嚴重依賴嗎？老司機的核心價值在于對路況的熟悉，這種經驗是非共享的，只存在老司機的腦中。但是，今天通過Google Maps，每個人都可以輕松獲得老司機的大部分經驗知識，經驗變成了共享的，這就極大的降低了出行對司機經驗的要求。在IT管理領域，豐富的IT架構地圖也能夠幫助IT菜鳥們快速掌握系統的運作原理和組件的依賴關系，幫助菜鳥能快速上手，即使老專家離職或轉崗也不那么害怕了。當然，我不是說IT老專家就沒用了，起碼這也能幫助IT老專家從日常事物中解脫出來，讓他們從事一些更高級的事情。

2

面向場景的自動發現

自動發現是提升配置數據質量的重要手段，現在常見的搞法是全網掃描。但這種方式往往會探測出大量沒有用的細粒度信息，且由于掃描范圍極大，掃描頻率不可能很高，這就導致了數據更新的不及時。更可怕的是，全網掃描很可能在某個角落引發安全或性能問題，而你卻并不知道。

Google Maps是怎么做的？他們的創意一度震驚業界：Let’s step back a tiny bit to recall with wonderment the idea that a single company decided to drive cars with custom cameras over every road they could access.(From ) 。

這就是大名鼎鼎的Street View car

這種方式看上去很蠢，但又非常成功：谷歌汽車以大中型城市為單位，從市中心向四周“爬行”，每次“爬行”會帶回兩種數據： Actual Tracks和 Photos。Actual Tracks用于驗證驗證地圖上的道路是否正確，Photos用于豐富街景信息。這是一種典型的面向場景的自動發現，每個大中型城市就是一個場景。

借鑒Google Maps的搞法，我們以場景為單位實施自動發現。由于場景的范圍遠遠小于全網環境，因此可以有更高的掃描頻率、更個性化的掃描內容和更小的掃描風險。

3

面向場景的消費反饋

前面說到，構建100%準確的CMDB是不可能的，也是沒有必要的。我們只需要建立起一套有效的反饋機制，讓用戶在使用過程中發現數據問題時能夠方便的反饋并及時修正就行。以Google Maps為例，每個城市地圖的生產流程基本是這樣的：首先基于GIS數據構建出一個城市的概要地圖，并輔以人工修正（谷歌內部成為hand-massage），然后進行地圖的數據豐富（引入街景、路況等信息），在使用時提供一個反饋界面，哪里出車禍啦？哪里錯啦？

每個城市都這樣做，那么就能得到一張準確的國家地圖，每個國家都這樣做，就能得到一張準確的全球地圖。

就IT管理而言，我們同樣可以基于CMDB+人工輔助構建場景視圖，通過數據集成為場景提供更加豐富的運維信息，再提供異常反饋界面讓用戶自行修正。用Bob的話來說：每個場景都要做到自洽的，當每個場景都準確時，我們就可以得到一個準確的CMDB。

不過，你真的需要一個準確的CMDB嗎？未必吧，你只要把自己關心的場景弄準確就好啦。

結語

后面，我們又驅車從蘇黎世到斯圖加特，一共210公里，路上還遇到了暴雨。不過沒關系，Google Maps在手，哪里都是坦途。當然，我們要感謝Google Maps的幕后英雄：GeoDB。也希望有一天，Bob能用上IT的Google Maps，從此再復雜的系統架構、再隱蔽的故障和漏洞也將一目了然。當這一切實現，我們要深深的感謝其幕后的英雄：CMDB。