变更管理实施细则
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2 变更管理基础
2.1 变更的定义
变更是指经授权的对 IT 配置项进行的添加、 删除、 修改或状态改变的操作。 即所有 IT 的软硬件系统的配置或者状态因为某项操作而发生改变就是变更。
2.2 变更的类型
变更包含有以下 4 种类型 安装（ Install ），例如新设备的安装、新系统的安装、新软件安装 删除 / 移动（ Move ），例如垃圾程序清理、设备的搬迁、数据的移动
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）应包含以下文档： 对于例行变更，应包含：
例行变更申请单（填写相关变更实施计划、预计变更时间和日期） 对于常规变更，应包含：
2.7 变更维护窗口
变更维护窗口是指经过预先研究， 认定 IT 维护对业务影响最小的时间段。 用于尽可 能的减少因为实施变更或者变更失败等对生产运行可能带来的影响。
我们定义以下 5 个变更维护时间窗口： 周末维护窗口 周六 -周日 晚间维护窗口 18:00-23:00 午间维护窗口 11:40-13:20 紧急维护窗口 立即 （仅适用于紧急变更）
为此，我们变更管理的目标包括： 管理和引导用户变更需求 正确评估变更计划和变更资源，维护 IT环境的完整性 减少或消除变更的危险和其它原因等的对 IT环境的破坏 确保所有的变更都是可控制的、已知的、有记录的和被批准。 提高 IT资源和人力资源的使用率
2.4 变更管理的范围：
2.4.1
属于变更管理的内容
日期
以下由变更实施人及系统所属处室填写 变更完成时间
变更实施人签字
变 更完 成情况 日期
变更申请人签字
日期
注：例行变更通常安排在周五下班后实施； 常规变更为审批通过后 2 个工作日内开始实施； 紧急变更为审批通过后立即实施。
变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日 期等）
变更实施详细步骤，测试完成报告（除非无法或无需测试） 应用软件开发需求（需要对系统软件和硬件做相应调整） 对于紧急变更，应包含：
变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日 期等）
变更实施详细步骤和风险控制点说明 “具体填写的注意事项，请参见相关附录”
3.3 变更的实施
在完成审批后，变更实施主管负责通过发布变更实施计划，通知变更影响单位或个 人。其中包括：
发放系统停机公文 通知相关支持人员 发布变更时间 发送注意要点和补充计划（如果有） 对于紧急变更，在获得批准后，变更经理可以先口头联系实施人员，安排实施。
变更实施中必须严格按照变更申请单和相关附件中的内容， 如碰到实际情况与申请 资料不符的情况，应该立即停止操作，恢复到实施前状态，并将实施结果标注为失败 且说明原因。
变更管理实施细则
目录
1 总则
1.1 文档简介
本文档是根据银行营运中心 IT 服务管理现状， 制定的变更管理规范。 本文档管理和 引导对 IT 系统的变更需求， 规范变更流程和行为， 维护 IT 系统完整性和提高服务质量。
1.2 适用范围
本文档描述仅限于对服务器硬件和操作系统等 IT 配置项的管理， 涉及部门包括灾备 与运维管理处、核心与机要系统运维处等与变更管理相关的处室。
行审阅和评估后，由变更申请人直属 / 主管领导批准的过程。
不管何种类型的变更，都必须获得变更申请人或变更发起人所在科室的变更批 准。变更配置研究员是通过专业技能和管理手段，对变更方案的合理性、准确 性、可行性进行研究，将变更实施方案提交给变更审批人。变更配置研究员对 变更内容的准确性负主责。 不管何种类型的变更，在通过变更审批后，都必须得到变更实施主管的确认。 变更实施主管的职责是确认变更类型是否正确，复核变更方案，同时着重关注 变更的实施方案，保障变更实施的可行。 如果变更实施主管对变更过程和结果引发争议，并且经过充分沟通，仍然无效 的情况下，变更实施主管可以把该变更请求上升至高级管理层进行裁决。
变更失败调查小组一般需要在变更失败后的两周内，发布失败变更调查报告。 失败变更调查报告主要包含以下几部分内容：
变更说明 失败现象和影响
实施过程描述 失败原因定位 后续行动方案和建议 失败调查报告发送给变更实施主管、变更审批人、主责任人所在团队的主管和 科长，并抄送其他审阅人员。
以下由变更申请人填写 申请人 变更 系统 名 称 / 主机名
变更 原因 及 变更内容 以下由变更实施人填写 预计 变更 日 期 变更实施计划
变更申请单
部门
申请日期 变更类型：
□ 例行变更 □ 常规变更 □ 紧急变更
变更时间 (预计起止时间 )
回退 计划
变更 影响
实施人签字：
以下由相关审批人填写 系统所属处室意见
负责人签字
日期
运行维护处意见
负责人签字
日期
惠普服务器运维团队 意见 负责人签字
说明： 对于例行变更和常规变更， 变更申请人需要将变更申请以书面的形式或电子邮件的 形式提交给变更审批人，但对于紧急变更，在非工作时间或条件不允许的情况下，允 许通过口头方式通知变更实施主管，事后再补足变更申请单。
3.2 变更的批准
变更的审阅是指为控制变更风险， 由专门的人员分别对变更方案和变更实施方案进
自定义时间窗口或批准的百度文库殊维护窗口
2.8 变更的计划
一个成功的变更，重要的因素是拥有完善的变更实施计划。 实施计划不仅包括变更设计规划、 实施规划，也包括计划的现场操作步骤和相应的 风险分析和回退计划，要做到有的放矢、弱化风险，从而
快速完成变更批准流程 充分理解、明确、掌握变更的实施步骤 选择合理的变更维护时间 完成变更的准备 安排最优的人员 做好对外通告等 同时，除紧急变更以外， 所有的变更都应该提前预约， 通过审批后再执行变更操作。 为了有效审阅变更计划和批准变更申请，我们定义三种变更类型服务级别如下： 例行变更
检查变更内容和变更步骤的合理性 检查变更请求所需的变更信息是否完整、准确 根据不同的变更类型，获得不同审批者签字 合理安排和协调变更的时间和相关资源 对变更的定期回顾、分析和绩效评估
2.4.2
不属于变更管理的内容
触发变更的需求是否合理 变更前测试工作的资源、案例、方法、工作量和质量 变更后的事件和问题是否的好合理解决 变更所设计的升级、扩容、移动、档案整理等
工作日工作时间内 9:00—15:00前提交变更申请 审阅完成时间：当前工作日 变更实施时间：变更通常安排在周五下班后实施 常规变更 工作日工作时间内 9:00—15:00前提交变更申请 审阅完成时间：第二工作日 变更实施时间：审批通过后 2个工作日内开始实施
紧急变更 不管是否为工作日 审阅完成时间：立即 变更实施时间：审批通过后立即或遵循特殊的变更维护窗口
5 变更的确认与关闭
对于变更 “失败”的变更，由变更实施人跟进，调查造成该变更失败的根因， 主笔撰写变更失败记录报告。 若涉及其它团队工作，其它团队负责提交失败原因分 析报告作为变更失败记录报告附件。
变更涉及多团队合作，则由变更实施人获得授权后组织各团队成立变更失败调 查小组，跟进，调查造成该变更失败的根本原因。
2.5 变更管理角色
变更管理中，我们定义了如下 5种角色和团队 变更申请人或发起人 变更配置研究员 变更审批人（应用系统审批人、运维管理审批人、变更实施主管） 变更实施人 高级管理层审批人
2.6 变更类型
根据变更的实施风险和紧急程度，定义了三种变更类型，以遵循不同的审批流程。 它们是例行变更、常规变更和紧急变更。
同时发送给配置管理员，通知其更新配置数据库。只有变更实施和变更结果确认同时 成功，该变更才可标识为成功。
4.2 变更的关闭
变更的关闭并不依赖于变更是否成功。根据变更的实际实施情况，变更的关闭可以 有以下 3 个关闭代码。
成功 失败
取消 其中失败，又可以有以下几个原因代码。
研发失误（变更开发逻辑存在问题） 管理问题（测试不足或版本、环境问题） 文档错误（文档描述不完整或不准确） 计划失误（安排的变更时间、人力或沟通出现纰漏） 实施失误（变更实施失误） 系统缺陷（系统存在缺陷，导致变更失败）
例行变更 –日常维护工作中定期或定时的变更操作，如补丁安装、病毒库更新等 –是可以计划和预约的，可以短期内实施 –变更影响的范围小，对应用影响小或无影响 –变更涉及的部门少，需其它人员少量协作或无需协作
– 操作风险小，变更容易回退 常规变更 –完全可以计划和预约 –变更影响的范围较大，对应用影响较大 –变更涉及的部门较多，需其它人员协作工作 –操作风险较大，变更不容易回退 紧急变更 紧急变更则必须要满足以下三个条件中的一个或多个 –面向客户的生产系统已经出现严重故障，必须要立即通过变更解决 –面向客户的生产系统存在已证实的，随时可能发生的重大故障，必须要通过 变更立即解决 –不可抗的行政要求（人民银行、银监会或信息中心总机理室），必须要通过 变更立即满足
软件换版必须严格按照实施步骤操作，特别要注意备份环节。 变更实施结果必须如实记录，实施失败或部分失败时需要写明原因和现象。 变更完成后实施人应将签署后的变更申请单复印后转交运维处变更审批人存档。
4 变更的确认与关闭
4.1 变更的确认
在变更成功实施完成后，变更实施人会在之后第一个工作日内通知变更递交人，确 认变更结果是否达到预期目的，变更结果同步发送消息给变更实施主管和变更审批人。
对于例行变更，对于有预先授权的变更可以由变更实施主管批准，无预先授权 的变更由应用审批人或运维审批人批准。批准后的选择合适的变更窗口，安排 资源进行实变更。 对于常规变更，由变更发起人所在处室领导进行批准，同时提交运维处负责人 批准，最后交由变更实施团队进行实施。变更审批人有责任从多角度来审阅变 更的内容和变更的实施，提出建设性的意见，协调各方的实施资源，以控制变 更的风险。 对于紧急变更，在变更审批人组织或授权变更实施主管召集相关的变更责任人 成立现场紧急变更小组进行变更的研究， 制定应急的变更措施和方案提交审批。 在非工作时间或条件不允许的情况下，允许通过口头方式批准，事后补足。
添加（ Add），在原有系统上的补充，例如补丁的安装、功能模块添加 变动（ Change），例如参数的调整、系统的重启、系统关闭，服务器状态变化 （测试 ->生产）
2.3 变更管理的目标：
变更管理通过标准统一的方法和步骤来管理和控制所有对 IT生产环境有影响的变 更。正确管理和引导变更需求，计划和记录变更操作，安全高效的实施变更操作，减 少和消除变更的负面影响。
2.1 变更的定义
变更是指经授权的对 IT 配置项进行的添加、 删除、 修改或状态改变的操作。 即所有 IT 的软硬件系统的配置或者状态因为某项操作而发生改变就是变更。
2.2 变更的类型
变更包含有以下 4 种类型 安装（ Install ），例如新设备的安装、新系统的安装、新软件安装 删除 / 移动（ Move ），例如垃圾程序清理、设备的搬迁、数据的移动
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）应包含以下文档： 对于例行变更，应包含：
例行变更申请单（填写相关变更实施计划、预计变更时间和日期） 对于常规变更，应包含：
2.7 变更维护窗口
变更维护窗口是指经过预先研究， 认定 IT 维护对业务影响最小的时间段。 用于尽可 能的减少因为实施变更或者变更失败等对生产运行可能带来的影响。
我们定义以下 5 个变更维护时间窗口： 周末维护窗口 周六 -周日 晚间维护窗口 18:00-23:00 午间维护窗口 11:40-13:20 紧急维护窗口 立即 （仅适用于紧急变更）
为此，我们变更管理的目标包括： 管理和引导用户变更需求 正确评估变更计划和变更资源，维护 IT环境的完整性 减少或消除变更的危险和其它原因等的对 IT环境的破坏 确保所有的变更都是可控制的、已知的、有记录的和被批准。 提高 IT资源和人力资源的使用率
2.4 变更管理的范围：
2.4.1
属于变更管理的内容
日期
以下由变更实施人及系统所属处室填写 变更完成时间
变更实施人签字
变 更完 成情况 日期
变更申请人签字
日期
注：例行变更通常安排在周五下班后实施； 常规变更为审批通过后 2 个工作日内开始实施； 紧急变更为审批通过后立即实施。
变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日 期等）
变更实施详细步骤，测试完成报告（除非无法或无需测试） 应用软件开发需求（需要对系统软件和硬件做相应调整） 对于紧急变更，应包含：
变更申请单（填写相关变更实施计划、回退计划、影响范围和预计变更时间和日 期等）
变更实施详细步骤和风险控制点说明 “具体填写的注意事项，请参见相关附录”
3.3 变更的实施
在完成审批后，变更实施主管负责通过发布变更实施计划，通知变更影响单位或个 人。其中包括：
发放系统停机公文 通知相关支持人员 发布变更时间 发送注意要点和补充计划（如果有） 对于紧急变更，在获得批准后，变更经理可以先口头联系实施人员，安排实施。
变更实施中必须严格按照变更申请单和相关附件中的内容， 如碰到实际情况与申请 资料不符的情况，应该立即停止操作，恢复到实施前状态，并将实施结果标注为失败 且说明原因。
变更管理实施细则
目录
1 总则
1.1 文档简介
本文档是根据银行营运中心 IT 服务管理现状， 制定的变更管理规范。 本文档管理和 引导对 IT 系统的变更需求， 规范变更流程和行为， 维护 IT 系统完整性和提高服务质量。
1.2 适用范围
本文档描述仅限于对服务器硬件和操作系统等 IT 配置项的管理， 涉及部门包括灾备 与运维管理处、核心与机要系统运维处等与变更管理相关的处室。
行审阅和评估后，由变更申请人直属 / 主管领导批准的过程。
不管何种类型的变更，都必须获得变更申请人或变更发起人所在科室的变更批 准。变更配置研究员是通过专业技能和管理手段，对变更方案的合理性、准确 性、可行性进行研究，将变更实施方案提交给变更审批人。变更配置研究员对 变更内容的准确性负主责。 不管何种类型的变更，在通过变更审批后，都必须得到变更实施主管的确认。 变更实施主管的职责是确认变更类型是否正确，复核变更方案，同时着重关注 变更的实施方案，保障变更实施的可行。 如果变更实施主管对变更过程和结果引发争议，并且经过充分沟通，仍然无效 的情况下，变更实施主管可以把该变更请求上升至高级管理层进行裁决。
变更失败调查小组一般需要在变更失败后的两周内，发布失败变更调查报告。 失败变更调查报告主要包含以下几部分内容：
变更说明 失败现象和影响
实施过程描述 失败原因定位 后续行动方案和建议 失败调查报告发送给变更实施主管、变更审批人、主责任人所在团队的主管和 科长，并抄送其他审阅人员。
以下由变更申请人填写 申请人 变更 系统 名 称 / 主机名
变更 原因 及 变更内容 以下由变更实施人填写 预计 变更 日 期 变更实施计划
变更申请单
部门
申请日期 变更类型：
□ 例行变更 □ 常规变更 □ 紧急变更
变更时间 (预计起止时间 )
回退 计划
变更 影响
实施人签字：
以下由相关审批人填写 系统所属处室意见
负责人签字
日期
运行维护处意见
负责人签字
日期
惠普服务器运维团队 意见 负责人签字
说明： 对于例行变更和常规变更， 变更申请人需要将变更申请以书面的形式或电子邮件的 形式提交给变更审批人，但对于紧急变更，在非工作时间或条件不允许的情况下，允 许通过口头方式通知变更实施主管，事后再补足变更申请单。
3.2 变更的批准
变更的审阅是指为控制变更风险， 由专门的人员分别对变更方案和变更实施方案进
自定义时间窗口或批准的百度文库殊维护窗口
2.8 变更的计划
一个成功的变更，重要的因素是拥有完善的变更实施计划。 实施计划不仅包括变更设计规划、 实施规划，也包括计划的现场操作步骤和相应的 风险分析和回退计划，要做到有的放矢、弱化风险，从而
快速完成变更批准流程 充分理解、明确、掌握变更的实施步骤 选择合理的变更维护时间 完成变更的准备 安排最优的人员 做好对外通告等 同时，除紧急变更以外， 所有的变更都应该提前预约， 通过审批后再执行变更操作。 为了有效审阅变更计划和批准变更申请，我们定义三种变更类型服务级别如下： 例行变更
检查变更内容和变更步骤的合理性 检查变更请求所需的变更信息是否完整、准确 根据不同的变更类型，获得不同审批者签字 合理安排和协调变更的时间和相关资源 对变更的定期回顾、分析和绩效评估
2.4.2
不属于变更管理的内容
触发变更的需求是否合理 变更前测试工作的资源、案例、方法、工作量和质量 变更后的事件和问题是否的好合理解决 变更所设计的升级、扩容、移动、档案整理等
工作日工作时间内 9:00—15:00前提交变更申请 审阅完成时间：当前工作日 变更实施时间：变更通常安排在周五下班后实施 常规变更 工作日工作时间内 9:00—15:00前提交变更申请 审阅完成时间：第二工作日 变更实施时间：审批通过后 2个工作日内开始实施
紧急变更 不管是否为工作日 审阅完成时间：立即 变更实施时间：审批通过后立即或遵循特殊的变更维护窗口
5 变更的确认与关闭
对于变更 “失败”的变更，由变更实施人跟进，调查造成该变更失败的根因， 主笔撰写变更失败记录报告。 若涉及其它团队工作，其它团队负责提交失败原因分 析报告作为变更失败记录报告附件。
变更涉及多团队合作，则由变更实施人获得授权后组织各团队成立变更失败调 查小组，跟进，调查造成该变更失败的根本原因。
2.5 变更管理角色
变更管理中，我们定义了如下 5种角色和团队 变更申请人或发起人 变更配置研究员 变更审批人（应用系统审批人、运维管理审批人、变更实施主管） 变更实施人 高级管理层审批人
2.6 变更类型
根据变更的实施风险和紧急程度，定义了三种变更类型，以遵循不同的审批流程。 它们是例行变更、常规变更和紧急变更。
同时发送给配置管理员，通知其更新配置数据库。只有变更实施和变更结果确认同时 成功，该变更才可标识为成功。
4.2 变更的关闭
变更的关闭并不依赖于变更是否成功。根据变更的实际实施情况，变更的关闭可以 有以下 3 个关闭代码。
成功 失败
取消 其中失败，又可以有以下几个原因代码。
研发失误（变更开发逻辑存在问题） 管理问题（测试不足或版本、环境问题） 文档错误（文档描述不完整或不准确） 计划失误（安排的变更时间、人力或沟通出现纰漏） 实施失误（变更实施失误） 系统缺陷（系统存在缺陷，导致变更失败）
例行变更 –日常维护工作中定期或定时的变更操作，如补丁安装、病毒库更新等 –是可以计划和预约的，可以短期内实施 –变更影响的范围小，对应用影响小或无影响 –变更涉及的部门少，需其它人员少量协作或无需协作
– 操作风险小，变更容易回退 常规变更 –完全可以计划和预约 –变更影响的范围较大，对应用影响较大 –变更涉及的部门较多，需其它人员协作工作 –操作风险较大，变更不容易回退 紧急变更 紧急变更则必须要满足以下三个条件中的一个或多个 –面向客户的生产系统已经出现严重故障，必须要立即通过变更解决 –面向客户的生产系统存在已证实的，随时可能发生的重大故障，必须要通过 变更立即解决 –不可抗的行政要求（人民银行、银监会或信息中心总机理室），必须要通过 变更立即满足
软件换版必须严格按照实施步骤操作，特别要注意备份环节。 变更实施结果必须如实记录，实施失败或部分失败时需要写明原因和现象。 变更完成后实施人应将签署后的变更申请单复印后转交运维处变更审批人存档。
4 变更的确认与关闭
4.1 变更的确认
在变更成功实施完成后，变更实施人会在之后第一个工作日内通知变更递交人，确 认变更结果是否达到预期目的，变更结果同步发送消息给变更实施主管和变更审批人。
对于例行变更，对于有预先授权的变更可以由变更实施主管批准，无预先授权 的变更由应用审批人或运维审批人批准。批准后的选择合适的变更窗口，安排 资源进行实变更。 对于常规变更，由变更发起人所在处室领导进行批准，同时提交运维处负责人 批准，最后交由变更实施团队进行实施。变更审批人有责任从多角度来审阅变 更的内容和变更的实施，提出建设性的意见，协调各方的实施资源，以控制变 更的风险。 对于紧急变更，在变更审批人组织或授权变更实施主管召集相关的变更责任人 成立现场紧急变更小组进行变更的研究， 制定应急的变更措施和方案提交审批。 在非工作时间或条件不允许的情况下，允许通过口头方式批准，事后补足。
添加（ Add），在原有系统上的补充，例如补丁的安装、功能模块添加 变动（ Change），例如参数的调整、系统的重启、系统关闭，服务器状态变化 （测试 ->生产）
2.3 变更管理的目标：
变更管理通过标准统一的方法和步骤来管理和控制所有对 IT生产环境有影响的变 更。正确管理和引导变更需求，计划和记录变更操作，安全高效的实施变更操作，减 少和消除变更的负面影响。