ERP项目Disaster recover.docVIP

灾难恢复流程 作者: 日期: 版本: 目录 文档目的 3 关键联系信息 3 灾难恢复流程 3 术语和定义 3 事件管理检查单 5 业务部门恢复步骤 9 重启程序 14 灾难恢复联系清单 17 紧急情况联系清单 17 执行人联系清单 17 供应商 18 有效的服务合同 19 有效期 19 签署批准申请 21 文档目的 此文档的目的在于定义在出现灾难恢复的情况时的操作流程，此文档应该经常更新联系信息。 关键联系信息 姓名 小组 联系号码 电子邮件地址 灾难恢复流程 术语和定义 步骤 用连续的数字表示灾难恢复步骤 行动 灾难恢复过程中需要执行的程序 负责人 有关灾难恢复行动的责任人 预计处理时间 灾难恢复过程的预估时间。这个时间有待于我们与STC的 Basis人员和IT人员商量决定。 实际处理时间 处理时间，当灾难真的发生时，实际的恢复时间。此时间 可用于更新此文档的相关内容。 是否完成 灾难恢复行动的检验栏。如果完成，选“是”，否则选“否”。 签名 当灾难恢复步骤完成，由相关人员或IT经理签署确认。 事件管理检查单 事件管理检查单用于事件的发生直到灾难的恢复。 步骤 行动 负责人 预计处理时间 实际处理时间 是否完成 ( 签名 备注 目前估计 实际时间 预测最大的可接受的停工期 根据STC在SAP系统中紧急事件处理的流程，最大的可接受的停工期应该根据主要用户和每个流程来决定。 恢复的时间将决定最大的可接受的停工期，这个时间是指业务部门在发生灾难事件后无论在工作日和非工作日都无法进行业务操作的时间。 IT 经理，每个模组的超级用户 N/A N/A 是 否 经与客户的讨论，最大的可接受的停工期应该在SAP上线前就定下来。 收到通知 当收到一个潜在的“灾难”或事件的通知，IT经理和总部的SAP帮助台应该得到一个简短的描述： 事件的种类； 任何损坏，类型和数量； 任何持续的损坏. 每个部门的IT 负责人，每个部门的主要用户。他们将向IT经理和总部的SAP帮助台报告。 10 分钟 从 ___:____am/pm 开始 到 ___:____am/pm 结束 是 否 每个部门的IT负责人都已经参与，而每个部门的主要用户尚未参与。 确认通知 如果可能就确认通知。 如果清楚来源，则进行下一步，如果不清楚来源，则电话确认其身份或联系其他人确认其身份。 硬件和SAP Basis是由IT经理负责，除了Basis的其他SAP部分由SAP帮助台负责。 5 分钟 从: ___:____am/pm开始 到: ___:____am/pm结束 是 否 初步毁坏情况估计 确认一个初步的毁坏情况. IT 经理 10 分钟 从: ___:____am/pm开始 到: ___:____am/pm结束 是 否 事件评估/灾难提升方法 检查最大的可接受的停工期，确认是否有足够的时间等待灾难修复或将灾难升级（例如：向信息系统总监报告） IT 经理 5 分钟 从: ___:____am/pm开始 到: ___:____am/pm结束 是 否 检查与outsource合伙人的服务协议级别。 如果事件评估显示事件无法由STC的IT队伍来恢复，就应该在最短的时间内联系outsourse的硬件供应商和应用服务商联系。 以下是应该考虑的问题： 硬件商能在多少时间内提供替代的硬件？ 是否由足够的签约的硬件供应商？ 灾难发生时，在硬件能保证的情况下是否有足够的签约服务来完成灾难恢复？ IT 经理 10 分钟 从: ___:____am/pm开始 到: ___:____am/pm结束 是 否 业务部门恢复步骤 业务部门恢复步骤是灾难发生到灾难恢复的业务功能详细步骤。 步骤 行动 负责人 预计处理 时间 实际处理时间 是否完成 ( 签名 备注 目前估计 实际时间 灾难恢复条件 当灾难事件发生后，评估现有的灾难恢复步骤是否对特有的恢复条件适用是很有必要的，以下是要考虑的问题： 什么时候灾难恢复计划适用？ 硬件和SAP Basis是由IT经理负责，除了Basis的其他SAP部分由SAP帮助台负责。 10 分钟 从: ___:____am/pm开始 到: ___:____am/pm结束 是 否 灾难恢复程序的的执行 一个详细的灾难恢复程序应该由特定人员确定，以确保灾难发生时能够得到执行，详细的恢复程序