服务变更管理程序.docx
《服务变更管理程序.docx》由会员分享，可在线阅读，更多相关《服务变更管理程序.docx（9页珍藏版）》请在冰豆网上搜索。
服务变更管理程序
服务变更管理程序
文档编号：
密级：
版本信息：
V1.0
建立日期：
创建：
审核：
批准：
版权声明：
本文中的所有信息均为北京首都在线科技股份有限公司内部公开信息，未经北京首都在线科技股份有限公司明确作出的书面许可，不得传播。
文档修订记录
版本编号或者更改记录编号
变化
状态
简要说明（变更内容和变更范围）
日期
变更人
批准日期
批准人
V1.0
C
新建
*变化状态：
C――创建，A——增加，M——修改，D——删除
1
简介
1.1目的
通过变更管理流程，可以帮助所有实施IT变更的人员有一套规范的分步流程去更新或升级IT系统。
从而保证由于变更而引起的对IT环境的影响降到最小，提高IT系统和服务的质量，为业务的快速发展提供更优质的IT服务。
1.2适用范围
适用于IT服务项目有关的一个或多个特定配置项（CI）实施变更的管理。
变更管理流程涵盖客户IT系统的所有变更，包括：
●主机系统；
●PC服务器；
●业务系统；
●所有中间件，包括数据库；
●客户端（客户端相关设备的批量变更，遵循本变更过程；单个客户终端的变更，授权工程师直接执行变更）；
●网络设备（直接连接客户端的桌面端网络设备的变更，授权工程师直接执行变更）；
●相关安全系统；
●通信设备及其软件；
不包括：
●尚处于开发阶段的IT系统的变更；
●不需要服务项目组介入的由用户控制的行为动作；
●已有固定流程的轻微变更,包括口令更改，PC申请维护升级报废，个人用户IP地址申请更改，INTERNET申请，EMAIL申请等；
●不包括变更所需要的开发。
变更的部署将由发布管理过程管理。
●单个客户终端的变更，授权工程师直接执行变更；
●直接连接客户端的桌面端网络设备的变更，授权工程师直接执行变更
1.3术语表
变更分类：
是指在维护过程中对系统或服务做出的各种改变，包括增补、移除和其他修改。
变更按照设备及技术类型进行分类，以便分配任务。
编号
代码
描述
1
服务器
服务器及存储设备的硬件、操作系统
2
网络
路由器、防火墙、交换机、IP地址
3
应用程序
OA、Email系统等
4
桌面终端
桌面端相关问题，Office、病毒等
变更分级
根据变更的风险大小，给变更分级，以保证项目组对变更必要的重视，以下是变更分级的参考原则。
当变更符合高级别的某一项或多项时，即应该按该级别进行处理。
考虑项目
轻微变更
一般变更
重大变更
对其他系统或应用的影响
没有
1个相关系统或应用
多个相关系统或应用
回退难度
低
有回退措施，较易执行
很难或不可能回退
对业务的影响
基本没有影响
对业务有较大影响
对业务有重大影响
变更的难度
很容易，且有经验
比较容易，有一定经验
难，新技术，无经验。
紧急变更
变更必须很快得以实施，否则将严重影响服务的提供或SLA的达成。
所有必须在2天内完成的变更，视为紧急变更。
正常变更：
为满足一项或多项业务要求，可以在预定的期限内完成的变更。
通常要求的期限超过2天。
1.4引用文件
【1】《ISO/IEC20000-1》
【2】《IT服务管理手册》
2职责
2.1项目经理
●接受变更请求（RFC），并做初步筛选。
●确保变更请求（RFC）得到评估、授权、控制和计划。
●确保所有相关人员都足够程度地引入到变更请求的评估中。
●确保管理层得到足够关于变更的数量,影响度和成本的信息。
●成立变更委员会，并领导和主持变更委员会（CAB）。
●确保变更在符合组织风险和需求的情况下，并在适当的时间内实施。
●协调变更的构建／测试和实施。
●确保变更管理流程，制定相关工作步骤及准则。
●提供复杂变更请求（RFC）的项目管理。
●生成有效的管理报表。
●制定变更项目计划和时间规划等。
●更新项目记录，生成变更工单。
●在整个变更中协调各工单，以维护变更项目的整体性。
●确保变更在预定的时间，资源和成本内完成。
●在必要时，确保恢复计划（FallbackPlan）得以正确实施。
2.2变更委员会（CAB）
●评审所有提交的RFC,并确保它们的潜在影响和风险得到评估。
●针对具体变更请求，评估并分派相应资源。
●回顾所有已执行的变更，确保满足变更目的。
●参加CAB会议和紧急CAB会议。
●协助项目经理确定变更优先级及变更规划。
2.3变更实施人员
●根据项目经理制定的变更实施计划。
●执行分派的任务以推进变更项目。
●向项目经理汇报工作进程。
●现场负责变更实施。
3流程图
4具体内容
4.1变更请求
4.1.1请求者确定变更请求，填写《变更请求表》提交给项目经理。
4.2记录和过滤变更
4.2.1项目经理接受变更请求,检查变更请求的完整性和正确性，项目经理根据需要确定是否接受变更，项目经理接受变更请求之后，将变更请求登记到《变更管理表》当中。
4.3评估紧急程度
4.3.1项目经理和变更提交者一起按照1.3节“变更分级分类”判断所提交的变更是否为紧急变更。
如果为紧急变更，则按紧急变更流程执行。
4.4确定风险变更等级
4.4.1项目经理和变更提交者一起按照1.3节“变更分级分类”判断所提交的变更的风险等级。
如果为一般变更，则由项目经理负责批准和授权。
如果为重大变更则由项目经理负责召集变更委员会进行讨论。
4.5影响和资源评估
4.5.1对于轻微和一般变更，由项目经理确定变更对服务的影响以及变更使用资源的估计。
4.5.2对于重大变更，由项目经理召集变更委员会讨论，确定变更对服务的影响以及变更使用资源的估计。
4.6批准
4.6.1对于轻微和一般变更，由项目经理决定是否批准该请求变更。
4.6.2对于重大变更，由项目经理召集变更委员会讨论，是否批准该请求变更。
4.6.3如果批准，则进入制定变更计划阶段。
如果拒绝变更请求，则由项目经理与变更请求者进行沟通。
4.7计划变更
4.7.1项目经理安排人员与发布管理、配置管理协同工作确定变更计划，并在《变更管理表》中确认变更计划的执行日期。
4.8构建/测试和实施变更
4.8.1构建阶段所需要完成的主要内容：
4.8.1.1新的版本；
4.8.1.2新的文档和手册；
4.8.1.3安装程序；
4.8.1.4备份计划；
4.8.1.5变更的硬件；
4.8.1.6回退计划；
4.8.1.7变更计划；
4.8.2变更管理在创建阶段负责控制、协调相关工作，必须完善《变更请求表》及相应的说明文件；
4.8.2.1完整的《变更请求表》应传递给发布管理，并与发布管理及相关部门协调完成各项工作。
发布管理及相关部门必须确保有足够的资源分配给已经计划的变更。
4.9测试
4.9.1测试内容可以包括：
支持文档、备份计划、恢复程序、回退计划、变更实施、变更预期结果。
4.9.2通过全面的测试改进并确定后续实施计划。
4.9.3对于因资源问题，不能进行测试的，应在变更前提供必要的回退措施或应急预案。
4.10发布
4.10.1将经过测试的变更发布到实际运行系统，项目经理根据实际需要制定发布计划。
4.11评估变更
4.11.1在变更实施后，按变更的风险级别由项目经理或变更委员会对变更的绩效和改进记录进行评审，评审结果应妥善保管并作为服务改进计划的输入。
4.12关闭变更
4.12.1变更成功后，更新变更记录并通知配置管理。
4.12.2从配置管理得到关于本次变更的配置变更确认后关闭变更请求。
4.13紧急变更
4.13.1项目经理和变更提交者一起按照1.3节“变更分级分类”判断所提交的变更是否为紧急变更。
如果为紧急变更，则按紧急变更流程执行。
4.14变更管理过程的KPI
4.14.1变更管理流程设定如下几个方面的衡量标准：
4.14.1.1每季度处理的每一类型的变更数量
4.14.1.2每季度执行恢复计划（Fallbackplan）的变更数量
4.14.1.3变更实施的成功率
4.14.1.4紧急变更所占的比率
4.14.1.5被拒绝的RFC的数量或比例
4.14.1.6由变更引起的非计划宕机时间
4.14.1.7项目经理就以上信息形成《服务月报》。
5输出的文件和记录
《变更请求记录》
《变更管理表》
《服务月报》
《发布计划》
升级会员 