下面对配置管理流程进行一个概要性介绍。前面两项活动，即规划和识别，主要涉及配置管理流程的建立，而其它活动则涉及流程的运作。
下面对配置管理流程进行一个概要性介绍。前面两项活动，即规划和识别，主要涉及配置管理流程的建立，而其它活动则涉及流程的运作。
• 规划－确定该流程的战略、政策和目标，分析现有的信息，确定所需的工具和资源，创建与其它流程、项目和供应商的接口，等等。
• 识别－建立流程来维护对数据库的更新。该流程的活动包括开发数据模型来记录所有的IT基础架构组件及其相互关系、所有人或负责人、状态以及可用的文档等方面的信息。该流程还要开发一套用于增加新的配置项（CI’s）和对现有配置项进行变更的程序。由于对信息的需求是在不断变化的，对配置数据的识别也应随之进行不断的调整。
• 控制－通过只认可、记录和监控那些经过授权和确认的配置项来确保配置管理数据库（CMDB）的及时更新。控制流程还需要确保对配置项的增加、变更、替换或移除只有在获得必要的文档的前提下才能进行。这里的文档包括如被批准的、附有最新规程的变更请求（RFC）
• 状态记录－存储有关配置项在其生命周期内所处状态的当前和历史信息。状态监控可用来识别变更所处的状态，如“开发中”、“测试中”、“库存中”、“使用中”以及“停止使用”
• 核实－通过对IT基础架构进行审计来检验配置管理数据库，以确认已记录配置项的存在性和验证记录的准确性。
• 报告－为其它流程提供信息，并就配置项的使用情况报告其趋势和发展。
1、规划
配置管理的目的、目标、范围和优先级必须在服务管理中进行定义，并与业务目标保持一致。配置管理的范围将在识别阶段详细说明。（至于如何实施配置管理则超出了本书的范围）
2、识别
识别主要是关于定义和维护IT基础架构的物理组件和有关文档的命名规范和版本号，以及定义和维护这些组件之间的相互关系和相关属性。当前和未来的硬件基准配置一般是按照配置项群（CI Clusters）来加以描述的。
在识别IT组件过程中通常会遇到的一个问题是：
“哪些服务和相关的IT基础架构组件应当置于服务管理流程的控制下？我们需要它们哪些方面的信息？”
在开发识别系统的时候，我们必须确定所要记录的信息的范围和详细程度。针对每一项要记录的性质（特征）必须识别其所有者或利益相关者。记录的特性越多，为更新信息所要付出的努力也就越多。为此，可通过回答一系列具体的问题来确定需要记录的信息。这些问题包括：
• 在收集和更新信息时有哪些资源可以利用？
• 管理和后勤（logistics）流程具备多高的成熟度？
• 组件在什么层次上被组织独立于大的组件得以安装、替换、开发和（或）分发？
• 由第三方实施的哪些活动应该是可测度的和处于控制之下？
• 如果受到故障的影响，哪些组件将会对服务产生影响？在诊断这样的故障时哪些信息是相关的？
• 哪些组件应该记录其状态和状态的历史记录？
• 哪些组件的多个版本需要在公司使用？
• 哪些组件在进行变更之后可能对服务的能力和可用性产生影响？
• 哪些高成本的组件应当受到特别保护以防被盗或丢失？
• 其它流程当前和未来对信息的需求是什么？
• 哪些组件应当具备系列号、购买日期和可供应该组件的供应商等信息？哪些信息是会计部门所需要的？
• 哪些要求是与服务级别协议的供应相关的？
• 为计费目的我们需要哪些信息？
• 我们的想法是否切合实际？是否有一些做法需要推迟一段时间？
对这些问题的回答为许多活动提供了信息。我们需要决定配置管理数据库（CMDB）的范围（宽度），分解的层数（深度）以及详细的程度（细节）。深度问题又可以进一步分为：层次的数目，需要跟踪的关系，命名规范以及属性。下面对这些问题展开讨论。
2.1具体化（CI类型的）范围
在建立配置管理数据库（CMDB）或更新实体和关系的数据模型时，需要确定IT基础架构的哪些部分需要纳入配置管理的控制。例如，PDA、网络复印机和传真机、键盘和IT人员是否被包括在配置管理的范围内？配置管理范围可以影响问题管理的诊断范围、变更管理的影响度分析的范围、服务级别协议的可检验性范围、以及可用性管理和影响管理的分析和规划范围。
除此以外，IT服务及其对客户业务活动的贡献和影响也可以加以分析并记录在配置管理数据库（CMDB）中，不过这需要与用户就支持和服务签订协议。
配置管理的范围可以分成具有不同信息需求和实施方法的几个类别。例如，可分为工作站、数据通信、文件、打印和应用服务、中央数据处理、数据库、IT系统和电话服务等。为了详细描述每个类别，可为它们分别启动一个项目来进行处理。
配置管理数据库（CMDB）的范围还包括相关的文档记录，如服务级别协议、程序、手册、技术规范、组织图、人员和项目计划等。像其它配置项一样，这些文档可能物理上存放在其它的位置，但其版本号、发行日期、作者及其它信息仍存入配置管理数据库（CMDB）中。因此，这些文档的特征仍受到配置管理、变更管理和发布管理的控制。
图－1显示了一项服务和配置管理数据库（CMDB）组件之间的关系。在这个图中，我们可以看到该项服务所需要的其它配置项。维持这些关系的记录可以更容易地确定事故对这项服务的影响。这样做也使生成一份有关该项服务所使用到的所有组件方面的报告成为可能。这些信息可用来制定服务改进计划。“服务”作为配置项与其它配置项（如与客户签订的服务级别协议等协议）之间也存在关系。在图中所示的例子中，服务B完全处在配置管理数据库（CMDB）的范围之外，在这种情况下，并不是所有与“服务A”有关的配置项都被包括在配置管理数据库（CMDB）的范围内，这意味着服务A不可能得到完全的支持。
在确定配置管理数据库（CMDB）所属范围内的类别的数量后，我们可以进一步确定可能会被包括在配置管理数据库（CMDB）范围内的配置项生命周期要素。类似于这样的问题需要加以解决：
• 其状态处于“开发中”或“订购中”的配置项是否可以被包括在配置管理数据库（CMDB）中？
• 或者仅仅当它们已经被实际安装在基础架构中时才可被纳入配置管理数据库（CMDB）中？
将处于开发状态的产品包括在配置管理数据库（CMDB）中的优势是，它们的规格说明在没有咨询意见的情况下不能随便变更，并且将它们转到管理环境也将更加平稳。选择这种做法可能使配置管理的状态监控活动受到影响，但可以在产品生命周期方面拓宽配置管理的范围。
2.2 详细程度（属性）
为每一类配置项确定其属性的详细程度是建立配置管理的一个重要的方面。为某一类配置项的属性确定的详细程度肯定不会适用于所有的配置项。某个配置项属性的详细程度决定了可获得的关于这个配置项及其名称和属性方面的信息。
在确定属性的详细程度时，需要审慎地平衡变更需求、事故、问题、其它管理流程、以及用于支持配置管理所需的相关的负载量以及可利用的资源等方面的关系。
2.3配置项之间的关系
配置项之间的关系对于诊断错误和预测服务的可用性是非常有用的。这些关系可表现为多种形式，如：
• 物理关系
“构成”：这是配置项之间的父/子关系，如某个软盘驱动器构成了某台PC机的一部分，某个软件模块构成了某个程序的一部分。
“连接”：如，某台PC机被连接到局域网（LAN）的某个节点上。
“需要”：如，运行应用系统需要硬件。
• 逻辑关系
“拷贝”：如一个标准模块、基准或程序的拷贝。
“涉及”：涉及一个程序、手册、文档、一份SLA、或一个客户区域。
“被使用”：如提供一项服务需要用到某个配置项，或某个程序模块被许多程序调用。
2.4深度――分解的层数
当定义一个配置管理数据库（CMDB）的深度时，需要确定一个系统或组件的分解程度以及组件和要素的层级结构。当父配置项被选定后，配置项被分解的层数也就应该被确定了。最高层是作为总体的IT基础架构本身，而最低层是最详细的一层，控制就应当在这一层展开。只有当对某个配置项的控制以及相关的信息对其它ITIL流程有益时，将这个配置项纳入配置管理数据库（CMDB）才是有用的。
有关深度的相关考虑还有：变更实施所在的层次，涉及的组件的重要性，以及能够在该层次上进行影响度评估的价值。
就第一点而言，如果变更在程序的层次进行而不是模块的层次，则分解到程序层就足够了；但是如果变更在模块的层次进行而这些模块又被组合成各种程序，则分解的最低的层次就应当是模块。
就第二和第三点而言，将PC机的鼠标记录在配置管理数据库（CMDB）中对于影响度评估来说未必是相关的，在资产管理中也不会提供什么有意义的帮助。
最初的实施一般都是从一个较高的层次开始的，而后特别是在实施了发布管理之后，才会有选择地将更低的分解层次引进来。
资料来源：OGC
下面两条是定义配置管理数据库（CMDB）时的一般性指导原则：
• 分解的层次越多，需要处理的信息越多。这将导致工作量也随之增加，从而导致一个更庞大和更复杂的配置管理数据库（CMDB）；
• 分解的层次越少，关于IT基础架构的控制和信息也就越少。
2.5 配置项类型变体的处理
如果配置管理数据库（CMDB）的详细程度太低，则很难对基础性组件进行有效监控。在这种情况下，任何对某个父配置项的组件所作的变更将会导致这个父配置项派生出另一个变体。例如，一台配备了两种类型的硬盘的PC机将会以变体A和变体B两种形式存在。如果对子组件进行了许多的变更，则对变体的编号就会变得越来越复杂，甚至到最后出现难以维护的情形。
反之，如果有更多的基础层，则这些变体就可以在一个适当的层次得到维护。比如可为这些子组件设立更多的属性，有关的已知错误也可以与这些属性进行关联，并且在此期间可提出一个更详细的诊断方面的问题，如“选择这个硬盘需要哪个驱动器？”、“这个网卡连到了哪个网络节点上？”以及“哪些程序在使用这个数据库？”
2.6 配置项变体的处理
如果一个配置项的多种形式共同存在着，则可以使用配置项变体，即存在着平行关系。例如，如果同时使用了配置项的新的版本和旧有版本，则版本的概念就存在了，即存在着序列关系。对这两个概念的有效使用可以协助制定变更规划。如果每个变体都单独地进行开发，则需要为每个变体引进独立的版本号系统。这是不受欢迎的模式，因为这使得IT基础架构更加复杂，同时也增加了维护的难度。在大多数情况下，对所有的变体进行开发并在可能的情况下为所需要的变体创建一个新的版本是一种明智的做法。
2.7命名规范和标签
每个配置项都应该有一个唯一的、系统化的名称以确保能把它与其它配置项区分开来。最基本的选择就是一种简易编号系统。这种编号系统可将每一配置项类别都分成几个级别。当一项新的配置项被创建时，随之也就生成了一个新的编号。可能的话，这些名称还应当是具有某种含义的，这样可以便于与用户进行沟通。
命名规范也可以用于为配置项贴物理标签，从而保证在审计、维护和事故记录时能够轻易地识别配置项。ITIL中推荐的一些命名规范包括：
• 硬件的物理标签对用户来说要易理解和易阅读，并且要难以移除。为此应该与第三方服务提供商达成协议在支持合同中参考这些标签。用户在报告事故时也应当可以读出相关的标签。
• 受控的文档，如SLA、规程、组织图等也应该标上配置项编号、版本号和版本日期。
• 软件的拷贝应该存放在最终软件库（DSL）中（见“发布管理”一章）。所有存储的软件都应该有一个配置项编号，并且可能的话，已经安装的软件也应当有一个版本号和拷贝编号。
2.8属性
针对每一种配置项类型，需要定义配置管理数据库（CMDB）的属性和关系的详细程度。属性被用来存储与配置项类型相关的信息。在建立一个配置管理数据库（CMDB）的配置项结构时，下列属性可能被用到。
像事故这样的事件在配置管理数据库（CMDB）中怎样进行记录？是作为一项配置项属性或以其它方式记录？这要取决于所使用的服务管理工具。通常是相关的配置项的编号被包含在事故记录、问题记录和变更记录中。不论选择哪种方法，配置项和下列记录之间的关系必须得以保存。
保存配置项之间的关系是配置管理的一个重要部分。根据数据库类型的不同，这些关系可能是作为配置项属性保存在配置管理数据库（CMDB）中，或是作为一张单独的表格保存。
有些数据库提供一种方式来提供关于属性及其关系的历史记录。这对于“当前状态”字段获取有关宕机时间、维修和维护方面的信息是非常有用的。同时，对追查关于所有权（责任归属）的历史状况也是很有用的。
为每种配置项类型保存技术信息方面的属性记录有时候是必要的。每种配置项类型都有不同的特征。例如，对于一台PC机来说，硬盘容量、BIOS制造商和BIOS版本、RAM、IP号等。许多系统管理系统都可以记录这些信息，从而足以为这些关于配置项类型的记录建立关联而防止信息的重复。 还应当为其它信息源建立关联，如位置、用户、部门、电话号码、预算控制人和预算标号。关于配置项属性的关联有多种选择，但是，在选择时必须考虑为维护这些文件的所需的工作量和变更控制方法。
2.9 基准
配置基准是一组配置项在某个特定时刻所处状态的快照（Snapshot）。它可用作：
• 可能会被安装在IT基础架构中的经过批准/受到支持的产品（这些基准一般包括在产品目录中）；
• 用于记录成本信息（成本要素）的标准配置项；
• 开发和测试新配置的起点；
• 在实施变更后如果新配置存在问题时的备用配置；
• 为用户提供配置的一个标准，如“标准工作站”；
• 供应新软件的起点。
标准工作站是产品基准最常见的例子。通过限制不同的标准工作站的数量，可以更加容易地估计试运行（Rollout）新的功能或改进措施可能产生的影响和所需的资源，也更易于对这些新功能和改进措施进行测试。基准还可用来为组合和规划一些变更设定政策，如为包发布设定政策。基准还有助于降低管理成本和便于进行项目规划。
产品目录是基准的又一项有益的应用。这个目录列出了经过认证的、可在IT基础架构中使用的配置和用户可以申请使用的配置。在这种情况下，一个新的配置项就是来自该目录的一个拷贝，且具有唯一的编号和标签。
新的配置模式或产品导入基础架构之前必须先在产品目录中列出。在决定是否将其加入产品目录的时候可以从以下几个方面综合考虑：
• 业务－它是否满足用户的业务需求？
• 财务－支持它成本是否是可接受的？
• 影响－对服务的影响是否是可接受的？
2.10 建立配置管理数据库（CMDB）
根据现有的财务记录和IT基础架构记录，以及来自供应商的一些技术数据，可以初步建立配置管理数据库（CMDB）。只有那些具有明确的利益相关者的信息才应当被记录，并且这些利益相关者必须同意通过变更管理流程来更新信息。
3、状态记录
组件的生命周期可被划分成多个阶段，每个阶段都可以分配一个状态代码。但具体分成几个阶段则取决于公司希望记录IT基础架构的哪些特征。保持对每次状态变化日期的记录可以提供关于一个产品的生命周期的有用的信息，如订购时间、安装时间以及所需的维护和支持。
组件的状态决定了可以对其进行操作的余地。例如，如果一个非运营性备件的状态为“被跟踪”（Tracked），则在没有经过协商同意的情况下是不能将其用作其它用途的，如作为灾难恢复计划的一部分。
下列是一些可能用到的状态分类：
• 新配置项：
- 开发中/订购中
- 已测试
- 已验收
• 现有配置项：
- 已收到
- 针对该配置项提出了变更请求，要求提供新的版本
- 变更已被批准并已纳入变更计划，需要提供新的配置项和文档（文档也属于配置项）
- 维护中
- 宕机状态
• 已归档配置项：
- 已停止使用
- 已删除
- 已移除
- 被盗
- 已出售或租期已满
- 待捐献、出售或销毁
- 已毁坏
• 所有配置项：
- 库存
- 定单已到货，或变更版本已经可用了
- 测试中
- 已发布，等待安装
- 激活（正在被使用）
- 备用
4、配置项的控制
必须有效控制信息以维持配置管理数据库（CMDB）的及时更新。一旦某项活动改变了配置项已记录的特征或配置项之间的关系，则必须在配置管理数据库（CMDB）中记录该项变动。需注意的是：只有变更管理才有权批准对配置项的特征进行变动，事故管理只能改变某个现有的配置项的状态来反映现实状况，如系统中断运行。
配置管理负责控制组织接收到的所有IT组件并需确保这些组件被记录在系统中。硬件可在其已订购或已交付时进行记录，而软件则通常在其被纳入最终软件库（DSL）时进行记录。
配置管理的另一项控制任务是确保配置项只有在已经过批准并被包括在产品目录中以后才被记录。由于这个原因，配置管理应与供应商、事故管理、问题管理和变更管理保持着密切的联系。
如果由配置管理协调的变更在IT基础架构中实施了，则配置管理需要将该信息记录在配置管理数据库（CMDB）中。为了能够实现这点，配置管理对组织内其它流程的成熟度提出了一定的要求，特别是对变更管理、发布管理和采购部门的流程更是如此。
此外，为了确保实际的情形符合经过批准的配置管理数据库（CMDB）中记录的信息，配置管理还需要对下列情形进行监控：
• 添加配置项
• 改变配置项状态，如“正常”或“宕机”（对可用性管理有用）
• 改变配置项其所有者
• 改变配置项与其它配置项的关系
• 移除配置项
• 配置项与某项服务、文档或其它配置项产生了其它关系
• 续签或修改配置项许
• 审计后对配置项信息进行更新
只要存在流程方面的问题，配置管理就有责任确保它们会得到解决。
5、检验和审计
执行审计是为了核实配置管理数据库（CMDB）中记录的信息是否仍然反映了当前的现实状况。例如，审计工具可以自动地对工作站进行分析，并报告IT基础架构当前的情形和状态。这些信息可用来检查和更新配置管理数据库（CMDB）。
在下列情形下需要执行审计：
• 在建立了新的配置管理数据库（CMDB）之后；• 建立配置管理数据库（CMDB）一段时间之后；
• 重大变更之前或之后；
• 灾难恢复之后；
• 其它任何方便的时候。
在执行一项审计过程中需要询问以下问题：
• 处在不同实施阶段的所有变更请求是否都被记录在配置管理数据库（CMDB）中？该记录过程是否处在配置管理的控制之下？
• 配置管理数据库（CMDB）是否反映了最新的信息？如果没有，为什么？
• 对变更管理的影响是什么（计划性变更的实际影响度分析）？
• 新配置项的命名是否遵循了命名规范？
• 有关配置项的变体是否被正确地使用？
• 基准配置是否被正确地记录了？它们是否即时可用？
• 最终软件库（DSL）和最终硬件库（DHS）中的内容与配置管理数据库（CMDB）中的信息是否是一致的？如果不是，原因是什么？
审计也可以随机地或在配置经理认为配置管理数据库（CMDB）中的信息不正确时进行。如果配置管理系统与审计工具之间存在关联，则可以每天生成针对某个相关领域的审计或德尔塔（Delta）报告。
在发现差异时，不应该允许审计工具自动更新配置管理数据库（CMDB）。所有的差异都表明变更管理流程可能被忽视了，所以应该对这些差异进行调查并通过变更管理对这些差异进行追溯性处理。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved