本页内容

	摘要
	简介
	配置管理概述
	过程与活动
	角色与职责
	与其他 SMF 的关系
	附录：推荐技术手段

摘要

配置管理是一项关键过程，负责对所有版本的硬件、软件、文档、过程、程序及信息技术（IT）机构内其它无生命组成要素进行识别、控制和跟踪。配置管理的目标在于，确保只有经过授权的组件才能在 IT 环境中得到应用，并对所有变更调整实施记录和跟踪。

本文档将集中讨论配置管理涵盖的主要过程与活动，并介绍必须在履行配置管理职能前开展的设置活动。

“配置管理”这项服务管理职能（SMF）的重要性将通过它与 Microsoft Operations Framework (MOF) 过程模型所含其它 SMF 之间的关联方式得以体现。例如，配置管理负责对 IT 生产环境执行基准评估。变更管理将利用这种基准评估结果进一步评价因变更产生的影响，并依赖配置数据的精确性保证有关影响得到正确理解和传达。在变更与发布过程中，配置管理还将负责对 CMDB 进行更新，以确保其如实反映针对 CI 进行的全部调整。

返回页首

简介

文档用途

这份指南将面向已经或正考虑在数据中心及其它企业计算环境中部署 Microsoft 技术的组织机构提供有关配置管理 SMF 的详细信息。这是 Microsoft Operations Framework (MOF) 定义和说明的 20 余个 SMF 中的一个。该指南假设读者熟悉 MOF 的意图、背景、基本概念及其所讨论的 Microsoft 技术。

读者可在服务管理职能信息库指南的“概况”章节中查阅有关 MOF 及其姊妹篇 Microsoft Solutions Framework (MSF) 的简要介绍。这份概述还提供了 MOF 所定义的各种服务管理职能的摘要信息。以下链接处的技术文章提供了有关各个框架的概念和原理的详细信息：http://www.microsoft.com/mof/.

有哪些新内容？

此项配置管理 SMF 已针对 MOF 3.0版进行了修订。它现可介绍将最新 MOF 团队模式角色群体与服务融入配置管理过程的具体实现方法。

返回页首

配置管理概述

目的与目标

配置管理是一项关键过程，负责对所有版本的硬件、软件、文档、过程、程序及信息技术（IT）机构内其它无生命组成要素进行识别、控制和跟踪。配置管理的目标体现为，确保只有经过授权的组件(即“配置项目[CI]”)才能在 IT 环境中得到应用，并在组件生命周期内对 CI 接受过的所有变更调整实施记录和跟踪。为实现上述意图，配置管理过程应包含下列具体目标：

关键定义

配置基准。为在某一特定时点开发的产品或系统设定的配置，既涵盖产品或系统的结构和详情，又允许在后续时点对产品或系统进行重建.

配置控制。针对配置项目调整实施控制的活动。这些活动包括评估、协调、核准或拒绝变更。

配置项目 （CI）。受配置管理过程控制的 IT 组件。每个 CI 均可能包含其它 CI。CI 涉及从整个系统（包括所有硬件、软件和文档在内）到单个软件模块或较小硬件组件的各个环节，不同 CI 在复杂程度、大小和类型方面大相径庭。

配置项目属性。对应于每个已知配置项目并被记录在 CMDB 当中的信息，内容涵盖项目名称、描述、位置以及有关配置和选项的技术细节。

配置管理数据库 （CMDB）。记录每个配置项目（CI）以及不同配置项目之间重要关联详情的数据库。这个数据库可能包含 ID 代码、拷贝和序列号、类别、状态、版本、模式、位置、职能或相关历史信息等内容。数据库所含信息的详细程度取决于信息用途或信息可用性水平。

配置管理负责人IT 机构中负责组织协调配置管理过程活动的角色。这个角色还负责遴选和培训配置管理团队，并为团队成员分派管理职责。

返回页首

过程与活动

流程一览

下图1形象描述了成功管理并控制 IT 基础架构关键组件所必需开展的配置管理流动。

图1. 配置管理流程

我们还可将高度概括的管理过程拆分为一系列微观活动及流程，具体情况如下：这些微观活动及流程将为配置管理过程描绘出全面完整的蓝图。

创建配置项目 （CI）

仅就与 IT 组件变更相关的跟踪和控制需求而言，将配置项目加入 CMDB 的过程首先要求合理确定跟踪与控制变更情况所必需的细化程度。接下来，配置项目（CI）将在数据库中得到生成，以便为基于上述细化程度的组件管理活动提供支持。

除资产管理外，配置管理职能提供的另一重要收益就是 IT 组件关系建模。IT 组件之间的关系必须得到明确界定，并应结合实用建模需要在配置项目之间形成连接。例如，工作站由桌面计算机、操作系统和应用程序构成，并被连接至用户和网络。针对 IT 组件彼此关系的正确理解和适当记录有助于围绕建议实施的变更调整开展细致深入的影响分析。

评价配置项目

有关 IT 组件及其相互关系的信息被添加至 CMDB 后，便可供其它 SMF 使用。例如，变更管理可利用在 CMDB 中定义的关系判定相关变更对 IT 环境下其它组件产生的影响。问题管理可将 CMDB 作为辨别意外事件根本诱因的信息资源。

修改配置项目

随着发布管理开始对 IT 组件做出调整，必须针对 CMDB 进行相应修改。如果没有准确及时的信息，配置管理数值就会丢失。这个流程应在一切可能情况下自动执行。对于除小型机构外的所有单位来说，庞大的信息量和频繁的调整活动足以令手工数据录入任务难以完成。

审核配置项目

CMDB 所含信息的准确性对于“变更管理”、“事件管理”及其它服务管理职能的成功实现具有至关重要的意义。因此，必须建立确保数据库如实反映 IT 生产环境状况的审核过程。

说明?? 还应定期执行更加基本的评审程序，以确保 CMDB 所含信息与业务需求相关并基于适当的细化程度?接受管理。

设置活动

在启动上述配置管理流程前，必须完成一系列细致周密的设置与规划活动，以确保配置管理职能得到有效发挥。以下流程图（图2）描述了这些活动及其执行顺序。

图2. 配置管理设置活动

一次性配置管理设置活动必须先于日常配置管理过程执行，并涉及大量决策与计划工作。设置活动将首先判定组织机构试图通过创建配置管理过程实现的目标（意图）。应纳入考虑的问题包括所需管理的 IT 环境范围和与之相应的管理力度。参与目标讨论活动的人员应当包括可能受到影响的各有关方面代表，而业务相关性则应成为指导性决定因素。

第二项重要设置活动是确定存在于公认管理界限内的全套 IT 组件。这将产生更多决策：判定应接受管理的组件子集。

管理指定 IT 组件所必需的全部信息几乎无一例外地存储在由数据库产品托管的 CMDB 当中。创建 CMDB 是第三项重要设置活动。这项活动包括定义表格并生成概要报告。一家组织机构可能拥有一或多个 CMDB 。

最后，设置活动还包含与 CMDB 实际运用相关的设计和开发任务。为此，必须创建数据库应用策略和程序，例如：设计安全与访问限制并制定维护过程（包括备份与恢复程序）。只有在上述设置活动完成后，方可为数据库填充信息资料。

典型情况下，配置管理设置活动将涉及所有 MOF 团队模式角色组合。当然，这些角色的参与程度不尽相同，主要取决于各角色群体自身所具备的特点（如表1所示）。

表1. MOF 团队模式角色群体在设置活动中担当的职责

商定目标

在实现配置管理部署目标的任何项目中，第一个也是最重要的步骤就是围绕关键目标达成体现设计意图的协议。这些目标将成为可供参考的条款，有助于确定组织机构希望对变更实施跟踪控制的程度，并识别应被认为处在配置管理职能“范围内”的 IT 组件与服务。

与商定目标密切相关的是对当前状况（背景）的深入理解。存在于当前环境的问题往往是隐藏在将此项职能付诸实现的决策背后的主要动因。举例来说，倘若看似与业务（LOB）应用无关的一系列变更已对业务应用造成了影响，就表明确实存在围绕这些 IT 组件之间的关联展开思考和建模活动的必要。事实上，针对组件关系进行建模并允许变更管理职能对潜在影响进行分析的能力恰恰是配置管理提供的一项关键优势。

每当围绕目标展开讨论时，均应确保来自各个方面并承担一定 IT 组件管理职责的代表出席。尽管配置管理职能可供用来在组织机构中的某个小范围内实现对 IT 组件的成功管理，然而，配置管理所蕴含优势只有在其得到全面运用时才能得到全面发挥。

下面两个例子解释了目标与变更跟踪控制水平和配置项目受控范围之间的联系方式：

商定管理界限

在理想状况下，关于变更管理所涉及全部组件和服务的信息均应被记录在单一 CMDB 当中。然而，在实际情况下，高度分散的地域分布结构、委托授权管理和特定 IT 组件所有权等组织问题都将对专有 CMDB 所包含的内容做出相应规定。

在前文举例说明的那个办公地点高度分散的机构中，设在每个国家的办公场所都需要使用只包含本地资源（也就是各自负责管理的资源）信息的 CMDB 。这种方式有助于确保系统快速响应能力，并将数据库容量和复杂性控制在最低水平。

在大多数情况下，本地环境变更所产生的影响会受到发生变更的国家的限制，因此，几乎不需要对与其它国家办公机构 IT 组件相关的配置数据进行维护。举例来说，为设在爱丁堡的办公机构的一台客户端安装企业标准软件将不会影响到剑桥或西雅图办公机构配备的类似客户端。

当然，某些变更将会对 IT 组件产生较大程度的影响。如果某项变更请求需要将 Microsoft Windows NT? 4.0 主域（包含全部用户帐户）升级至 Windows Server? 2003 ，那么，将有不止一个国家或地区的用户受到这种变更的影响.

最佳实践途径就是创建可在建议实施特定类型变更的任何时候向其它群组发出通知的过程与程序。具有上述类型特征的变更包括升级或替换国际线路或开展与关键业务（LOB）应用相连的网络服务。

服务中心与支持模式的职责和地位也应在此纳入考虑范围。如果服务中心采用“全日制”模式（利用地理时区覆盖包括24个小时的自然日）提供 24x7 支持服务，则必须具备访问包含求助电话所提及 IT 组件信息之 CMDB 的能力。如果正在使用的数据库不止一个，就有必要生成所用远程 CMDB 的本地拷贝，以缓解网络延迟造成的影响，并确保支持人员能够在网络故障情况下访问所需数据。

在由地域因素导致的组织机构问题得到解决后，另一个应纳入考虑且与变更范围相关的组织机构因素就是可被记录于 CMDB 并在这个数据库中接受跟踪监控的资源类型。

例如，桌面计算机和操作系统的安装设置通常由 IT 部门负责，而工作区域（包括办公桌椅和电话）的分配则由行政后勤单位负责。假设一名新员工向 IT 部门申请配备一台桌面计算机，并向行政后勤部门申请一部电话和一套办公桌椅。如果由 IT 和行政部门提供的资源信息均被记录在单一 CMDB 当中，那么，围绕新员工所需基本办公设备的交付任务展开的挑选和协调工作便轻而易举。

然而，在实际情况下， CMDB 可能只包含与 IT 组件及相关服务有关的信息。行政后勤部门往往运用另一套系统（如资产登记系统）管理其所掌控的资源。为此，必须制定一个人工程序，以确保 IT 部门和行政部门同时获知可能对其各自掌控资源产生影响的配置变更。

制定配置管理标准

配置管理仅相当于控制其自身行为的策略和程序。这其中包括更新 CMDB 、执行审核、校对 CMDB 和编制管理报告等配置任务专用程序。所有配置流程活动均应得到明确定义并被纳入文档记录。

有关人员还必须定义必要的策略和程序，用以明确配置管理、变更管理和发布管理之间的关系和沟通方式。如果没有这些群组之间的适当规划和沟通，配置管理过程的目标将难以实现。此外，还应制定适当的安全指导原则，以便引导这些群组开展交流沟通。

配置管理标准的定义和归档是一种最佳实践手段，可将有关标准作为安全位置下的单个文档加以维护。最佳实践策略的一个典型示例为：只允许少数人员和自动过程具有对 CMDB 进行更新的权限。

揭示 IT 组件

存在于公认管理界限内所有 IT 组件必须在确定需要利用配置管理手段跟踪控制的 IT 组件之前得到明确识别。除应用软件、操作系统、网络路由器、工作站和服务器之外，这里所指的 IT 组件还包括过程文档、参考指南、技术手册和构建文档。

有关人员还应进行广泛审核，以期对部署在公认管理界限内的硬件和软件类型加以分辨，并收集为这个环境提供支持的文档资料（包括过程和技术方面）。上述审核工作还应对 IT 组件之间的关联加以识别。例如，所有工作站均应利用 Microsoft Windows XP 客户端构建文档创建。

确定需要管理的对象

即使在小型 IT 环境中，对所有单个组件变更情况分别进行跟踪管理也不具备可行性。除将全面收集此类信息并将其载入 CMDB 之外，数据库维护与更新成本同样令人难以承受。

因此，应对必须置于管理状态下的组件子集做出选择。这就需要考虑对业务相关性和 IT 环境组件及其彼此之间关系的重要性予以充分考虑。最佳实践经验建议仅对具有下列特征的组件实施管控：

有关人员应定期对已决定纳入 CMDB 的组件进行审核。

创建 CMDB

CMDB 是 IT 环境组件信息的单一来源。这些信息可供组织机构用于增强系统可靠性、可用性和控制力。配置管理职能将通过创建用于跟踪 IT 组件（即配置项目）的数据库确保只有经过许可授权的组件方可在 IT 环境中得到应用。仅限使用经过许可的组件为何如此重要？这是一个重要控制环节，因为未经许可授权的组件将对相关组件产生某些未知影响，而这些影响可能无档可查、具有负面效应且/或不易跟踪。

这个单一信息源将赋予组织机构中的其它群体（如服务中心、意外事件管理团队和问题管理团队）针对意外事件与问题的影响和诱因做出快速准确评估的能力。这有助于提高问题解决速度并缩短系统故障时间。而由此产生的结果则是 IT 环境可用性和可靠性的提高。举例来说，针对用户提问迅速做出解答通常需要对用户所使用的硬件和软件配置有所了解。在使用 CMDB 的情况下，服务中心人员只需通过点击鼠标即可调出这些信息。

除选择用于托管 CMDB 的工具和技术手段外，还需要在向数据库中填充受控 IT 组件与组件关联信息之前执行一系列设置与初始化任务。这些任务包括：

需要在这个阶段完成的任务取决于已被选用的数据库产品和受控 IT 环境复杂程度。

这些设置活动一经执行完毕，即可开展实施配置管理所必需的流程活动。

创建配置项目

图3展示了辨别配置项目及其彼此关系并将相关配置追加到 CMDB 的操作流程。

　

图3. 配置项目创建流程

　

针对 IT 组件变更的跟踪控制任务包括将变更情况添加到 CMDB 。这种添加操作假设变更跟踪控制所需细化程度已在前述设置阶段内得到确定，而允许在这种细化程度上管理 IT 组件的配置项目（CI）也已在数据库中生成完毕。

当相关组件被记录于 CMDB 时，即可在组件之间建立关联，以便对 IT 组件在真实情况下的连接与依存方式进行建模。例如，工作站由桌面计算机、操作系统和应用软件组成，而工作站本身则连接并使用着网络。对 CMDB 所记录组件关系的正确理解和建模有助于对建议实施的变更进行深入细致的影响分析。

虽然CI 识别活动主要由发布角色群体负责管理，但其它团队模式角色群体也会参与进来（如表2所示）。

表2. MOF 团队模式角色群体在配置项目创建活动中的参与情况

是否需要对某项资产实施跟踪控制？

初始设置与准备活动应包括编制须被置于配置管理手段控制下的 IT 组件列表。新增组件与资产得到确认后，只有在其出现于列表的前提下才会被添加至 CMDB。

将某一 IT 组件纳入 CMDB 或从 CMDB 中清除的决定应定期接受审核，以确保该数据库能够为组织机构需求和对其加以运用的服务管理职能提供支持。

确定需要接受管理的 CI

将某一 IT 组件加入 CMDB 需要将其创建为一或多个 CI 。为选择适当的 CI ，有关人员必须参考组织机构在变更跟踪控制方面惯于采用的细化程度。这样一来，在数据库中创建的 CI 将允许根据既定细化程度管理 IT 组件。

以工作站为例。一个工作站通常包括多种组件：已安装就绪的操作系统、应用软件、处理器和内存。

组织机构通常采用操作系统和已安装应用软件等代表整个工作站的配置项目对其进行管理。然而，在某些情况下，已被创建的 CI 可能直接代表每种组件，从而使组织机构得以在高度细化水平上对变更实施跟踪控制。诸如个人计算机硬件厂商之类的专业化机构可能需要 CMSB 包含允许（在极端细化程度上)跟踪监控变更情况的配置项目——也就是说，令配置项目的界定具体到已安装于某一特定型号个人计算机的图形卡、网卡和主板。

尽管这种需求可以得到满足，然而，保持 CMDB 即时更新所需付出的高昂代价远远超出了在过高细化程度上实施变更跟踪监控所带来的优势。由于每个机构具有不同目标，因此，不存在可资界定合理细化程度的明确指导原则。当然，应在决策前将可用时间、资源和技术纳入考虑范畴。这是组织机构在最初确定配置管理目标的过程中必须研讨的典型问题。

说明?? 没有必要对组织机构视为低值易耗品的项目变量情况实施跟踪监控。为工作站配备的鼠标和键盘通常就属于此类低值易耗品。

辨别 CI 之间的关系和依存性

与资产管理相比，配置管理的一项关键优势体现为配置管理可针对 IT 组件之间的关系进行建模。为实现这种优势，必须首先分辨出这些关系，并确保配置项目之间的关联如实反映现实状况。

例如，倘若某个 DNS 服务器的 Internet 协议（IP）地址发生变化，就应对依靠这台服务器执行名称解析的所有客户端的 DNS 解析程序设置做相应调整。如果 DNS 服务器与其客户端之间的关系未被存储于 CMDB ，那么，某些客户端便有可能被遗漏，并因此无法访问网络资源。

某些关系可能比较容易识别，而另一些关系却只会在针对 IT 基础架构所含组件进行调整时显现出来。为此，我们建议首先集中识别重要关系——确保组件及其所属基础架构正常运转所必需的关系，再根据实际需要添加其它关系。

您可通过在 CMDB 中创建配置项目关联的方式对 IT 组件之间的关系进行建模。每当建议对某个配置项目进行调整时，即可利用这些关联分辨出将会受到变更影响的配置项目。针对某一配置项目进行调整不一定影响到与之相关联的所有配置项目，为此，应制定可确保只会在影响分析过程中分辨出相关配置项目（将受到变更影响的项目）识别规则。

例如，将工作站内存容量从 256 MB 增加到 512 MB 的调整就不会影响到与之相连的网络。然而，安装需要大量（专有）网络带宽的视频会议应用则会对网络产生实质影响。

制定足以涵盖所有可能性的自动识别规则既不现实也不可能。识别可能受到变更影响的配置项目往往要求将自动判断规则与专业人员的经验技巧相结合。

选择 CI 属性

得到识别的每个配置项目均具有大量可供记录于 CMDB 的信息，内容涵盖项目名称、项目描述、项目所在地、配置设定及配置选项等属性。

正如本文始终强调的，配置管理的价值完全取决于 CMDB 所含信息的质量和精确度。倘若所选属性过多，就可能为确保相关信息的准确性和及时性付出高昂代价。更明智的做法是只选择配置项目管理任务所必备且组织机构需要对与之相关的变更进行跟踪监控的那些属性。

举例来说，用来描述某个应用软件的配置项目 (CI) 可能具有以下属性：

此外，还可生成并存储用来汇总细微情况或包含由信息处理或筛选程序计算得出数值的属性。针对这些（已处理）属性的需要取决于每个组织机构的具体要求和对配置项目加以识别和定义的细化程度。

向 CMDB 中添加 CI

在识别（或发现）配置项目及其相互关系并选定代表 IT 基础架构受控组件的属性后，需要执行的下一个主要过程就是将这些信息添加至 CMDB。

这个过程的第一步是依次分析每个配置项目（CI），并找出获取每个受控属性取值（指定或计算得出的数量值或用来描述属性的字符串）的最佳方式。这些取值通常被记录在多个不同位置，有关人员必须从中选出用来填充 CMDB 的取值。

例如，您可能在 DNS 、自动编录系统数据库甚至处于手工维护状态的 IP 地址注册表中找到网络服务器 IP 地址。IP 地址还可能出现在本地位置。

在选择信息源时，应将信息精确度、是否处于即时更新状态及其检索难度和成本代价纳入考虑范畴。在上面提到的例子中，服务器 IP 地址最可能通过自动编录系统获得，通过 DNS 或 IP 地址注册表获得的可能性次之。

下一步是确定信息检索方式。通过开发与信息源相连接的专用工具并提取所需信息的方式自动收集属性值往往更加快捷高效。在某些情况下，这种方法并不符合成本效益原则，甚至不具备可行性；而相当一部分信息则必须手工录入。当然，考虑到手工数据录入既浪费时间又容易出错，应尽可能少地采取这种方式。

说明?? 一旦需要将数据库数值同生产环境数值进行对比（即数据库验证），就必须为从信息源中检索属性值而专门开发工具及相关流程。

当这些预备性步骤完成后，第三步就是发出变更请求，用以描述即将添加至 CMDB 的配置项目、属性和关联。这个请求还应对属性值填充机制加以描述。

变更请求如能获得批准，配置管理负责人或授权代理人员还应对数据库结构进行更新，以确保将新增配置项目、属性及其关联包含在内。接下来，应运用在变更请求中指定的工具和技术手段将属性值填充到数据库。

所有相关文档属性均应在将文档保存于生产 CMDB 之前设置完毕。

访问配置项目

当配置项目及其属性和关联被记录至 CMDB 后，负责履行其它服务管理职能的人员或自动流程便可要求访问这些信息（如图4所示）。

图4. 配置项目访问流程

举例来说，两种最主要且最常见的 CI 访问情形分别是：变更管理职能利用 CMDB 中定义的关系判断对 IT 环境下其它组件进行调整所带来的影响；问题管理职能将 CMDB 作为一项资源，赖以分辨导致意外事件发生的根源。

虽然针对某个 CI 的访问调用可能涉及所有 MOF 团队模式角色群体，但是，这些群体的参与方式和程度将遵循表3所列示的群体职责范围。

表3. MOF 团队模式角色群体在配置项目访问活动中的参与情况

请求调用信息

针对 CMDB 所含信息的访问调用请求可能随时源自某项 SMF 。申请调用的信息可能涉及一或多个配置项目，以期运用项目关系和依存性执行（类似于变更管理的）影响力分析。

在拥有不止一个 CMDB 的组件机构中，可能需要一系列个别请求方可对某项变更产生实质影响。例如，为了解替换一条越洋线路可能产生的影响，变更管理团队成员可能需要同时从分别位于爱丁堡和西雅图的数据库中调用信息资料。

为获得所需结果，信息访问请求必须对已在特定 CMDB 中完成建模的环境组成部分给予必要关注。举例来说，倘若 CMDB 没有包括桌椅和电话，则必须针对其它数据库（如资产登记表）发出查询，以获取所需信息。我们应通过这个例子发现，直接发出请求的员工和设定自动请求的程序员都对 CMDB 所含信息类型了如指掌。

说明?? 如欲确保只有经过授权的用户才能访问基于 CMDB 存储的信息，则应设定访问权限并提供访问控件。即使在这个角色群体中，仍然存在对某些敏感信息设定访问限制的需要。例如，只有某些特定用户才应具备查看网络路由器具体属性的权限。为此，应在配置管理设置过程中创建安全指导原则、安全策略和访问限制。

如何申请调用信息？

在授权访问情况下，信息检索可通过 CMDB 应用程序或公开发布的用户界面进行。

提交信息

将信息资料提交给请求调用者的方式主要取决于赖以执行信息查询的方法或工具。信息资料既可通过 Web 报告或数据库查询工具在线提交，又可通过报告打印件或复印件方式提交。

说明?? 返回给担当服务管理职能人员的信息所蕴含的价值完全取决于?保存在 CMDB 中的信息质量。为保证实现预期收益，数据库所含信息必须全面完整、精确无误且即时更新。在这些方面确保信息质量是一项与“调整 CI ”及“复核 CI ”步骤相关的职责。应坚持定期复核（配置管理流程的最后一步），以确保数据库和反馈给 SMF 的信息如实体现生产环境所处状态。

例如，倘若 CMDB 将某些重要配置项目之间关系和依存性遗漏，那么，在影响力分析过程中反馈给变更管理职能的信息就是不完整的。当然，仅就配置管理职能而言，由 SMF 检索并向其提交的信息是全面完整的。

为简化这些工具的使用方法，必须以简便易行且符合逻辑的方式提交相关信息。为此，应重点考虑 CMDB 字段命名标准——当针对查询请求直接编制报告时，往往要求字段名具有一目了然的效果。

在某些情况下， CMDB 所含信息的呈现方式体现着针对配置项目提出的调整要求。在这种情况下，必须在对 IT 组件进行物理调整之前，严格履行定期调整过程（包括通过变更管理职能进行核准与授权）。也只有在这种情况下， CMDB 所含信息才会得到相应调整。

调整配置项目

随着 IT 组件在发布管理过程中接受调整， CMDB 所含配置项目及其相互关系也必须接受相应调整。如果对生产环境下的受控 IT 组件进行变更的同时没有相应调整 CMDB 中的配置项目，那么，数据库所含信息很快就会变得过时或不够准确，而配置管理职能相对于其它 SMF 的价值也将大打折扣。发布机制应在一切可能情况下自动执行上述调整；但在实际中，却并不总能付诸实现。有时需要通过手工录入数据确保数据库内容的及时更新。

下图重点说明了这样一个事实， IT 组件的变更不太可能成为孤立事件。IT 组件彼此之间的关联和依存性往往意味着，针对任一组件进行的调整均可能影响到另一个组件，并迫使对受到影响的组件进行相应调整或更新。

图5. 配置项目变更流程

例如，为工作站添加视频会议装置可能在会议进行时导致网络带宽占用量提高。如果局域网 （LAN） 已经处于满负荷运转状态，那么，在没有对其它 IT 组件和服务进行相应调整的前提下，视频会议将无法正常进行。为克服这个问题，可将工作站从当前网段转移到另一网段，同时，还应为降低网络占用强度对局域网重新分段——除非能够找到其它可行解决方案。

然而，无论处于何种情况，均应在视频会议成功部署并投入使用前针对一或多个相关 IT 组件进行必要调整。请注意，这些调整还必须征得变更管理过程的同意与核准。如果调整事项获得批准， 则应根据初始变更（为工作站添加视频会议装置）和为初始变更提供支持的增补变更（将工作站转移到另一网段）对 CMDB 进行相应更新。

配置项目调整活动虽由发布角色群体管理并掌控，但其它每种团队角色均有可能介入此项活动（如表4所示）。

表4. MOF 团队角色群体在配置项目调整活动的参与情况

调整 CI

在变更管理核准与发布管理将变更最终全面部署至生产环境之间可能出现较为明显的延迟现象。为保证 CMDB 将这种延迟纳入考虑并准确反映 IT 组件所处状态，必须在每次变更过程中至少对 CMDB 进行两次更新——在最初核准变更时更新一次，在变更完成时再更新一次。

在变更得到核准时进行的首次更新应确保向数据库查询特定配置项目信息的 SMF 能够获知即将发生的变更。而在这个阶段被追加到数据库中的信息则应包含 RFC 、建议变更日期和显示变更待决状态的标识。

说明?? 某一特定配置项目可能与不止一个待决 RFC 相对应?。例如，一台服务器可能与下列待决 RFC 相对应：将服务器内存容量从 256 MB 升级到 512 MB (RFC1) 并安装 SQL Server (RFC2)。

配置项目可能在寿命期内接受多次更新。因此，应当维护一份变更历史记录（包括相关日期），以便为问题管理 SMF 及其它 SMF 提供配置项目生成以来的变更情况一览表。如需将已执行完毕的变更逆转并将 IT 组件恢复为初始状态，这种信息就会成为无价之宝。

如果利用 SMS 执行应用软件或安装实例逆转任务，则可借助“通告接收成功（或失败）”这条提示消息触发 CMDB 更新操作。请注意，已被绑定至状态消息系统（和特定提示消息）的程序可供用来编写输入 CMDB 的更新内容。

调整从属 CI

如前所述， IT 组件之间的关联和依存性往往意味着针对某个组件进行的调整可能影响到另一个组件。在某些情况下，完全有必要为支持初始变更而进行补充调整.

举例来说，如需安装 Microsoft Windows Messenger 4.6 ，则必须运行 Windows XP。如果现已安装的操作系统是 Microsoft Windows 2000 或 Windows 98，则必须在安装 Windows Messenger 之前进行操作系统升级。此外，客户端可能尚不具备满足 Windows XP 系统需求的内存容量和磁盘空间，并因此需要接受进一步调整，以期达到所需配置水平。

因为配置管理的目标在于搭建生产环境模型，所以， CMDB 必须对初始变更和为之提供支持的后续变更进行跟踪记录。在前面的例子中，针对操作系统、内存容量和磁盘空间所进行的调整必须在 CMDB 中得到跟踪记录。只有在上述调整全部成功实现的前提下，才能开始安装 Windows Messenger 。

复核配置项目

由于 CMDB 所含信息的精确性对于变更管理、意外事件管理及其它相关 SMF 的成功履行具有至关重要的意义，因此，应设置赖以确保数据库精确反映 IT 生产环境的审核过程（如图6所示）。

图6. 配置项目复核流程

配置管理团队应定期对生产环境下的受控组件进行盘点（与审核），并将收集到的信息同 CMDB 所含数据进行核对。倘若不存在差异，就应记录下核对日期与时间，以便日后进行跟踪复核。

倘若存在核对差异，则应根据发现的差异因素采取相应措施（如果有）。如果经过核准的变更已部署就位但 CMDB 所含信息却已过时，则应以当前配置值对数据库进行更新。当然，如果 CMDB 表明 Windows XP 已被安装于工作站，而安装的却是 Windows 98，那么，与意外事件管理相关的问题就会随之出现。

我们还建议定期对 CMDB 所记录配置项目与业务需求的相关性进行检验，以确保组织机构在适当的深度（即细化程度）上管理 IT 环境。无独有偶，公认管理界限和配置管理范围的准确程度也应得到确认。（流程图并未展现这种结构化复核类型。）

配置项目复核活动同样由发布角色群体管理和掌控，但与其它配置管理过程相似的是，其他团队模式角色群体均可能参与到这项活动当中。

表5. MOF 团队模式角色群体在配置项目复核活动中的参与情况

执行盘点信息收集

复核过程的第一个阶段就是从 IT 生产环境中获取信息资料。此项任务虽可通过多种不同途径完成，却应尽可能以自动化方式进行。针对 IT 组件和资产的人工审核大多需要付出高昂的财务和工时代价，而信息收集成果往往在接受分析处理前就已过时。

将盘点结果与 CMDB 所含信息进行核对

在从生产环境收集到所需信息后，应将这些信息与存储在 CMDB 中的数据进行核对。与盘点信息收集过程相似，这项任务也应尽可能以自动方式完成。举例来说，如果信息收集活动以人工方式进行，收集到的信息将被追加到电子表格或数据库应用当中，进而在 CMDB 校验机制中充当数据输入来源。

如果盘点数值与 CMDB 记录之间不存在差异，就应记录下核对日期与时间，以便日后进行跟踪复核。尽管盘点数值与数据库记录相符，仍需对待决变更加以进一步检验。如果已经超过变更“实现截止”日期，但生产环境仍保持不变，则应将问题上报给意外事件管理职能。

举例说明：要求在月底前为所有工作站部署 Microsoft Office XP 的变更请求已制定完毕并获得批准。到这个月底， CMDB 信息将接受审核。CMDB 将部分工作站配置状况误报为已经安装了 Office 2000 ，而实际上 Office XP 安装实例早已部署就位。如果盘点过程确认 Office 2000 仍处于有效安装状态，与意外事件管理相关的问题就会随之出现。

如果生产环境实际情况与 CMDB 记录之间存在差异，则应因根据一系列影响因素采取相关措施：

然而，在所有情况下， CMDB 与生产环境之间的差异均应同所需采取的措施（如果有）一道纳入日志记录。每当需要对配置管理职能在机构内部有效性进行评价时，就会需要使用这种日志记录。

返回页首

角色与职责

本章节将对配置管理负责人与配置管理团队成员所担当的角色及相关职责加以描述。请注意，我们所介绍的是角色，而非作业说明——这一点很重要。小型机构可能要求一个人担当若干角色，而大型机构则可能为每个角色分派一支团队。当然，我们通常建议只由一个人担当配置管理负责人角色。

这些角色还对应于 MOF 团队模式中的七个角色群体分别定义的角色。这些角色群体（发布、基础架构、支持、操作运转、合作伙伴、服务与安全保障）代表着为实现成功运转而必须在 IT 环境下得到执行的高水平管理职能。每个角色群体中的个别角色彼此之间密切相关。

针对配置发布管理过程定义的重要角色包括：

配置管理负责人

配置管理负责人主要负责定义用于 CMDB 管理目的的过程和程序。担当这个角色的人员应当是变更顾问团（CAB）成员，并应与变更管理负责人保持密切协作，以确保在变更获得授权批准之间掌握其可能产生的影响，并将针对 IT　环境进行的调整准确记录到　CMDB　当中。

如需进一步了解　CAB，请参阅“变更管理　SMF”指南。

配置管理团队成员

配置管理团队规模主要取决于组织机构规模、IT 环境中变更与发布活动的规模及频率、 CMDB 自动化程度以及 CMDB 记录 CI 的粒度化水平。配置管理负责人应确保配备足够的团队成员，以避免配置过程妨碍其它相关流程的正常开展。

如果一个组织机构分散在多个不同地点，则应将配置团队成员相应部署到每个办公地点。在小型机构中，配置管理团队成员可能同时担当不同职责。然而，大型机构则需要配备专职管理团队成员——将整个管理团队拆分成若干小组，每个小组负责 IT 环境的某一特定领域。如果将配置管理团队划分为若干独立小组，则必须确保团队成员之间的密切协作，以防止出现信息更新差错。

在定义 CMDB 管理过程与程序时，配置管理负责人必须建立适当的控制机制，以确保由配置管理团队成员录入 CMDB 的信息兼具准确性和完整性。

表6 概括了每种配置管理角色所需担当的职责。

表6. 配置管理角色与职责

返回页首

与其他 SMF 的关系

构成 MOF 变更体系的三项服务管理职能（变更管理、配置管理和发布管理）之间存在着较为紧密的关系。图7展现了存在于这三种 SMF 之间的关联。

图 7. MOF 变更体系流程

变更管理：

配置管理：

发布管理：

考虑到应用至特定领域的变更管理手段可能对每项 SMF 造成直接影响，因此，其他各项服务管理职能均可能与变更管理职能相关。这不仅适用于运转体系所涵盖的各个技术领域，而且，还适用于可能对支持和优化体系中的 SMF 过程产生影响的变更事项。

返回页首

附录：推荐技术手段

试图借助配置管理手段对自有 IT 环境重要组件变更事项实施跟踪监控的任何组织机构都必须获取并使用特定工具和技术手段。适当的工具数量和复杂程度取决于组织机构规模和需要管理的 IT 组件数量及类型。

与这种服务管理职能相关的指导原则采取了“中间路线”，也就是对支持配置管理具体流程所需工具手段加以描述。这里所描述的工具手段具有足够的普遍性，允许各种类型和规模的组织机构采纳相关建议。

微软公司提供了大量有助于执行配置管理过程的工具手段。这些工具包括：

返回页首