构建CMDB模型

     企业在实施 ITIL 项目的时候，配置管理常常被视为项目的“鸡肋”――食之无味，弃之可惜。究其原因主要是因为企业在创建 CMDB （配置管理数据库）的时候，往往不知所措，耗费了大量的人力和时间收集各类 IT 基础架构信息，最后，大功告成的却是一个极其复杂而难以维护的“ IT 基础架构信息库”。这与 ITIL 描绘的配置管理是企业实践 IT 服务管理的基础或核心，为 ITIL 其它流程提供基础信息的关键地位相去甚远。那么，我们应该如何来构建 CMDB 呢？在此，撰写本文将我对 CMDB 构建的一些理解和认识与大家共同来探讨。

1. 制定配置管理政策

企业政策，是企业管理的行动指南和共同纲领。它使企业在认识上形成统一，减少了不必要的沟通成本，并使企业在流程执行上事半功倍。对于构建CMDB 而言，主要有以下两类政策：

宏观政策，主要是涉及公司或IT部门层面指导性、方向性的政策，其目标是在企业内部形成统一认识。如：

1 ．企业 IT 内部应当使用统一的配置管理流程，并且使用标准的文档记录和汇报机制。

分析：配置管理流程的使用主体很大程度上确定了 CMDB 的范围和细节程度。如果其使用主体 IT 部门的职责和范围包括了开发和运维的话，那么， IT 部门在构建 CMDB 的时候，要充分考虑两个团队的管理需要确定配置管理的范围和细节程度。一个共享的 CMDB 将为企业配置管理带来便利，但需要严格定义 CMDB 中 CI （配置项）的访问权限。

运营政策，主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等各要素以及流程之间相互协调、信息交互方面的指导原则，其目标是使流程能够在政策的指引下稳健、有效地执行。如：

2 ．所有有关配置项的变更都需要通过变更管理流程进行控制，变更记录关闭前，必须通知到配置管理并得到批准。

分析：此项政策反映了两个流程之间关键的交互点。变更管理和配置管理是两个紧密相关的流程，只有成熟的变更控制才能保证 CMDB 数据的正确性。同时， CMDB 应尽可能地反映真实环境的数据，从而更为准确地为其它流程提供管理信息。

3 ．如果条件具备，应当采用自动的方式从生产环境中获取配置数据，尽量减少或避免手工采集配置数据。

分析：此项政策描述了 CMDB 输入上的指导原则。 CMDB 需要记录 IT 基础架构的信息，在大量数据的情况下，手工采集容易导致错误。因而，此政策将有助于 CMDB 的构建团队仅可能获取相关资源改善流程的运营管理。

2. 确定配置管理的范围

政策的制订定为企业构建 CMDB 营造了良好的环境，配置管理范围的确定才是企业构建 CMDB 的真正开始。配置管理的范围主要指的是 CI 的宽度和深度，以及 CI 的生命周期。（ 注：ITIL所提到的配置管理范围主要指的是CI的宽度和深度，CI的生命周期ITIL认为是从CI的接收到最终的报废退出，但在实施过程中，由于流程管理主体的差异化，对CI管理的生命周期的划分也有所不同。）

CI宽度和深度确定的时候，企业IT部门应当充分考虑以下原则：

1 ．企业 IT 服务的需要

分析：CMDB 模型是为了满足企业的 IT 服务管理需求而构建的，主要涉及的需求包括：

q  相关法案和法规对 IT 管理的需求

  企业对 IT 的依赖性越来越高，同时，对 IT 风险的控制也就越来越重要，因此，企业 IT 部门往往面临着众多的法案和法规，而 CMDB 的构建将非常有利于企业对 IT 风险的识别和控制，如 Sarbanes-Oxley 法案 404 条款要求控制所有影响财务部的流程，而其中必然会涉及到 IT 财务应用系统，那么在决定 CI 范围的时候可以将其识别为 CI ，并且通过 CI 之间的关系能够清晰地分析出需要重点控制的 CIs 。法案和法规基本上分为三个层级：国家性法案，如美国有 Sarbanes-Oxley 法案；行业性法规条款，如国内银行业有《银行业金融机构信息系统风险管理指引》；企业内部制度，企业管理制度上的规定。

q  IT 库存和资产管理的需求

CMDB 和企业 IT 资产管理间存在着非常密切的关系，我们需要识别企业在库存管理和资产管理方面的需求。特别是当我们把提升 IT 资产管理成熟度作为 CMDB 项目的一个建设目标时，我们更需要和 IT 资产经理一起协同作战，共同识别并定义当前 IT 资产管理的管理范围，例如：合同和 IT 财务信息。与此同时，我们还需要不断比较、分析、筛选配置管理和 IT 资产管理两者的需求，找到一个平衡点。

q  服务目录的需求

对于部分计划实施服务水平管理的企业，将服务目录（ Service Catalog ）需求纳入到整个 CMDB 建设中来也是至关重要的。“这台服务器是支撑哪些服务的？”，这个问题的答案对于当今的绝大多数企业来说也许只隐藏在部分高级工程师，甚至是 IT 经理的脑子中。如何让企业 IT 部门的每个员工都能够回答上面的问题，也逐渐成为企业构建 CMDB 的目标之一，它帮助我们能够更好的满足 SLAs 的要求，同时也能够进行精确的 IT 服务的成本核算。在这个环节中，建立配置项（ CI ）和服务条目（定义在服务目录中）之间的关系是企业需要特别关注的。

2 ．企业 IT 服务管理的水平

分析：CMDB 作为整个 ITIL 体系中的粘合剂，需要将 IT 服务管理流程的中涉及的数据和信息纳入到 CMDB 中。企业 IT 服务管理水平越高，其对 CMDB 数据的依赖也就越强， CMDB 数据的准确性和完整性的要求也就越高。而 IT 服务管理水平很大程度影响了企业 CMDB 构建的范围和细节程度，例如，有些管理水平较高的企业为了减少人为判断事件的优先级的情况，因此，在 CMDB 中对每个配置项（ CI ）添加影响度、紧急度、影响人数等信息。

3 ．企业 CMDB 运营管理成本

分析：CI 的颗粒度决定了 CMDB 中信息的详细程度，而其详细程度的有效维护则取决于企业 IT 部门投入的管理成本。如果无法投入相应资源实现 CMDB 的有效维护， CMDB 则无法保证其数据的准确性，也无法发挥其应有的价值。

企业在初始化构建 CMDB 的时候，无论从服务管理意识上，还是服务管理水平上往往都处于中下游，而且，难以一次性投入大量的人力和物力，因而，一般性而言， CMDB 初始构建应当由粗及细，循序渐进，逐步完善。

CI生命周期的确定实际上主要是指对如下两个问题的确定：

4． 什么时候识别 CI 并记录到 CMDB

分析：对于配置管理流程来说， CI 全生命周期的理想状态应当包括从采购申请到报废退出。但在实际实施的过程中，流程执行主体的管理范围和职责决定了 CI 被识别的时间点。如配置管理的管理主体是企业 IT 的运维部门，其 IT 设备的采购则由采购部门负责，那么， IT 运维部门对于采购阶段的 IT 设备无法进行跟踪管理，只有当采购部门将 IT 设备移交到运维部门后才被纳入配置管理的范围。

5 ．什么时候对 CI 记录进行删除

分析：流程执行主体的管理范围和职责同样决定了 CI 生命周期被删除的时间点。如 IT 运维部门对于租赁的 CI ，企业并不关心该 CI 的报废过程，而只关心其在生产环境的状况，因而，一旦该 CI 被租赁公司进行了更换，则该 CI 记录将可能标记为删除。但如果企业需要遵守萨班尼斯法案， IT 运维部门则必须关注所有 CI 的报废，因而，需要租赁公司在做相应处理后通知，然后，将该 CI 记录标记为删除。（ 注：CI记录删除并不是数据的真正删除，而是将其标记为删除，主要是因为CI的历史记录能够为审计提供重要信息。 ）

3. 构建CMDB模型

在前面确定了配置管理范围之后，我们就要开始来梳理配置项信息及其关系，从而设计出 CMDB 模型蓝图，它是一项极富挑战性的工作，主要包括以下步骤：

1 ．定义配置项的关系

配置项（ CI ）之间关系的定义也是配置管理建设和 IT 资产管理建设的区别点之一。一般 可以采取两种方法进行具体的梳理工作，一种是“自上而下”；另一种是“自下而上”。

“自上而下”方法一般要求企业已经明确了对外提供的服务目录，然后基于服务目录按照“业务服务 à IT 服务 à IT 系统 à IT 组件”的顺序进行梳理。

顾名思义，“自下而上”方法是“自上而下”方法的逆向过程，企业先从对内部 IT 组件关系进行梳理的过程开始，然后逐步将 IT 组件映射到 IT 服务。相对来说，当前“自下而上”的方法适用范围更广。

2 ．定义配置项的属性

在构建 CMDB 的过程中，除了构建配置项（ CI ）关系外，我们还需要为每个配置项（ CI ）定义属性。对于同一种类型的 CI 属性的定义，对于同步的企业可能截然不同，这给企业带来了巨大的挑战。一般来说我们遵循一个原则和一套结构：

一个原则就是“精而不多”，这个原则我相信每个人都能够体会，对于 CMDB 建设同样适用。简单说，如果我们将大量的属性纳入到 CMDB 中，那么将存在大量信息需要进行维护，这无疑增加了成本。反之，如果属性过少，维护工作虽然减轻了，但是 CMDB 的有效性就大大降低了。因此，“精而不多”就是我们的平衡点。在这里，我们说的“精”在于强调“属性需要具备面向服务的特性”，举例来说，对于一台商用服务器，也许在这台服务器的说明书中包括了上百个属性，但实际上经过我们的筛选，对企业有实际意义往往是 CPU 个数、 CPU 主频、内存、硬盘、网卡等信息。

一套结构指的是通常我们可以把一个配置项（ CI ）的属性分为五大来源，见下表：

来源	举例（一台商用服务器）
配置项（CI）本身	主频、内存数、重量、功率
IT资产管理的需要	供应商、厂商、折旧信息、购买日期、报废日期
IT服务财务管理的需要	成本中心、收费、利润率
其它IT服务管理流程的需要	CPU 性能参数、支持的最大内存数、安全等级、容错能力
其它	管理信息（配置分类、CI名称）等

3 ．设计 IT 服务模型蓝图

最后，我们还需要构建一份 IT 服务模型蓝图。蓝图主要起到了两个作用，一方面它是对当前企业 CMDB 建设工作成果的验证；另一方面，它也是对将来企业 CMDB 建设方向的一种指引。通常蓝图中应该包括以下内容：判断 CI 的标准；定义 CI 属性、关系的准则 ；持续改进方案和过程；当前的 IT 服务模型等。

4. 结束语

随着国内 IT 服务管理应用地不断推进和深化，软件厂商们纷纷支招， CMDB 构建已经成为了大家议论的热点。本文结合作者的咨询实施经验，给出了构建 CMDB 模型的相关步骤，在构建完 CMDB 模型之后，还需要进行 CMDB 初始化数据的收集和审计，并在配置管理运营过程中不断地优化和改进 CMDB 模型，让 CMDB 真正成为企业实施 ITIL 的有力保障。