变更管理流程批准或拒绝每一个变更请求（RFC）。流程由变更经理推动，但是对于更重要的变更的真正决定是由变更顾问委员会（CAB）作出的。变更顾问委员会拥有来自整个组织许多部门的成员，也有顾客和供应商。配置管理负责提供关于建议的变更的潜在影响的信息。
变更管理流程批准或拒绝每一个变更请求（RFC）。流程由变更经理推动，但是对于更重要的变更的真正决定是由变更顾问委员会（CAB）作出的。变更顾问委员会拥有来自整个组织许多部门的成员，也有顾客和供应商。配置管理负责提供关于建议的变更的潜在影响的信息。
变更管理流程的输入包括：
• 变更请求（RFC）；
• 配置管理数据库（CMDB）信息（特别使变更影响度分析）
• 来自其它流程的信息（能力数据库，预算信息等）。
• 变更规划（变更进度计划表，FSC）。
变更管理流程的输出包括：
• 更新变更规划（变更进度计划表：FSC）；
• 触发配置管理和发布管理；
• CAB议程，备忘录和行动列表。
• 变更管理报告。
变更管理进行如下的活动来处理变更：
记录——变更管理负责确保所有的变更资源可以提交给变更请求（RFC），且它们都被完整地记录下来。
审查——过滤变更请求（RFC），对其进行验收以备进一步考虑。
归类——按照类别和优先级对变更请求（RFC）进行分类。
规划和批准——巩固变更；规划和批准开发和实现过程；确保要求的资源可用，以及上述要求所需的CAB。
协调——协调变更的建立，测试和实现过程。
评价——判定每个变更是否成功并从中汲取教训以有利于处理。
1、记录
首先，所有的变更请求（RFC）都必须记录下来并记入日志。当一个变更请求（RFC）被提交去处理问题，然后记录下已知错误的数目。
1.1 变更请求（RFC）由什么组成？
并不是每一个修改请求都像变更一样处理：一些由过程（标准变更）明确定义并完成的常规管理任务包括基础架构变更可以像服务请求一样处理。这也致使变更的有如下的分类：
标准变更 — 如同服务请求——单独记录的，但没有被变更管理单独评估的变更模式得到全面的定义和批准。这些改变定期被执行。（注意：不是所有的服务请求都是变更）。
非标准变更 — 所有其它管理基础架构的修改都是非标准变更。
1.2 变更请求（RFC）从哪里来的？
变更请求（RFC）可能关心ITIL流程范围内基础架构的所有方面。任何工作在基础架构部分的人都提交一项变更请求（RFC）。我们可以这样定义一些变更请求（RFC）源：
问题管理——提交处理办法以消除错误，稳定服务的供给。
用户——可能请求更多，更少或者其它服务。这些请求可能像变更请求（RFC）一样被直接提交。或者通过服务台，服务级别管理或IT客户关系管理引导。
立法——如果新调整的变更用于商业活动，或者如果为IT安全，商业持续性和许可证管理引入新的需求。有相关的流程控制它。
供应商——供应商发布新的版本并更新他们的产品，确定他们所补救的错误。他们可能也与相互通信，表示不在支持某些版本，或者某个版本的执行不安全。这可能引发问题管理或可用性管理提出一个变更请求。
计划——一项计划往往会带来大量的变更。计划管理必须通过相关的流程有效地与变更管理协调，例如，服务级别管理，能力管理等等。
所有其它的IT人员——原则上，任何人都可以提交意见以提高服务质量。特别地，IT人员对程序和手册的提高作出贡献。
1.3 变更请求（RFC）记录
下面是变更请求（RFC）中的包含的信息的例子：
• 变更请求（RFC）标识码。
• 相关联的问题/已知错误码（相关处）。
• 相关配置项的描述和验证。
• 包括调整和商业利益的变更的原因。
• 要被变更的配置项当前的和新的版本。
• 提交该变更请求（RFC）的人的姓名，地点和电话号码。
• 提交建议的时间。
• 估计的资源和时间计划。
2、验收
当变更请求（RFC）被记录后，变更管理将会作出一个初步评估以检查是否有变更请求（RFC）不清楚、不合理、不可行或者不必要。如果拒绝这项请求，需要说明原因；并给予提交请求的人解释的机会。
变更会导致配置管理数据库（CMDB）中数据的更改，例如：
• 现有配置项状况的变更；
• 配置项与其它配置项之间关系的变更；
• 新的配置项，或者现有配置项的变种；
• 配置项的新属主或地点。
如果变更请求（RFC）被接受，变更进一步处理所需的信息包含在变更记录中。接着，下面的信息会被加入到记录中：
• 指定的优先级；
• 对影响和所需成本的评估；
• 类别；
• 变更经理的建议；
• 授权数据和时间；
• 变更计划实施数据；
• 后援计划；
• 支持需求；
• 实施计划；
• 构建者和实施者的信息；
• 变更的实际数据和时间；
• 评价数据；
• 测试结果和观察问题；
• 拒绝请求（相关的）的原因；
• 情境和评价信息。
3、分类
一旦一项变更请求（RFC）被接受，它的优先级和类别也被指定。
优先级显示一项变更相对于其它变更请求（RFC）的重要程度，并且它来源于时间紧急度和变更的商业需求。如果变更关系到已知错误的更正，问题管理可能已经指定了它的优先级码。但是，考虑到其它正在处理的变更请求（RFC）后，变更管理分配最终的优先码。
变更管理基于变更对服务和资源可用性的影响决定变更的类别。如果变更请求（RFC）很可能失败，且可用资源也不充足，变更管理必须很谨慎地处理这项变更。
3.1 优先级的决定
以下是一个优先级码系统的例子：
• 低优先级 — 些变更很值得，但是需要等待很长时间，（如：下一次发布或者定期维护）。
• 一般优先级 — 没有很紧急或者重大的影响，但是变更不能被推迟。在CAB会议上，当分配资源的时候，给它分配了一般优先级。
• 高优先级 — 影响许多用户的严重错误，或影响大量用户的困难错误，或与其它紧急事件有关的错误。这种变更将在CAB的下一次会议上给予最高优先级。
• 最高优先级 — 变更请求（RFC）关注严重影响用户使用潜在服务的问题，或者紧急IT变更（如，商业原因新增的功能，紧急立法或不能等待的暂时安排）。具有这种优先级的变更被划分为紧急变更。如果可以使所要求的资源立即可用，紧急变更可以不遵循一般的程序。这可能要求召开CAB或者IT筹划指导委员会的一次紧急会议。特别为了这个目的，一次CAB/EC（应急委员会）需要召开，他们有权作出紧急决议。所有先前的计划都可能被延迟或中断。
这种优先级码可以与数字关联起来，如低优先级＝1/最高优先级＝4。
3.2 类别的决定
类别由变更管理决定，在与CAB的磋商中很有必要，它显示了变更的影响和IT组织的需求。以下是类别的一些例子：
• 次要影响——要求很低，且造成重大服务问题的风险也极低的变更。变更经理可以无须将它们提交给CAB，就批准这些变更。
• 实际影响——需要做大量的工作，且对服务有切实的影响的变更。这些变更在CAB会议上讨论以决定所需的工作和潜在的影响。在会议之前，相关的文档会在CAB成员，可能包括专家以及开发人员之间传阅。
• 主要影响——需要做很大量的工作，且会影响到组织的主要部分的变更。变更经理需要有IT管理或IT筹备指导委员会的优先级授权，在此之后，变更必须提交给CAB.
类别码可以与数字关联起来，如：次要影响＝1/主要影响＝3。
大部分变更都被归为前两类。除类别以外，致力于处理问题的小组和受变更影响的服务也必须指明。
4、规划和批准
变更管理使用变更日历或者变更进度计划表（FSC）来规划变更。FSC包括所有批准的变更和它们的计划实施数据细节。CAB成员商量裁夺重大的变更，人员，资源的可用性，成本，对服务的影响，并确保用户也参予进来。CAB像咨询委员会一样运作。变更管理拥有委托授权，它执行IT管理的工作。在提交CAB之前，主要变更可能必须经过IT管理层的批准。这种批准由三个方面组成：
最终批准——成本/优势分析和预算。
技术批准——影响，必要性和可行性。
业务批准——由要求变更和受变更影响功能的用户批准。
为了有效地规划，变更管理必须与项目小组成员以及其它创建和实施该变更的人保持密切联系。甚至，必须细心关注与有效变更规划联系，可能以变更进度计划表的形式。
4.1 变更策略
变更请求（RFC）可以组合到一个发布中。这种情况下，如果某事出错，单个备份计划就可以处理。这样大量的发布本身必须被看作是一项变更，即便是它包含很多每一个都可单独得到批准的变更。
发布可以为一些商业的功能性目的设计，典型的如应用维护发布。它们可以包括软件和硬件，且由发布管理实现。在这个领域定义策略，并把它与IT组织和顾客（也可能是发布管理）的联系起来，这种做法是很明智的。策略必须旨在避免对用户不必要的干扰（“每周都要掘路”）。
CAB与相关的IT 部门磋商之后，可以定义定时实施变更的窗口，它可以将对服务的影响最小化。最合适的时间是周末或者非上班时间。类似的，周期可以在很少或者没有允许的变更的时候确定，如在工作时间或者年终当所有的部门结束工作的时候。
4.2 CAB 会议
规划一项变更的信息必须在CAB会议之前发布出去。日程上相关的文档和信息必须在会议之前传阅。
CAB会议议程上有很多固定的条款，包括：
• 未授权变更
• 没有提交给CAB的授权变更
• 需要交CAB成员评估的变更请求（RFC）
• 开始或者结束变更
• 评价以往的变更
4.3 影响和资源估计
当估计变更的影响和所需资源时，CAB成员，变更经理和所有其它CAB定义的相关人员都必须考虑以下几个方面：
• 受影响服务的能力和执行
• 可靠性和可恢复性
• IT服务持续性管理
• 备份计划
• 安全性
• 变更对其它服务的影响
• 记录和批准
• 所需的资源和成本（支持和维护）
• 所需专家的数目和可用性
• 变更所需的周期时间
• 待出售和测试的新资源
• 对运营的影响
• 与其它任何变更的冲突
CAB成员也可以对优先级起作用。
5、协调
被批准的变更与相关的产品专家保持联系，他们可以创建和整合变更。变更在实施前要经过测试。发布管理在创建，测试，实施已批准的变更过程中起重要作用。同时，也要注意与计划中的变更的联系。
5.1 创建
不是所有变更都有明确的创建阶段。例如，标准变更如重新配置PC就是在计划之后立即实施。
创建可能包括产生新的版本、新的文档和手册、安装程序以及备份计划和硬件变更。变更管理负责控制和协调。发布管理和一线管理人员必须保证有足够的资源分配给计划的变更。
如果变更没有给出要求的结果，备份程序必须作为变更提交的一部分。如果没有备份程序，变更管理不能批准该变更。如果影响用户环境，必须有通信计划。变更计划也必须在创建阶段拟定。
5.2 测试
备份程序、变更实施和变更预计结果都必须全面测试。还必须考虑先前由CAB定义的标准。大部分情况下，需要独立的测试环境和测试实验室。虽然早期的测试可以由创建者完成，但是如果没有独立的测试，变更并不能实施。
测试通常有两种方式——用户验收测试，即业务小组（通常是变更用户）测试变更的功能，和运作验收测试，即必须由支持和维护基础架构变更的人进行的独立测试，包括技术支持领域和服务台。他们将测试支持文档、备份和恢复程序等。测试的质量和测试结果记载也需要清晰的说明。
5.3 实施
任何负责管理IT基础架构的相关部门都可能需要实施变更。变更管理确保变更处于变更进度表中。需要一个清楚计划显示谁必须知道变更，如，用户，服务台，网络管理等。
如果变更不能得到充分的测试，则可在少量用户中实施该变更，并在大规模实施该项变更之前对之前的小规模的实施结果进行评估以了解大规模实施该变更的合理性。
6、评价
鉴于标准变更可能出现的例外，实施过的变更需要进行评价。如果必要的话，CAB会决定是否需要重复评估。以下是需要考虑的问题：
• 变更是否达到预定的目的？
• 用户对结果是否满意？
• 是否有副作用？
• 是否超过预估的成本和代价？
如果变更实施成功，变更请求（RFC）就可以结束了。结果在实施后评审（PIR）或变更评价中。如果变更不成功，流程将采用修正后的方法，从出错的地方重新执行。一般情况下，最好是备份变更，并在原始变更请求（RFC）的基础上创建一项新的变更请求（RFC）。
继续执行一项不成功的变更往往会使情况更糟。特定时间限制内的评价程序有助于确保变更评价不被忽视。根据变更的本质，评价可以在几天或者几个月之后进行。例如，每天都会用到的PC的变更可以在几天之后执行，但是对于系统的变更，几个星期才会用到一次，仅需要在三个月之后评价。
7、紧急变更实施
尽管规划得很好，依然可能会有需要最对优先级的变更。紧急变更很重要，且必须尽可能快地执行。大多数情况下，分配给其它活动的资源都必须分给这些变更。紧急变更可以对计划好的工作有一系列影响。因此，目标是紧急变更或者意外变更（优先级为最高）的数目要尽可能小。预防措施包括：
• 确保变更在变成紧急变更之前，及时被请求；
• 当修复错误引起未准备好的变更时，没有先前版本，不能回复到先前错误状态。然后，就需要准备一种变更的改进实施策略。
尽管有上述措施，紧急变更还是可能发生，而且他们要求程序在变更管理不对流程失去控制的情况下尽快执行他们。如果有时间，变更经理可以组织一次CAB/EC的紧急会议。这种会议仅有特定的成员需要对其评价，授权，为其分配资源。如果没有时间或者请求发生在工作时间以外，就必须有获取授权的其它办法。CAB/EC不需要开面对面的会议，可以开电话会议以代之。
在事故管理流程中提到的例子中，一种应急措施可以用力解决一个严重的事故。如果情况严重且不允许延迟，可能需要启动紧急变更请求（RFC）程序。
变更发生之前也可能没有足够的时间做正常的测试，但是之后，正常流程所有必需的步骤都必须完成以保证任何以前跳过的测试现在都被执行，并且文档（变更记录和CMDB）也得到了更新，以保证“什么变更了？”是可记录的。
京ICP备06004481号 Copyright 2002 - 2006 ITGov.org.cn, All Rights Reserved