应急恢复预案模板

1、 网络系统应急恢复预案网络系统应急恢复预案 密级说明密级说明 一般商密一般商密 此计划中包含的信息不得以任何形式泄露给此计划中包含的信息不得以任何形式泄露给 xx 银行信息技银行信息技 术部以外的人员。术部以外的人员。 编写： 批准： 编制时间： 年 月 文档修订记录文档修订记录 编号编号版本号版本号修订内容简述修订内容简述修订日期修订日期作者作者审核审核 目目 录录 1.1.概述概述.5 5 1.1. 介绍.5 1.2. 目标.5 1.3. 原则.5 1.4. 依据.6 1.5. 适用对象及范围.6 2.2.系统固有属性系统固有属性.6 6 2.1. 网络基本信息描述.6 2.1.1.网络拓

2、扑图 .6 2.1.2.核心网络设备描述.6 2.1.2.1.核心网络设备基本信息描述.6 2.1.2.2.核心网络设备板卡信息描述.6 2.1.2.3.核心网络设备路由信息描述.6 2.1.2.4.互连端口分配.6 2.1.2.5.设备互连地址分配.6 2.1.2.6.核心交换机连接表信息.6 2.1.2.7.服务器接口信息表信息.6 2.2. 系统相关文档列表.6 2.3. 系统可能存在的风险、损失和影响分析.7 2.4. 需要处置的风险场景.8 3.3.应急处置说明应急处置说明.9 3.1. 应急处置条件和资源.9 3.2. 应急处置流程.10 3.3. 网络故障定位.10 3.3.1.

3、明确故障影响范围 .10 3.3.2.判定故障产生原因.10 3.3.3.判定故障恢复所需时间.10 3.3.4.要求服务商协助定位故障.10 3.4. 网络故障分析流程.10 3.5. 应急处置过程及步骤说明.11 3.5.1.硬件故障处理步骤.12 3.5.2.线路故障处理步骤.12 3.5.3.端口故障处理步骤.12 3.5.4.软件故障处理步骤.12 3.5.5.机房环境问题处理步骤.12 3.5.6.其它突发性故障处理步骤.12 3.6. 对没有满足判断准则的处理办法.12 3.6. 应急终止条件及后续保障措施.12 4.4.预案说明预案说明.1313 4.1. 应急预案编制、验证、

4、评审、发布说明.13 4.2. 预案修订与报备.14 4.3. 预案培训与演练.14 4.4. 预案分发范围及保管地点.15 5.5.配套材料说明配套材料说明.1515 5.1. 网络应急组织体系及联系方式.15 5.2. 相关附件.15 5.3. 其他配套资料索引.15 1.概述概述 1.1.介绍 范例：本预案用于网络系统突发事件应急响应和恢复工作的参考文件和检查表。是为 规范各种网络紧急事件的处理程序，提高故障处理效率，以确保分行网络系统、业务系统 正常进行所依据的策略、资源、步骤和流程。 1.2.目标 范例： 对 xx 银行 xx 分行的网络系统的非计划性停止进行快速反应； 加速网络系统

5、的硬件、软件、端口和通讯的恢复； 减少突发事件对 xx 银行技术和业务运营的影响，减少财务损失； 减少突发事件造成的混乱； 减少由于疏忽和遗漏造成的工作错误。 1.3.原则 应急预案编制应遵循以下基本原则： 有效性原则：应急预案应在一定范围内及时有效地应对紧急事件。 可操作性原则：应急预案应具有较强的可操作性，宜以流程图等形式表示。 规范性原则：应急预案的编制应符合国家、行业规范、监管部门、上级行的要求。 一致性原则：总体预案与专项预案、以及专项预案之间应保持统一和相互配合。 可扩展性原则：应急预案的编制应针对现行信息系统，也应考虑将来可能的扩展。 保密性原则：应急预案应根据有关制度，严格注明

6、保密级别和范围。 1.4.依据 该预案依据国家的法律法规、金融行业规范、监管部门监管要求及总行相关管理制度 进行编写制定。 1.5.适用对象及范围 范例：本预案仅适用于 xx 银行 xx 分行网络系统的非计划性的生产类紧急事件 4 级、5 级及突发事件 6、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.

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

8、务、信誉及形象造成不良影响。 端口、线路风险 端口硬件、端口配置、线路中断引起的网络故障 有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展， 对分行的业务、信誉及形象造成不良影响。 操作风险 网络维护人员操作失误导致的网络设备不可用 有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展， 对分行的业务、信誉及形象造成不良影响。 机房环境风险 机房内 ups、pdu、空调原因而导致的网络故障，如 ups、pdu 停止供电而引起 网络设备断电宕机，空调控温失败而导致网络设备超过温度警戒线而自动重 启。 有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，

9、对分行的业务、信誉及形象造成不良影响。 病毒爆发或网络入侵风险 大面积的病毒爆发或网络入侵有可能会导致网络等异常中止、导致与其相连 的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及 形象造成不良影响。 自然灾害风险（火灾、水灾、地震） 自然灾害类的事件有可能会导致网络系统的硬件遭到破坏，导致与其相连的 系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形 象造成不良影响。 结合风险分析结果和中断损失影响程度，确定各业务功能对恢复时间的敏感程度要 求，确定信息系统应急恢复的 rto、rpo 技术指标。 恢复时间目标（rto： recovery time objec

10、tive）灾难发生后，系统或业务 功能从停顿到必须恢复的时间要求：（按照系统要求确定） 恢复点目标（rpo：recovery point objective）灾难发生后，系统和数据必 须恢复到的时间点要求： （按照系统要求确定） 2.4.需要处置的风险场景（各分行可结合实际酌情删减） 硬件故障硬件故障：经分析可以明确定位是路由器、交换机、防火墙等网络设备由于硬件出 错而导致的网络故障，如板卡、引擎等硬件问题。 问题现象： 频繁/突然重启，并产生异常 crash 信息。 进入 rmon 状态；或网络设备死机，console 端口无响应； 网络设备板卡、引擎、电源、风扇等工作异常，相关模块的 le

11、d 指示灯异常 板卡无法识别。 设备无法启动。 问题分析： 硬件故障有以下可能： 设备老化； 雷击，或者异常电压引起硬件故障； 人工意外、运输意外损坏； 当前辽宁省分行和辖行骨干设备都具有冗余性。具有冗余性的设备出现单台 硬件故障，虽然不会影响生产，但存在隐患，需及时处理。冗余设备同时出 现硬件故障需要使用备件及时替换，否则会影响生产。 端口故障： 问题现象： 问题分析： 软件故障： 问题现象： 问题分析： 机房环境问题： 问题现象： 问题分析： 其它突发性故障： 3.应急处置说明应急处置说明 3.1.应急处置条件和资源 应急预案的启动条件 应急处置资源清单和环境描述 硬件设备： 软件资源：

12、预案实施地点： 应急处置实施人员 故障接报： 故障分析： 应急处置方案决策： 故障应急恢复： 3.2.应急处置流程 上报流程 决策流程 决策通知流程 确定恢复顺序。根据业务恢复需求和业务功能的相互依赖关系和程度，确定系统的 恢复顺序。 考虑在资源不能保障的情况下的业务降级处理的策略。 范例提供：范例提供： 按系统恢复顺序进行恢复。按系统恢复顺序进行恢复。 在系统不能恢复的情况下，通知业务部门启动业务连续性方案。在系统不能恢复的情况下，通知业务部门启动业务连续性方案。 应急处置流程图 3.3.网络故障定位 在分行网络出现故障时首先应对网络故障进行定位，包括明确故障影响的范围，判断 故障所造成的危

13、害程度以及初步判定故障产生的原因，并由此进一步制定相应的紧急处理 措施。 3.3.1.明确故障影响的范围 确定网络故障是发生在分行网络结构中的个别区域、局部区域，还是整个网络系统的 故障。确定故障对分行各业务应用系统的影响程度。 3.3.2.判定故障产生的原因 根据故障现象并通过 ping、traceroute 以及简单 show 命令初步判定故障是配置错误、 设备硬件故障还是线路故障或者是由于供电原因导致的设备断电。 3.3.3.判定故障恢复所需时间 判断网络故障通过应急处理是否可以在短时间内恢复。 3.3.4.要求服务商协助定位故障 出现网络故障后，若无法及时进行故障的定位与处理，需要立刻

14、联系服务商进行协助 进行故障定位与处理。 3.4.网络故障分析流程 3.5.应急处置过程及步骤说明 可结合上述风险场景分类从引发业务中断的线路故障、硬件故障、端口故障、软件故可结合上述风险场景分类从引发业务中断的线路故障、硬件故障、端口故障、软件故 障、机房环境问题分别表述应急处置过程及步骤，如涉及到指令操作，要细化到具体的指障、机房环境问题分别表述应急处置过程及步骤，如涉及到指令操作，要细化到具体的指 令。对于风险场景，各分行可结合实际酌情删减。令。对于风险场景，各分行可结合实际酌情删减。 3.5.1.线路故障处理步骤 3.5.2.硬件故障处理步骤 3.5.3.软件故障处理步骤 3.5.4.

15、机房环境问题处理步骤 3.5.5.其它突发性故障处理步骤 3.6.对没有满足判断准则的处理办法 寻求总行技术人员支持 联系电话： 联系人： 联系电话： 联系人： 联系电话： 联系人： 联系电话： 联系人： 3.7.应急终止条件及后续保障措施 应急终止条件：业务能够正常办理，对外服务恢复正常。 后续保障措施：业务部门做好各类交易、业务的测试、验证，确保所有业务 均可以正常受理；保障部门做好对外客户的进一步解释与应答工作，对外通 知业务恢复，可以正常办理。 4.预案预案本身的管理本身的管理 4.1.应急预案编制、验证、评审、发布 应急预案编制、验证、评审、发布 应急预案由系统负责人牵头，组织成立由

16、技术人员、业务人员、信息安全管 理人员等构成的编制组共同负责编写。 由编制组共同编制具体的测试方案对其进行测试验证，验证应急预案在具体 场景下的有效性，并根据测试结果及时修正，待测试验证通过后方可进行评 审。 系统负责人将验证通过的应急预案提交给信息技术部高级经理，由其组织相 关部门高级经理进行评审，系统负责人根据评审提出的问题疑点进行修正， 再次提交审核，直到审核通过。 应急预案评审通过后，由系统负责人发布实施，保证及时通知到预案中涉及 的所有相关人员。 评审要点说明 完整性：信息安全类突发事件应急恢复预案应包含应急恢复的整个过程，以 及应急恢复所需的尽可能全面的数据和资料； 易用性：预案应

17、运用易于理解的语言和图表，并适合在紧急情况下使用； 明确性：预案应采用清晰的结构，对资源进行清楚的描述，工作内容和步骤 应具体，每项工作应有明确的责任人； 有效性：预案应尽可能满足突发事件发生时进行恢复的实际需要，并保持与 实际系统和人员组织的同步更新； 兼容性：应急恢复预案应与其它应急预案体系有机结合。 4.2.预案修订与报备 应急预案的修订 应急预案的修订由信息技术部系统负责人负责，常规修订周期为半年一次。 由于人员信息、资源变动或制度变更可按照应急预案的常规修订周期进行修 改。 由于系统重要变更、流程、技术发生变化可随时对预案进行修改，以保证应 急预案的可用性。 在应急预案演练、实施后应

18、根据实际情况及时地进行评估总结，对预案第一 时间进行修订，以保证应急预案的可用性。 应急预案的报备 应急预案要在每年初向总行、监管部门进行报备。 4.3.预案培训与演练 应急预案的培训 应急预案的培训工作由系统负责人牵头负责，在预案编制完成后要及时组织 预案中涉及的所有相关人员开展预案的培训。 如发生系统重要变更、流程、技术等重要变动，系统负责人要及时组织相关 人员开展预案的培训，以保证所有相关人员及时熟悉和掌握预案最新内容。 应急预案的演练 应急演练要保证定期性、常规性，一般情况下，重要类信息系统每年至少演 练一次，一般类信息系统要根据情况制定演练周期，一般为每三年全覆盖一 次。 应急演练由系统负责人牵头负责开展，演练前应确定演练范围、编写演练方 案并做好人员、资金和物资的准备工作。 应急预案演练应定期开展，并满足监管部门的要求； 应急演练结束后应及时总结，并根据演练情况更新应急预案。 4.4.预案分发范围及保管地点 应急预案电子文档由系统负责人管理。 应急预案电子文档、纸质文档由文档管理员进行保管，并将电子文档上传文档服务 器进行保存。 5.配套材料说明配套材料说明 5.1.应急组织体系及联系方式（也可另行成册） 网络应急组织体系及联系方式网络应急组织体系及联系方式