应急恢复预案模板

1、网络系统应急恢复预案密级说明般商密此计划中包含的信息不得以任何形式泄露给XX银行信息技术部以外的人员。编写: 批准: 编制时间:文档修订记录编P版本号修订内容简述修订日期作者审核1.概述5.介绍5.目标5.原则5.依据6.适用对象及范围 6.2._系统固有属性6.网络基本信息描述6.网络拓扑图6.核心网络设备描述 6.核心网络设备基本信息描述 6.核心网络设备板卡信息描述 6.核心网络设备路由信息描述 6.互连端口分配6.设备互连地址分配6.核心交换机连接表信息 6.服务器接口信息表信息 6.系统相关文档歹表6.系统可能存在的风险、损失和影响分析 7.需要处置的风险场景8.3._应急处置说明9

2、_应急处置条件和资源9.应急处置流程1.0.网络故障定位 1.0明确故障影响范围1.0判定故障产生原因1.0判定故障恢复所需时间10要求服务商协助定位故障10.网络故障分析流程10.应急处置过程及步骤说明1.1硬件故障处理步骤 1.2线路故障处理步骤 1.2端口故障处理步骤1.2软件故障处理步骤 1.2机房环境问题处理步骤 12其它突发性故障处理步骤12.对没有满足判断准则的处理办法 1.21 应急终止条件及后续保障措施124 .预案说明13.应急预案编制、验证、评审、发布说明 1 3.预案修订与报备1.4.预案培训与演练1.4.预案分发范围及保管地点错误！未定义书签。55 .配套材料说明 1

3、5.网络应息组织体系及联系方式 1.5.相关附件1.5.其他配套资料索引 151. 概述1.1. 介绍范例：本预案用于网络系统突发事件应急响应和恢复工作的参考文件和检查表。是为规范各种网络紧急事件的处理程序， 提高故障处理效率，以确保分行网络系统、业务系统正常 进行所依据的策略、资源、步骤和流程。1.2. 目标范例：对XX银行XX分行的网络系统的非计划性停止进行快速反应；加速网络系统的硬件、软件、端口和通讯的恢复；减少突发事件对XX银行技术和业务运营的影响，减少财务损失；减少突发事件造成的混乱；减少由于疏忽和遗漏造成的工作错误。1.3. 原则应急预案编制应遵循以下基本原则：有效性原则：应急预案

4、应在一定范围内及时有效地应对紧急事件。可操作性原则：应急预案应具有较强的可操作性，宜以流程图等形式表示。规范性原则：应急预案的编制应符合国家、行业规范、监管部门、上级行的要求。一致性原则：总体预案与专项预案、以及专项预案之间应保持统一和相互配合。可扩展性原则：应急预案的编制应针对现行信息系统，也应考虑将来可能的扩展。保密性原则：应急预案应根据有关制度，严格注明保密级别和范围。1.4. 依据该预案依据国家的法律法规、金融行业规范、监管部门监管要求及总行相关管理制度进行编写制定。1.5. 适用对象及范围范例：本预案仅适用于 XX银行XX分行网络系统的非计划性的生产类紧急事件4级、5级及突发事件6、

5、7、8级的应急处理。日常技术问题处置不适用本预案。2. 系统固有属性2.1. 网络基本信息描述2.1.1. 网络拓扑图：插入图表，或另做附件2.1.2. 核心网络设备描述2.1.2.1. 心网络设备基本信息描述：插入图表，或另做附件2.1.2.2. 核心网络设备板卡信息描述：插入图表，或另做附件2.1.2.3. 核心网络设备路由描述：插入图表，或另做附件2.1.2.4. 互连端口分配：插入图表，或另做附件2.1.2.5. 设备互连地址分配：插入图表，或另做附件2.1.2.6. 核心交换机连接表：插入图表，或另做附件2.1.2.7. 服务器接口信息表：插入图表，或另做附件2.2. 系统相关文档列

6、表填写与网络系统应急恢复相关的文档名称或列表2.3. 系统可能存在的风险、损失和影响分析硬件风险网络设备硬件故障导致的停机或者部分功能不可用有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。软件风险操作系统崩溃有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。网络配置、策略有误有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。端口、线路风险端口硬件、端口配置、线路中断引起的网络故障有可能会导致与其相连的系统发生宕机，进而引发分行业务无

7、法正常开展，对分行的业务、信誉及形象造成不良影响。操作风险网络维护人员操作失误导致的网络设备不可用有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。机房环境风险机房内UPS PDU、空调原因而导致白网络故障，如 UPS PDU停止供电而引起网络设备断电宕机， 空调控温失败而导致网络设备超过温度警戒线而自动重启。有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。病毒爆发或网络入侵风险大面积的病毒爆发或网络入侵有可能会导致网络等异常中止、导致与其相连的系统发生宕机，进而引发分行业务无法正常开

8、展，对分行的业务、信誉及形象 造成不良影响。自然灾害风险（火灾、水灾、地震）自然灾害类的事件有可能会导致网络系统的硬件遭到破坏，导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造 成不良影响。结合风险分析结果和中断损失影响程度，确定各业务功能对恢复时间的敏感程度要求，确定信息系统应急恢复的RT。RPO技术指标。恢复时间目标（RTO: Recovery Time Objective）灾难发生后，系统或业务功能从停顿到必须恢复的时间要求：填写内容（按照系统要求确定）恢复点目标（RPQ Recovery Point Objective ）灾难发生后，系统和数据必须恢

9、 复到的时间点要求：填写内容（按照系统要求确定）2.4. 需要处置的风险场景 （各分行可结合实际酌情删减）硬件故障：经分析可以明确定位是路由器、交换机、防火墙等网络设备由于硬件出错而导致的网络故障，如板卡、引擎等硬件问题。问题现象：频繁/突然重启，并产生异常CRASH言息。进入RMON状态；或网络设备死机，console端口无响应；网络设备板卡、引擎、电源、风扇等工作异常，相关模块的LED指示灯异常板 卡无法识别。设备无法启动。问题分析：硬件故障有以下可能：设备老化；雷击，或者异常电压引起硬件故障；人工意外、运输意外损坏；当前辽宁省分行和辖行骨干设备都具有冗余性。具有冗余性的设备出现单台硬 件

10、故障，虽然不会影响生产，但存在隐患，需及时处理。冗余设备同时出现硬 件故障需要使用备件及时替换，否则会影响生产。端口故障：填写内容问题现象：填写内容问题分析：填写内容软件故障：填写内容问题现象：填写内容问题分析：填写内容机房环境问题：填写内容问题现象：填写内容问题分析：填写内容其它突发性故障：填写内容3. 应急处置说明3.1. 应急处置条件和资源应急预案的启动条件填写内容应急处置资源清单和环境描述硬件设备：填写内容软件资源：填写内容预案实施地点：填写内容应急处置实施人员故障接报：填写内容故障分析：填写内容应急处置方案决策：填写内容故障应急恢复：填写内容3.2. 应急处置流程上报流程通过文字或图

11、表对流程进行表述决策流程通过文字或图表对流程进行表述决策通知流程通过文字或图表对流程进行表述确定恢复顺序。根据业务恢复需求和业务功能的相互依赖关系和程度，确定系统的 恢复顺序。填写内容考虑在资源不能保障的情况下的业务降级处理的策略。填写内容范例提供：按系统恢复顺序进行恢复。在系统不能恢复的情况下，通知业务部门启动业务连续性方案。应急处置流程图插入图表3.3. 网络故障定位判断故在分行网络出现故障时首先应对网络故障进行定位，包括明确故障影响的范围，障所造成的危害程度以及初步判定故障产生的原因，并由此进一步制定相应的紧急处理措 施。3.3.1.明确故障影响的范围确定网络故障是发生在分行网络结构中的

12、个别区域、 局部区域， 还是整个网络系统的故障。确定故障对分行各业务应用系统的影响程度。3.3.1. 判定故障产生的原因根据故障现象并通过PING、 Traceroute 以及简单 show 命令初步判定故障是配置错误、设备硬件故障还是线路故障或者是由于供电原因导致的设备断电。3.3.2. 判定故障恢复所需时间判断网络故障通过应急处理是否可以在短时间内恢复。3.3.3. 要求服务商协助定位故障出现网络故障后，若无法及时进行故障的定位与处理，需要立刻联系服务商进行协助进行故障定位与处理。3.4. 网络故障分析流程<可插入图表进行表述>3.5. 应急处置过程及步骤说明可结合上述风险场景

13、分类从引发业务中断的线路故障、硬件故障、端口故障、软件故障、机房环境问题分别表述应急处置过程及步骤，如涉及到指令操作，要细化到具体的指令。对于风险场景，各分行可结合实际酌情删减。3.5.1. 线路故障处理步骤<填写内容>3.5.2. 硬件故障处理步骤<填写内容>3.5.3. 软件故障处理步骤填写内容3.5.4. 机房环境问题处理步骤填写内容3.5.5. 其它突发性故障处理步骤填写内容3.6. 对没有满足判断准则的处理办法寻求总行技术人员支持联系电话：填写内容联系电话：填写内容联系电话：填写内容联系电话：填写内容联系人：填写内容联系人：填写内容联系人：填写内容联系人：填写

14、内容3.7. 应急终止条件及后续保障措施应急终止条件：业务能够正常办理，对外服务恢复正常。后续保障措施：业务部门做好各类交易、业务的测试、验证，确保所有业务均 可以正常受理；保障部门做好对外客户的进一步解释与应答工作，对外通知业 务恢复，可以正常办理。4. 预案本身的管理4.1. 应急预案编制、验证、评审、发布应急预案编制、验证、评审、发布应急预案由系统负责人牵头，组织成立由技术人员、业务人员、信息安全管理人员等构成的编制组共同负责编写。由编制组共同编制具体的测试方案对其进行测试验证，验证应急预案在具体场景下的有效性，并根据测试结果及时修正，待测试验证通过后方可进行评审。系统负责人将验证通过的

15、应急预案提交给信息技术部高级经理，由其组织相关部门高级经理进行评审，系统负责人根据评审提出的问题疑点进行修正，再次提交审核，直到审核通过。应急预案评审通过后，由系统负责人发布实施，保证及时通知到预案中涉及的所有相关人员。评审要点说明完整性：信息安全类突发事件应急恢复预案应包含应急恢复的整个过程，以及应急恢复所需的尽可能全面的数据和资料；易用性：预案应运用易于理解的语言和图表，并适合在紧急情况下使用；明确性：预案应采用清晰的结构，对资源进行清楚的描述，工作内容和步骤应具体，每项工作应有明确的责任人；有效性：预案应尽可能满足突发事件发生时进行恢复的实际需要，并保持与实际系统和人员组织的同步更新；兼

16、容性：应急恢复预案应与其它应急预案体系有机结合。4.2. 预案修订与报备应急预案的修订应急预案的修订由信息技术部系统负责人负责，常规修订周期为半年一次。由于人员信息、资源变动或制度变更可按照应急预案的常规修订周期进行修改。由于系统重要变更、流程、技术发生变化可随时对预案进行修改，以保证应急 预案的可用性。在应急预案演练、实施后应根据实际情况及时地进行评估总结，对预案第一时 间进行修订，以保证应急预案的可用性。应急预案的报备应急预案要在每年初向总行、监管部门进行报备。4.3. 预案培训与演练应急预案的培训应急预案的培训工作由系统负责人牵头负责，在预案编制完成后要及时组织预案中涉及的所有相关人员开

17、展预案的培训。如发生系统重要变更、流程、技术等重要变动，系统负责人要及时组织相关人 员开展预案的培训，以保证所有相关人员及时熟悉和掌握预案最新内容。应急预案的演练应急演练要保证定期性、常规性，一般情况下，重要类信息系统每年至少演练 一次，一般类信息系统要根据情况制定演练周期，一般为每三年全覆盖一次。应急演练由系统负责人牵头负责开展，演练前应确定演练范围、编写演练方案并做好人员、资金和物资的准备工作。应急预案演练应定期开展，并满足监管部门的要求；应急演练结束后应及时总结，并根据演练情况更新应急预案。4.4. 预案分发范围及保管地点应急预案电子文档由系统负责人管理。应急预案电子文档、纸质文档由文档管理员进行保管，并将电子文档上传文档服务器进行保存。5. 配套材料说明5.1. 应急组织体系及联系方式（也可另行成册）角色姓名办公室电话移动电话家庭电话邮箱（一）分管彳于长（主管应急指挥组组长（二）技术部门负责人应急指挥组副组长（三）应急恢复团队成员网络恢复小组成员网络维保公司人员通讯运营商人员安全管理员技术类文档管理员5.2. 相关附件附件一：应急演练计划表附件二：应急演练总结表5.3. 其它配套资料索引常见问题排查手册、各类操作手册、知识库、维护手册、常规故障分析及处理办法、备件统计等附件一：应急演练计划表编号:计划演练时间演练地点牵头部门部门领导审批责任人评估人演练类型（注1）演练