CMDB 是什么
CMDB（Configuration Management Database，配置管理数据库）记录配置项（CI）及其关系，是影响分析、变更评估、事件定位与容量规划的数据基础。它回答的是“这套服务由哪些组件支撑、改这个会牵动谁”。难点从来不是建模，而是数据准确性：CMDB 一旦过期就会把决策带偏，比没有更危险。ITIL 4 把这项能力放在服务配置管理实践中，强调自动发现与流程约束结合使用。
基本信息
| 存什么 | 服务、应用、主机、数据库、中间件、网络设备等 CI 及关系 |
|---|---|
| 谁维护 | 自动发现为主，流程约束下人工确认 |
| 核心关系 | 依赖/被依赖、部署位置、关联变更与工单 |
| 核查方式 | 定期审计、存活校验与差异修复 |
| 覆盖策略 | 先核心服务与关键链路，再逐步扩展 |
| 常见误区 | 追求大而全，导致数据迅速过期 |
典型使用场景
- 影响分析：变更前查依赖关系，判断会牵动哪些系统与业务链路
- 事件定位：故障时快速找到负责团队与关联组件，缩短恢复时间
- 容量与生命周期：掌握版本、到期时间与责任人，提前安排升级替换
- 合规审计：为等保、ISO 27001 等提供资产台账与责任人证据
- 变更关联：变更单绑定 CI，出事后可回溯最近一次改动
- 成本优化：识别闲置资源与重复采购，为预算分配提供依据
CI 关键属性示例
CI 关键属性示例
标识：CI 编号 / 名称 / 别名 / 唯一来源
属性：环境 / 版本 / 责任人 / 所属服务 / 到期时间
关系：依赖 / 被依赖 / 部署位置 / 关联变更与工单
维护：自动发现每日同步，差异生成待确认清单
校验：季度抽样审计，核对责任人与环境属性数据项与失真要命点
| 数据项 | 含义 | 准确的标志 | 失真的后果 |
|---|---|---|---|
| CI 清单 | 有哪些组件 | 自动发现与台账一致 | 遗漏组件导致影响分析漏判 |
| 关系 | 组件之间的依赖 | 调用链与部署关系可追溯 | 改一处牵动多处，事故扩散 |
| 责任人 | 谁负责这个组件 | 值班时能直接联系到人 | 排障时间大量消耗在找人上 |
| 版本与环境 | 组件当前状态 | 与环境实际保持一致 | 变更评估建立在错误前提上 |
| 生命周期 | 到期与退役计划 | 有明确时间点与动作 | 老版本长期运行，安全风险堆积 |
CMDB 不准确会误导决策：宁可范围小但准确，再逐步扩展覆盖；先做核心服务与关键依赖，比一开始铺满全量更容易守住质量。
自动发现工具能解决“有什么”，但责任人与业务归属往往仍需流程约束：把 CI 属性更新写进上线与下线流程，数据才有持续更新动力。
CI 粒度要先定义清楚：记到服务、应用到主机还是进程，决定了影响分析能否自动化；粒度混用时关系图往往拼不起来。
先做小再做全
落地顺序建议是：先圈定一两条核心业务链路，把链路上的服务、应用、数据库与依赖关系录准；再接入自动发现做日常同步；等到影响分析与值班排障都愿意查它，再逐步扩大覆盖范围。反过来先建全量模型，通常会在数据维护上耗尽人力，最后无人信任。