应急恢复预案模板

网络系统应急恢复预案密级说明一般商密此计划中包含的信息不得以任何形式泄露给XX银行信息技术部以外的人员。编写：批准：编制时间：年月文档修订记录编号版本号修订内容简述修订日期作者审核目 录1.概述51.1.介绍51.2.目标51.3.原则51.4.依据61.5.适用对象及X围62.系统固有属性62.1.网络基本信息描述62.1.1.网络拓扑图62.1.2.核心网络设备描述62.1.2.1.核心网络设备基本信息描述62.1.2.2.核心网络设备板卡信息描述62.1.2.3.核心网络设备路由信息描述62.1.2.4.互连端口分配62.1.2.5.设备互连地址分配62.1.2.6.核心交换机连接表信息62.1.2.7.服务器接口信息表信息62.2.系统相关文档列表62.3.系统可能存在的风险、损失和影响分析72.4.需要处置的风险场景83.应急处置说明93.1.应急处置条件和资源93.2.应急处置流程103.3.网络故障定位103.3.1.明确故障影响X围103.3.2.判定故障产生原因103.3.3.判定故障恢复所需时间103.3.4.要求服务商协助定位故障103.4.网络故障分析流程103.5.应急处置过程及步骤说明113.5.1.硬件故障处理步骤123.5.2.线路故障处理步骤123.5.3.端口故障处理步骤123.5.4.软件故障处理步骤123.5.5.机房环境问题处理步骤123.5.6.其它突发性故障处理步骤123.6.对没有满足判断准则的处理办法123.6.应急终止条件及后续保障措施124.预案说明134.1.应急预案编制、验证、评审、发布说明134.2.预案修订与报备144.3.预案培训与演练144.4.预案分发X围及保管地点155.配套材料说明155.1.网络应急组织体系及联系方式155.2.相关附件155.3.其他配套资料索引151. 概述1.1. 介绍X例：本预案用于网络系统突发事件应急响应和恢复工作的参考文件和检查表。是为规X各种网络紧急事件的处理程序，提高故障处理效率，以确保分行网络系统、业务系统正常进行所依据的策略、资源、步骤和流程。1.2. 目标X例： 对XX银行XX分行的网络系统的非计划性停止进行快速反应； 加速网络系统的硬件、软件、端口和通讯的恢复； 减少突发事件对XX银行技术和业务运营的影响，减少财务损失； 减少突发事件造成的混乱； 减少由于疏忽和遗漏造成的工作错误。1.3. 原则应急预案编制应遵循以下基本原则： 有效性原则：应急预案应在一定X围内及时有效地应对紧急事件。 可操作性原则：应急预案应具有较强的可操作性，宜以流程图等形式表示。 规X性原则：应急预案的编制应符合国家、行业规X、监管部门、上级行的要求。 一致性原则：总体预案与专项预案、以及专项预案之间应保持统一和相互配合。 可扩展性原则：应急预案的编制应针对现行信息系统，也应考虑将来可能的扩展。 某性原则：应急预案应根据有关制度，严格注明某级别和X围。1.4. 依据该预案依据国家的法律法规、金融行业规X、监管部门监管要求及总行相关管理制度进行编写制定。1.5. 适用对象及X围 X例：本预案仅适用于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.设备互连地址分配：2.1.2.6.核心交换机连接表：2.1.2.7.服务器接口信息表：2.2. 系统相关文档列表填写与网络系统应急恢复相关的文档名称或列表2.3. 系统可能存在的风险、损失和影响分析 硬件风险 网络设备硬件故障导致的停机或者部分功能不可用有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 软件风险 操作系统崩溃有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 网络配置、策略有误有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 端口、线路风险 端口硬件、端口配置、线路中断引起的网络故障有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 操作风险 网络维护人员操作失误导致的网络设备不可用有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 机房环境风险 机房内UPS、PDU、空调原因而导致的网络故障，如UPS、PDU停止供电而引起网络设备断电宕机，空调控温失败而导致网络设备超过温度警戒线而自动重启。有可能会导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 病毒爆发或网络入侵风险 大面积的病毒爆发或网络入侵有可能会导致网络等异常中止、导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 自然灾害风险（火灾、水灾、地震） 自然灾害类的事件有可能会导致网络系统的硬件遭到破坏，导致与其相连的系统发生宕机，进而引发分行业务无法正常开展，对分行的业务、信誉及形象造成不良影响。 结合风险分析结果和中断损失影响程度，确定各业务功能对恢复时间的敏感程度要求，确定信息系统应急恢复的RTO、RPO技术指标。 恢复时间目标（RTO： Recovery Time Objective）灾难发生后，系统或业务功能从停顿到必须恢复的时间要求：（按照系统要求确定） 恢复点目标（RPO：Recovery Point Objective）灾难发生后，系统和数据必须恢复到的时间点要求：（按照系统要求确定）2.4. 需要处置的风险场景（各分行可结合实际酌情删减） 硬件故障：经分析可以明确定位是路由器、交换机、防火墙等网络设备由于硬件出错而导致的网络故障，如板卡、引擎等硬件问题。 问题现象：n 频繁/突然重启，并产生异常CRASH信息。n 进入RMON状态；或网络设备死机，console端口无响应；n 网络设备板卡、引擎、电源、风扇等工作异常，相关模块的LED指示灯异常板卡无法识别。n 设备无法启动。 问题分析：硬件故障有以下可能：n 设备老化；n 雷击，或者异常电压引起硬件故障；n 人工意外、运输意外损坏；n 当前某省分行和辖行骨干设备都具有冗余性。具有冗余性的设备出现单台硬件故障，虽然不会影响生产，但存在隐患，需及时处理。冗余设备同时出现硬件故障需要使用备件及时替换，否则会影响生产。 端口故障： 问题现象： 问题分析： 软件故障： 问题现象： 问题分析： 机房环境问题： 问题现象： 问题分析： 其它突发性故障：3. 应急处置说明3.1. 应急处置条件和资源 应急预案的启动条件 应急处置资源清单和环境描述 硬件设备： 软件资源： 预案实施地点： 应急处置实施人员 故障接报： 故障分析： 应急处置方案决策： 故障应急恢复：3.2. 应急处置流程 上报流程 决策流程 决策通知流程 确定恢复顺序。根据业务恢复需求和业务功能的相互依赖关系和程度，确定系统的恢复顺序。 考虑在资源不能保障的情况下的业务降级处理的策略。X例提供： 按系统恢复顺序进行恢复。 在系统不能恢复的情况下，通知业务部门启动业务连续性方案。 应急处置流程图3.3. 网络故障定位在分行网络出现故障时首先应对网络故障进行定位，包括明确故障影响的X围，判断故障所造成的危害程度以及初步判定故障产生的原因，并由此进一步制定相应的紧急处理措施。3.3.1. 明确故障影响的X围确定网络故障是发生在分行网络结构中的个别区域、局部区域，还是整个网络系统的故障。确定故障对分行各业务应用系统的影响程度。3.3.2. 判定故障产生的原因根据故障现象并通过PING、Traceroute以及简单show命令初步判定故障是配置错误、设备硬件故障还是线路故障或者是由于供电原因导致的设备断电。3.3.3. 判定故障恢复所需时间判断网络故障通过应急处理是否可以在短时间内恢复。3.3.4. 要求服务商协助定位故障 出现网络故障后，若无法及时进行故障的定位与处理，需要立刻联系服务商进行协助进行故障定位与处理。3.4. 网络故障分析流程3.5. 应急处置过程及步骤说明可结合上述风险场景分类从引发业务中断的线路故障、硬件故障、端口故障、软件故障、机房环境问题分别表述应急处置过程及步骤，如涉及到指令操作，要细化到具体的指令。对于风险场景，各分行可结合实际酌情删减。3.5.1. 线路故障处理步骤3.5.2. 硬件故障处理步骤3.5.3. 软件故障处理步骤3.5.4. 机房环境问题处理步骤3.5.5. 其它突发性故障处理步骤3.6. 对没有满足判断准则的处理办法 寻求总行技术人员支持 联系：联系人： 联系： 联系人： 联系： 联系人： 联系： 联系人：3.7. 应急终止条件及后续保障措施 应急终止条件：业务能够正常办理，对外服务恢复正常。 后续保障措施：业务部门做好各类交易、业务的测试、验证，确保所有业务均可以正常受理；保障部门做好对外客户的进一步解释与应答工作，对外通知业务恢复，可以正常办理。4. 预案本身的管理4.1. 应急预案编制、验证、评审、发布 应急预案编制、验证、评审、发布 应急预案由系统负责人牵头，组织成立由技术人员、业务人员、信息安全管理人员等构成的编制组共同负责编写。 由编制组共同编制具体的测试方案对其进行测试验证，验证应急预案在具体场景下的有效性，并根据测试结果及时修正，待测试验证通过后方可进行评审。 系统负责人将验证通过的应急预案提交给信息技术部高级经理，由其组织相关部门高级经理进行评审，系统负责人根据评审提出的问题疑点进行修正，再次提交审核，直到审核通过。 应急预案评审通过后，由系统负责人发布实施，保证及时通知到预案中涉及的所有相关人员。 评审要点说明 完整性：信息安全类突发事件应急恢复预案应包含应急恢复的整个过程，以及应急恢复所需的尽可能全面的数据和资料； 易用性：预案应运用易于理解的语言和图表，并适合在紧急情况下使用； 明确性：预案应采用清晰的结构，对资源进行清楚的描述，工作内容和步骤应具体，每项工作应有明确的责任人； 有效性：预案应尽可能满足突发事件发生时进行恢复的实际需要，并保持与实际系统和人员组织的同步更新； 兼容性：应急恢复预案应与其它应急预案体系有机结合。4.2. 预案修订与报备 应急预案的修订 应急预案的修订由信息技术部系统负责人负责，常规修订周期为半年一次。 由于人员信息、资源变动或制度变更可按照应急预案的常规修订周期进行修改。 由于系统重要变更、流程、技术发生变化可随时对预案进行修改，以保证应急预案的可用性。 在应急预案演练、实施后应根据实际情况及时地进行评估总结，对预案第一时间进行修订，以保证应急预案的可用性。 应急预案的报备 应急预案要在每年初向总行、监管部门进行报备。4.3. 预案培训与演练 应急预案的培训 应急预案的培训工作由系统负责人牵头负责，在预案编制完成后要及时组织预案中涉及的所有相关人员开展预案的培训。 如发生系统重要变更、流程、技术等重要变动，系统负责人要及时组织相关人员开展预案的培训，以保证所有相关人员及时熟悉和掌握预案最新内容。 应急预案的演练 应急演练要保证定期性、常规性，一般情况下，重要类信息系统每年至少演练一次，一般类信息系统要根据情况制定演练周期，一般为每三年全覆盖一次。 应急演练由系统负责人牵头负责开展，演练前应确定演练X围、编写演练方案并做好人员、资金和物资的准备工作。 应急预案演练应定期开展，并满足监管部门的要求； 应急演练结束后应及时总结，并根据演练情况更新应急预案。4.4. 预案分发X围及保管地点 应急预案电子文档由系统负责人管理。 应急预案电子文档、纸质文档由文档管理员进行保管，并将电子文档上传文档服务器进行保存。5. 配套材料说明5.1. 应急组织体系及联系方式（也可另行成册）网络应急组织体系及联系方式角色某办公室移动家庭(一) 分管行长（主管IT）应急指挥组组长(二)技术部门负责人应急指挥组副组长(三) 应急恢复团队成员网络恢复小组成员网络维保公司人员通讯运营商人员安全管理员技术类文档管理员5.2. 相关附件 附件一：应急演练计划表 附件二：应急演练总结表5.3. 其它配套资料索引常见问题排查手册、各类操作手册、知识库、维护手册、常规故障分析及处理办法、备件统计等附件一:应急演练计划表编号：计划演练时间演练地点牵头部门部门领导审批责任人评估人演练类型（注1）演练涉及系统参与部门及人员演练场景1（注2）演练场景2演练场景3备注注1：应急演练可分为完全演练和部分演练。完全演练需采用真实环境或实战方式进行，部分演练可采用变通的方式以减少对业务的影响，如桌面演练。注2：演练场景中的具体演练步骤可以作为应急演练计划的附件。附件二:应急演练总结表演练时间演练地点演练涉及系统指挥组长评估人记录人复核人演练情况(阐述此次演练的场景、演练结果、用时、参与人员、取得的经验等)演练中发现的问题（阐述演练中发现的问题、解决问题所花时间、预案中存在的不足等）改进计划（包括修改应急预案）风险部签字确认审计部签字确认业务部门签字确认备注18 / 18