CMDB怎么建模？配置项类型、属性与关系的设计方法

CMDB建模，是指在配置管理数据库中，定义要管理哪些类型的配置项（CI）、每种配置项记录哪些属性、配置项之间用什么关系连接的设计工作。 模型是CMDB的"骨架"：骨架合理，数据才有地方放、能被查、可以支撑影响分析和变更评估；骨架混乱，要么什么都往里塞、没人维护，要么字段设计得过于理想，最后落地不了。很多CMDB项目失败，问题不在工具，而在一开始就想把整个IT环境一次性建模，既复杂又难持续。

本文梳理CMDB建模的基本概念、设计原则、常见的配置项类型与关系，以及如何借助 自动化 和 IT资产管理 数据降低维护成本，供 IT服务台 与运维团队参考。

---

一、先理解几个基本概念

1. 配置项（CI）

配置项是需要被管理、对提供IT服务有价值的对象，如服务器、数据库、网络设备、应用系统、业务服务，甚至重要文档与合同。并非所有资产都需要成为配置项，关键看它是否影响服务的交付与稳定。

2. 配置项类型（CI Class）

将性质相近的配置项归为一类，如"服务器""交换机""应用""数据库""业务服务"。每个类型有各自的属性集合。

3. 属性（Attribute）

描述配置项的特征，如服务器的主机名、IP地址、操作系统、CPU、内存、责任人、所在机房、状态。属性可以来自自动发现，也可以由人工补充。

4. 关系（Relationship）

配置项之间的连接，如"应用运行在服务器上""服务器连接到交换机""业务服务依赖某个应用"。关系让CMDB从一张"清单"变成一张"地图"，是影响分析和故障定位的关键。

5. CMDB与资产管理的关系

对比项	IT资产管理	CMDB
关注点	资产的财务、合同、生命周期	配置项的技术属性与关系
典型数据	采购价、保修期、责任部门	依赖关系、运行环境、配置参数
主要用途	盘点、成本、合规	影响分析、变更评估、排障
范围	实物与软件资产	资产加上服务、应用等逻辑对象

两者相互补充：资产信息可以作为配置项的一部分，CMDB则在其上增加了关系与服务视角。

---

二、建模的核心原则

1. 以用途驱动，而不是以完整为目标

先问：我们希望CMDB回答什么问题？是"这台服务器出问题会影响哪些业务"，还是"这次变更涉及哪些配置项"？根据要回答的问题决定需要的配置项与属性，而不是追求描述一切。

2. 从小范围、高价值开始

优先覆盖支撑核心业务的服务、应用和关键基础设施。先把一条完整的链路建好，如业务服务、应用、数据库、服务器、网络，再逐步扩大。局部先做好，比全局都做不好更有价值。

3. 保持模型简洁

配置项类型和属性应保持在可维护的范围内。每增加一个属性，就意味着有人需要持续维护它。如果某个属性没人使用、也无法自动获取，就不要放进去。

4. 属性要有数据来源与责任人

每个关键属性都应明确：数据从哪里来（自动发现、人事系统、手工录入）、谁负责更新、多久校验一次。没有来源和责任的属性，很快就会过时。

5. 关系要有意义，也要可维护

关系的类型要清晰、数量要克制。重点关注对影响分析最有价值的关系，如依赖、运行于、连接，而不是把所有可能的联系都记录下来。

6. 使用统一的命名与标识

为配置项设置唯一标识和统一的命名规则，避免同一台服务器在不同系统中有不同的名字。唯一标识是跨系统关联、去重和同步的基础。

7. 区分"技术视图"与"业务视图"

技术视图关注设备和软件之间的关系，业务视图关注业务服务及其支撑。两者连接起来，才能回答"某台设备故障会影响哪些业务"，这正是CMDB价值所在。

---

三、常见的建模做法与落地要点

1. 常见的配置项分层

可以按层次组织：业务服务层（如财务系统、邮件服务）；应用层（应用程序、中间件、数据库实例）；基础设施层（服务器、虚拟机、存储、网络设备）；终端与其他层（办公设备、外设）。分层让关系更清晰，也便于从业务向下追溯。

2. 典型的关系类型

常用的关系包括：依赖于、运行于、连接到、包含、由……支撑、由……负责。这些关系应有明确含义和方向，避免含糊的"相关"，以保证影响分析的结论可信。

3. 用自动发现填充技术属性

服务器配置、软件清单、网络连接等信息，可以通过自动发现获取并定期更新，自动化 的采集能显著降低维护成本，保证数据新鲜。人工则补充业务含义，如重要程度、责任人、所属业务。

4. 与工单和变更流程联动

工单可以关联到受影响的配置项，变更评估时自动展示相关依赖。反过来，变更完成后更新对应的配置项。这样，CMDB不是孤立的数据库，而是融入日常流程。

5. 设定数据质量规则

对关键属性设置必填、格式校验和唯一性检查，如IP地址格式、主机名唯一。定期运行质量检查，找出重复、缺失和过期的记录。

6. 管理配置项的生命周期状态

为配置项设置状态，如计划中、在用、维护中、已退役。退役的配置项应保留历史记录，但不再参与当前的影响分析，避免干扰判断。

7. 采用分阶段的建设路线

第一阶段，建立关键基础设施与核心应用的配置项，并导入基本属性；第二阶段，补充重要关系和业务服务视图；第三阶段，与变更、事件和问题管理深度联动；第四阶段，持续优化和扩展范围。

---

四、常见问题解答（FAQ）

Q1：CMDB建模一定要遵循某个国际标准吗？
不一定。可以参考行业通用的模型作为起点，再根据自己的需求裁剪。关键是适用，而不是照搬。

Q2：CMDB里应该记录多少个属性？
以够用为原则。通常先记录能支撑影响分析和排障的核心属性，如名称、类型、状态、责任人、位置、关键配置，之后按需要增加。

Q3：小企业需要CMDB吗？
可以从简化版本开始，例如只记录关键服务器、网络设备和核心应用，以及它们之间的主要依赖。规模小时，轻量也能带来价值。

Q4：CMDB数据不准怎么办？
首先建立自动发现，减少手工；其次明确责任人和更新流程；再通过变更流程与定期审计持续校验。数据准确性是持续过程。

Q5：应用与业务服务的关系怎么建立？
通常需要业务与IT共同梳理：每项业务服务由哪些应用支撑，应用运行在哪些服务器上。可以先从最核心的几项业务开始。

Q6：旧系统与云资源也要放进CMDB吗？
如果它们支撑重要业务，就应纳入。可以通过接口或自动发现获取云资源信息，并保持与本地环境一致的模型。

Q7：如何避免CMDB变成"摆设"？
让它融入日常流程：工单、变更、事件、问题都使用CMDB的数据，并把使用效果作为改进依据。有人使用，才有人维护。

---

五、结语：先让模型"够用"，再让数据"可信"

CMDB建模 的关键，不是一次设计出完美的模型，而是围绕用途，从关键服务出发，保持简洁，明确数据来源和责任，并通过 自动化 与流程联动让数据持续新鲜。当 CMDB 能真正帮助团队快速判断影响、定位故障时，它的价值才会被所有人认可。

如果你正在建设CMDB，可以了解一下 ManageEngine ServiceDesk Plus。它内置CMDB与资产管理，支持配置项类型与关系管理、资产自动发现，并与工单、变更、问题流程联动，适合作为落地CMDB建模时的参考选项之一。