什么是 ITSM 中的 CMDB？收益、案例、最佳实践

总结

ISO、NIS2、HIPAA、DORA 和 GDPR 等法规都清楚表明，对于一个组织来说，IT 环境必须要有全面，清晰的可见性。所以保持合规就意味着要知道组织内部有哪些资产、它们是如何配置的，如何协同运作的。CMDB 正是这样一个可靠的数据库，帮助组织管理整个 IT 版图。

关键要点

CMDB 是所有配置项、服务及其关系的核心数据源。
它帮助 IT 团队以清晰、一致的方式掌控复杂的混合环境。
优秀的 CMDB 能够加快事件解决、简化变更管理、支持合规并帮助扩容规划。
正确实施的 CMDB 是一个完善的 ITSM 的基础。

什么是 CMDB？

CMDB 是一个有信息枢纽，用于存放有关你 IT 环境的每一个关键信息。它存储所有业务得以运转的组件——配置项（CI）——的信息，并对它们的关系和依赖进行建模，从而能够展示 IT 系统的不同细粒度的架构。CMDB 作为单一的，权威的数据源，帮助 IT 团队更好地了解其 IT 基础架构，执行变更影响分析与事件解决，并支持基于数据的决策。

CMDB 是组织的数字蓝图，展示 IT 环境中的各个模块是如何相互关联并彼此影响的。比如说，某个业务应用突然崩溃。与其猜测问题出在哪里，你的 CMDB 可以告诉你：

该应用运行在哪台服务器上
还有哪些服务依赖这台服务器
谁是这个服务负责者
近期这个服务有哪些正在进行，或已经执行的变更

在像 ServiceDesk Plus 这样的现代化 ITSM 解决方案中，CMDB 与事件、问题、变更和资产管理等模块紧密协作。它帮助你：

在变更前执行影响分析时，查看相关 CI 的依赖关系
在事件或问题排查期间识别可能受影响的关联 CI 或服务，帮助技术人员快速缩小排查范围
了解任何关键 CI 的所有者、访问权限和最近变更，从而实现更快速、更有针对性的根因分析，并与合适的相关方顺畅协作
更高效地规划日常维护，因为团队清楚需要通知谁、谁有权限执行相应操作

CMDB 的核心组成

CMDB 建立在三个核心要素之上：CI、本身属性以及它们之间的关系。

1. CI 是任何需要被追踪的组件，比如服务器、软件、人员或一条网络链路。并非每个 IT 资产都是 CI，只有那些相互依赖会影响服务交付的组件才应该在 CMDB 中跟踪。例如，一台计算机符合 CI 的定义，因为其操作系统、安装的应用和网络链路是互相关联且需要管理的。相比之下，一个鼠标通常只在 ITAM 中跟踪，因为它不会影响服务配置与交付。

CMDB 中的 CI 可以归类到不同的 CI 类型之下，用于对具有相似属性的一组 CI 进行分类。例如，数据中心、存储设备、计算机、部门、人员等。

2. 属性定义 CI 的特征或数据结构，如版本、所有者或安装日期。这些属性能够帮助 IT 团队清晰地了解每个组件的具体信息，“负责人是谁、是什么用途、在什么位置等”。

3. 关系显示 CI 之间如何相互依赖或交互。常见关系类型包括：

依赖于：某个应用服务依赖于一个数据库。
连接到：一台服务器连接到了一个网络交换机。
承载：一台物理服务器承载多个虚机；一个虚机承载多个应用。
支持：一个支持团队支持某个特定应用。
包含：一个数据中心包含多个机柜，而机柜中包含多台服务器。

例如，考虑 邮件服务 这个 CI，它属于继承自父 CI 类型“服务”的 业务服务 CI 类型。它可以包含服务负责者、可用性或服务器的详情配置信息等字段，并展示诸如“运行于”“托管于”“依赖于”等关系，以映射其底层的基础架构。

CMDB relationships showing depends on, hosts, and connected to links

通过依赖关系映射直观地展示这些连接，可以为你的 IT 环境提供全局视图。它显示服务之间如何相互依赖，突显单点故障，并帮助你看清变更或中断的真实影响。这类映射能够将分散的数据转化为有用、可落地的洞察。

Email service mapped to servers and dependencies

缺少 CMDB 时常见的 IT 困境

资产数据分散在多个系统中，难以获得整个 IT 环境的统一视图。
IT 团队在事件处理时需要额外时间手动识别受影响及相关组件，增加平均解决时间（MTTR）。
IT 团队有时在未充分了解潜在的连锁反应的情况下批准了变更，一个小更新就可能意外引发严重的业务中断。
应对合规审计要求时，过程繁琐且依赖手工，而由于 IT 基础架构文档不完整或不一致，审计也常常困难重重。

为什么 CMDB 很重要：CMDB 带来的收益

CMDB 不只是做资产跟踪，它通过将基础架构与企业运营关联起来发挥价值。它帮助 IT 团队理解诸如服务器、网络和应用等组件在交付业务服务时是如何协同工作的。

以下是 CMDB 的关键收益：

收益	说明
提升可见性	消除分散记录和孤立工具导致的碎片化，为你提供一个统一视图来查看每个资产、其配置以及其所在的位置信息。
更快的事件解决	在事件发生时，CMDB 能帮助团队立刻识别到受影响系统的依赖关系。
变更影响分析	在你推进变更之前，CMDB 会展示变更如何影响相关组件，大幅减少因规划考虑不周全的变更导致的服务中断。
合规性	保持所有资产信息及其当前配置信息准确、可审计，轻松生成合规报告。
为自动化提供配置数据	CMDB 向 ITSM、DevOps、AIOps 和编排工具提供准确的配置数据，从而实现可靠的自动化、更智能的事件关联和更安全的变更执行。

CMDB 与 ITAM：有什么不同？

CMDB 用于映射 CI 是如何配置，相互关联的，配合事件、变更管理等 ITSM 流程。ITAM 则是处理 IT 资产的业务属性，包括成本、许可、合同和库存管理等。

方面	CMDB	ITAM
目的	跟踪 CI 及其属性和关系。	管理硬件和软件的财务、合同及生命周期相关信息。
核心关注点	维护对服务交付至关重要的 CI 数据库，如服务器、应用和网络设备。	将资产视为对组织具有财务价值的条目进行管理。
存储数据	CI 属性、依赖关系。	资产、许可证、财务信息、维保信息。
使用场景	事件、变更、问题管理及合规。	生命周期管理、采购、预算规划、审计。
示例	服务器承载多个应用。	服务器成本为 17500 元，保修期到 2028 年。

CMDB 与 ITAM 如何协同工作

在实践中，CMDB 和 ITAM 不是有我没你的竞争关系，而是彼此协同配合的。

ITAM 提供准确的库存数据和生命周期详情。它能回答这样的问题：这台服务器是否仍然在保？该软件的许可证使用情况如何？
CMDB 通过添加相关的上下文和与其它 CI 的关系来丰富这些数据。清晰展示服务的影响，并能回答：有哪些关键业务应用依赖于这台服务器？

两者结合能构建 IT 环境的统一视图。这种协同帮助 IT 团队降低不必要成本、管理时间和合规风险，并帮助 IT 团队更快地响应影响服务的事件。

CMDB 的工作方式

要将分散的 IT 配置数据整合到一个可信、集成的数据源中，需要结构化的方法，主要包括以下几个关键步骤：

发现与数据导入：CMDB 首先从现有的 ITAM 工具、基于代理的扫描系统、ITOM 工具及其他业务应用集成中收集数据，以了解环境中有哪些人员、资产和服务。
规范化与数据清洗：接着，对数据进行清洗，去重并标准化所有导入的 CI，确保信息准确可靠。
关系映射：然后识别应用、服务和基础架构之间的依赖关系。一部分关系通过集成工具自动发现，另一部分则需要 IT 团队手动添加，并对这些映射连接进行校验以确保准确性。
存储与索引：所有 CI 会根据 IT 团队的策略进行组织和分类，便于在需要时搜索、检索和关联。
可视化与查询：通过仪表板、服务视图和关系视图，帮助团队掌握整个 IT 环境并理解各模块是如何整合在一起的。
持续更新：定期通过通用协议同步，API同步各平台数据至CMDB，配合人工审查，确保 CMDB 中的数据保持时效性和准确性。
在日常运营中的使用：借助清晰的、关联的数据，IT 团队可以更快解决事件、评估影响、规划变更、支持审计，做出更明智的 ITSM 决策。

CMDB 的实际应用：使用场景

强化 ITSM 核心流程： CMDB 的真正价值在于，将基于关系的数据应用到日常 IT 运维中。当它与关键 ITSM 流程集成，用于降低风险并加速服务恢复时，其实际效益便会充分体现出来。

ITSM 流程	使用的 CMDB 功能	战略业务成果	影响
变更控制	影响分析和 CI 依赖映射：CMDB 提供针对待变更的 CI 的所有关联的服务与 CI 的完整可视化信息。	风险缓解与服务韧性：将变更影响分析从依赖人工猜测转变为系统化、数据驱动的方式，使变更经理能够精准评估拟议变更的影响。	规划不足的变更是造成服务中断的重要原因。一个运行良好的 CMDB 能确保全面的风险评估，降低回退率和服务中断。
事件管理	情景分类与 CI 关联：将新发生的事件关联到受影响的 CI，为服务台技术人员提供事件的历史背景（之前出现过什么问题，最近做过什么变更）、所有者及底层基础架构等详情信息。	加速 MTTR：一线支持可以跳过手工查找，快速识别服务所有者和可能的根因，从而缩短分派到具体责任人所需的时间，减少不必要的升级，大幅缩短服务恢复时间。	快速定位并引用 CI 记录的能力，有助于通过更快识别问题组件来满足严格的 SLA 目标。
问题管理	模式识别与根因分析：CMDB 数据帮助你将反复出现的事件与导致它们的底层 CI 关联起来，并追踪相关的服务依赖关系，从而更轻松地确定问题的真正根源。	问题分析与服务稳定性：CMDB 数据通过突显引发重复问题的资产或服务器集群来加速根因分析，帮助 IT 团队更快解决问题并规划有针对性的维护，从而提升稳定性。	通过 CMDB 依赖映射实现的前瞻性方法，可以构建健全的已知错误数据库（KEDB），从而整体上增强 IT 环境的稳定性和成熟度。
合规	审计可追溯性：CMDB 维护 CI 及其变更的历史记录，使 IT 团队能够追踪“发生了什么变更、变更计划、回退计划、何时发生、由谁执行”。	合规保证与治理成熟度：通过提供完整可靠的审计追踪，帮助组织满足监管、审计和安全要求。	减少审计发现问题，避免合规罚款，改善安全态势，并强化整体 IT 治理。

DevOps 与云环境：现代 CMDB 能够与持续集成/持续交付/持续部署流水线集成，使 DevOps 团队能够跨混合环境跟踪资源。这有助于防止环境之间数据产生偏差，确保从开发到生产的一致性。

容量规划与优化：通过分析 CI 使用情况及其相互依赖，IT 团队可以预测容量瓶颈并更高效地分配资源。

CMDB 关联事件、问题与变更管理的使用案例

以下示例展示了在一次重大系统故障期间，CMDB 如何为三大核心 ITSM 流程提供关键数据支撑。

案例：邮件服务中断

场景：公司 Zylker Tech 的邮件服务（CMDB 中的一个业务服务 CI）宕机。员工无法发送或接收邮件，业务运营受到影响。

阶段一：事件管理

用户报告问题。
事件被记录并自动关联到 CMDB 中的邮件服务 CI。
服务台可以看到所有关联信息：服务器、邮件网关、依赖关系和近期变更。
快速分析发现，一个邮件服务的子服务器 CI ，中有一个服务失败。

借助 CMDB 洞察，团队识别出服务依赖并快速找到备用邮件服务器。在监控工具确认备用邮件服务器健康后，他们将邮件流量切换至该备服务器，在调查根因期间临时恢复服务。

阶段二：问题管理

由于这是重大故障，创建问题记录以查找根因。
CMDB 关系历史显示，最近对邮件服务器应用的补丁 CI 可能引发了故障。
问题管理团队利用 CMDB 分析依赖，评估对相关服务，如 CRM 和 HR 系统产生了的影响（问题影响分析），并追踪到底层问题——最终发现正是该补丁导致了故障。

阶段三：变更管理

提出变更请求，回滚或修复应用在邮件服务器上的问题补丁。
CMDB 关系帮助在批准变更前评估变更风险、受影响的 CI 以及潜在停机时间。
变更在计划窗口内实施，并在 CMDB 中自动更新邮件服务器 CI 的相关信息。
在验证修复后，事件彻底解决，问题记录被关闭。

结果

借助 CMDB ，快速找到临时解决方案，邮件服务被迅速恢复，将业务中断的影响降至最低。
通过对 CI 关系和历史的分析，准确识别出根因。
通过受控、低风险的变更永久解决问题并防止再次发生。
所有记录——事件、问题和变更——均与相同的 CI 关联，确保完全可追溯性并便于未来排障。
因为部署了 CMDB。Zylker 的 IT 团队大幅缩短了 MTTR，避免了计划外停机，并提升了整体服务可靠性。

CMDB 的最佳实践

CMDB 要想成功，必须被视为一个持续演进的过程，而不是一次性完成的项目。通过明确责任、持续审计以及恰当的自动化，CMDB 才能成为 IT 团队可靠的事实来源。以下是一些需要遵循的最佳实践：

定义清晰范围并分配 CI 责任人：从小而聚焦的范围开始。与其将每一台设备或资产都纳入其中，不如先识别真正影响业务服务的 CI。与服务所有者和应用所有者合作，确定哪些 CI 类别和属性重要。为每个 CI 指定明确的责任人，确保能够自动化更新或手动更新，并始终有人负责保证其信息的准确与及时更新。
利用自动化与集成：利用自动化和集成，从 ITAM、ADDM、监控、可观测性及发现工具中将经过验证的数据同步到 CMDB 中，自动识别组件并映射其关系。
通过持续审计维护数据质量：CMDB 数据随着时间推移往往会过时。通过定期开展健康检查、移除陈旧 CI 并执行验证流程，可以确保数据保持最新。监控数据准确率、解决数据差异所需时间等关键绩效指标( KPI )，有助于评估 CMDB 的整体健康状况以及弥补数据差异的速度。

衡量 CMDB 成功的关键指标

这些关键指标有助于评估 CMDB 在支持 ITSM 流程时的准确性、完整性和运营价值。

关键指标类别	度量指标	相关性
数据质量	CI 数据准确率	衡量具有正确、已验证属性的 CI 所占比例，与对 CMDB 的信任度直接相关。
及时性	解决数据差异的平均时间（MTTR-D）	跟踪在纠正错误 CI 记录方面，配置管理流程的效率。
覆盖率	关键服务覆盖率（%）	衡量业务关键服务中，已完全映射其底层 CI 的比例，体现 CMDB 的范围。
流程集成度	由 CMDB 集成不足，产生的数据差异，导致的变更失败率	衡量因关系数据缺失或错误而造成的变更失败所占比例。

选择合适的 CMDB 工具

选择合适的 CMDB 解决方案，取决于其可扩展性、集成能力以及与当前 ITSM 流程的原生契合度。可以考虑以下问题：

能否扩展？该解决方案能否在不降低性能的前提下处理成千上万的 CI 和高并发事务？
能否集成？它是否提供与监控、发现和工单系统的开箱即用、双向集成能力？
是否原生内置？CMDB 是否原生内置在 ITSM 平台中？从而避免复杂的集成工作
是否具备智能能力？它是否提供基于 AI 的自动关系发现与预测性影响分析功能？

在 ServiceDesk Plus 中搭建你的 CMDB

借助 ServiceDesk Plus，你可以快速从网络环境中发现、从 ITAM 和其他工具引入干净数据，并在不增加复杂度的情况下映射关键服务。平台内的功能向导、自动化流程和内置集成，使你能够构建一个可靠的 CMDB，从而让团队立即提升事件响应、变更管理和服务可见性。

ServiceDesk Plus 中的关键 CMDB 功能

功能	能力说明
IT 资产发现	通过代理、探针和自扫描脚本对 IT 资产进行扫描和发现。
自定义 CI 类型和关系	允许定义 CI 类别、创建自定义 CI 类型，并设置正向/反向关系。
可视化关系映射	提供交互式视图，用于可视化依赖关系并理解服务影响。
CI 清单管理	集中式列表视图，方便查看、筛选、添加、编辑或删除 CI。
业务视图	支持自定义服务视图，以可视化 CI 如何支撑业务服务。
自动 CI 同步	自动将新发现的资产更新到 CMDB。
用于依赖映射的集成	与多种发现、监控和 IT 运维工具集成，包括 ManageEngine application Manager、OpManager 和 Endpoint Central，以及第三方来源，以自动填充 CI 数据和应用依赖关系。
ITSM 流程集成	将 CI 与事件、问题、变更和发布关联，以便进行更好的影响分析。
CI 状态与生命周期追踪	追踪 CI 的生命周期状态，如“在用”“维修中”或“EOL”。
自定义 CI 表单与属性	允许添加无限制的自定义字段，定义个性化的数据结构，以捕获特定的 CI 数据。
CI 审计与历史追踪	维护 CI 更新历史，以满足问责和合规要求。
基于角色的访问控制	根据用户角色限制对 CMDB 的访问与编辑权限。

分阶段的部署方式可以帮助团队循序渐进地构建一个可用且准确的 CMDB。目标是从小处着手，确保数据准确，然后逐步扩展。

阶段一：确定范围和 CI 类别

识别需要优先建模的业务关键服务
定义这些服务所需的 CI 类别（服务器、虚机、应用、网络设备、数据库等）
为每个 CI 类别明确责任人

核心目的：清晰的范围能避免过度设计，团队只需聚焦那些能立刻带来价值的服务。

阶段二：发现、导入并清洗 CI 数据

使用 ServiceDesk Plus 的发现工具（网络扫描、基于代理的发现、扫描脚本）
如已有资产清单，或者其它第三方应用可导出，则可直接导入通过表格导入
在导入后立即清洗和验证数据
- 删除重复项
- 统一命名规范
- 确认 CI 所有者和支持组

核心目的：准确、干净的数据是关系、报表和根因分析可靠的基础。

阶段三：构建关系并联通 ITSM 流程

在服务、应用、服务器和数据库之间映射依赖关系
将 CI 与事件、问题、变更和发布关联起来
验证测试技术人员在工单中如何使用 CI 信息

核心目的：关系将静态 CI 数据转化为可操作洞察。技术人员可以更快看清影响路径并识别高风险变更范围。

阶段四：通过集成与自动化以确保持续的准确性

将 ServiceDesk Plus 与以下系统集成：

ITOM 工具（确认健康状况/性能）
终端管理（工作站/服务器更新）
身份管理系统（用户和权限数据）
云服务（SaaS 和虚机同步）

设置计划扫描和同步规则，将资产、部门、服务类别、软件安装、支持组和用户作为 CI 自动填充到 ServiceDesk Plus。
构建 CMDB 审计用的仪表板和报表

核心目的：集成让 CI 数据保持时效性，自动化减少人工工作，确保 CMDB 长期可靠。

为什么这种分阶段方法更有效

一旦在事件和变更工单中出现关系和影响视图，团队就能立刻感受到价值。
你只构建真正需要的内容，而不会把 CMDB 变成数据多而杂，还不能确保时效性的垃圾场，。
在建模核心服务后，有了添加和维护的经验之后，可以再继续添加更多内容，如网络、云资源或业务服务等。
持续的数据同步能确保准确的影响分析、更快的根因分析以及更高的变更成功率。

CMDB 的未来：自动化与 AI

AI 驱动的关系映射：未来的 CMDB 将不再依赖技术人员手工绘制关系，而是利用 AI 理解应用在环境中的通信方式。通过分析来自 APM 工具、可视化平台、日志和拓扑图的数据，CMDB 将能够自动填充准确的服务模型。这在不适合人工发现和手动关系映射的微服务和混合云环境中尤为重要

预测影响分析：AI 将分析大量过往事件、变更记录、CI 详情和服务连接，识别深层的关联关系。它可以洞察团队可能忽略的内容，如逐渐累积的故障趋势，或与同一 CI 反复相关的服务中断。这样可以将 CMDB 从静态数据库转变为一个智能助手，帮助变更经理更快理解风险并更有信心地做出决策。

自愈能力：作为 AIOps 集成的一部分，CMDB 将为自动修复操作提供上下文支撑，从而推动 IT 向自愈系统迈进，在这种系统中，配置偏差能够被自动检测并纠正。

一个优秀的 CMDB 并不只是帮助你完成合规要求，它能让每个人的工作都变得更轻松。当你清楚自己拥有什么资产以及它们如何互相关联时，就能在关键时刻避免混乱，更快地解决问题并保持服务稳定运行。借助互相关联并且可靠的数据，每一个 ITSM 流程都会运转得更好，业务也能从更高的稳定性和效率中受益。

常见问题

全部展开

什么是配置项（CI）？

CI 是你 IT 环境中，为了交付服务而需要进行跟踪的任何组件。它可以是一台服务器、一个诸如邮件这样的业务服务、一台虚机，甚至是一个关键应用。只要它会影响你的服务运行，它就是一个 CI。

CMDB 应该多久更新一次？

理想情况下，CMDB 应该持续更新。每当 CI 被新增、删除或变更时，CMDB 都需要相应反映出来。

CMDB 如何帮助事件管理和变更？

一个维护良好的 CMDB 能让技术人员快速看到 CI 之间的关联关系。在事件管理中，它有助于更快找到根因；在变更管理中，它能帮助你评估依赖关系和风险，从而避免分析不足误导致的关键服务宕机。

CMDB 只对大型企业有用，还是中小企业也能受益？

CMDB 对中小型企业和大型企业都很有用。其价值与其说取决于组织规模，不如说取决于 IT 环境的复杂度。如果企业高度依赖其技术栈，或正面临不断增长的基础架构需求，那么无论规模大小，CMDB 都能为企业提供可视化、可控性和可靠性。

在 ServiceDesk Plus 中可以自定义 CI 类型和属性吗？

可以。ServiceDesk Plus 允许你创建自定义 CI 类型、定义属性并设置符合你实际 IT 环境的关系，从而在不增加 CMDB 复杂度的前提下提供灵活性。

CMDB 与资产清单有什么区别？

资产清单告诉你“拥有什么”，而 CMDB 告诉你一切是如何协同工作的。它不仅仅是硬件和软件列表，还会映射关系、依赖以及每个组件所支撑的服务。

ServiceDesk Plus 如何通过集成填充 CMDB？

ServiceDesk Plus 可以通过集成和 API，从发现工具、监控系统、目录服务以及第三方应用中拉取数据，从而自动填充和丰富 CMDB，确保数据的准确性和实时性。

保持 CMDB 数据完整性的最佳实践有哪些？

要遵循清晰的 CI 纳入标准，明确责任人，并尽可能进行自动化。使用统一的命名规范，定期审查 CI 数据，避免将不必要的条目塞进 CMDB。高质量、可信赖的数据能在事件、变更和审计中促成更好的决策。