2023年初，我们决定"建一个CMDB"。

当时的想法很简单：MySQL建几张表（设备表、位置表、负责人表），Excel做导入导出，前端用开源Admin框架搭个页面。三个人花了两周，上线了V1.0。

三年后，这张数据库里有47张表、1100+字段、8600+条记录。看起来像一个"成熟的CMDB"。

直到上个月一次资产盘点，我们随机抽查了200台服务器的CMDB记录和线上实际情况做对比。结果：32%的IP地址已变更但CMDB未同步，18%的资产找不到当前负责人，最老的一条记录是2019年的一台服务器——去年已经报废了，记录还躺在表里。

这不是MySQL的问题，也不是Excel的问题。是我们花了三年才理解的一个事实：CMDB的核心不是"能存多少数据"，是数据能不能自己活下去。

一、自建CMDB的美好开头和残酷现实

1.1 第一阶段：手动录入时代（2023.01 - 2023.06）

刚开始的时候，47张表里只有5张真的在用——device、location、owner、application、relation。整个团队对CMDB的热情很高，每次新上架一台服务器，大家都会主动去系统里录入：IP、主机名、配置、负责人、上架时间……

这个阶段，CMDB准确率大约85%。

1.2 第二阶段：数据开始腐化（2023.07 - 2024.06）

大概半年后，问题开始出现。启动"数据腐化"的触发因素有四个：

变更不更新。运维在服务器上改了IP，但不记得去CMDB里更新。监控系统、自动化脚本、CMDB里各存一套IP，不知道哪个是对的。

离职不断档。服务器原来的负责人离职了，新接手的同事不知道要更新CMDB里的owner字段。或者知道了，但觉得"这是小事，不急"。然后就不了了之。

报废不清理。设备下架了、重装了、报废了——没人去CMDB里标记状态。记录永远留在表里，像数字世界的鬼魂。

字段膨胀失控。因为是自己建的库，每个人都可以加字段。有人觉得"表里应该记录SN号"，加了。有人觉得"应该记录保修到期日"，加了。三年后1100+字段中，真实使用率不到15%。

到2024年中，CMDB准确率降到了大约60%。这个数字意味着：你查CMDB得到的信息，有近一半可能是错的。一个数据不准确的CMDB比没有CMDB更危险——因为它给了你一个"有数据"的幻觉。

1.3 第三阶段：终于想换但已经换不动了（2024.07 - 至今）

当CMDB准确率跌破60%，我们开始认真评估替代方案。但迁移面临两个难题：

数据怎么迁。47张表、1100+字段不是每个都有价值。哪些该迁、哪些该扔、关系怎么重建——光是数据清洗就需要至少2个全职人周。

流程怎么办。告警系统、自动化脚本、月报报表都在读写这个CMDB。换新的意味着这些集成都得重新对接。

如果你现在还在用Excel做CMDB，这篇文章希望能帮你在"表还没到47张"的时候想清楚——CMDB不是一个数据库项目，是一个数据治理项目。

二、iTop半年试用：功能强大，但门槛不低

2025年初，我们花了半年试用了iTop——开源的ITIL CMDB，功能全面、社区活跃。

客观评价：iTop在CI建模和ITIL流程管理上非常强大。它的Configuration Item关系模型可以覆盖从服务器到交换机到应用到合同的几乎任何IT资产。如果你需要一个"ITIL合规"的CMDB，iTop是开源社区里的首选。

但半年下来，我们的实际使用感受是"功能强大但不顺手"：

学习曲线陡峭。不是安装的难度——Docker部署很快。而是它的设计理念完全围绕ITIL框架——服务请求→变更管理→CI关系。如果你团队里有ITIL背景的人，上手会快。如果都是"野路子运维"，理解"SLA→OLA→UC"这些概念就需要时间。

自动发现是短板。iTop有自动发现插件（TeemIP、DataCollector），但配置和维护成本不低。我们的环境里200+台设备跨了3个网段、4种设备类型，配通自动发现花了约两周。而且自动发现只解决了"新增"——已变更的IP、已报废的设备，仍然需要手工维护。

⚠️ 风险提示：iTop的自动发现依赖额外插件和手动配置，不是开箱即用。如果你管理的设备类型多（服务器+网络+IoT+IPMI）、网段复杂，配置自动发现的工作量不容低估。建议在评估阶段就用真实环境做POC，不要只看文档上的功能列表。

数据保鲜依然靠人。这是所有自建/开源CMDB的共同痛点：自动发现能帮你"看到现在的状态"，但"把现在的状态更新到CMDB里"这个过程，iTop没有完全自动化。你需要定期跑同步脚本、比对差异、手工处理冲突。

三、最小可用的CMDB数据模型

在聊平台化方案之前，先分享一个我们踩完坑后总结的"最小CMDB数据模型"。不管你用什么工具，核心数据就这5张表：

-- 1. 设备表（核心）
CREATE TABLE device (
    id INT PRIMARY KEY AUTO_INCREMENT,
    hostname VARCHAR(255) NOT NULL,
    ip VARCHAR(45),
    type ENUM('server','switch','router','firewall','ap','other'),
    status ENUM('online','offline','maintenance','decommissioned'),
    os VARCHAR(100),
    location_id INT,
    owner_id INT,
    serial_number VARCHAR(100),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    last_discovered_at TIMESTAMP NULL  -- ⚠️ 数据保鲜的关键字段
);

-- 2. 位置表
CREATE TABLE location (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    type ENUM('datacenter','branch','office','warehouse')
);

-- 3. 负责人表
CREATE TABLE owner (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(100) NOT NULL,
    dept VARCHAR(100),
    contact VARCHAR(100)  -- 企业微信/邮箱
);

-- 4. 应用表
CREATE TABLE application (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    port INT,
    version VARCHAR(50),
    device_id INT,
    FOREIGN KEY (device_id) REFERENCES device(id)
);

-- 5. 关系表（拓扑的核心）
CREATE TABLE relation (
    id INT PRIMARY KEY AUTO_INCREMENT,
    source_device_id INT,
    target_device_id INT,
    relation_type ENUM('depends_on','connects_to','runs_on','backup_of'),
    FOREIGN KEY (source_device_id) REFERENCES device(id),
    FOREIGN KEY (target_device_id) REFERENCES device(id)
);

关键是 last_discovered_at 字段。它回答了CMDB最致命的问题：这条数据是活的还是死的？ 超过N天没有被自动发现更新过的记录，系统应该标记为"可能已过期"，而不是假装数据还是准的。

四、同一条变更，CMDB能管到哪一步

选型时不要只看"能存什么"，要看"存储之后发生了什么"。

六步覆盖度对比

环节	自建MySQL+Excel	iTop	冠服云EMS CMDB
数据录入	✅ 手工	✅ 手工	✅ 自动发现+手工补充
自动发现	❌ 无	⚠️ 需插件配置	✅ 内置多协议采集
关系维护	⚠️ 手工画拓扑	✅ CI关系建模	✅ 拓扑关系自动生成
变更审计	❌ 无	✅ 变更历史	✅ 完整变更追溯
数据保鲜	❌ 数据腐化	⚠️ 需手动触发同步	✅ 自动保鲜（last_discovered_at驱动）
告警关联	❌ 无	❌ 无原生集成	✅ 告警主机自动关联CMDB

核心断点分析

自建方案最大断点在于"数据保鲜"。没有自动发现，CMDB就是一个"数据库快照"——录入那一刻是准的，下一秒就可能已经过期。数据腐化是自建CMDB的最终归宿。

iTop在CI关系建模和变更历史上很强，但自动发现和数据保鲜依赖插件和手动配置，不是开箱即用。如果你的团队有人能维护这套自动发现流水线，iTop可以跑得很好。如果没人维护，半年后数据准确率开始走低的规律和自建CMDB一样。

EMS CMDB的核心差异在于它和监控系统是同一个平台——自动发现时采集的设备信息直接写入CMDB，不需要额外的集成或同步脚本。告警触发时，告警主机自动关联CMDB中的设备信息和拓扑关系——人看到告警的同时就知道这台机器在哪、谁负责、上下游依赖是谁。

⚠️ 数据口径：EMS CMDB作为ITOM平台的内置模块，与监控、告警、自动化共享同一数据源。如果你评估的是独立CMDB产品，需要额外评估它和你现有监控系统的集成方案和同步延迟。

五、CMDB真实健康度审计

不管你现在用什么CMDB，建议做一个10分钟快速审计：

-- 1. 有多少设备超过30天没被更新过？（数据腐化率）
SELECT COUNT(*) as stale_count,
       ROUND(COUNT(*) * 100.0 / (SELECT COUNT(*) FROM device), 1) as stale_pct
FROM device
WHERE updated_at < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- 2. 有多少设备没有负责人？（责任缺失率）
SELECT COUNT(*) as orphan_count
FROM device WHERE owner_id IS NULL;

-- 3. 有多少设备状态未知？（状态不明率）
SELECT COUNT(*) as unknown_count
FROM device WHERE status NOT IN ('online','offline','decommissioned')
   OR status IS NULL;

指标	健康	预警	危险
数据腐化率	<10%	10-25%	>25%
责任缺失率	<5%	5-15%	>15%
状态不明率	❤️%	3-10%	>10%

我们审计时腐化率32%、责任缺失率18%——稳稳的"危险区"。

六、选型建议

你的情况	建议
团队<5人，设备<50台，Excel+Wiki够用	先不急着上CMDB，等设备过百再说
有ITIL经验，愿意投入专人维护	iTop是不错的开源选择
设备100+，不希望CMDB变成"另一个需要维护的系统"	考虑平台化CMDB，自动发现能力比能存多少字段更重要
最重要的选型标准	不是功能数量，是"6个月后数据还准吗"

⚠️ 选型提醒：CMDB选型和告警/监控不同——CMDB的迁移成本最高（数据清洗+集成改造+流程适配）。如果现有CMDB准确率在70%以上，建议先治理数据再考虑换工具。如果准确率已经低于50%且持续恶化，迁移的性价比反而更高——因为旧数据的可信度已经太低，不如重新来。

---

本文对比基于2026年6月实测。iTop为3.1.x社区版；冠服云EMS CMDB为ITOM平台内置模块。不同版本功能可能有变化，请以各产品最新官方信息为准。