什么是 CMDB？

CMDB 的特征

因此，我们了解 CMDB 的作用、它在配置管理中的作用，以及它与资产管理的关系和不同之处。但是，在更实际的层面上，CMDB 功能是什么样的？

CMDB 的核心功能特征是：

具有 CI 指标和分析的无缝仪表板，可轻松跟踪 CI 的运行状况、他们的关系、变更的影响、导致事件或问题的模式，以及在组织内构建和维护每项服务的成本（金钱和资源）。

合规性功能可为您提供详细的记录，让审计人员不仅可以了解 CI 的当前状态，还可以了解其历史变更、制衡、事件等。

创建 CI 并及时填充数据，支持三种不同的方法：手动输入、集成（API 驱动、SCCM）和发现工具，这些工具可自动扫描组织网络中的所有 IP 地址以收集软件和硬件信息，有效收集公司内每台物理和虚拟设备的清单。

支持联合数据集，包括 CI 及其数据的规范化和协调。

IT 服务映射（通常是关系和依赖关系的图形说明）。

访问控制允许您根据需要为不同的人员或团队提供不同的访问级别，并在出现问题或事件时追溯到变更来源。

CMDB 的优势

CMDB 解决的核心问题是孤立的数据和过时的信息。在实施 CMDB 之前，大多数组织都将数据分散在具有不同负责人的不同系统中，这就很难概览所有 CI 及其相互依赖关系，而且更难理解哪些信息是最新的，哪些不是。

这会使团队在做出决策时无法理解重要的背景，这可能会影响风险评估和报告、影响决策、减慢问题解决速度，并最终给企业带来财务和声誉方面的损失。

例如，假设 CI A 的数据保存在一个部门，而 CI B 的数据存储在另一个部门。CI B 依赖于 CI A 正常工作。但是，当 CI A 的部门决定将其下线进行维护时，他们无法了解自己对 CI B 的影响。

做好的情况就是，这可能会导致团队之间的混乱。而最坏的情况，它可能会变成重大事件。要避免这种情况，只需要一个良好的 CMDB。

Forrester 确定了 CMDB 在当今至关重要的三个用例：

规划

技术经理需要 CMDB 数据进行规划，既需要企业架构和项目组合管理的高级规划，也需要更详细的资产和容量管理。

会计

IT 财务需要应用或服务代码的记录，以便分配账单和妥善管理企业财务。

运营

CMDB 改进了许多核心 ITSM 实践，包括变更管理、事件管理和问题管理。

在变更管理中，CMDB 可以通过预测哪些用户、系统和其他 CI 可能受到影响来改进风险评估。在受监管的行业中，它还可以帮助满足合规性要求，帮助团队管理控制并提供清晰的审计跟踪。

在事件管理中，CMDB 可以帮助识别导致事件的变更，并更快地解决问题。事件记录可以与其相关 CI 相关联，从而帮助团队跟踪一段时间内的事件及其影响的资产。

在问题管理中，CMDB 可以帮助进行根本原因分析，使团队更快地找到问题核心。它还可以帮助团队确定需要升级的资产，减少服务成本和计划外停机期间，从而支持主动的问题管理。

归根结底，CMDB 应该降低复杂性、防止错误、提高安全性，并帮助 ITSM 实践（如变更和事件管理）顺利运行。

CMDB 面临的挑战

行业统计数据告诉我们，只有 25% 的组织从其 CMDB 投资中获得了有意义的价值。如此高的失败率导致该技术的声誉不佳。

好消息是，失败的原因是可以预防的，往往分为六个可预测的类别：

文化

与组织中的任何事物一样，文化和团队承诺是决定新技术和流程能否成功的最重要因素之一。《哈佛商业评论》最近一项研究显示，93％ 的高管表示，数据驱动的数字化转型的最大挑战是人员和流程。对于 CMDB 项目来说，情况也是如此。

相关性

CMDB 通常被称为“单一数据源”，这有时会导致组织试图将所有数据合而为一，而不考虑与其需求相关的用例。

与任何数据存储库一样，CMDB 应包含重点突出、有用的数据，以支持变更管理等内部流程。确保您的 CMDB 具有明确定义的价值目标、负责人以及更新数据以反映所有变更的方法。

集中化

当我们说 CMDB 是查看资产数据的集中位置时，这并不意味着所有资产数据都必须仅存放在 CMDB 中。当团队试图将所有数据转移到这个“单一数据源”中时，这种常见的误解可能会变成大量工作。这里真正的最佳实践是联合来自其他工具的数据，以便使用最合适的工具来支持每个用例。

例如，将财务数据保存在 IT 财务管理 (ITFM) 工具中，将软件许可证信息保存在软件资产管理 (SAM) 工具中通常更有意义。数据可以导入并镜像到您的 CMDB 中，即使它不是其主要存储空间。

精确度

许多组织都在努力开发和维护准确的 CMDB。最常见的问题是发现工具运行频率太低、缺少自动化规则或依赖手动输入。应对这些挑战的典型答案是事件驱动的发现，它增强了传统的自下而上的发现。

对于那些不熟悉这些术语的人来说，自下而上的发现是指资产从基础架构开始，然后扩展到面向客户的 CI。事件驱动的发现是指发生某些事情（系统内的事件、问题等）导致系统相互通信。然后，系统会根据该事件映射相关的 CI 及其连接。

现在，并不是每个 CI 都能被发现。例如，您的团队可能希望在 CMDB 中映射监视器。由于自动化系统无法发现监视器，因此需要通过电子表格（或类似方法）手动输入它们。

准确性的关键在于利用自下而上的发现和事件驱动的发现的力量，以最清晰地了解您的资产及其联系。

流程

一些组织认为 CMDB 用于建模传统基础架构和软件，而不是云和软件定义基础架构的新堆栈以及托管在其上的现代工作流程。

这里的事实是，我们不应该让关于语义的争论阻碍我们探索跟踪我们（传统和现代）CI 的真正价值，这种工具可以让我们概览我们的技术生态系统。

工具

如果您想避免上方的故障统计数据，那么选择正确的工具至关重要。一些 CMDB 工具只不过是资产存储库——固定在传统物理基础架构上的数据结构和对任何变更都反应缓慢的发现工具。要在 CMDB 上取得成功，您需要一个能够容纳新型资产并能够快速变更的 CMDB。

选择要在您的 CMDB 中管理什么

对于您应该在 CMDB 中管理哪些 CI，没有一个放之四海而皆准的答案。每个组织的用例和目标都应确定对其 CMDB 设置有意义的广度和深度。总的来说，从高级别开始并获得合适的服务，然后只在需要的地方更广泛或更深入地实现组织目标是有意义的。

也就是说，CI 可以大致分为技术实体或非技术实体。

技术实体包括商业服务、技术服务、应用、软件、数据库、容器、虚拟机、操作系统、硬件、网络、端口等。

如果您需要在 IT 服务映射中将非技术实体表示为依赖实体或受其他资产影响，也可以在 CMDB 中对它们进行建模。非技术实体可能包括用户、客户、组织、地点、服务协议、文档等。

最后，在设计 CMDB 模型时应考虑云服务。两种 SaaS 产品（例如谷歌应用、Dropbox、Salesforce 等）和 IaaS 产品（例如DigitalOcean、Linode、Rackspace、Amazon Web Services 等）可以根据需要表示为 CI。