信息系统运维变更管理规范Word格式.docx

资源描述

信息系统运维变更管理规范Word格式.docx

《信息系统运维变更管理规范Word格式.docx》由会员分享，可在线阅读，更多相关《信息系统运维变更管理规范Word格式.docx（18页珍藏版）》请在冰豆网上搜索。

信息系统运维变更管理规范Word格式.docx

变更管理流程负责人

a）确保流程满足实际的需要，角色职责明确，流程各环节合理。

b）接收各方意见和建议，改进和提高变更管理流程的有效性和效率，进行流程培训相关工作。

c）制定和解释变更管理流程的相关内容。

d）参与重大变更的变更顾问委员会和紧急变更顾问委员会工作。

a）深刻了解变更管理流程。

b）熟悉业务系统的运维。

c）较强的流程规划和制定能力。

d）较强的组织和协调能力。

e）具备一定企业管理知识。

变更经理

a）接收变更请求，并做初步筛选。

b）确保变更请求得到评估、授权、控制和计划。

c）成立变更顾问委员会，并组织相关会议，确保所有相关人员都尽可能地参与到变更请求的评估中。

d）协调相应资源，指导变更的构建、测试和实施，确保变更在符合组织风险和需求的情况下，在适当的时间内实施。

a）熟悉变更管理、问题管理、配置管理和事件管理流程及其他们之间的关系。

b）了解公司的IT架构和环境。

c）较强的沟通技巧、组织能力、团队领导能力。

变更顾问委员会/紧急变更顾问委员会

a）审核变更请求，评估其潜在影响和风险，做出批准或拒绝的决定。

b）针对具体变更请求，评估相应资源的分派。

c）回顾所有已执行的变更，确保满足变更目的。

a）有项目管理的经验，具备协调、组织和管理的能力。

b）熟悉本系统的业务，了解公司的IT架构和环境。

c）某个问题或某种技术的专家

d）较强的沟通技巧。

变更主管

a）协助变更经理接收变更请求。

b）组织实施变更请求，制定变更计划和时间规划等。

c）负责领导变更的构建、测试、实施和回顾，更新变更记录单，生成变更任务单，协调各任务工单，以维护变更的整体性。

d）确保变更在预定的时间、资源和成本内完成。

e）在必要时，确保回退计划正确实施。

b）较强的沟通技巧。

c）了解配置项之间的关系。

变更实施人员

a）根据变更计划实施变更。

b）执行分派的任务工单。

c）向变更主管汇报工作进程。

d）现场负责变更实施或恢复实施。

a）某个问题或某种技术的专家。

b）熟悉所变更的系统情况。

6流程原则

6.1基本原则

基本原则包括：

a）所有对变更范围中涉及的变更都必须遵循本变更管理流程，以控制变更所带来的风险。

b）所有的变更请求都应该被记录和追踪，并在变更过程中及时对变更申请表进行更新。

c）应定期进行流程检查和回顾，回顾内容包括关键绩效指标、流程执行效率和流程支持工具等的有效性，以完善变更管理流程。

6.2分类原则

变更类型代表了变更执行的审批路径，变更包括标准变更、常规变更和紧急变更三类，具体执行原则如下。

6.2.1标准变更执行原则

标准变更执行原则包括：

a）标准变更需要预先制定出相应的标准变更列表，参见附录A《表A.1标准变更列表》。

b）定期分析变更报告，对存在的风险进行控制，对标准变更列表内容进行必要调整。

6.2.2常规变更执行原则

常规变更执行原则包括：

a）变更执行需提前通知变更相关方作变更准备。

b）准备详细的变更方案。

c）对变更方案进行二次审批。

d）严格管理其计划、测试、评估、审批和实施过程。

6.2.3紧急变更执行原则

紧急变更执行原则包括：

a）制定紧急变更快速实施处理机制。

b）应遵循紧急变更子流程以获得及时实施。

c）紧急变更申请时，需要写清楚紧急变更目的，可以在执行后再补充相关的单据。

6.3审批原则

预先定义的标准变更可直接实施，常规变更和紧急变更必须经过审批之后方可实施，对不同类型的变更，对应的执行路径和审批人员可以不相同：

a）常规变更需要变更顾问委员会受权和审批。

b）紧急变更须经紧急变更顾问委员会授权和审批。

6.4通知原则

对现有业务系统产生影响的变更均需在变更执行前通知有关人员做好业务调整，以减少对业务的影响，待实施完成后再次通告。

6.5回退原则

当变更实施失败，则需要进行回退，任何回退的变更将作为变更失败而关闭。

在下一次实施前，变更请求者必须重新提交新的变更申请单，进行重新审批。

6.6关闭原则

变更实施完毕并且得到确认后，将关闭变更申请单。

变更之后如果引发了其他问题，将更新变更申请单的信息。

7流程和说明

7.1流程图

变更管理流程图见图1所示。

图1变更管理流程图

7.2流程图说明

7.2.1提交变更请求

该流程活动主要包括以下内容：

a）变更请求方通过提交请求提出变更，变更请求方可以是要求进行变更的个人或组织。

其它流程如事件和服务请求管理流程、问题管理流程等也可以触发变更。

b）附录A《表A.2变更申请表》提供了变更请求的信息示例，详细程度可根据变更的规模和影响度进行调整。

c）建议变更申请的记录通过集成的服务管理工具来完成，此类工具能够存储配置项及配置项间的关系，当评估信息系统某一组件的变更对其它组件可能产生的影响时将非常有帮助。

7.2.2接受与分类

a）在接受变更请求时，应检查变更请求，审查其完整性、清晰性、合法性、可行性及必要性，相关活动如下：

1）进行真实性审查，过滤掉不切实际的、早期重复的变更申请（此类变更申请已经被接受、拒绝或仍在考虑中）；

2）进行完整性审查，对于不完善的变更申请，需对必要的信息进行补充和确认；

3）在必要情况下对变更优先级重新界定。

b）对受理的变更请求，在后续流程中补充受理后的相关信息，可参考附录A《表A.2变更申请表》。

c）对被拒绝的变更申请连同有关拒绝原因的简要信息返还至变更请求方，并提供正常的管理渠道为被拒绝的变更进行上诉的权力。

d）对初步为通过审查的变更分配类型、风险等级，按变更申请内容将变更类型分为：

标准变更、常规变更和紧急变更。

根据不同的变更类型执行不同的处理流程：

1）标准变更：

按照标准变更子流程执行，参见7.2.7节；

2）常规变更：

按照常规变更后续活动（评估审批、构建变更、实施变更和回顾关闭）执行；

3）紧急变更：

按照紧急变更子流程执行，参见7.2.8节。

7.2.3评估审批

a）变更经理根据变更的类型确定变更顾问委员会成员，召开变更评估会议。

变更顾问委员会人员建议参考附录A《表A.3变更委员会组成参考表》。

b）变更顾问委员会根据变更的具体情况，评估该变更的风险、业务需求、技术实现等因素，具体信息参看附录A《表A.4变更管理评估表》。

c）变更顾问委员会总结分析结果，审批后授权或拒绝变更请求。

7.2.4构建变更

a）制定变更计划，主要包括以下计划：

1）实施计划。

2）测试计划。

3）回退计划。

b）构建变更方案，主要包括以下方案：

1）实施方案。

2）测试方案。

3）回退方案。

4）配置项更新方案

c）方案测试验证，对实施方案进行测试，提供测试报告，确保系统变更的正常进行及回退的有效性。

测试主要针对以下几个方面：

1）性能。

2）安全性。

3）可维护性。

4）可支持性。

5）可靠性和可用性。

6）可操作性。

d）审核变更方案，确认计划、资源、测试结果是否可行，通过或修订变更方案。

e）符合发布条件的，将触发进入发布管理流程处理。

7.2.5实施变更

a）变更计划和方案通过审核后，可以正式实施变更，在实施过程中需要确保所有变更按照变更计划来进行。

b）变更时间、影响范围及预期影响需告之变更相关部门，以便其及时准备。

c）变更方案实施后，根据执行情况及时更新相关情况，参考附录A《表A.5变更实施表》。

d）变更实施过程中，如果涉及发布则提交发布申请单转到发布管理流程进行处理。

e）监控实施后的运行状况，判断功能和业务运行是否成功。

f）变更失败时，要执行预定回退计划，实施补救措施，以取消本次变更带来的影响。

7.2.6回顾关闭

a）召开回顾会议，根据变更结果的反馈信息组织变更回顾和总结。

b）变更导致用户操作改变的，应对用户进行培训，确保业务活动在系统变更后不受影响。

c）变更过程中如果与其它流程有接口，变更结束后，向其它相关流程反馈信息。

d）监控并审查变更实施后的效果，更新配置管理数据库相关配置项信息。

e）变更实施完成后整理变更结果，将变更结果更新至变更回顾表，参见附录A《表A.4变更评价表》。

f）回顾总结变更经验，对于有借鉴意义的变更形成变更案例或经验知识进行总结或放入知识库，主要应从以下几个方面对变更实施的情况进行回顾：

1）变更是否达到预期目标；

2）变更请求方对变更结果是否满意；

3）变更是否存在负面影响。

g）回顾结果认为变更达到预期目标，更新变更记录，关闭变更，并通知变更请求方。

h）回顾结果认为未能完全实现预期定目标，通过其他变更可以用较低的成本取得预期成效，提交新的变更请求。

i）回顾结果认为未达到预期目标，且产生负面影响的，则考虑取消变更，以消除对生产环境造成的影响。

回顾结果认为未达到预期目标，但取消变更并恢复原状的代价过高或风险过大或额外变更无助于实现预期目标时，可以不取消变更。

对于考虑取消的变更，变更顾问委员会应讨论以下几个问题：

1）取消变更并恢复原状所需工作量；

2）可能对其它计划内或已部署的变更造成的影响；

3）用户对已完成变更但未达到预期目标的系统继续使用的可能性。

7.2.7标准变更子流程

该子流程活动主要包括以下内容：

a）标准变更的重要元素包括：

1）有确定的触发条件以启动变更请求；

2）任务为大家所知、并被记录和证明；

3）已事先授予有效权力；

4）预算审批通常预先确定，或者在变更请求方的控制之下；

5）风险通常较低，且易于理解。

b）标准变更应在构建变更管理流程的早期就确定下来，以提升效率。

c）针对配置项的标准变更可以在资产或配置项生命周期中进行跟踪，尤其是具备全面的配置管理系统时。

配置管理系统可提供变更报告、变更现状、相关配置项和相关配置项版本的状态。

在这项情况下，变更与配置管理报告被集成在一起，同时变更管理可以“监督”所有针对服务配置项和发布配置项的变更。

d）标准变更实施的审批工作由针对此类标准变更的授权机构进行。

e）标准变更确认可依据标准变更列表信息，参考附录A《A.1标准变更列表》。

f）变更实施完成后，关闭变更，变更顾问委员会需要定期对实施的标准变更进行回顾，并更新标准变更列表信息。

图2标准变更子流程图

7.2.8紧急变更子流程

a）组织需要为紧急变更确定授权级别，同时必须明确记录和了解获授权力的级别。

b）紧急变更顾问委员会评估变更的风险、业务需求、技术实现等因素，做出驳回或批准紧急变更申请意见。

c）在紧急情况下，可能无法召开完整的变更顾问委员会会议。

如果需要变更顾问委员会的审批，紧急变更顾问委员会将进行审批。

d）紧急变更构建应确保有足够的人员和资源等来支持。

e）多次测试紧急变更，严禁实施完全没有经过测试的变更。

f）如果只能进行有限的测试，并且假定更稳定版本的开发与紧急变更同时进行，则测试应包括以下方面：

1）将被立即使用的服务；

2）将会导致大多数短期困难的元素。

g）如果对紧急变更进行多次尝试均失败，则应询问以下问题：

1）是否正确发现、分析和诊断了错误；

2）是否对建议的解决方案进行了足够的测试；

3）解决方案是否得到了正确的实施。

h）总结紧急变更经验，对于有借鉴意义的变更形成变更案例或经验知识进行总结。

图3紧急变更子流程图

7.3流程接口

变更管理流程主要与事件和服务请求、问题、配置流程接口存在强关联关系。

a）与事件和服务请求、问题等流程的关联：

接收并处理事件和服务请求、问题、业务关系、供应商、信息安全等管理流程提交的变更。

b）与配置管理的关联：

1）变更引起配置项的任何变化，将由配置管理进行控制。

2）配置管理作为变更管理的基础，支持变更风险评估等相关环节的整个过程。

8指标和报告

8.1指标

反映变更管理流程运维效率和效果的主要指标有：

a）失败变更的百分比；

b）未授权变更的数量；

c）导致事件的变更百分比；

d）紧急变更的数量。

变更管理流程指标的描述、用途、计算方法等信息参考附录B，表B.1～表B.4。

8.2报告

8.2.1报告的用途

变更管理报告既可以用来支持其它管理流程，如发布管理、配置管理等，也可以用于风险管控。

8.2.2报告的周期

报告的周期可以采用日报、周报、月报、季报、半年报、年报等方式。

8.2.3报告的内容

变更管理报告应包括以下几个方面的内容：

a）变更原因及内容描述；

b）影响及风险评估；

c）变更内容设计；

d）变更顾问委员会的建议和决定；

e）变更执行计划和回退计划；

f）发布记录信息；

g）用户是否满意。

附录A

（资料性附录）

文档模板

表A.1标准变更列表

类型

标准变更名称

描述

业务系统

用户帐号增减

用户申请新增或删除账号信息

用户密码修改

重置或修改用户的密码

用户权限变更

对用户的权限经行调整的操作

业务数据

业务数据的增添

操作界面调整

对操作界面进行简单的调整

基础架构

简单的设备搬迁

对某台设备经行物理位置的搬迁

服务器IP的调整

对服务器的IP进行调整，对应用系统没有大的影响

表A.2变更申请表

变更请求者信息

单位/部门

变更请求者姓名

联系方式

变更请求基本信息

变更来源

□事件和服务请求管理□问题管理□内部或业务部门提出

关联来源编号

变更请求时间

期望完成时间

变更分类

变更类型

口标准变更

口常规变更

口紧急变更

变更对象

关联配置项

变更状态

口新建口已批准口实施中口已关闭

变更标题

变更原因

变更方案

常规/紧急变更审核

审核意见

签字/日期：

常规/紧急变更审核评审

评审成员

评审结论

变更实施

实施结果

签字/日期：

变更关闭

实施后评审

变更申请者确认

变更关闭代码

□成功□回退□取消

变更关闭时间

表A.3变更委员会组成参考表

角色

成员

变更顾问委员会

紧急变更

部门领导、变更经理、业务部门代表

常规变更（高）

部门领导、变更经理、变更主管、业务部门代表、技术专家、财务/法律/内控人员、供应商、流程负责人

常规变更（中）

变更经理、变更主管、技术专家

常规变更（低）

标准变更

N/A

表A.4变更管理评估表

变更原因及内容描述：

请求人：

请求时间：

（本栏可为附件）

影响及风险评估：

变更内容设计：

评估人：

评估时间：

变更顾问委员会的建议和决定：

批准人：

批准时间：

变更执行计划：

回退计划：

（本栏可附件）

开始执行的时间

变更完成期限

备注：

注：

1、如果该变更申请与问题管理相关，记录相关的问题编号；

2、影响部分可以围绕变更管理质量和变更管理带来的好处等实际情况进行填写。

表A.5变更实施表

变更操作人

受理日期

□是□否

源代码修改

□是附：

源代码变更交接表，编号：

□否

实施步骤、回退机制及实施结果：

（本栏可为附件）

操作人签字：

年月日

测试（如需要）

测试步骤及测试结果：

测试人签字：

注：

如果是外包实施则在填写变更实施步骤栏中写明第三方公司名称、变更内容交接时间等具体情况。

附录B

变更管理流程指标

表B.1失败变更的百分比

指标

失败变更的百分比

没有达到变更方案结果的变更比例

用途

说明变更结果的成功比率