变更管理实施细则.docx

变更管理实施细则.docx

《变更管理实施细则.docx》由会员分享，可在线阅读，更多相关《变更管理实施细则.docx（13页珍藏版）》请在冰豆网上搜索。

变更管理实施细则

变更管理实施细则

1总则

1.1文档简介

本文档是根据银行营运中心IT服务管理现状，制定的变更管理规范。

本文档管理和引导对IT系统的变更需求，规范变更流程和行为，维护IT系统完整性和提高服务质量。

1.2适用范围

本文档描述仅限于对服务器硬件和操作系统等IT配置项的管理，涉及部门包括灾备与运维管理处、核心与机要系统运维处等与变更管理相关的处室。

2变更管理基础

2.1变更的定义

变更是指经授权的对IT配置项进行的添加、删除、修改或状态改变的操作。

即所有IT的软硬件系统的配置或者状态因为某项操作而发生改变就是变更。

2.2变更的类型

变更包含有以下4种类型

安装（Install），例如新设备的安装、新系统的安装、新软件安装

删除/移动（Move），例如垃圾程序清理、设备的搬迁、数据的移动

添加（Add），在原有系统上的补充，例如补丁的安装、功能模块添加

变动（Change），例如参数的调整、系统的重启、系统关闭，服务器状态变化（测试->生产）

2.3变更管理的目标：

变更管理通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。

正确管理和引导变更需求，计划和记录变更操作，安全高效的实施变更操作，减少和消除变更的负面影响。

为此，我们变更管理的目标包括：

管理和引导用户变更需求

正确评估变更计划和变更资源，维护IT环境的完整性

减少或消除变更的危险和其它原因等的对IT环境的破坏

确保所有的变更都是可控制的、已知的、有记录的和被批准。

提高IT资源和人力资源的使用率

2.4变更管理的范围：

2.4.1属于变更管理的内容

检查变更内容和变更步骤的合理性

检查变更请求所需的变更信息是否完整、准确

根据不同的变更类型，获得不同审批者签字

合理安排和协调变更的时间和相关资源

对变更的定期回顾、分析和绩效评估

2.4.2不属于变更管理的内容

触发变更的需求是否合理

变更前测试工作的资源、案例、方法、工作量和质量

变更后的事件和问题是否的好合理解决

变更所设计的升级、扩容、移动、档案整理等

2.5变更管理角色

变更管理中，我们定义了如下5种角色和团队

变更申请人或发起人

变更配置研究员

变更审批人（应用系统审批人、运维管理审批人、变更实施主管）

变更实施人

高级管理层审批人

2.6变更类型

根据变更的实施风险和紧急程度，定义了三种变更类型，以遵循不同的审批流程。

它们是例行变更、常规变更和紧急变更。

例行变更

–日常维护工作中定期或定时的变更操作，如补丁安装、病毒库更新等

–是可以计划和预约的，可以短期内实施

–变更影响的范围小，对应用影响小或无影响

–变更涉及的部门少，需其它人员少量协作或无需协作

–操作风险小，变更容易回退

常规变更

–完全可以计划和预约

–变更影响的范围较大，对应用影响较大

–变更涉及的部门较多，需其它人员协作工作

–操作风险较大，变更不容易回退

紧急变更

紧急变更则必须要满足以下三个条件中的一个或多个

–面向客户的生产系统已经出现严重故障，必须要立即通过变更解决

–面向客户的生产系统存在已证实的，随时可能发生的重大故障，必须要通过变更立即解决

–不可抗的行政要求（人民银行、银监会或信息中心总机理室），必须要通过变更立即满足

2.7变更维护窗口

变更维护窗口是指经过预先研究，认定IT维护对业务影响最小的时间段。

用于尽可能的减少因为实施变更或者变更失败等对生产运行可能带来的影响。

我们定义以下5个变更维护时间窗口：

􀁺周末维护窗口周六-周日

􀁺晚间维护窗口18:

00-23:

00

􀁺午间维护窗口11:

40-13:

20

􀁺紧急维护窗口立即（仅适用于紧急变更）

自定义时间窗口或批准的特殊维护窗口

2.8变更的计划

一个成功的变更，重要的因素是拥有完善的变更实施计划。

实施计划不仅包括变更设计规划、实施规划，也包括计划的现场操作步骤和相应的风险分析和回退计划，要做到有的放矢、弱化风险，从而

􀁺快速完成变更批准流程

􀁺充分理解、明确、掌握变更的实施步骤

􀁺选择合理的变更维护时间

􀁺完成变更的准备

􀁺安排最优的人员

􀁺做好对外通告等

同时，除紧急变更以外，所有的变更都应该提前预约，通过审批后再执行变更操作。

为了有效审阅变更计划和批准变更申请，我们定义三种变更类型服务级别如下：

例行变更

◆工作日工作时间内9:

00—15:

00前提交变更申请

审阅完成时间：

当前工作日

◆变更实施时间：

变更通常安排在周五下班后实施

常规变更

◆工作日工作时间内9:

00—15:

00前提交变更申请

审阅完成时间：

第二工作日

◆变更实施时间：

审批通过后2个工作日内开始实施

紧急变更

◆不管是否为工作日

审阅完成时间：

立即

◆变更实施时间：

审批通过后立即或遵循特殊的变更维护窗口

2.9变更批准流程

2.9.1变更批准流程

基于上述对三种变更类型的定义，我们制定变更审批流程如下：

例行变更

常规变更

紧急变更

批准状态

必须

可选

必须

可选

必须

可选

应用系统审批人

　N/A

　是

　是

　N/A

　N/A

是

运维管理审批人

　N/A

　是

　是

　N/A

　是

N/A

变更实施主管

　是

　N/A

　是

　N/A

　是

　N/A

2.9.2变更管理流程图

3变更的提交、批准与实施

3.1变更的提交

变更的提交是指变更申请人独立或与变更配置研究员一起在完成变更设计并通过必要的测试后，向变更审批者提交变更申请（RFC）的过程。

一封完整的变更申请（RFC）应包含以下文档：

对于例行变更，应包含：

􀁺例行变更申请单（填写相关变更实施计划、预计变更时间和日期）

对于常规变更，应包含：

􀁺变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日期等）

􀁺变更实施详细步骤，测试完成报告（除非无法或无需测试）

应用软件开发需求（需要对系统软件和硬件做相应调整）

对于紧急变更，应包含：

􀁺变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日期等）

􀁺变更实施详细步骤和风险控制点说明

“具体填写的注意事项，请参见相关附录”

说明：

对于例行变更和常规变更，变更申请人需要将变更申请以书面的形式或电子邮件的形式提交给变更审批人，但对于紧急变更，在非工作时间或条件不允许的情况下，允许通过口头方式通知变更实施主管，事后再补足变更申请单。

3.2变更的批准

变更的审阅是指为控制变更风险，由专门的人员分别对变更方案和变更实施方案进行审阅和评估后，由变更申请人直属/主管领导批准的过程。

不管何种类型的变更，都必须获得变更申请人或变更发起人所在科室的变更批准。

变更配置研究员是通过专业技能和管理手段，对变更方案的合理性、准确性、可行性进行研究，将变更实施方案提交给变更审批人。

变更配置研究员对变更内容的准确性负主责。

不管何种类型的变更，在通过变更审批后，都必须得到变更实施主管的确认。

变更实施主管的职责是确认变更类型是否正确，复核变更方案，同时着重关注变更的实施方案，保障变更实施的可行。

如果变更实施主管对变更过程和结果引发争议，并且经过充分沟通，仍然无效的情况下，变更实施主管可以把该变更请求上升至高级管理层进行裁决。

对于例行变更，对于有预先授权的变更可以由变更实施主管批准，无预先授权的变更由应用审批人或运维审批人批准。

批准后的选择合适的变更窗口，安排资源进行实变更。

对于常规变更，由变更发起人所在处室领导进行批准，同时提交运维处负责人批准，最后交由变更实施团队进行实施。

变更审批人有责任从多角度来审阅变更的内容和变更的实施，提出建设性的意见，协调各方的实施资源，以控制变更的风险。

对于紧急变更，在变更审批人组织或授权变更实施主管召集相关的变更责任人成立现场紧急变更小组进行变更的研究，制定应急的变更措施和方案提交审批。

在非工作时间或条件不允许的情况下，允许通过口头方式批准，事后补足。

3.3变更的实施

在完成审批后，变更实施主管负责通过发布变更实施计划，通知变更影响单位或个人。

其中包括：

􀁺发放系统停机公文

􀁺通知相关支持人员

􀁺发布变更时间

􀁺发送注意要点和补充计划（如果有）

对于紧急变更，在获得批准后，变更经理可以先口头联系实施人员，安排实施。

􀂋

变更实施中必须严格按照变更申请单和相关附件中的内容，如碰到实际情况与申请资料不符的情况，应该立即停止操作，恢复到实施前状态，并将实施结果标注为失败且说明原因。

􀂋软件换版必须严格按照实施步骤操作，特别要注意备份环节。

􀂋变更实施结果必须如实记录，实施失败或部分失败时需要写明原因和现象。

􀂋变更完成后实施人应将签署后的变更申请单复印后转交运维处变更审批人存档。

4变更的确认与关闭

4.1变更的确认

在变更成功实施完成后，变更实施人会在之后第一个工作日内通知变更递交人，确认变更结果是否达到预期目的，变更结果同步发送消息给变更实施主管和变更审批人。

同时发送给配置管理员，通知其更新配置数据库。

只有变更实施和变更结果确认同时成功，该变更才可标识为成功。

4.2变更的关闭

变更的关闭并不依赖于变更是否成功。

根据变更的实际实施情况，变更的关闭可以有以下3个关闭代码。

􀁺成功

􀁺失败

取消

其中失败，又可以有以下几个原因代码。

研发失误（变更开发逻辑存在问题）

管理问题（测试不足或版本、环境问题）

文档错误（文档描述不完整或不准确）

计划失误（安排的变更时间、人力或沟通出现纰漏）

实施失误（变更实施失误）

系统缺陷（系统存在缺陷，导致变更失败）

5变更的确认与关闭

对于变更“失败”的变更，由变更实施人跟进，调查造成该变更失败的根因，主笔撰写变更失败记录报告。

若涉及其它团队工作，其它团队负责提交失败原因分析报告作为变更失败记录报告附件。

变更涉及多团队合作，则由变更实施人获得授权后组织各团队成立变更失败调查小组，跟进，调查造成该变更失败的根本原因。

变更失败调查小组一般需要在变更失败后的两周内，发布失败变更调查报告。

失败变更调查报告主要包含以下几部分内容：

◆􀁺变更说明

◆􀁺失败现象和影响

◆实施过程描述

◆􀁺失败原因定位

◆􀁺后续行动方案和建议

失败调查报告发送给变更实施主管、变更审批人、主责任人所在团队的主管和科长，并抄送其他审阅人员。

变更申请单

以下由变更申请人填写

申请人

部门

申请日期

变更系统名称/主机名

变更类型：

□例行变更

□常规变更

□紧急变更

变更原因及变更内容

以下由变更实施人填写

预计变更日期

变更时间（预计起止时间）

变更实施计划

实施人签字：

回退计划

变更影响

以下由相关审批人填写

系统所属处室意见

负责人签字

日期

运行维护处意见

负责人签字

日期

惠普服务器运维团队意见

负责人签字

日期

以下由变更实施人及系统所属处室填写

变更完成时间

变更完成情况

变更实施人签字

日期

变更申请人签字

日期

注：

例行变更通常安排在周五下班后实施；常规变更为审批通过后2个工作日内开始实施；紧急变更为审批通过后立即实施。