变更管理流程.docx
《变更管理流程.docx》由会员分享，可在线阅读，更多相关《变更管理流程.docx（25页珍藏版）》请在冰点文库上搜索。
变更管理流程
变更管理流程
版本：
V1.0
目录
1内容范围3
2变更管理概述4
3变更管理目标5
4术语定义6
5主要角色及职责7
6流程描述9
6.1变更管理主体流程9
6.2变更请求子流程10
6.3变更分类子流程11
6.4紧急变更子流程12
6.5重要变更子流程14
6.6标准变更子流程16
6.7变更许可子流程17
6.8变更开发子流程18
6.9变更回审子流程19
7流程中涉及的定义及标准21
7.1变更来源21
7.2接受变更请求的标准21
7.3变更优先级标准22
7.4变更类别标准22
7.5变更review标准22
7.6测试方法23
8变更状态跟踪与记录24
8.1变更状态24
8.2变更记录24
9与其他流程的关系26
10工具与方法27
11衡量指标27
12流程改进28
13相关文档29
14附录29
1内容范围
本文档内容包括：
1.变更管理概述：
从整体的角度对变更管理进行简要的描述。
2.变更管理目标，描述突发变更管理流程所要达到的目标。
3.术语定义：
在本文档中出现的关键术语的说明。
4.主要角色及职责：
描述在变更管理活动中各主要的角色及其所担负的职责和活动。
5.流程描述：
包括变更管理主体流程与各子流程。
主体流程中包括流程图，各阶段的活动描述及输入、控制和输出；子流程包括详细活动的流程图和流程描述。
6.流程中涉及的标准：
包括流程中用来进行判断，分类，分级以及升级的标准。
7.变更记录与状态跟踪：
包括变更各阶段，应该记录的内容；变更的状态与状态跟踪。
8.与其它流程之间的关系，描述为其他流程提供的输出，及其他流程的输入。
9.工具与方法：
描述该流程将用何种工具来进行具体操作。
10.衡量指标，定义衡量管理绩效的指标。
11.流程改进，定义流程回顾和改进方法。
12.相关文档：
与本文档相关联的一些文档。
13.附录：
文档主体中涉及的记录表单等。
2变更管理概述
本文档规定了运维中心应用系统运维项目变更的操作方法，目的在于明确各部门在变更管理过程中的职责，加强变更管理，提高变更处理准确率，减少数据变更对生产环境可能造成的影响。
通过降低因实施不期望发生或未授权的变更引发的风险来提高质量。
通过全面跟踪所有变更请求来改进追责机制。
变更管理流程目的是确保变更请求，或服务请求能得到快速解决，恢复服务。
记录确保没有遗漏的变更或服务请求，允许记录得到跟踪，并提供帮助问题管理和活动计划的信息。
服务请求，例如变更请求（RFC）或文档请求等，也按照该类流程进行记录然后处理。
3变更管理目标
变更管理目标是确保在变更实施的过程中使用标准的方法和步骤，从而以最快的速度实施变更，将由变更所导致的业务中断的影响减少到最低。
变更管理专注于对运维中心IT架构和应用程序实施可控的变更，此流程的目标是确定所需的变更，并决定这些变更如何在对运维中心IT服务产生最小的不利影响的范围内得以实施，同时确保其变更是可追溯的，而且是经过整个组织内部有效地磋商和协调的，在客户组织提交变更请求后，由配置管理流程监控其状态，与问题管理和若干其它流程进行协调，变更实施履行一个特定的路径，包括定义、计划、建立、测试、接受、实施、和评估。
4术语定义
下面是变更管理流程中的关键术语：
变更：
加入IT环境的一切新增IT组件，要么对IT服务级别产生影响，或对公司IT环境或它的某一部分产生影响。
变更类别：
变更部署对公司IT管理和业务运营产生影响的衡量指标。
为确定变更类型，需要将对变更复杂程度和所需资源（包括人员、资金及时间）加以衡量。
此外，部署风险（包括可能发生的服务中断）也是一个影响因素。
变更实施人员:
负责在IT环境下计划并实施变更事项的人员。
变更实施人员由变更管理人员将变更事项指派给变更实施人员，变更实施人员在收到已经核准的RFC的时刻起承担相关职责。
变更实施人员必须遵循业经核准的变更时间安排。
变更优先级:
决定变更请求核准与实施速度的变更分类等级。
需求的紧迫性和不实施变更的业务风险是确定优先级的主要标准。
配置项（CI）:
受配置管理职能控制的IT组件。
每个CI都可能由其他的CI组成。
大到整个系统（包括全部硬件、软件和文档），小到单个软件模块或次要硬件组件，不同CI的复杂程度、大小和类型可能存在很大不同。
发布:
由一个或多项变更组成的方案，其中包括已通过测试并被引入生产环境的新增或变更配置项目。
变更请求（RFC）:
这里指正规变更请求，包括针对变更的描述、受到影响的组件、业务需求、成本估算、风险评估、资源需求及核准状态等信息。
5主要角色及职责
变更管理流程的角色主要有：
变更评审小组、变更发起人、变更经理、变更实施人员、紧急变更小组和审计人员。
角色名称
职责描述
责任人
变更评审小组
CAB
评估并核准针对生产环境的变更；
客户、运维经理、技术线
审核整个变更程序的变更状态；
评估已核准计划的进度；
确定如何纠正已发现的问题；
与适当的主管及利益关系人沟通发现的问题，包括他们所代表的IT执行委员会；
针对具有特殊优先级的紧急变更事项做出授权或予以否决；
负责评价变更请求、优先级别、成本/效益指标以及对其他系统或过程的潜在影响；
针对变更请求提出付诸实施、深入分析、暂缓实施或彻底否决等建议；
推动变更管理流程的效率和效力；
变更回审。
变更发起人
发起变更；
客户、运维内部
依照程序提交RFC；
协助变更管理人员更新RFC；
在后期审核过程中提供意见。
监视所有未完成的变更的状态和进度。
变更经理
接收RFC并确保将它们正确记录在变更日志当中；
审核、更新并验证RFC；
选择CAB成员并使CAB会议顺利进行；
准备CAB会议议程并在召开委员会会议前将所有必要的审核信息提供给CAB成员；
指派团队来执行RFC影响分析与风险评估；
将CAB无法决定的RFC上报至IT执行委员会；
针对RFC执行分析、排定优先次序、实施分类并制订计划；
除非同样是紧急变更，否则将其核准为次要变更；
为变更发起人及其它相关各方提供变更通知；
监督所有RFC的顺利完成，以确保所使用的程序可以依照变更计划；
审核并评估变更程序；
更新变更信息，为其他人员提供变更过程和测试结果记录；
让受影响的用户了解进度。
变更实施人员
接收来自CAB的已核准变更；
一线人员、二线人员
依照CAB核准的变更日程计划；
在各变更开发项目阶段之间进行（适当）协调；
为变更管理人员和CAB提供项目状态反馈意见；
确定所造成的问题；
与变更发起人共同协作以确保变更符合变更发起人的需求；
报告状态并将发现的问题提交至CAB；
准备并主持后期评审；
让受影响的用户了解进度。
紧急变更小组CAB
评估和核准针对生产环境的紧急变更；
紧急变更的鉴别，审核整个变更程序的紧急变更状态；
监督重大紧急变更的进展，协调资源；
参与重大紧急变更的审查；
更新紧急变更状态的CAB；
审计人员
定期或不定期检验变更的工作流程、制度、指标是否与预期的结果一致；
把检查的过程、结果记录在案，形成审计报告，提交给变更管理人员；
通过审计发现的问题，审计人员要协助问题负责人进行解决，参与解决问题的方案讨论、评估与实施。
6流程描述
变更管理流程是贯穿整个变更过程的整个生命周期，从变更的发起、变更方案的确定、变更分析及测试、变更的实施、回滚与恢复，直至变更过程结束。
变更管理主体流程
变更管理流程主体过程的活动如下描述：
活动
描述
责任人
输入
控制
输出
6.1.1变更发起人
相关的人、相关的过程都可以作为变更发起人，例如突发变更、问题管理、客户、内部人员等
用户
变更请求内容
变更请求内容
6.1.2变更请求
变更发起人依据程序和格式提交RFC
变更管理人
RFC内容
接收RFC并确保将它们正确记录在变更日志当中；
审核、更新并验证RFC
RFC记录
6.1.3变更分类
识别变更类型，
变更管理人员
RFC记录
判断是紧急变更还是标准变更等；
选择CAB成员并使CAB会议顺利进行
RFC记录、类别；
变更方案；
变更计划
6.1.4变更许可
审核和批准变更计划
CAB
RFC记录、类别；
变更方案；
变更计划
CAB评估并核准针对生产环境的变更；
审核整个变更程序的状态；
评估已核准计划的进度；
CAB的已核准变更；
CAB核准的变更日程计划；
6.1.5变更开发
按照已核准的变更计划和方案进行开发
变更开发人员
变更计划；
变更方案
开发方案设计、
回滚方案设计
方案测试；
回退计划
开发报告；
测试报告
6.1.7变更回审
对变更实施后的结果进行回顾、评审
CAB；
审计人员
实施完成报告
比对实施结果与计划的偏差
审计报告；
回审报告
变更请求子流程
变更请求需要一定的程序和格式。
具体子流程如下：
流程描述：
1.变更申请人根据业务或管理需要，按照规定的格式和内容填写变更申请单RFC；
2.将申请单提交给变更经理。
3.变更经理对RFC的内容和格式进行审定，如果RFC内容不够完整，则变更管理人员会要求申请人完善RFC。
4.如果变更经理觉得变更申请没有问题则通知申请人其申请通过初审并进入变更分类流程。
变更分类子流程
流程描述：
1.变更申请通过初审以后，变更管理人员需要对变更申请按照分类标准进行分类，并进行登记；
2.如果属于紧急变更，则进入紧急变更流程；
3.如果属于重要变更，则直接进入重要变更流程；
4.其余变更均进入标准变更流程。
紧急变更子流程
流程如下图：
流程描述：
1.如果变更经理确定变更是紧急变更，会组织CAB成员进行评审；
2.CAB成员需确认和定义评审规则；
3.CAB成员对RFC进行评审；
4.如果RFC信息不全，则要求其他相关人员提供足够的信息；
5.如果认定不是紧急变更，则返回变更分类流程对变更重新分类；
6.如果是紧急变更，则进入变更许可流程，此次主要审批是否做变更；
7.如果在变更许可流程中，变更未得到批准，则在变更许可流程做出处理，不再进入该流程；
8.如果在变更许可流程中，变更得到批转则通知申请人；
9.变更批准后，进入变更开发流程；
10.变更开发完毕后，则需再次进入变更许可流程，此次主要审批变更开发是否可以发布；
11.如果变更开发得到未得到批准，则需重新开发，此步骤会在变更许可流程中体现；
12.如果变更开发得到批准，则进入发布管理流程；
13.变更发布完成后，进入变更回审流程。
重要变更子流程
流程如下图：
流程描述：
1.如果变更经理确定变更是重要变更，会组织CAB成员进行评审；
2.CAB成员需确认和定义评审规则；
3.CAB成员对RFC进行评审；
4.如果RFC信息不全，则要求其他相关人员提供足够的信息；
5.如果认定不是重要变更，则返回变更分类流程对变更重新分类；
6.如果是重要变更，则进入变更许可流程，此次主要审批是否做变更；
7.如果在变更许可流程中，变更未得到批准，则在变更许可流程做出处理，不再进入该流程；
8.如果在变更许可流程中，变更得到批转则通知申请人；
9.变更批准后，进入变更开发流程；
10.变更开发完毕后，进行变更测试。
11.如果测试不成功，则重新进行变更开发，如果测试成功，则再次进入变更许可流程，此次主要审批变更开发是否可以发布；
12.如果变更开发得到未得到批准，则需重新开发，此步骤会在变更许可流程中体现；
13.如果变更开发得到批准，则进入发布管理流程；
14.变更发布完成后，进入变更回审流程。
标准变更子流程
流程如下图：
流程描述：
1.如果变更经理确定变更是标准变更，则直接进行变更开发；
2.变更开发完毕后，进行变更测试，测试时需要给出详细的测试用例，并在准生产环境进行测试，如果需要除进行功能测试外还可进行压力测试。
3.如果测试不成功，则重新进行变更开发，如果测试成功，则再次进入变更许可流程；
4.如果变更开发得到未得到批准，则需重新开发，此步骤会在变更许可流程中体现；
5.如果变更开发得到批准，则进入发布管理流程；
6.变更发布完成后，进入变更回审流程。
变更许可子流程
流程如下图：
流程描述：
1．XX变更指的是紧急变更、重要变更、标准变更中的一个；
2．CAB成员在对变更评审前需先判断是否有权限许可变更，如果没有则升级至IT执行小组，由IT执行小组来判断；
3．如果有权限许可变更，则对变更进行影响分析和风险评估；
4．然后CAB成员对RFC进行投票决策；决策策略有三种：
A．全部通过则变更许可通过
B．只要有一个通过则变更许可通过
C．通过票数大于不通过票数则变更许可通过
5．如果CAB成员不能对变更申请作出决策，则升级至IT执行小组，由IT执行小组来判断；
6．如果变更被批准则重新返回XX变更流程，如果变更没有被批准，则关闭变更或重新提交。
变更开发子流程
流程如下图：
流程描述：
1.进入变更开发流程，变更经理确定变更负责人，并由变更负责人制定变更计划和方案。
2.进行开发方案设计、回滚方案设计、开发、开发和回滚测试等环节。
3.变更方案和回滚方案准本完毕，则可以进入XX变更管理。
变更回审子流程
流程如下图：
流程描述：
1.变更发布以后，CAB要对变更的实施效果进行回审，主要审核该变更在生产环境下运行的效果和运行效率，以及一段时候内，生产环境是否稳定，变更是否引起其他问题或异常。
2.如果与变更的目标相符则在变更记录上作登记，关闭RFC，变更流程结束，如果该变更是问题管理引发则需把变更结果返回给问题管理。
3.如果效果不好需要回滚，则进行回滚，在变更记录上作登记，转入问题管理流程。
4.如果不需要回滚，则考察该变更中是否还有其他未处理的RFC，如果有，就更新变更记录，关闭该RFC，同时重新转入变更请求流程。
5.如果没有其他未处理的RFC，则关闭该RFC，流程结束。
7流程中涉及的定义及标准
变更来源
变更请求（RFC）可能涉及所有业务流程。
任何相关的人都可以提交一项变更请求（RFC）。
可能的变更请求（RFC）源包括：
1.问题管理——提交解决办法以消除错误，稳定服务的交付。
2.用户——可能请求更多、更少或者其他服务。
这些请求可能像变更请求（RFC）一样被直接提交。
或者通过服务台、服务级别管理或IT客户关系管理引导。
3.建立规章制度——如果有关业务的新法规、规章制度出台，或者为了IT安全，业务持续性和许可证管理引入新的需求，则需要变更管理流程控制它。
4.供应商——供应商发布新的版本并更新他们的产品，确定他们所补救的错误。
他们可能告知，表示不再支持某些版本，或者某个版本的执行不安全。
这可能引发问题管理或可用性管理提出一个变更请求。
5.计划——一项计划往往会带来大量的变更。
计划管理必须通过相关的流程有效地与变更管理协调，例如，服务级别管理、能力管理等。
所有其他的人员——原则上，任何人都可以提交意见以提高服务质量。
特别地，当IT人员需要对程序和手册进行更新时和业务处理人员声和变更数据时。
接受变更请求的标准
首先，所有的变更请求（RFC）都必须记录下来并记入日志。
当一个变更请求（RFC）被提交去处理问题，然后记录下已知错误的数目。
1.变更请求（RFC）标识码。
2.相关联的问题/已知错误码。
3.相关配置项的描述和验证。
4.包括调整和利益变更的原因。
5.要被变更的配置项当前的和新的版本。
6.提交该变更请求（RFC）的人的姓名、地点和电话号码。
7.提交建议的时间。
8.估计的资源和时间计划。
变更优先级标准
在变更管理程序中，紧急程度取决于业务单位要求的变更实施速度。
针对优先级的设定提议共分三档：
1.紧急——如不立即实施变更，将导致企业面临重大风险。
例如，应用安全修补程序。
2.重大——对企业具有较高重要性的变更，必须尽快执行。
例如，为适应最新法规要求而实施的升级。
3.中——应当执行的变更，旨在通过调整支持服务谋求收益。
例如，针对客户反馈服务应用不同升级版本。
4.低——虽不紧迫但有价值的变更。
例如，针对用户配置文件附加“建议选配”信息。
紧急变更实行紧急变更流程，重大变更实行重大变更流程，其他实行标准变更流程。
具有紧急优先级的变更请求为确保变更得到尽快实施而采取了不同的审批程序。
这种优先级仅限应用于以下变更事项：
如不尽快实施就会对服务水平构成严重影响或导致企业付出更大代价。
由于实施紧急变更会导致风险增大，因此，应尽量避免提出紧急变更请求；对紧急变更请求的使用无法替代细致周密的计划工作。
变更类别标准
我们根据变更内容对变更进行分类：
1.数据变更——生产系统中有任何数据需要从后台进行修改的变更。
2.硬件变更——对生产系统中的硬件进行的变更。
3.版本升级——生产系统中应用软件的版本升级变更。
4.文档变更——对生产系统中的文档进行的变更。
5.其他变更——不属于上述四类的变更。
变更review标准
变更项目一旦成功发布并部署至生产环境，有关方面就应执行评审程序，以判断变更是否获得预期效果，是否达到最初要求。
1.基础架构方面——变更实施期间是否出现过技术或容量方面的问题。
2.操作运转方面——变更实施期间或变更完成之后是否出现过操作运转方面的问题。
3.合作伙伴方面——变更项目是否曾导致与第三方或合作伙伴之间的摩擦。
4.发布方面——变更项目采取何种途径通过变更管理流程，可从中汲取哪些经验。
5.安全保障方面——变更项目是否导致安全问题明朗化。
6.支持方面——变更实施期间或变更完成之后是否出现过明显的支持能力问题。
7.服务方面——变更实施期间或变更完成之后是否出现过违反服务级别约定的情况。
测试方法
测试时需要给出详细的测试用例，并在准生产环境进行测试，如果需要除进行功能测试外还可进行压力测试。
测试通常有两种方式：
1.用户验收测试——即业务小组（通常是变更用户）测试变更的功能。
2.运作验收测试——即必须由支持和维护基础设施变更的人进行的独立测试，包括技术支持领域和服务台。
他们将测试支持文档、备份和恢复程序等。
测试的质量和测试结果记载也需要清晰的说明。
8变更状态跟踪与记录
变更状态
变更的状态一般分为：
请求阶段、评估阶段、开发阶段、测试阶段、发布阶段、发布后review阶段。
变更记录
变更请求表，是变更请求的载体，是需要变更的客户与变更管理经理的信息媒体。
它主要有以下几个部分组成。
在变更初始阶段，变更请求表需要记录：
1.变更请求号，如果与问题管理相关，还需要记录相关的问题号。
2.变更描述。
3.变更原因。
4.不实施变更，可能带来的后果。
在变更评估阶段，变更请求表主要需要记录：
1.影响和风险评估：
影响可以围绕变更管理质量和变更管理带来的好处等实际情况进行设置，例如，可以进行变更管理对项目总进度，项目质量，项目资源等等多个角度，进行影响和资源评估。
2.变更优先权：
在进行影响和风险评估后，可以进行变更优先权的设置。
在变更批准阶段，变更请求表主要需要记录：
3.变更咨询委员会的建议和决定。
变更咨询委员会是来自于企业的各个部分，有利于综合、客观地价变更对于企业其他部门的影响。
4.批准签名，也可以使用电子方式。
5.批准的日期
在变更开发阶段，变更请求表主要需要记录：
1.变更开发计划，用于详细说明如何根据变更需求进行开发，必要时候，也可以独立于变更请求表。
2.变更开发负责人。
3.变更开发开始执行时间和完成期限。
4.回退方案，一旦开发内容发布失败，就需要回退方案回退至变更前的生产环境。
在变更测试阶段，变更请求表主要需要记录：
1.变更测试计划，用于详细说明如何进行变更测试，必要时候，也可以独立于变更请求表。
2.变更测试负责人。
3.变更测试开始执行时间和完成期限。
在变更发布阶段，变更请求表主要需要记录：
1.变更发布计划，用于详细说明如何进行变更，必要时候，也可以独立于变更请求表。
2.变更发布负责人。
3.变更发布开始执行时间和完成期限。
4.发布是否成功，如果发布失败是如何回退的。
在变更发布成功一段时间后，变更请求表主要需要记录：
1.变更核查日期（reviewdate）
2.核查结果。
3.企业在连续性等方面影响。
如果核查结果显示此次变更是失败的，则将根据现有情况，进行新的变更管理；如果核查结果认为此次变更是成功的，则变更管理结束。
9与其他流程的关系
变更管理和其他流程的关系如下图所示：
1.变更管理
变更管理与变更管理有两方面的关系。
一方面，变更管理处理变更管理请求的变更从而抵消变更的影响。
另一方面，尽管采取了很多预防措施，变更的实现还是会导致错误和变更。
这些可能与变更执行的不好有关，或者与没有为变更做好充分准备的用户有关。
变更管理的相关人员必须明白变更的执行，这样可以很快确定和补救任何相关的变更。
2.配置管理
变更管理和配置管理紧密相关，因此这两个流程可以有效地结合起来，这一点在ITIL服务支持书籍中也得到推荐。
在配置管理的控制下，变更被记录下来，同时，变更影响度分析也被记录；配置管理确立了变更正在处理的配置项和其他配置项之间的关系，显示变更将影响到什么。
3.问题管理
变更管理和问题管理的关系很像变更管理和变更管理的关系。
一方面，变更往往被要求去纠正错误，解决问题。
另一方面，如果变更的实现没有得到很好的控制，变更会导致新的错误，引发新的问题。
4.发布管理
变更经常会引起一系列应用系统或者技术架构的开发和分发。
许多影响IT应用系统或处于基础设施同一区域的变更也被整合到一个包发布，由发布管理统一管理。
通常，它会带来更彻底的测试和沟通等好处。
新发布的上线由变更管理控制。
5.服务级别管理
服务级别管理关注变更对服务和业务流程的影响。
鉴于这种情况，服务级别管理可能在CAB中声明。
如果一个变更会带来较大的影响或者高风险，它的实现和时间必须与用户进行讨论决定。
变更管理向服务级别管理提交服务计划可用性报告，在这个报告中，变更管理列出对现有服务级别协议的改变和对服务可用性中变更进度计划表的影响。
6.可用性管理
可用性管理发起旨在提高服务可用性的变更。
如果真的得到了提高，它也会进行验证。
可用性管理经常包括在估计变更的潜在影响中，同样地，影响会对服务的可用性起作用。
7.能力管理
能力管理首先必须考虑到变更长时间的累积效应，例如，相应时间的增加和更多处理的需求，网络或存储能力。
在能力计划的基础上，能力管理将有规律地以变更请求（RFC）的形式提议增加或者变更，以提高现有能力的使用，并对其进行扩展。
8.IT服务持续性管理
确保
升级会员 