文章编译——如何决定配置管理数据库的最佳粒度（编译：AMT 张纯棣）

如何决定配置管理数据库的最佳粒度

By Mans Shapshak

编译：AMT 张纯棣

配置管理的微软操作框架软件（Microsoft Operational Framework, MOF）操作指南告诉了我们，什么样的工具可以在实施配置管理时用来设计配置管理的功能和配置管理数据库。很明显，实施如HP，Red Box或Visonael等公司的配置管理软件时可以产生一些迅速见效的效果：比如更容易追踪到发生问题的配置项以及，协助问题管理模块解决问题等；然而，各种问题也伴随着实施这些软件时而产生，尤其是在决定配置管理数据库（Configuration Management DataBase，CMDB）的正确粒度时，往往会有很大的分歧。我们很可能无法确定数据库的数据粒度，使得CMDB无法更好的满足各种服务管理模块的需求，决定的数据粒度要么过细（粒度级别太高），要么过粗（粒度级别太低），降低了CMDB的效率。

一些专业的基于网络的运营公司，有时候将系统管理工具的概念集成到配置管理数据库中，即使配置管理数据库CMDB也具有系统管理的功能。然而，这样的任务难度其实是非常大的，即使对于一个很全面、完整的IT组织，他们在实施类似集成任务的经验告诉我们，完成这样的实施工作是非常复杂的，并且只有最自动化的工具才能在实施工作中担当起重任。

因为这样的自动化工具很可能仅仅在CMDB方面很有效果，而在其他的管理模块中则效果很差，因此在使用类似工具时，常会发生错误的流程和数据进行匹配的现象，影响了使用该数据的流程顺利进行。也许你会建议使用一个涵盖这个网络所有配置项的配置项管理数据库，并建议使用一些特殊的工具去定义该配置管理数据库中的每一个配置项和变更项，以便为变更管理服务。然而，这在实际中并不可行。因为在实际操作中，这样的任务一般是作为运营级别的任务，同时结合系统管理工具来实现的。

事实上，将配置管理数据库看作服务管理工具可以为我们提供一个对变更管理和运营管理接口的更加清晰、一致认识。因此，我们建议将第一级别的指示性链接定义为指向系统的配置管理信息，而不是更高一级别的变更管理信息。这样定义的数据粒度级别好处是：指向系统配置管理信息的CMDB第一级别数据粒度可以使我们更好的区分变更管理和一般的系统管理，明确该管理应进行的任务和所涉及的范围。因此，就这个层面上来说，这些工具必须要有从一个CMDB的完全粒度中追溯回上一级别的能力，即从细节中追溯回上一层的能力。

根据以上要求，这里我们简单列出一些有用的选择配置项信息的条件，以供大家创建一个配置管理数据库时进行参考，合理确定自己的配置项管理数据库数据级别。

明确问题实质

首先，我们在决定什么配置项应该放入CMDB中时，可以有各种各样的原因，但在这些原因中有一点是必须满足的，即要保证所选择的配置项一定能被全部的服务管理功能模块所访问或使用，保证服务管理工的顺利进行。如果选择的配置项被服务管理模块利用率不高，则整个配置管理数据库的利用率也不会高，这势必降低了CMDB的使用率和效率。

“勿”入歧途——谨防粒度陷阱

其次，我们在决定配置项管理数据库的数据粒度时，常会产生如下误区：级别越细越好，因为级别越细，可以记录的信息越多，权责就越明确。那么，是否真的是这样呢？

变更管理和版本管理都需要与配置管理数据库CMDB进行交互，以便于在变更管理流程中执行他们的任务。如果创建的CMDB太过于“完整”，即确定的数据粒度级别过细，我们在进行变更管理时就会陷入过多地冗余操作中，加大了变更管理的任务量。为避免掉入CMDB的数据粒度陷阱中，我们建议维持一定的数据粒度，取而代之地使用变更日志来不断补充配置项的修订信息和变更信息。

与商业合同进行关联

有时候，业务上的因素迫使组织在进行服务级别管理，应急管理，财务管理，能力管理和可用性管理时，要格外留心配置项的设置，将某些具体的配置项与业务合同进行联系。常见的做法是，在CMDB中，除记录相应配置项信息外，还保存着该配置项CI与哪些商业合同相关等信息。这些配置项包括服务级别协议（Service Level Agreements，SLAs），运营级别协议（Operational Level Agreements，OLAs），以及支持合同（Underpinned Contracts，UC）等。

如何平衡这对矛盾？

服务台和突发事件管理以及问题管理可能是配置管理数据库中使用信息记录最多的几个功能和模块。然而，服务台以及突发事件案管理与问题管理对CMDB数据粒度的要求就不同。一方面，服务台和突发事件管理要求教粗的数据粒度。这样，服务台和突发事件管理才能在最短时间内，根据CMDB中记录的配置项CI所发生的突发事件信息，将发生突发事件的配置项识别并定位出来。方便服务台员工采取进一步行动措施，迅速恢复服务。而另一方面，与突发事件案管理相比问题管理就要求CMDB数据粒度相对较细。通常问题管理需要一个可以提供大量突发事件信息的数据库，这样问它才可以利用数据挖掘工具对大量的背景信息和突发事件信息进行挖掘，实施主动问题管理和被动问题管理，以发现问题的解决方案，彻底解决问题。这里的数据挖掘对CMDB的数据粒度要求就非常高，一定要有非常详细的事件和问题信息，才可以满足问题管理的这一特殊挖掘需求。可见，处理好这几个模块对数据粒度需求的矛盾，平衡好各自之间的需求是一门艺术！

面面俱到

最后，CMDB的数据粒度要能满足服务管理运营模块的需求。从本质上来说，运营管理与系统管理工具关系更密切，它有时候需要那些没有包含在CMDB中的配置项信息。所以，我们这里一定要格外注意这一重叠部分，因为这些信息重叠部分往往会引起混淆和混乱，尤其是当我们在考虑能力数据库的数据粒度以确定未来计划的需求时，更要谨慎，要兼顾各方的需求，面面俱到。

根据以上几点要求，我们在决定一个配置管理数据库CMDB可能需要包括什么配置项信息时，即在决定CMDB的数据粒度时，可以按照如下的步骤进行：

·        选择那些与多项配置项有关的数据粒度级别

·        选择那些系统管理工具中没有包括的配置项信息，要格外留心那些特别的或者不可操作的配置项

·        CMDB中应包括各种配置项关系的信息，尤其要包含完全不同的配置项间关系的信息，如UNIX系统与NT系统间的关系

·        CMDB中一定要包括重要的服务级别协议SLA，支持合同UC和运营级别协议OLA

·        在选择主要配置项时，长根据如下的路径来做：从一个普通的问题和突发事件到最终用户的服务

·        其他的项目还包括，运营管理专家根据其丰富的经验，从一个更加整体的角度所为组织选择的配置项

综上所述，从服务管理的各种功能以及CMDB的使用上定义CMDB的数据粒度和配置项信息是非常必要的。一个定义良好的系统管理和服务管理接口能帮助你更好的划清运营管理和变更管理的界限，区分运营管理和变更管理的活动。只有这样，才能提高你的配置项管理数据库CMDB绩的效，取得更高的配置管理数据库内部回报率。（2856字，原文见附件）