CMDB建设：让运维先看清有什么
导语：连自己有什么资产都不清楚，运维就是盲打；CMDB 是看清家底的第一前提。
一、为什么要关注（背景与痛点）
故障来了找不到责任人、扩容不知还剩多少资源、审计对不上台账——根源多是资产"说不清"。CMDB（配置管理数据库）把分散的资产、关系、属性收敛成单一可信源。
二、核心原理 / 关键概念
- CI（配置项）：服务器、网络、应用、接口、负责人。
- 关系拓扑：谁依赖谁，故障影响可推演。
- 单一可信源：避免多套台账冲突。
- 自动发现：减少人工维护偏差。
- 与监控/变更联动：变更即更新。
三、落地做法 / 操作步骤
- 定范围：先核心系统后全量。
- 建模型：CI 类型 + 属性 + 关系。
- 自动发现 + 人工校正。
- 流程绑定：变更必更新 CMDB。
- 消费场景：故障影响分析、容量规划。 检查清单：□ CI 模型 □ 自动发现 □ 关系图 □ 变更联动 □ 消费场景。
四、与群晖NAS / 信创云盘的对应能力
信创云盘可承载 CMDB 文档与拓扑图，按权限共享给运维，版本可溯。群晖NAS 作为存储资产可纳入 CMDB 登记（型号、序列号、容量、责任人），其健康指标可与监控联动；资产台账可参考 DS425+ / DS725+ / DS925+ / DS1525+ / DS1825+ 等机型信息归档。
五、常见误区 / 避坑提醒
- 建完不维护，很快过时成摆设。
- 只录服务器不录关系，故障推不了影响面。
- 人工为主无自动发现，偏差大。
六、小结与行动建议
CMDB 贵在"活"。建议从核心资产起步，绑定变更流程自动更新，让它在故障定位与容量规划中真正被用起来。