ITIL变更管理流程.docx
《ITIL变更管理流程.docx》由会员分享,可在线阅读,更多相关《ITIL变更管理流程.docx(15页珍藏版)》请在冰点文库上搜索。
![ITIL变更管理流程.docx](https://file1.bingdoc.com/fileroot1/2023-5/22/60247002-c895-4629-9c71-94836066b836/60247002-c895-4629-9c71-94836066b8361.gif)
ITIL变更管理流程
生产系统变更管理流程
一、目标
变更管理的目标是通过规范生产系统变更实施的流程步骤,来减少变更对BOSS生产系统的影响,减少因变更带来的问题,提高系统的稳定性,并确保变更的顺利执行。
通过变更管理流程,实现:
∙将变更的风险控制在可接受的范围内
∙对用户的影响最小
∙采用合适的控制手段
∙保护其它系统不受影响
二、适用范围
该流程适用于下列变更:
∙系统硬件和软件的变更
∙生产系统上应用软件的变更
∙网络硬件和软件的变更
∙日常作业运行时间的变更
∙对外部造成影响的环境变更
∙各种配置和参数的变更
∙生产文档的增加和更新
变更领域
描述
系统软件/网络软件
产品安装/升级/维护
系统任务安装/删除
系统硬件/网络硬件
安装/升级/维护/搬迁/删除
应用软件
安装,升级,维护,修改,增加
日常作业运行时间的变更
日常定时启动的任务改变启动时间
环境
电力系统,空调,建筑物,布线
配置和参数的变更
对主机、数据库、存储设备
文档/流程
生产文档的创建/更新/停用
生产管理流程的创建/更新/停用
除了以上的定义,符合下列条件之一的变更都需要遵循此变更管理流程:
∙安装时或安装失败回退时需要系统操作员参与的变更
∙对用户使用有影响的,需要通知用户的变更
∙安装时或安装失败回退时将引起BOSS提供的服务停止或某些功能停止的变更
∙日常操作,包括自动化操作的变化,如备份周期的变化
∙系统配置的变化
∙对容量规划有影响的变化
∙对灾难恢复计划有影响的变化
三、相关定义
1.变更原因
需要说明为什么进行变更。
在某些情况下可能是基于下列多种原因而进行变更,请选择最主要的原因。
变更原因
说明
业务
业务发展(新业务)
信息
只是为了提供信息
预防
预防性维护
科技
技术的发展/新的版本
容量
增加容量
性能
提高系统性能
问题
出现问题,进行修复
用户请求
用户提出申请
2.变更优先级
变更的优先级是指如果没有实施此变更,则会对业务造成多大影响。
优先级
说明
高
不能更改日期,必须按期完成
中
可以改变日期,但会有一定的风险
低
可以改变日期,没有风险
3.变更风险
当确定一个变更的风险时,需要考虑以下因素:
∙变更成功的可能性
∙因变更而带来问题的可能性
∙变更失败后,恢复的难易程度
∙对于用户和员工的影响
∙变更实施的复杂性,需要什么样的配合
∙如果变更失败,受影响的人数
风险
条件
说明
E(紧急变更)
●会对很多用户造成影响/必须得到领导批准
●
●
必须立即进行变更。
通常此类变更是为了解决系统问题,或为了防止某种重大问题的出现而改变系统的状况。
1
高风险/影响大
-系统不能工作
-可能会带来后续的问题
-变更失败后的恢复很难或根本无法恢复
-变更失败会对业务造成影响
-变更实施流程从未实践过或不可重复
-如果变更失败,使用该系统的所有用户将受影响
2
高风险/影响小
-系统不能工作
-可能会带来后续的问题
-变更失败后,需要通过恢复流程恢复
-变更失败会对业务造成影响
-变更实施流程从未实践过或不可重复
-如果变更失败,使用该系统的大多数用户将受影响
3
中度风险/影响小
-系统可能不能工作
-可能会带来后续的问题
-变更失败后,恢复不难并且恢复的成功性高
-变更失败会对业务造成一点影响
-该变更流程已被采用过多次,或该流程非常简单
-如果变更失败,使用该系统的少部分用户将受影响
4
低风险/没有影响
-系统能工作
-变更对用户没有影响
-变更失败后的恢复流程一定会成功,并且恢复流程对用户没有影响.
-变更失败不会有任何影响
-在相同的环境中,类似变更已被成功实施多次
-如果变更失败,使用该系统的用户不会有任何影响
4.角色和职责
变更管理协调员
负责管理变更管理流程,更新流程文档,监督流程的执行,管理变更管理工具,保存变更记录,制作变更报告。
作为变更管理流程的协调人,确保所有的变更请求都是合理的,并严格按照变更管理流程执行:
∙合理安排变更时间,确保不同时进行互相冲突的变更
∙根据变更的内容、变更所涉及的系统指派变更审查人员
∙在需要的时候组织变更前以及变更后的协调会
∙在需要的时候,通知审查人员,并协助获得审查人员的批准
∙确保获得所有的批准,并保存这些批准信息
∙如果变更引发了系统停机等问题,协助通知受影响的用户
∙每月提交变更管理报告
变更申请人
经授权可以通过变更管理工具提交变更申请的人。
∙在变更管理工具中填写:
-详细变更计划,包括每个变更步骤
-回退方案,测试方案等
-受影响的用户
∙指明变更的执行人,回退方案的执行人
∙指明变更执行情况汇报人
∙写明需要配合此变更的系统和人员,以及此变更将会影响的系统和人员
∙必要时提供相关的批准文件
∙获得批准人的批准
批准人
变更申请人的经理或该经理的授权人批准变更申请。
∙审查和支持此变更,确定变更是否必须进行
∙明确变更的影响
∙如果认为不需要进行此变更,或变更申请中有不正确、不合适的地方,驳回变更申请
审查组
受到变更影响的系统以及变更范围内的系统的维护人员。
变更管理协调员将协调并获得他们的审核和批准。
∙研究确定是否需要进行此变更
∙评估变更的影响,批准或驳回变更
∙审查是否有多个变更之间的冲突
执行人
将具体执行变更的人员。
∙确保在进行变更前,有变更申请记录、变更号,并且获得了所有相关的批准
∙协调变更相关的工作
∙按照变更记录中的变更计划实施变更
汇报人(可以和执行人是一个人,也可以指定另外一个人)
负责汇报变更过程中实施状况和具体时间的人员。
∙与变更执行人一起根据变更记录中的变更计划实施变更
∙报告变更相关信息,包括每一步的详细信息/状态/时间等
四、总体流程
五、流程说明
1.提交变更申请
变更申请人在提交变更申请前需要确保该变更做好了充分的计划和测试。
如变更涉及BOSS系统开发商,则由变更协调人负责与开发商联系,具体沟通方式同新业务开发。
开发商应提交具体的变更方案、测试计划、实施计划、回退计划和人员安排。
最终由变更申请人在变更管理工具中或以文档方式提交变更申请表.
为了确保所有变更申请在实施变更前都得到了相应的评估和批准,申请人需要提前1-2个星期提交变更申请。
(风险级别为E,即紧急变更除外)
2.可行性审批
计费部经理作为变更的批准人,负责审核变更的必要性、合理性和可行性,批准或拒绝变更。
批准人填写变更审批表中的变更可行性审批部分,并发送给变更协调员。
若变更被拒绝,则由变更协调人负责与申请人沟通,由申请人重新填写申请并做适当的修改,重新获得相关的批准。
若涉及开发商,则由变更协调人与开发商继续沟通。
对于紧急变更,可以先获得经理的口头批准,但是事后需补交相关申请。
批准人应在接到申请后2日内给出审批意见.
3.方案评估
由变更管理协调员组织会议,召集变更审批组就变更方案和变更细节以及变更实施时间等各方面进行讨论审批,变更申请人需列席会议.评审人员需确保此变更不会与任何系统有任何冲突。
评估小组在取得一致性意见后,需填写变更审批表中的变更方案审批部分,如果评审小组拒绝此变更,则必须将拒绝原因写入变更审批表,并发送给变更协调员。
若变更被拒绝,则由申请人修改方案.若涉及开发商,则由变更协调人与开发商继续沟通,修改后方案需再提交审批小组审批。
审批小组应在接到申请后2日内给出审批意见.
根据审批时限,变更管理协调员需要提醒评审人尽快审核、批准。
在必要的时候,变更管理协调员提醒变更申请人执行相关流程。
4.主管领导审批
审批小组通过变更方案后,需报请计费业务中心主管领导审批。
只有获得领导批准后才可以实施变更。
主管领导需填写变更审批表中实施审批部分,在接到申请和审批小组审批意见后2日内给出审批意见,就最终是否实施变更给出明确批示.
5.发布变更通知
若变更获准实施,则由变更协调人在变更实施前2日向全中心发布变更通告.若变更实施会对外部造成影响,则需同时向相关部门发布变更通知.
6.实施变更
只有在获得所有批准后才可以开始变更。
变更执行人必须是计费业务中心人员,其他任何人都禁止对BOSS系统进行任何变更操作.若变更实施需要开发商配合,则开发商必须安排技术人员按时到场配合.
变更执行人必须严格按照获得批准的变更计划的步骤实施变更,由变更报告人在执行过程中随时填写变更执行表.
若变更过程中出现问题,在明确错误原因和解决方法的情况下,报请计费部经理批准后,可临时制定变更方案,按新方案继续执行.若原因不明或需要对方案作较大修改,则必须立即停止变更执行过程,启动应急回退方案,将系统回退到变更前状态.
变更符合以下条件则认为是成功的:
-在变更实施过程中未遇到问题
-在预期的时间范围内完成
-未影响其它系统和服务
变更完成后,不管成功与否,报告人都需要提交变更实施报告,报告实际的开始、结束时间、变更执行结果和执行过程中遇到的问题。
对于失败的变更,需由申请人重新提出修改后的申请,按照一个新的变更申请处理。
7.更新配置信息
如果变更成功,且涉及到系统配置信息的变动,则变更协调员应在变更实施完毕后一日内向配置管理员提交配置信息变更单,配置管理员遵循配置管理流程更新系统配置文件信息。
8.变更记录归档
由变更协调人填写变更汇总表,将本次变更记录在案,并在变更执行完毕后3日内,将本次变更所有文档提交资料管理员进行归档处理,至此结束一个完整的变更流程。
所有变更记录需保存3年以上。
每个月变更管理协调员应该生成变更月报,通报相关人员,并与变更记录保存在一起。
附件一:
变更申请表
变更名称
变更编号
申请提交日期/时间
变更计划开始时间
变更计划结束时间
变更内容
变更原因
参见相关定义
变更风险
参见相关定义
变更优先级
参见相关定义
不变更会带来的影响
申请人
执行人
汇报人
问题号
如果是因为问题引发的变更,则需要填入问题记录号
是否影响灾难恢复
变更概述和原因描述
相关的变更需求文档作为本表的附件
影响/系统中断时间
变更方案
此处填写相应文档编号.具体文档作为本表附件
测试计划
此处填写相应文档编号.具体文档作为本表附件
实施计划
此处填写相应文档编号.具体文档作为本表附件
应急回退计划
此处填写相应文档编号.具体文档作为本表附件
此外,开发商的所有相关回复文档都与此表共同保存.
附件二:
变更审批表
变更名称
变更编号
可行性审批
接到申请时间
批复时间
审批人
可行
不可行
审批意见
方案审批
接到申请时间
批复时间
审批人
通过
不通过
审批意见
实施审批
接到申请时间
批复时间
审批人
可以实施
不可实施
审批意见
附件三:
变更执行表
变更名称:
变更编号:
报告人:
序号
操作说明
执行结果
执行时间
执行人
附件四:
变更汇总表
序号
变更时间
变更名称
变更编号
变更描述
执行结果