学习资料：IT运维管理社区专家讲堂直播300期视频回放

各位朋友，先锋小编为你们选了一篇很好的文章，欢迎讨论！

IT服务管理顾问以某个地方县实施配置管理为例，带您了解配置管理的具体步骤。

目前，随着关于IT基础结构标准库（ITIL）配置管理数据库（CMDB）宣传的泛滥和各种相关书籍的出版，从业者对于如何实现配置管理感到困惑，这已不足为奇。

我曾经在很多此类公司工作过，它们经常遇到的主要问题是“从何处着手”。为配置管理设定一个开始点这很困难，因为关于CMDB系统的观点很难让人理解。

面临的挑战总是很多，因为ITIL对于配置管理的定义要求文档化并确认各种各样的相互依赖因素，这远远超出了大多数人们当听到这个术语时所想到的意思。因此，配置管理实际上成为所有ITIL过程的基础，而CMDB就成了核心。

简单地说，一个CMDB就是一个元数据库，或称为数据库的数据库。实际上，刚开始时它可能根本不是传统意义上的数据库，只不过是一个简单注册表用于记录访问与第一阶段CMDB对象相关的其它信息来源。

换句话说，CMDB包含关于其它数据库及它们是如何相互关联的数据。但就这一点就使得建立一个CMDB以及配置管理过程让人感到“恐怖”。

CMDB示例之旅

这是为一个县城府的IT部门建立配置管理的例子。这个县极其重要，年度IT预算达35000000美元。为了“为更多人提供更多服务利用更少的资源”——这是所有IT部门的普通要求，不仅仅是政府部门，他们决定开始ITIL之路。本例中的经验值得所有准备开始ITILCMDB之路的IT组织借鉴。

在该县向前推进他们的ITIL实现时，他们聘请了顾问来做成熟度评估，并且让他们的大量员工接受了ITILFoundation和Practitioner认证培训。然后他们将每个过程管理分配给该组织中的高级经理，同时他们还组织了研讨会来学习如何组织ITIL工作流，并建立了管理控制，使用高级管理。经过将近一年的准备工作，他们感觉已经准备好可以开始着手开始实现。

几个月后，我接到他们的IT主管请求帮助进行配置管理的电话。他们已经完成了大量工作如事件、服务台、问题以及容量和可用性管理，但是配置管理进展很不顺利。首先，我会见了配置经理，听他讲了一个非常熟悉的情况——身份认证、标记以及记录配置项(CI)日志是十分重要的观点。除了这个进展缓慢的任务外，对于如何将CIs组织成为服务对他们来说没有什么限制的地方。

简单地说，他们不能决定“从何处开始”。我建议他们的IT主管召集所有的功能和过程管理经理一起召开一个研讨会，目的是探讨并定义ITIL所说的与持续服务改进计划（CSIP）相联系的配置管理计划。

研讨会

在研讨会上，我请经理们定义IT面临的最大问题。为了成功进行配置管理和实现一个CMDB系统，我们知道，您必须从头到尾对要做的工作有清楚的了解，换句话说，您必须知道最终的目标或输出需求。然后，通过进行配置管理（和CMDB）工作达到这一目标。

当然，就ITIL而言，所有的IT工作必须直接面对业务需求，因此，简单地说“我们需要一个CMDB来加快解决问题”或“我们需要一个CMDB来帮助我们内部改变管理过程”是不够的。为了成功，您需要知道想通过ITIL来解决什么业务/客户问题，具体说来就是您期望解决什么问题，如何测量以及向谁演示结果。

这才是真正的IT工作与业务需求保持一致。这一点（经常被忽视或弱化）才是使得创建一个有效的CMDB系统对很多人来说十分困难的原因。

最后在研讨会上这个团队得出结论IT面对的唯一最大问题是对终端用户的服务质量。问题是当用户寻求服务支持时服务台没有办法将用户应用同特定服务器联系起来。结果常常导致问题被误转。被误转的问题接下来就会成为IT组织内一个推来推去的问题，一直得不到解决的顽疾。

随着问题存在时间的增加，迟迟得不到解决，用户可能将问题提交给高级IT管理，然后IT没有其它方法只能使用最大的组织力量去解决这个问题。这是被大多说IT组织称作“火功”的典型挑战。当然，问题是工作在这种模式下，IT组织没有时间来提高效率。

在我们理解了IT组织面对的主要业务/用户问题后，解决起来就很简单（误传问题是因为缺乏对体系结构配置的了解，这就导致延长了用户储运损耗和等待时间。现在我们知道了“从何处开始”而且对要的结果有清楚的了解——实施CMDB的目标是提供一个信息服务台用以显示那个应用运行在那个服务器上，然后指示向何处转发标记。

在实现CMDB时，所需数据通常已经存在IT组织的某处了。问题不是缺少数据，大部分IT组织有大量的管理数据仓库（MDR）。实际上，他们拥有太多不一致的数据源分散于多个IT域中并且通常分布于不同的地区。

这个不断增殖的“对立源”正是创建CMDB系统的主要驱动力之一，也是因为它提出了一个最复杂的挑战，它使得IT组织不知道关键的管理数据存在于何处，在需要时很难查找到它们。这正是为什么ITIL不把CMDB描述为一个单体实体而把它作为一个“数据库的数据库”的原因。

在决定了何处开始以及为什么后，下一步我们需要定位MDR目前存在于IT部门的那一部分中，这更像有按照技术组织的工作组组成。既然我们有全部过程和职能经理，那么我的下一个问题是“谁知道什么应用，该运行于什么服务器上？”，很快就有了答案，他们想到了MDR来解决这个问题，MDR位于服务器存储备份小组中，他们有一个Excel数据表来记录每个服务器以及它的操作系统，软件，数据库等等。这也是为什么我要求所有功能和过程经理参见讨论会的原因。

然后，我找到配置经理，并告诉他利用服务台来管理对由服务器存储备份小组维护的Execl数据表MDR的访问。他们决定在服务台上通过一个Web网页来公布MDR，这样就诞生了真正的业务需求，ITIL的配置管理以及实际公司中的真实CMDB。

照这样创建的配置管理和CMDB可以保证快速胜利，因为这种可测量可演示的方式提高了IT服务质量。它还为IT组织提供了一种评估和调整同CMDB的建立相关的ROI（投资回报率）的一种方法。同时，它还有助于我们对维护CMDB和配置管理过程所需TCO的理解——包括花费或过程，工作流和资源使用等。

随着时间增加，最初的配置管理过程现在已变成具有严格标准的同业务需求步伐一致的CMDB，现在这个县的IT组织作为业务伙伴而不是业务的感觉障碍良好的运行着。（转）

不错的案例

实施CMDB的目标是提供一个信息服务台用以显示那个应用运行在那个服务器上，然后指示向何处转发标记。
当目标明确后，就知道下一步需要做什么，不能为CMDB而CMDB，防止掉进CMDB内部的圈子里。

小编精选的文章都很有价值

小编选的文章的对我们都很有帮助啊:lol