3、CMDB配置管理数据库：模型设计、自动发现机制、数据一致性保障
聊到CMDB，很多运维同学第一反应就是「又脏又乱又没人用」。说实话，我见过太多CMDB项目最后变成了摆设。数据不准、没人维护、跟实际环境对不上。嗯，这其实不是CMDB的错，是设计思路出了问题。
今天我就把我在金融云这几年折腾CMDB的经验，掰开了揉碎了讲给你听。核心就三件事：模型怎么设计、数据怎么自动发现、一致性怎么保障。
3.1 模型设计：别想着一步到位
模型设计是CMDB的根基。我见过最惨的案例，是某团队一开始设计了200多个字段，结果运维同学填了三天就放弃了。你想想看，谁会愿意手动维护那么多信息？
我个人习惯是「最小可用原则」。先保证核心字段，后面慢慢迭代。
3.1.1 核心模型结构
金融云的CMDB，我一般分成三层：
| 层级 | 示例 | 核心字段 |
|---|---|---|
| 资源层 | 服务器、网络设备、存储 | IP、序列号、型号、机房位置 |
| 逻辑层 | 应用、中间件、数据库实例 | 端口、版本、所属应用、配置参数 |
| 业务层 | 业务系统、服务单元 | 业务线、负责人、SLA等级 |
这里有个坑——千万别把逻辑层和资源层混在一起。我在项目中遇到过，有人把IP地址直接当成应用实例的唯一标识。结果一台服务器上部署了三个应用，数据全乱套了。
核心原则：资源层管「有什么」，逻辑层管「跑什么」，业务层管「谁在用」。三层之间通过关联关系连接，不要互相包含字段。
3.1.2 关系设计
模型之间的关系，我建议用「简单关联」而不是「复杂继承」。说白了，就是一张表记录A和B的关系，别搞什么多态继承那一套。
-- 关系表示例
CREATE TABLE cmdb_relation (
id INT PRIMARY KEY,
source_type VARCHAR(50), -- 源对象类型
source_id INT, -- 源对象ID
target_type VARCHAR(50), -- 目标对象类型
target_id INT, -- 目标对象ID
relation_type VARCHAR(50), -- 关系类型：部署在、依赖、连接
create_time DATETIME
);为什么这么设计？因为金融云的环境变化太快。今天这个应用部署在A机器，明天可能就迁移到B机器了。用这种松耦合的关系表，改起来特别方便。
3.2 自动发现机制：让数据自己长出来
手动录入？那是上个时代的玩法。自动发现才是CMDB的灵魂。我曾经接手过一个项目，2000台服务器全靠人工录入，准确率不到60%。后来我上了自动发现，三个月后准确率提到了95%以上。
3.2.1 发现策略分层
自动发现不能一把抓，要分层进行：
- 网络层发现：通过SNMP、LLDP协议，发现网络拓扑和设备信息
- 系统层发现：通过Agent或SSH，采集OS信息、CPU、内存、磁盘
- 应用层发现：通过API或日志，发现中间件、数据库、应用进程
我的经验：网络层用SNMP轮询，每5分钟一次。系统层用Agent推送，每1分钟一次。应用层用事件触发，有变化才上报。这样既保证了实时性，又不会把CMDB压垮。
3.2.2 发现脚本示例
这里给一个简单的Agent发现脚本，采集服务器基本信息：
#!/bin/bash
# 服务器自动发现脚本
# 采集信息并上报到CMDB
HOSTNAME=$(hostname)
IP=$(ip addr show eth0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1)
CPU_CORES=$(nproc)
MEM_TOTAL=$(free -m | grep Mem | awk '{print $2}')
DISK_TOTAL=$(df -h / | tail -1 | awk '{print $2}')
OS_VERSION=$(cat /etc/os-release | grep PRETTY_NAME | cut -d= -f2 | tr -d '"')
# 上报到CMDB API
curl -X POST http://cmdb-api:8080/v1/resource \
-H "Content-Type: application/json" \
-d '{
"hostname": "'$HOSTNAME'",
"ip": "'$IP'",
"cpu_cores": '$CPU_CORES',
"mem_total_mb": '$MEM_TOTAL',
"disk_total": "'$DISK_TOTAL'",
"os_version": "'$OS_VERSION'"
}'这个脚本看起来简单，但我在实际项目中踩过坑——Agent的版本管理。曾经有一次，我更新了Agent脚本，但没通知所有团队。结果有的机器跑旧版本，有的跑新版本，上报的数据格式都不一样。后来我强制所有Agent通过CMDB统一分发，才解决了这个问题。
3.3 数据一致性保障：CMDB的命根子
数据一致性，说白了就是「CMDB里的数据跟实际环境一模一样」。这听起来简单，做起来难。我见过太多CMDB，刚上线时数据挺准，三个月后就没人信了。
3.3.1 一致性检查机制
我一般用「三明治检查法」：
- 上层检查：业务系统负责人定期确认应用关系是否正确
- 中层检查：自动发现引擎每天全量比对一次
- 底层检查：Agent实时上报，发现差异立即告警
注意：自动发现不是万能的。有些信息，比如「这个应用属于哪个业务线」，机器是发现不了的。这种信息需要人工维护，但一定要有审批流程，不能随便改。
3.3.2 差异处理流程
当发现数据不一致时，我建议走这个流程：
- 自动修复：如果是Agent上报的差异，且差异在阈值范围内，自动更新CMDB
- 人工确认：如果是结构变化（比如新增了应用），发工单给负责人确认
- 审计追溯：所有变更记录都要保留，方便回溯
为什么会这样设计？因为金融云对变更管控特别严。我曾经因为一个自动修复的误操作，把生产环境的配置改错了，差点引发事故。从那以后，我对自动修复加了「阈值保护」——只有差异在5%以内才允许自动修复，超过5%必须人工介入。
3.3.3 一致性评分
我习惯给每个资源打一个「一致性评分」，让数据质量变得可量化：
| 评分区间 | 含义 | 处理方式 |
|---|---|---|
| 95-100分 | 数据准确，无需处理 | 正常监控 |
| 80-94分 | 少量差异，自动修复 | 触发自动修复流程 |
| 60-79分 | 较多差异，需要人工介入 | 生成工单，通知负责人 |
| 60分以下 | 数据不可信，需要全面排查 | 紧急告警，暂停依赖该数据的自动化任务 |
这个评分机制，说白了就是给CMDB的数据质量上了个「仪表盘」。运维团队每天看一眼评分，就知道今天的数据靠不靠谱。
3.4 整体架构图
下面这张图，是我在金融云实践中总结的CMDB核心架构。你看一眼，基本就能理解整个体系是怎么运转的。
这张图里，数据从底层采集上来，经过模型层标准化，再通过一致性保障层确保准确。三个环节环环相扣，缺一不可。
总结一下：CMDB不是一次性项目，而是一个持续运营的过程。模型设计要轻量，自动发现要分层，一致性保障要量化。做到这三点，你的CMDB就能从「没人用」变成「离不开」。
嗯，关于CMDB的核心内容就这些。如果你在实际落地中遇到什么问题，欢迎随时交流。毕竟，金融云的运维自动化，从来不是一个人的战斗。