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。