如果你现在负责一个CMDB项目，那恭喜你即将加入那个拥挤的“85%失败者俱乐部”。

CMDB项目就像是“西西弗斯推石头”的数字化版本：钱花了不少，PPT画得很漂亮，项目验收那天就是它死亡的开始。半年后，它就会变成一个没人信、没人用、只有审计检查时才会被想起来的“电子垃圾场”。

如果你立志要为公司打造一座宏伟的“数字化废墟”，请务必熟读以下这份《必败实操手册》。只要做对其中一条，我保你项目黄得透透的。

在中国企业搞IT，讲究一个“大而全”。既然要建库，那就得有“纳管一切”的气魄。

必败心法：

别管什么核心业务，先把鼠标垫录进去： 千万别听什么“最小可行性产品（MVP）”的鬼话。既然买了软件，就要把每一个键盘、鼠标、甚至行政部茶水间的微波炉都录进去。 你要坚信：如果不记录所有东西，就等于没记录。要把“固定资产盘点（ITAM）”和“运维配置管理（CMDB）”混在一起煮。当你的数据库里充斥着五万条“联想鼠标”和“公牛插座”时，那些真正承载每秒几百万交易的核心数据库服务器，就会完美地隐身在垃圾堆里。

填空题必须填满： 对着一台服务器，只记录IP、主机名和负责人太寒酸了。你得让运维兄弟们把CPU二级缓存大小、风扇转速阈值、机箱颜色全部填上。哪怕这些数据这辈子都没人用，但填满字段显得我们工作量饱和啊！这就叫“用战术上的勤奋掩盖战略上的无能”。

这是老板们最容易踩的坑。他们以为混乱的流程是因为缺个好工具，只要砸钱买了某大厂的“一体化运维平台”，世界就清净了。

必败心法：

只买软件，不改流程： 不管是以前迷信国外的ServiceNow/BMC，还是现在跟风买国内的软件，记住：只谈功能，别谈流程。 你要相信销售的话：“我们这系统带AI，全自动治理。”项目一验收，顾问一撤场，你就等着看那个花了几百万买的系统在那儿空转。没有流程强制约束，数据在上线后两周就开始发臭腐烂。

搬运“电子垃圾”上云： 旧的CMDB数据烂得没法看？没关系，趁着信创替代或者系统升级，把旧系统里的垃圾数据原封不动地导入新系统（Lift and Shift）。 这种“搬屎上云”的操作逻辑无懈可击：“虽然数据是错的，但总比没有强吧？”结果就是新系统上线第一天，大家一查：“哟，这台服务器三年前就下架了怎么还在？”——信任卒，全剧终。

大家都喜欢自动化，觉得那是银弹。但如果你没有脑子，自动化就是制造垃圾的高效机枪。

必败心法：

开着拖网渔船去扫描： 配置自动发现（Discovery）功能时，千万别设过滤规则，直接全网段0.0.0.0/0无差别扫描。 你要把开发偷偷开的测试机、员工私接的无线路由、甚至老板办公室的智能马桶圈全都扫进CMDB。让核心生产数据淹没在数以万计的“僵尸节点”里，让运维在故障排查时玩“找你妹”游戏。

多源数据打架（关掉IRE）： 当阿里云说这台机器叫i-123，Zabbix说它叫Web-01，Excel表里记着Web-Prd-01时，千万别配什么“身份识别与协调引擎（IRE）”。 就让这些数据在CMDB里互殴。今天生成一条新记录，明天删掉一条旧记录，搞出一堆“幽灵服务器”。等到自动化补丁脚本因为读了重复数据，把核心交易节点给重启了，那画面太美我不敢看。

CMDB失败，技术原因最多占两成，八成是“政治”原因。

必败心法：

让CMDB变成孤岛： 千万别把CMDB和业务关联起来。当业务老大拍桌子问：“我的网银系统瘫了，到底哪台机器坏了？”你要确保CMDB里只有冷冰冰的IP列表，根本查不出这台机器属于哪个业务系统。这就叫“切断业务上下文”，让CMDB彻底沦为底层的自以此乐。

只要没有责任人，就没有责任： 数据字段里的“负责人（Owner）”要么空着，要么填“IT部”，要么填一个三年前离职的倒霉蛋。 出了数据质量问题，网络组说是系统的锅，系统组说是应用的锅。大家踢皮球踢得越欢，CMDB死得越快。

别玩了，如果你真的想救活CMDB... 如果你不想让你的职业生涯变成一个段子，想真正把CMDB做成企业的“数字底座”，请立刻停止上述自杀行为，参考以下救命药方：

1）别贪心：设计宽泛，实施聚焦 (Design Wide, Implement Narrow)

• 谁用谁说话： 加字段前先灵魂拷问：谁要看这个数据？拿它干嘛？如果说不出来，坚决不加。别为了那1%的可能性去浪费99%的维护成本。

• 先爬后跑： 别上来就搞全量。先把核心的服务器、网络设备管准了，再去想那些边缘资产。

2）讲人话：套用CSDM标准

• 别自己造轮子： 别自己瞎发明数据模型。直接参考通用的服务数据模型（CSDM），打通“业务应用”到“基础设施”的任督二脉。

• 讲清楚故事： CMDB不是硬件台账，它得能回答“这台交换机断电，会影响哪个分公司的哪个业务”。

3）搞独裁：必须有人“背锅”

• 把数据变成KPI： 别指望运维人员靠情怀维护数据。要把数据准确性跟他们的绩效挂钩。定期发邮件逼他们确认资产状态（Attestation），不确认就冻结他的变更权限。

• 利益交换： 告诉应用开发团队：“你的CMDB数据要是填不准，发布变更就得走人工审批，排队三天；填准了就能全自动发布。”你看他们填得快不快。

4）守底线：数据治理前置

• IRE是守门员： 必须配置强大的标识与协调规则，解决多源数据冲突。

   

• 信任就是命： 只要有一次运维人员发现CMDB里的IP是错的，他以后就再也不会信这个系统了。所以，宁可数据少点，也必须是准的。

总结一句： CMDB不是买个工具装上就完了，它是一场反人性的“熵减”运动。你要么别做，要做就得把自己变成一个强硬的“独裁者”，跟混乱和惰性死磕到底。否则，那也不过是又一个烂尾工程罢了。