42、XX变更失败恢复程序说明文件.doc

XXX公司

变更失败恢复程序说明书

制定目标

为了建立对变更的合理有效的控制管理，要求对当前正式的变更进行深思熟虑，仔细的检测和深入的评估，以降低变更带来的风险，为用户提供高效可靠的业务服务。

适用范围

修改系统配置选项、补丁升级、数据库后台操作、变更批处理任务、修改源程序、更换服务器等基础硬件架构服务器网络等基础硬件的更换、系统配置变更、操作系统及数据库等补丁升级、应用程序变更（包括所有由研发保障与管理部负责的程序开发和变更以及外包应用程序的变更）等内容。

紧急变更

恢复计划：制定当变更失败时可以恢复到变更之前状态的方法。

紧急变更：系统发生了紧急的故障，不立即处理可能会导致严重的后果。这种情况下申请人可以先通过相关系统拥有者。

管理细则

变更申请

在执行系统变更之前，需要经过正式的申请审批程序。触发变更的原因有多个方面，包括最终用户组、研发保障与管理部或者外部供应商等。另外，现存的运行环境的缺陷也可能会导致变更申请。

申请人须根据需要填写变更申请单，说明注明变更原因，并详细描述变更内容，经系统所有者部门主任审批后，交由研发保障与管理部审核批准。

对于需要研发保障与管理部进行操作的系统变更，研发保障与管理部应主任根据申请人的变更描述情况，及判断变更类型：补丁升级、配置变更、硬件更换和程序变更。初步估计变更的影响范围，并判断变更的风险等级，从而确定变更实施的优先级。

风险等级2和风险等级3的变更经研发保障与管理部主任审批后方可执行，风险等级为1的变更经研发保障与管理部主任审批后还须征得研发保障与管理部直属副总批准方可执行。

变更实施

变更申请经审批后，由研发保障与管理部主管确定变更的实施人，详细划分员工在变更实施中的不同职责，确保不发生不适当的职责交叉的情况。

服务器网络等基础硬件的更换、系统配置变更、操作系统及数据库等补丁升级由研发保障与管理部服务器管理员负责执行。

公司内部小型应用程序变更由研发保障与管理部程序员负责程序开发执行。

需要外包的应用程序变更由相应的第三方供应商负责程序开发实施，在实施过程中，研发保障与管理部要给予充分的配合。

在实施过程中实施人要制定并维护相关的文档,并及时进行文档版本的升级，所有的版本必须保留，以反映变动的历史。变更若涉及程序代码的开发或更新，也必须进行相应的版本控制。

考虑到变更实施的风险性，在执行变更之前，应根据实际情况必须制定可行的恢复计划，以保证变更失败时可以恢复到变更前的状态，例如执行系统配置变更前可对系统原有配置进行备份、执行应用程序变更前必须对原来的程序代码进行备份。如果变更对现有系统的影响很小，可省略制定恢复计划的步骤。

在变更实施到正式环境以后，必须检验变更是否达到了预期的效果，如果变更失败，要立即执行恢复计划，将系统恢复到变更前的状态，并将失败的原因记录到申请单上，反馈给申请人，如要再次执行变更必须重新填写申请。

变更成功后，实施人根据需要对用户手册等相关文档进行更新。

变更失败恢复细则

恢复/预警

实施人员应根据与开发、测试部干系人的沟通结果，确定进行发布恢复操作或发布预警操作：

发布恢复：使发布环境（β环境或生产环境）返回到本次发布前的正常状态。为了更快捷的执行发布恢复操作，通常情况下在实施发布前应对发布环境进行备份，在发布失败后按下列顺序进行操作：

?关闭所发布的程序或服务；

?回滚至发布前的版本；

?启动当前版本的程序或服务；

发布预警：对于发布失败但无法执行发布恢复的，应对发布失败产生的风险进行评估，并将评估结果通报本次发布工作干系人。通报范围至少包括：

?本次发布所涉及到的产品部产品经理；

?运维部主管领导；

?开发部主管领导；

?测试部主管领导；