4. CMDB设计与实现：配置管理数据库的核心模型、资产采集与同步机制、API设计
聊到运维自动化，CMDB 绝对是个绕不开的话题。
很多人觉得 CMDB 就是个资产登记表，把服务器 IP 记下来就完事了。说实话，我早年也这么想过。直到有一次线上故障，我们花了整整 4 个小时才搞清楚某台机器上跑了哪些应用、依赖了哪些中间件……那感觉，真叫一个抓狂。
所以今天咱们好好聊聊，一个真正能用的 CMDB，到底该怎么设计。
4.1 核心模型：不只是“记个IP”那么简单
CMDB 的核心，说白了就是“配置项”以及它们之间的关系。
配置项是什么？服务器、数据库、负载均衡、容器、甚至一个 DNS 记录，都可以是 CI。
我个人习惯把模型分成三层：
- 资源层：物理机、虚拟机、云主机、网络设备
- 服务层：应用进程、中间件实例、数据库实例
- 逻辑层：业务系统、服务分组、集群
举个例子，一台物理机上跑着 MySQL 和 Nginx，它们都属于不同的服务层 CI，但都挂在这台物理机下面。而这两个服务又可能属于同一个业务系统。
核心模型字段建议：
- CI 唯一标识（UUID）
- CI 类型（主机/数据库/应用等）
- CI 名称 + 别名
- 状态（运行中/停用/故障）
- 所属环境（开发/测试/生产）
- 关联关系列表（父 CI、子 CI、依赖 CI）
嗯，这里要注意：关系模型比属性模型更重要。你想想看，如果只知道某台机器的 CPU 是 8 核，却不知道它上面跑了什么业务，那这个 CMDB 的价值就大打折扣了。
4.2 资产采集与同步机制：别让数据“烂”在库里
模型设计好了，数据从哪来？
我见过不少团队，初期靠人工录入，结果三个月后数据就全对不上了。机器换了 IP、应用迁移了、中间件升级了……没人更新。
所以，自动采集才是王道。
4.2.1 采集方式
我一般推荐三种方式配合使用：
- Agent 采集：在每台机器上部署轻量 Agent，上报 CPU、内存、磁盘、进程列表等信息。适合内网环境，实时性高。
- API 对接：对接云厂商 API（阿里云、AWS）或虚拟化平台（vCenter），自动拉取资源清单。适合混合云场景。
- 扫描发现：通过 SNMP、SSH 等方式主动扫描网段，发现新设备。适合网络设备或老旧系统。
我的经验：Agent 采集最靠谱，但要注意 Agent 本身的资源消耗。我曾经遇到过 Agent 写日志把磁盘打满的惨案……所以一定要限制日志大小和上报频率。
4.2.2 同步机制
采集到数据后，怎么同步到 CMDB？
这里有个关键点：增量同步 vs 全量同步。
- 全量同步：每天凌晨跑一次，把所有 CI 重新拉一遍。简单粗暴，但数据量大时很慢。
- 增量同步：只上报变化的部分。比如进程列表变了，只更新进程相关的 CI。
我个人建议：日常用增量同步，每周做一次全量对账。这样既能保证实时性，又能兜底修复遗漏的数据。
避坑指南：我曾经遇到过增量同步时，某个 Agent 挂了三天，导致一批机器“失联”。结果 CMDB 里这些机器还是“运行中”状态，直到全量对账才发现。所以一定要加心跳检测，超过 N 分钟没上报就标记为“未知”或“异常”。
4.3 API 设计：让 CMDB 成为“数据中台”
CMDB 不只是给自己用的。它应该是一个数据服务，供监控系统、发布系统、工单系统调用。
所以 API 设计得好不好，直接决定了 CMDB 的“生态位”。
4.3.1 核心 API 清单
| 接口 | 方法 | 说明 |
|---|---|---|
| /api/v1/ci/list | GET | 查询 CI 列表，支持按类型、环境、状态过滤 |
| /api/v1/ci/detail | GET | 查询单个 CI 详情，包含关联关系 |
| /api/v1/ci/create | POST | 创建 CI（通常由采集系统调用） |
| /api/v1/ci/update | PUT | 更新 CI 属性 |
| /api/v1/ci/relation | GET | 查询 CI 之间的拓扑关系 |
| /api/v1/sync/report | POST | Agent 上报增量数据 |
4.3.2 设计要点
我总结了几条原则：
- 统一返回格式：所有接口返回 {code, message, data} 结构，方便调用方统一处理。
- 支持批量操作：比如批量更新 CI 状态，避免循环调用。
- 版本控制：API 路径带 v1/v2，方便后续升级。
- 鉴权与限流：CMDB 是核心数据，不能随便让人调。至少要有 Token 鉴权和调用频率限制。
代码示例：查询 CI 详情
GET /api/v1/ci/detail?ci_id=abc-123
{
"code": 0,
"message": "success",
"data": {
"ci_id": "abc-123",
"ci_type": "host",
"name": "web-server-01",
"status": "running",
"env": "production",
"attributes": {
"cpu": 8,
"memory": "32GB",
"ip": "10.0.0.1"
},
"relations": [
{"type": "runs_on", "target_ci_id": "phy-001"},
{"type": "contains", "target_ci_id": "app-nginx-01"}
]
}
}你想想看，如果监控系统能直接通过 API 查到某台机器上跑了哪些应用，那故障定位是不是快多了？
4.4 总结一下
CMDB 的设计，其实就三件事：
- 模型：把 CI 和关系定义清楚
- 采集：用自动化手段保证数据新鲜
- API：把数据开放出去，让上下游系统用起来
嗯，说起来简单，做起来坑不少。但只要你把这三块打扎实了，CMDB 就能从“摆设”变成真正的运维数据底座。
下一章咱们聊聊自动化作业平台，到时候会用到 CMDB 的数据来做目标机器选择，敬请期待。