学习资料： ITIL培训基地专家讲堂直播 300期视频回放

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

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

宏观政策，主要是涉及公司或IT部门层面指导性、方向性的政策，其目标是在企业内部形成统一认识。如：
企业IT内部应当使用统一的配置管理流程，并且使用标准的文档记录和汇报机制。

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

运营政策，主要涉及到流程目标、人员、输入、输出、活动以及KPI(关键绩效指标)等各要素以及流程之间相互协调、信息交互方面的指导原则，其目标是使流程能够在政策的指引下稳健、有效地执行。如：
所有有关配置项的变更都需要通过变更管理流程进行控制，变更记录关闭前，必须通知到配置管理并得到批准。

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

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

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

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

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

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

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

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

企业CMDB运营管理成本
分析：CI的颗粒度决定了CMDB中信息的详细程度，而其详细程度的有效维护则取决于企业IT部门投入的管理成本。如果无法投入相应资源实现CMDB的有效维护，CMDB则无法保证其数据的准确性，也无法发挥其应有的价值。
企业在初始化构建CMDB的时候，无论从服务管理意识上，还是服务管理水平上往往都处于中下游，而且，难以一次性投入大量的人力和物力，因而，一般性而言，CMDB初始构建应当由粗及细，循序渐进，逐步完善。

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

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

第三步，构建CMDB模型
在前面确定了配置管理范围之后，我们就要开始来梳理配置项信息及其关系，从而设计出CMDB模型蓝图，它是一项极富挑战性的工作，主要包括以下步骤：
定义配置项的关系
配置项（CI）之间关系的定义也是配置管理建设和IT资产管理建设的区别点之一。一般 可以采取两种方法进行具体的梳理工作，一种是“自上而下”；另一种是“自下而上”。
“自上而下”方法一般要求企业已经明确了对外提供的服务目录，然后基于服务目录按照“业务服务àIT服务àIT系统àIT组件”的顺序进行梳理。

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

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

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

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

不错，为CMDB思路提供了一种思路，我会在我的一个项目中作为参考。

本身而言CMDB具有较高复杂度，是属于战术级功能。按照之前经验，真正能够做好这一块的太难；小公司资源不足，难以维护；大公司配置太多，难以落地。而CMDB的管理也关系到一个颗粒度问题，不同企业会有不同的制约。

也真如楼主所以，CMDB最终成了“IT基础架构信息库”，这是一个不愿看到的结果。。

感谢楼主分享~~~CMDB库建立不是一朝一夕的事儿，维护其中的数据更是日积月累长期坚持的浩瀚工程~~~个人认为ittil的落地，归根到底也是CMDB库的持续数据更新维护的落地问题~~~