变更管理实施细则

1、变更管理实施细则目录1总则1.1 文档简介本文档是根据银行营运中心IT服务管理现状，制定的变更管理规范。本文档管理和 引导对IT系统的变更需求，规范变更流程和行为，维护IT系统完整性和提高服务质量。1.2 适用范围本文档描述仅限于对服务器硬件和操作系统等IT配置项的管理，涉及部门包括灾备与运维管理处、核心与机要系统运维处等与变更管理相关的处室。2变更管理基础2.1 变更的定义变更是指经授权的对IT配置项进行的添加、删除、修改或状态改变的操作。即所有IT的软硬件系统的配置或者状态因为某项操作而发生改变就是变更。2.2 变更的类型变更包含有以下4种类型亠安装(In stall )，例如新设备的安装

2、、新系统的安装、新软件安装亠 删除/移动(Move)，例如垃圾程序清理、设备的搬迁、数据的移动亠添加（Add），在原有系统上的补充，例如补丁的安装、功能模块添加厲 变动（Change），例如参数的调整、系统的重启、系统关闭，服务器状态变化 （测试-生产）2.3 变更管理的目标：变更管理通过标准统一的方法和步骤来管理和控制所有对IT生产环境有影响的变更。正确管理和引导变更需求，计划和记录变更操作，安全高效的实施变更操作，减 少和消除变更的负面影响。为此，我们变更管理的目标包括：亠管理和引导用户变更需求亠正确评估变更计划和变更资源，维护 IT环境的完整性亠减少或消除变更的危险和其它原因等的对IT环

3、境的破坏亠 确保所有的变更都是可控制的、已知的、有记录的和被批准。亠提高IT资源和人力资源的使用率2.4 变更管理的范围：2.4.1属于变更管理的内容亠 检查变更内容和变更步骤的合理性亠检查变更请求所需的变更信息是否完整、准确亠根据不同的变更类型，获得不同审批者签字亠合理安排和协调变更的时间和相关资源亠对变更的定期回顾、分析和绩效评估亠触发变更的需求是否合理亠变更前测试工作的资源、案例、方法、工作量和质量亠变更后的事件和问题是否的好合理解决亠变更所设计的升级、扩容、移动、档案整理等2.5 变更管理角色变更管理中，我们定义了如下 5种角色和团队亠变更申请人或发起人亠变更配置研究员亠 变更审批人（

4、应用系统审批人、运维管理审批人、变更实施主管）亠变更实施人亠高级管理层审批人2.6 变更类型根据变更的实施风险和紧急程度，定义了三种变更类型，以遵循不同的审批流程。 它们是例行变更、常规变更和紧急变更。亠例行变更-日常维护工作中定期或定时的变更操作，如补丁安装、病毒库更新等-是可以计划和预约的，可以短期内实施-变更影响的范围小，对应用影响小或无影响-变更涉及的部门少，需其它人员少量协作或无需协作-操作风险小，变更容易回退亠常规变更-完全可以计划和预约-变更影响的范围较大，对应用影响较大-变更涉及的部门较多，需其它人员协作工作-操作风险较大，变更不容易回退亠紧急变更紧急变更则必须要满足以下三个条

5、件中的一个或多个-面向客户的生产系统已经出现严重故障，必须要立即通过变更解决面向客户的生产系统存在已证实的，随时可能发生的重大故障，必须要通过 变更立即解决-不可抗的行政要求（人民银行、银监会或信息中心总机理室），必须要通过 变更立即满足2.7 变更维护窗口变更维护窗口是指经过预先研究，认定IT维护对业务影响最小的时间段。用于尽可能的减少因为实施变更或者变更失败等对生产运行可能带来的影响。我们定义以下5个变更维护时间窗口：亠周末维护窗口周六-周日“晚间维护窗口18:00-23:00乂午间维护窗口11:40-13:20紧急维护窗口 立即（仅适用于紧急变更）*自定义时间窗口或批准的特殊维护窗口2.

6、8 变更的计划一个成功的变更，重要的因素是拥有完善的变更实施计划。实施计划不仅包括变更设计规划、实施规划，也包括计划的现场操作步骤和相应的 风险分析和回退计划，要做到有的放矢、弱化风险，从而亠快速完成变更批准流程亠充分理解、明确、掌握变更的实施步骤亠选择合理的变更维护时间乂完成变更的准备乂安排最优的人员*做好对外通告等同时，除紧急变更以外，所有的变更都应该提前预约，通过审批后再执行变更操作为了有效审阅变更计划和批准变更申请，我们定义三种变更类型服务级别如下：亠例行变更工作日工作时间内9:0015:00前提交变更申请审阅完成时间：当前工作日变更实施时间：变更通常安排在周五下班后实施亠常规变更工作

7、日工作时间内9:0015:00前提交变更申请审阅完成时间：第二工作日 变更实施时间：审批通过后2个工作日内幵始实施亠紧急变更不管是否为工作日审阅完成时间：立即变更实施时间：审批通过后立即或遵循特殊的变更维护窗口2.9变更批准流程2.9.1变更批准流程基于上述对三种变更类型的定义，我们制定变更审批流程如下:例行变更常规变更紧急变更批准状态必须可选必须可选必须可选应用系统审批人N/A是是N/AN/A是运维管理审批人N/A是是N/A是N/A变更实施主管是N/A是N/A是N/A2.9.2变更管理流程图3变更的提交、批准与实施3.1变更的提交变更的提交是指变更申请人独立或与变更配置研究员一起在完成变更设

8、计并通过一封完整的变更申请（RFC应包含以下文档：亠 对于例行变更，应包含：例行变更申请单（填写相关变更实施计划、预计变更时间和日期）亠 对于常规变更，应包含：变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日 期等）变更实施详细步骤，测试完成报告（除非无法或无需测试）应用软件幵发需求（需要对系统软件和硬件做相应调整）亠 对于紧急变更，应包含：变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日 期等）变更实施详细步骤和风险控制点说明“具体填写的注意事项，请参见相关附录”说明：对于例行变更和常规变更，变更申请人需要将变更申请以书面的形式或电子邮件的 形式提

9、交给变更审批人，但对于紧急变更，在非工作时间或条件不允许的情况下，允 许通过口头方式通知变更实施主管，事后再补足变更申请单。3.2 变更的批准变更的审阅是指为控制变更风险，由专门的人员分别对变更方案和变更实施方案进 亠不管何种类型的变更，都必须获得变更申请人或变更发起人所在科室的变更批 准。变更配置研究员是通过专业技能和管理手段，对变更方案的合理性、准确 性、可行性进行研究，将变更实施方案提交给变更审批人。变更配置研究员对 变更内容的准确性负主责。亠不管何种类型的变更，在通过变更审批后，都必须得到变更实施主管的确认。 变更实施主管的职责是确认变更类型是否正确，复核变更方案，同时着重关注 变更的

10、实施方案，保障变更实施的可行。亠如果变更实施主管对变更过程和结果引发争议，并且经过充分沟通，仍然无效 的情况下，变更实施主管可以把该变更请求上升至高级管理层进行裁决。亠对于例行变更，对于有预先授权的变更可以由变更实施主管批准，无预先授权 的变更由应用审批人或运维审批人批准。批准后的选择合适的变更窗口，安排 资源进行实变更。对于常规变更，由变更发起人所在处室领导进行批准，同时提交运维处负责人 批准，最后交由变更实施团队进行实施。变更审批人有责任从多角度来审阅变 更的内容和变更的实施，提出建设性的意见，协调各方的实施资源，以控制变 更的风险。亠对于紧急变更，在变更审批人组织或授权变更实施主管召集相

11、关的变更责任人 成立现场紧急变更小组进行变更的研究，制定应急的变更措施和方案提交审批。在非工作时间或条件不允许的情况下，允许通过口头方式批准，事后补足。3.3 变更的实施在完成审批后，变更实施主管负责通过发布变更实施计划，通知变更影响单位或个 人。其中包括：发放系统停机公文通知相关支持人员发布变更时间发送注意要点和补充计划（如果有） 对于紧急变更，在获得批准后，变更经理可以先口头联系实施人员，安排实施。变更实施中必须严格按照变更申请单和相关附件中的内容， 如碰到实际情况与申请 资料不符的情况，应该立即停止操作，恢复到实施前状态，并将实施结果标注为失败 且说明原因。软件换版必须严格按照实施步骤操

12、作，特别要注意备份环节。变更实施结果必须如实记录，实施失败或部分失败时需要写明原因和现象。 变更完成后实施人应将签署后的变更申请单复印后转交运维处变更审批人存档。4 变更的确认与关闭4.1 变更的确认在变更成功实施完成后，变更实施人会在之后第一个工作日内通知变更递交人，确 认变更结果是否达到预期目的，变更结果同步发送消息给变更实施主管和变更审批人同时发送给配置管理员，通知其更新配置数据库。只有变更实施和变更结果确认同时 成功，该变更才可标识为成功。4.2 变更的关闭变更的关闭并不依赖于变更是否成功。根据变更的实际实施情况，变更的关闭可以 有以下 3 个关闭代码。成功失败取消其中失败，又可以有以

13、下几个原因代码。研发失误（变更开发逻辑存在问题） 管理问题（测试不足或版本、环境问题） 文档错误（文档描述不完整或不准确） 计划失误（安排的变更时间、人力或沟通出现纰漏） 实施失误（变更实施失误）系统缺陷（系统存在缺陷，导致变更失败）5 变更的确认与关闭对于变更 “失败”的变更，由变更实施人跟进，调查造成该变更失败的根因，主笔撰写变更失败记录报告。 若涉及其它团队工作，其它团队负责提交失败原因分析报告作为变更失败记录报告附件变更涉及多团队合作，则由变更实施人获得授权后组织各团队成立变更失败调 查小组，跟进，调查造成该变更失败的根本原因。变更失败调查小组一般需要在变更失败后的两周内，发布失败变更调查报告。 失败变更调查报告主要包含以下几部分内容：变更说明失败现象和影响实施过程描述失败原因定位后续行动方案和建议失败调查报告发送给变更实施主管、变更审批人、主责任人所在团队的主管和科长，并抄送其他审阅人员变更申请单以下由