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

    CMDB作为整个ITIL体系中的粘合剂，需要将IT服务管理流程的中涉及的数据和信息纳入到CMDB中。企业IT服务管理水平越高，其对CMDB数据的依赖也就越强，CMDB数据的准确性和完整性的要求也就越高。

    而IT服务管理水平很大程度影响了企业CMDB构建的范围和细节程度，例如，有些管理水平较高的企业为了减少人为判断事件的优先级的情况，因此，在CMDB中对每个配置项（CI）添加影响度、紧急度、影响人数等信息。

    3、企业CMDB运营管理成本

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

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

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

    1、什么时候识别CI并记录到CMDB

    对于配置管理流程来说，CI全生命周期的理想状态应当包括从采购申请到报废退出。但在实际实施的过程中，流程执行主体的管理范围和职责决定了CI被识别的时间点。

    如配置管理的管理主体是企业IT的运维部门，其IT设备的采购则由采购部门负责，那么，IT运维部门对于采购阶段的IT设备无法进行跟踪管理，只有当采购部门将IT设备移交到运维部门后才被纳入配置管理的范围。

    2、什么时候对CI记录进行删除

    流程执行主体的管理范围和职责同样决定了CI生命周期被删除的时间点。如IT运维部门对于租赁的CI，企业并不关心该CI的报废过程，而只关心其在生产环境的状况，因而，一旦该CI被租赁公司进行了更换，则该CI记录将可能标记为删除。

    但如果企业需要遵守萨班尼斯法案，IT运维部门则必须关注所有CI的报废，因而，需要租赁公司在做相应处理后通知，然后，将该CI记录标记为删除。

    构建模型 

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

    1、定义配置项的关系

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

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

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

    2、定义配置项的属性

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

    一个原则就是“精而不多”，这个原则我相信每个人都能够体会，对于CMDB建设同样适用。简单说，如果我们将大量的属性纳入到CMDB中，那么将存在大量信息需要进行维护，这无疑增加了成本。

    反之，如果属性过少，维护工作虽然减轻了，但是CMDB的有效性就大大降低了。因此，“精而不多”就是我们的平衡点。

    在这里，我们说的“精”在于强调“属性需要具备面向服务的特性”，举例来说，对于一台商用服务器，也许在这台服务器的说明书中包括了上百个属性，但实际上经过我们的筛选，对企业有实际意义往往是CPU个数、CPU主频、内存、硬盘、网卡等信息。

    一套结构指的是通常我们可以把一个配置项（CI）的属性分为五大来源，如表3所示。

    最后，我们还需要构建一份IT服务模型蓝图。蓝图主要起到了两个作用，一方面它是对当前企业CMDB建设工作成果的验证；另一方面，它也是对将来企业CMDB建设方向的一种指引。

    通常，蓝图中应包括以下内容：判断CI的标准；定义CI属性、关系的准则；持续改进方案和过程；当前的IT服务模型等。