存储级数据容灾方案模板 - 图文

方案设计

1. 用户现状与需求

1.1. 用户IT系统现状

用户现有系统包括数据库、应用、WEB、邮件等系统，虽然是双机架构，但是其稳定性和可靠性都没有达到核心系统应该具备的标准，而且直连的存储架构对于性能和管理型都有一定的局限性。

业务数据是企业业务的生命线，如何保护好计算机系统里存储的数据，保证系统稳定可靠地运行，并为业务系统提供快捷可靠的访问，是系统建设中最重要的问题之一。为了保护业务系统的关键业务数据，我们必须对这些数据进行有效的备份，并支持快速恢复。

通过备份的方式将文件、数据库等重要数据做一个副本，只能在本地建立数据保护。但因意外(如火灾、地震等)停止工作时，随之而来的损失更是不可估量，为避免类似风险的存在，就需要建立异地容灾系统，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作，保证业务稳定运行。

1.2. 用户需求

1.2.1. 建设目标

从容灾的级别来说，可以规划数据级容灾和应用级容灾，根据业务种类多，业务方式多样化的特点，仅建设一个数据级容灾是不够，容灾发生时，业务快速的恢复是容灾系统的一大需求。应用级容灾是建立在数据级容灾的基础上，在容灾切换时，除了切换核心的数据库数据外，还包含了IP地址切换（按客户需要选择），中间件服务，用户级业务。应用级容灾从流程上实现了全业务的连续性需求。

从我们的灾难系统建设经验出发，xxx有限公司可以考虑以下业务连续性计划目标：

? RPO（最大允许数据丢失时间）：零数据丢失 ? RTO（最大允许宕机时间）：30分钟

北京海量智能数据技术有限公司 1

方案设计

? 应用级容灾需求

1.2.2. 需求分析

用户需要保障数据的长期安全可靠的，数据对于灾难的安全性和可恢复性：

灾难切换时间要求 多种灾难切换方式

灾难系统切换时间不超过30分钟，最好在10分钟内实现。 提供自动灾难系统切换和手动灾难切换方式

计划内维护要求 提供计划内维护支持能力，计划内维护切换时间不多于10分钟 数据丢失性要求 原则上要求零数据丢失，可以依据情况进行调整 数据同步方式

提供同步和异步两种方式

备份和灾难备份方式 采用物理备份方式实现 物理部件失败要求 致的失败保护。

站点失败要求 逻辑失败要求 护

人类错误失败要求 保护或者恢复。

生产系统的性能影响要求 生产系统性能影响不超过5% 生产系统可用性要求 容灾系统不会降低生产系统可用性 网络链路分钟级别短暂故障 网络链路小时级别长期故障

要求不会对生产系统产生影响 要求不会对生产系统产生影响

要求不会对生产系统产生影响

支持由于人类误操作以及入侵等导致人类错误失败导致的数据支持由于火灾，电力以及其他因素导致站点失败的数据保护。 支持由于数据块腐败导致的数据库无法启动，数据丢失等逻辑失败保支持部分磁盘，文件系统，主机，磁盘柜等各种物理部件失败导网络链路密集的秒级别短暂故障 网络链路容错

支持网络链路的容错，可以利用网络的备份链路，比如多路网卡等

灾难系统的硬件故障 由于灾难系统硬件故障导致的灾难系统不可用不会对生产系统产生影响，比如网卡，磁盘以及控制卡等

灾难系统的软件故障 由于灾难系统软件故障导致的灾难系统不可用不会对生产系统产生影响，比如灾难系统管理软件部件等

网络协议

采用IP网络实现

2

北京海量智能数据技术有限公司

方案设计

网络带宽

一般的百兆或者千兆带宽

RTT要求 RTT要求在10ms以内即可满足要求，可以容忍部分时间的30ms响应

在线实施要求 要求在备份系统实施期间保持生产系统运行

存储系统失败的原址运行 在生产系统主机可用的情况下可以支持系统原址运行 部分文件失败的原址运行 在部分文件失败的情况下可以支持系统原址运行

北京海量智能数据技术有限公司 3

方案设计

2. 建议方案

2.1设计原则

通过对用户具体环境和需求的分析，我们在针对性的方案设计上应遵循以下原则：

? 最高的性价比，根据用户的实际需求，提供合适的解决方案，在有限的

资金许可范围内提供符合需求的方案。

? 优化的策略，关键业务系统和一般应用系统优先级的策略化，需要确保

关键业务系统的数据不丢失。

? 广泛的适用性，支持异构平台，产品可以适应不同类型的应用、数据以

及主机存储设备。

2.3.8容灾方案设计

目前有很多种容灾技术，分类也比较复杂。根据用户应用系统特点的不同，应用系统持续服务紧迫性的区别，应有针对性的选择容灾系统方案。

北京海量智能数据技术有限公司

4

方案设计

（1）基于应用程序容灾解决方案 ? 方案优点

? ?

应用程序在本地、远端双写I/O；

该方案能够实现业务系统在发生灾难时自动切换，保证业务的完全连续性；

? 方案缺点

? ? ?

（2） 基于数据库复制的远程容灾解决方案 ? 方案优点

? ?

数据库本身的远程复制（Oracle DB Guard）； 实施相对简便，支持异构存储； 投资非常高，容灾软件价格昂贵； 实施复杂，应用系统需要重新搭建；

该方案完全由软件实现，需消耗主机系统资源，效率底；

? 方案缺点

? ? ?

（3） 基于主机的远程数据复制软件容灾解决方案 ? 方案优点

? ? ?

复制软件在卷管理器层面截获I/O，远程复制 支持异构存储；

可以实现应用的实时、自动切换； 只能复制数据库文件，实现数据库容灾； 需要重新调试、安装数据库； 停机时间较长；

? 方案缺点

? ?

5

需要重新配置存储卷，停机时间较长； 新增容灾系统需要增加软件授权；

北京海量智能数据技术有限公司

方案设计

（4） 基于存储的远程数据复制容灾解决方案 ? 方案优点

? ? ? ?

智能存储远程数据复制，技术较成熟； 设备、软件投资费用低；

实施简便，应用系统仅需短时间停机； 不需要对应用、数据库重新安装调试；

? 方案缺点

? ?

根据用户的应用特点：建议使用基于存储的容灾方案。

只支持同一厂商同一系列存储； 不能实现应用的实时、自动切换；

2.3.9系统整体架构

本地灾备中心

服务器均采用原有服务器，所有服务器配置HBA卡，连接至用户现有光纤交换机；

新增存储加入SAN网络，存储空间可根据业务需求，自由划分给多套系统使用；

北京海量智能数据技术有限公司 6

方案设计

新增一台备份服务器，安装NBU服务端，新增一台HDS虚拟带库作为备份介质保存备份数据，实现SAN备份。

主数据中心和灾备中心之间通过高速光纤链路连接，为数据复制和备份提供了很好的链路基础。利用HDS 容灾管理软件TrueCopy实现磁盘阵列之间数据的复制。建立同城异地容灭系统，通过数据同步保证在总部运行中心出现重大灾难故障时，能启用灾备中心进行正常交易。

异地备份中心

容灾中心新增容灾服务器、容灾交换机，新增的HDS AMS 2100作为容灾存储设备，该备份中心只需要保存业务系统数据一份可用的备份。当本地机房瘫痪时，容灾服务器接管ERP及交易系统。

北京海量智能数据技术有限公司 7

方案设计

3. 灾备中心运行维护方案

3.1. 解决方案选择

保持业务持续性，恢复业务处理的方法可以包括与冷、温或热站点供应商签订商业合同、移动站点、镜像站点、与内部或外部机构签订互惠协议、与设备供应商签订服务水平协议（SLA）。另外，在制定系统恢复策略时应该考虑诸如独立磁盘冗余阵列（RAID）、自动故障切换、不间断电源（UPS）和镜像系统等技术。

业务持续性计划必须包括在比较长的期间在备用设施中恢复和执行系统运行的策略。通常，有三种备用站点可供选择：

? 由机构拥有或运行的专用站点

? 与内部或外部实体签订的互惠协议或协议备忘录 ? 商业租用设施

无论选择哪种类型的备用站点，设施必须能够支持应急计划中所定义的系统操作。三种站点类型可以根据运行的准备程度进行分类。这样的话，站点可以被确定为冷站点、温站点、热站点、移动站点和镜像站点。

根据BIA的结果和银联对业务持续性的要求，选择的解决方案可以描述为： （1）建立异地容灾中心将完全复制生产中心的数据，并实现两中心间的数据实时同步，其功能为：

a．正常工作状态下，灾备中心将配置为生产中心的完全数据复制，以保证当生产中心发生灾难时，数据的完整性。

b．当生产中心的存储系统及数据不可访问时,可以通过对备份数据中心的数据的访问。

（2）建立灾备中心，生产中心的数据将完全复制到灾备中心，允许存在一定的时间差，但应满足RPO和RTO要求。灾备中心配置有与生产中心架构相同的服务器系统，在生产中心无法运行的情况下接替生产中心的生产业务，实现对业务持续性的要求。

北京海量智能数据技术有限公司

8

方案设计

a．正常工作状态下，备份中心将配置为生产中心的数据复制源，以最大限度的不影响生产中心的主机和存储系统的性能。

b．当生产中心灾难发生时，灾备中心的完全复制数据将用于生产数据中心的数据同步，以保证当生产中心灾难发生时，灾备中心没有数据丢失；业务可以恢复运行。

3.2. 业务持续性策略

3.2.1. 日常运行状态

在没有任何异常情况发生的情况下，系统按照正常的运行状态运转，工作人员按照各自的岗位职责开展工作。定期将工作内容和工作结果向上级管理人员汇报并接受上级管理人员的监督和检查。

3.2.2. 切换流程

切换流程分计划内切换流程和计划外切换流程，首先讨论计划为切换流程。 1. 发现并确定灾难情况

运行中心运行保障室是负责发现可能导致业务系统灾难的事件的主要部门。同时，网络维护室、系统维护室和安全管理室等其它部门应该将所发现的可能导致灾难的时间随时向运行保障室报告。

2. 通知负责恢复的人员

运行保障室按照预定程序通知业务持续管理小组的值班人员，值班人员需要监控事件的发展，必要时将向业务持续小组负责人通报。

当发生可能导致业务处理中心的情况后，需要通知以下人员： ? 信息中心主管

? 业务持续管理小组负责人 ? 业务持续行政小组负责人

? 负责维护发生以外事件的系统的部门负责人 3. 判断异常影响程度，启动BCP计划

北京海量智能数据技术有限公司

9

方案设计

启动BCP计划是业务持续管理小组和/或业务持续行政小组的职责。通常由业务持续管理小组和/或业务持续行政小组的负责人宣布BCP计划的启动。在被授权的组织会负责人确定需要启动灾备站点后，宣布BCP计划启动。

按照BCP所定义的工作内容，损害评估小组和灾难恢复小组开始工作。 4. 激活灾备站点

在通知恢复的人员过程中，灾备站点的值班人员必须被通知并立即投入工作，做好业务运行环境的检查等工作。关闭可能对恢复业务运行有影响的任何应用系统，做好恢复业务运行的准备。

在收到BCP启动的通知后，按照BCP所定义的操作流程，与生产中心陪着或独立执行业务恢复工作。

5. 发布公告

业务持续管理小组的相关成员按照BCP所定义的工作内容向外发布公告 6. 提供业务恢复所需的服务

在业务恢复以及业务在灾备站点运行期间，内部和外部的支持团队以及相关工作人员按照BCP所定义的工作内容为业务的持续运行服务。

对于计划内切换流程，其大部分内容与计划为流程相同，通常由通知负责恢复的人员开始，直到提供业务恢复所需的服务。计划内切换可能是由于演习或需要进行站点级的设备维护造成的，有很强的计划性，灾备站点人员应该提早完成恢复业务运行的准备工作，如所有工作人员到位等。

3.2.3. 非切换异常处理流程

切换流程用于处理不会导致业务切换的异常事件，如部分设备的损坏没有影响业务处理的正常运行，或备份中型和/或灾备中心发生异常等。虽然这些异常事件不会对业务的运行造成直接影响，但是使系统整体的稳定性降低，业务运行的风险加大了，而且这样的事件大量存在，应该引起足够的重视。初步计划的非切换异常处理流程如下：

1. 发现并确定灾难情况

运行中心运行保障室是负责发现可能导致业务系统灾难的事件的主要部门。

北京海量智能数据技术有限公司

10

方案设计

后果的评估：

（1） 分析形势并提供有效的评估报告 （2） 评价事件对机构的直接影响

（3） 将形势通报给相关设施和机构其他地点中的员工

（4） 提供对媒体可能关注事项的理解并与现存的公共关系和/或市场部门联合制定响应方案

决定最适宜的行动：

（1） 了解在建议或决定连续性选项过程中需要考虑的事项 （2） 了解紧急事件服务的角色

（3） 维护安全的原则（人员、物理和信息）

4、将灾难恢复、业务连续性规程与紧急事件规程整合起来 5、识别管理紧急事件的命令和控制需求 设计和装备紧急事件运作中心 在事件中命令和决策的职权角色

通信载体（如邮件、无线电、信使和移动电话等）

6、建议制定对角色、职权进行定义的命令和控制规程以及管理紧急事件的通信规程

开启紧急事件运作中心 紧急事件运作中心的安全 紧急事件运作中心团队的进度安排 紧急事件运作中心的管理和运作 关闭紧急事件运作中心 7、紧急事件响应和分类救护

制定、实施和演练紧急事件响应和分类救护规程，包括确定紧急事件中行动的优先顺序

制定、实施和演练分类救护规程，如急救和医疗；确定地点和制定到附近医院的运输规程

8、拯救和复原需求

16

北京海量智能数据技术有限公司

方案设计

集合适当的团队：

（7） 了解通过电话进行有效诊断的需要

（8） 了解在受到影响的地点对相关资源进行有效集中的需要

（9） 制定内部逐级规程以便在事件/响应展开的现场提供所需等级的资源 定义初始现场的行动策略：

（1） 了解对直接消减损失和拯救需求进行识别的需要

（2） 了解其需求并在需要的情况下准备站点保安、安全和稳定措施计划 （3） 识别保护现场资产的适当方法，包括设备房产和文档

（4） 认识建立与外部机构联络的潜在需求（如法律法规、紧急事件服务如消防部门以及警察、保险公司、损失理赔等）

（5） 了解业务需求和对其进行解释以协助物理资产的恢复 （6） 与公共当局建立设施访问的规程

（7） 与第三方服务提供商尽力规程，包括适当的合同协议 9、确保紧急事件响应规程与公共当局的要求相统一

5.1.3. 紧急响应场所的分类和功能、建设描述

紧急响应场所至少包括避难所（shelter in place）、紧急操作中心EOC（emergency operation center）、紧急事件运作中心ICS（incident command center）；

紧急响应场所建设描述，包括建设内容、设备需求、场地需求、环境需求等； 紧急事件运作中心ICS是紧急指挥体系的首脑部门，也是紧急事件处理指挥的场所。实现对紧急事件的分析、计划、组织、协调和管理控制等指挥功能。

紧急事件运作中心的总体目标是：面对紧急事件，能够为指挥首长和参与指挥的业务人员和专家，提供各种通讯和信息服务，提供决策依据和分析手段，和指挥命令实施部署和监督方法能及时、有效地调集各种资源，实施事故、灾难控制和抢修救治工作，减轻紧急事件对生命安全和业务造成的威胁，用最有效的控制手段和最小的资源投入，将损失控制在最小范围内。

紧急事件运作中心基本功能包括：

1. 紧急事件的评估与触发启动，根据对各种资料数据的分析评估，对事件

北京海量智能数据技术有限公司

17

方案设计

进行级别判定，经核实后向相应级别的部门提出预案启动建议。

2. 指挥功能：指挥现场为参加指挥首长提供会议设施、桌面终端网络、电话系统。参谋人员为首长提供各种辅助决策信息。

3. 通讯功能：利用专线、因特网、卫星网络、电话设备、移动通讯设备与及其他相关单位的通讯网络。

4. 信息收集分析功能：收集、整理各种相关信息资源。

紧急事件运作中心应急指挥系统具有以下六大功能：

（1）可实现针对特定事件的特定范围内资源实时调度方案的辅助制定，合理配置有关资源，及时控制事件蔓延。

（2）可实现对特定范围内紧急事件的实时监测，及时发现突发事件。 （3）可生成针对不同应急事件的多种处理预案。

（5）可实现具有真实感的虚拟环境下的事件演化模型，并对处理方案的预期效果进行模拟。

（6）可实现相关资源管理业务和信息管理的统一性和一致性，并实现网络化远程调度管理，从根本上提高管理效率。

5.1.4. 紧急场所设施使用人员的权限分配

建议制定对角色、职权进行定义的命令和控制规程，考虑管理和职权的连续性。

5.1.5. 紧急事件发生前的监测、监控与预警系统

监测、监控与预警系统是紧急预警处理的基础。平时细致有效的监测与监控是第一步。一旦发现有紧急事件出现，对局部事件进行实时监控，就可以展开及时的调查和分析，防止事件的扩散，在全面分析和科学判断的前提下，发出预警信号，提醒企业和社会进行相关的应对和准备工作，防患于未然。

监测预警主要包括：

北京海量智能数据技术有限公司 18

方案设计

? 火灾监测 ? 供电监测 ? 监测 ? 急救监测 ? 影响区域监测

以上部分根据风险分析来完善。

预警系统是指对监测数据进行整合、分析和判断，建立诊断和预测模型，对易造成重大危害的分布状态及危险因素进行早期报告。

紧急事件紧急预警处理系统要想达到高效、快速反应，首先必须形成完全覆盖，不留漏点。但完全覆盖必然涉及到社会的方方面面，其中包括许多单位和行政、事业单位。

北京海量智能数据技术有限公司 19

方案设计

5.1.6. 紧急事件发生后的紧急事件响应程序

紧急事件的一般响应程序是：

紧急事件的一般处理程序包括事件通知、事件评估、紧急预案启动及相关措施；

5.1.6.1. 事件通知

通知规程

北京海量智能数据技术有限公司 20

方案设计

事件的发生可能有先兆也可能没有先兆。例如，飓风将影响某个地区或计算机病毒会在某日发作经常会得到实现通知。但是，设备故障或者犯罪活动就可能没有先兆。通知规程应该在计划中包含这两种情况。适当的通知对减少IT系统的影响是很重要的；在一些情况下，它可以为允许系统人员正常关闭系统避免系统崩溃赢得足够的时间。在灾难发生后，应该通知损害评估小组使其能够确定事态的严重程度和下一步将要采取的行动。损害评估完成后，应该通知相应的恢复和支持小组。

可以通过各种方法完成通知，包括电话、传呼、电子邮件或者移动电话。由于无法确定能否有效恢复，所以通过电子邮件发送通知应该谨慎从事。在工作时间发送的通知应该发送到办公地址，在局域网停顿的事件中可以使用个人电子邮箱传送消息。在影响广泛的灾难事件中，有效的通知工具是电台、电视广播和WEB网站。

通知策略应该定义在事件发生后人员无法联络时的规程。一种通知方法是呼叫树。这种技术指定特定人员执行通知任务，此人负责通知其他的恢复人员。呼叫树应该包括主要的和备用的联络方法，应该讨论在某个人无法联系时应该采取的规程。下面是一个呼叫树（举个例子）：

需要通知的人员应该在计划附录中的联系清单中标明。这个清单确定人员在其团队中的职位、姓名和联络信息（如家庭、工作电话号码及传呼号码、电子邮件地址和家庭地址）。

通知还应该发给会因为不知情而受到负面影响的外部机构或者互联的伙伴系统。根据中断类型的不同，POC可能具有恢复能力。所以，与外部机构相连的每一个互联系统应相互协助，协助的方式应该根据所提供的系统互联协议确定。这些POC应该被列入计划的附录中。

21

北京海量智能数据技术有限公司

方案设计

通知中所传递的信息类型应该在计划中载明。所传递的信息数量和详细程度可依据被通知的团队而定。根据需要，通知信息可以包括以下内容：

? 所发生或者将发生的紧急情况的性质 ? 死亡或者受伤情况 ? 任何已知的评估结果 ? 响应和恢复的细节

? 何时何地召集会议介绍简况或者听取进一步的响应指令 ? 在评估期间进行重新部署准备的指令 使用呼叫树完成通知的指令（如果需要）

5.1.6.2. 损害评估

要确定紧急事件后如何实施紧急计划，对系统损害性质和程度的评估是非常重要的。这个损害评估应该在能够确保人员安全这个最优先任务的前提下尽快完成。所以，如果可能，损害评估小组是第一个得到时间通知的小组。损害评估规程对于不同的系统是不同的；但是应该涉及到以下领域：

? 造成紧急情况或者中断的原因 ? 潜在的附加中断和损失 ? 受到紧急情况影响的区域

? 物理架构（如计算机室结构的完整性、电源、电信、以及制热、通风和

空调）的状况

? IT设备的总量和功能状态 ? IT设备及其存货的损失类型

? 被更换的项目（如硬件、软件、固件或者支持材料） ? 估计恢复正常服务所需的事件

在书面计划无法得到的情况下,具有损害评估职责的人员应该了解和能够执行这些规程.一旦系统的影响被确定,就应该将最新信息和对此情况的响应计划通知给适当的团队。通知应该按照通知规程进行。

北京海量智能数据技术有限公司

22

方案设计

5.1.6.3. 计划的启动

只有当损害评估的结果显示一个或多个系统启动条件被满足时，IT紧急计划才应该被启动。如果满足启动条件，紧急计划协调人或者CIO应启动计划。各机构的启动条件各不相同，应该在紧急计划策略条款中予以说明。条件可以基于以下方面：

? 人员的安全和/或设施损失的程度 ? 系统损失的程度

? 系统对于机构使命的影响程度 ? 预期的中断持续时间

一旦明确了系统损害，紧急计划协调人就可以选择适当的恢复策略并通知相关的恢复团队。

5.1.6.4. 通知和启动阶段模板

本阶段涉及到用来探测和评估由（系统名称）中断造成的损害的最初行为。基于对事件的评估，可以通过紧急计划协调人启动计划。

在紧急情况下，在执行通知和启动规程前（机构名称）的最优先任务是保护人员的健康和安全。

关联人员的联络信息列在附录中，通知顺序如下：

? 最初的反应是通知紧急计划协调人。所有已知的信息被传递给紧急计划

协调人。

? （系统负责人）与（损害评估小组负责人）联系并将事件通知他们。（紧

急计划协调人）指示团队负责人开始评估规程。

? （损害评估小组负责人）通知小组成员并指导他们完成以下评估规程以

确定损害的范围和预计的恢复时间。如果由于安全条件的限制无法在本

北京海量智能数据技术有限公司 23

方案设计

地继续损害评估，（损害评估小组）可以遵循以下指导。

损害评估规程：

应该列出详细的行动规程，包括确定中断原因、确定潜在的附加中断或者损害、确定受影响的物理区域和物理设施的状态、确定包括需要更换的IT设备在内的IT设备的功能和总量的状态、预计将服务恢复到正常运行状态所需的时间。

? 接到（紧急计划协调人）的通知后（损害评估小组负责人）应该…. ? （损害评估小组）应该…. 备用评估规程：

? 接到（紧急计划协调人）的通知后（损害评估小组负责人）应该…. ? （损害评估小组）应该….

---当完成损害评估后，（损害评估小组负责人）将结果通知（紧急计划协调人）。

---（紧急计划协调人）对结果进行评估并确定是否启动紧急计划以及是否需要重新进行配置。

---依据评估结果，在适当的情况下（紧急计划协调人）将评估结果通知国家紧急情况相关人员（如警察、消防）。

以下一个或者多个标准得到满足将启动紧急预案： 1、（系统名称）超过规定时间内无法使用。 2、设施受损并且超过规定时间内无法使用。 3、其他适当的标准。

? 如果要启动紧急预案，（紧急计划协调人）要通知所有团队的负责人并

将事件的细节以及是否需要重新配置通知他们。

? 收到（紧急计划协调人）的通知，团队负责人要通知各自团队。应该将

所有适当信息通知团队成员，团队成员应该做好响应和重新配置的准备。

北京海量智能数据技术有限公司 24

方案设计

? （紧急计划协调人）要通知（离站存储设施）发生了紧急事件并且（损

害评估确定的情况下）将所需材料送到（备用站点）。

? （紧急计划协调人）要通知（备用站点）发生了紧急事件并要求其为(机

构)的到达进行准备。

? （紧急计划协调人）要将事件的大致情况通知剩余人员（通过通知规

程）。

5.1.6.5. 局部事故紧急响应预案

局部事故应急预案指企业单位针对本单位存在的现实危险和有可能发生的事故，在积极预防的基础上，为避免和防止事故中人员伤亡和财产损失扩大而实施应急救援的组织方案和行动计划。

(一)应急预案的编制原则

1、应根据本单位危险源的特点编制，要有较强的针对性。 2、救援措施、避险要领应该简洁明了，有较强的可操作性。 3、应急救援预案的编制应遵循企业自救与社会救援相结合的原则。 (二)应急预案的主要内容 1、危险源辨识及评价结果。 2、事故类型及可能造成的危害分析。 3、事故应急救援及紧急避险措施。

4、事故应急救援组织指挥机构、救援队伍及职责分工。 5、事故应急救援器材、装备。 6、需请求社会救援的事项。

7、事故应急预案演练的考核评价标准。 8、事故应急预案管理制度。 (三)应急预案制定的基本程序及要求

应急预案的制定是针对各项事故应急措施(含信息)、程序和行动计划的文件化过程。预案的制定应按如下程序及要求进行。

北京海量智能数据技术有限公司

25

方案设计

1、危险源评估。通过辨识危险因素和危险部位，确定危险(危害)类型。 2、事故类型与危害分析。事故类型与危害分析是在危险源评估的基础上对其可能发生的危害类型进行分析认定，从而科学地预测可能发生事故的类型及事故产生危害的大小，以此作为制定事故应急措施的依据。

3、制定应急措施。根据不同的事故类别、事故危害等，研究制定相应的应对措施。对可能发生无法直接施救或可产生较大次生灾害的事故要给予特别关注，制定紧急疏散等应急措施，防止盲目施救导致伤亡扩大。

4、根据事故应急措施需要，制定应急救援装备、器材配置方案。主要包括抢险器材设备、人员防护装备、通讯设备、救护器材设备的种类和数量等。

5、制定应急救援组织指挥机构和应急救援队伍方案，并明确职责分工。保证事故应急救援组织指挥机构在发生事故时能根据事故状况实施有效的协调指挥；应急救援队伍能够实施有效的应急抢险、排险、救援、救护等工作。

6、分析确定需社会救援的事项。为了在发生重、特大事故时能够及时得到有效的社会救援支持，应依据可能发生的事故类型及危害，分析确定需要社会救援的事项，纳入预案管理。

7、制定有关人员培训内容和预案演练考核标准。为使应急指挥人员和救援队伍掌握应急指挥与救援要领，危险岗位工作人员掌握事故状态下应急抢险或避险逃生的要领，应研究制定相关培训内容和预案演练考核标准。

8、形成预案。在上述工作的基础上，经过专家评审和领导审批后，作为执行性文件。

特大事故应急救援预案应报有关管理部门备案。 (四)预案措施的落实与管理

应急救援预案确定后，企业单位的主要负责人要组织预案措施的落实工作。 (五)预案演练

预案演练是保证一旦发生事故，预案可以有效发挥作用的重要环节。演练的主要内容：

1、事故报告与接报。包括第一时间的事故现场人员或事故发现人员的报告；事故单位接报响应；事故单位向当地政府及其应急保障系统报告，请求外围应急

北京海量智能数据技术有限公司 26

方案设计

救援支援及其接报响应。

2、事故发生后第一时间的现场应急抢险或避险。

3、事故应急调度指挥部指挥与抢险。包括指挥部人员迅速赶赴现场预定位置指挥抢险工作；通知各有关应急机构进入应急状态；指挥调动应急救援队伍开展抢险、排险、疏散、警戒、救护等相关工作。

4、调用物资。包括应急抢险车辆、装备、通讯器材、医疗器材、药品和个人防护用品等。

5、演练总结和预案补充。根据演练考核标准，对演练情况进行总结，补充完善预案。

5.1.6.6. 重、特大事故紧急响应预案

重、特大事故应急响应预案是指针对行业、地区或所属单位重大危险源及有可能发生的重、特大生产事故，为迅速掌握和报送事故信息，及时协调抢险、救灾、救护等工作而制定的事故应急响应方案和行动计划。

重、特大事故应急响应预案由主管领导审批执行,在相关部门备案。 主要内容应包括：

(一)事故应急响应组织体系及各部分职能 1、组织领导机构。 2、办事机构。

3、明确事故应急响应职责。 (二)事故信息报送程序及要求 1、各类事故信息报送程序及要求。 2、通讯方式和通信联络体系。 3、重大事项的决策程序。 4、重大指令下达程序。 (三)事故分级响应指挥调度程序 1、重大事故响应程序。 2、特大事故响应程序。

北京海量智能数据技术有限公司

27

方案设计

3、特别重大事故响应程序。 (四)应急响应终结 1、事故情况上报事项。

2、需向事故调查处理小组移交的相关事项。 3、事故应急情况工作报告。

5.1.7. 紧急响应策略保持有效性的监管措施

通过建立监管措施,并且根据规划执行3年一次的BCP计划回顾和更新保证BCP计划的有效性.

6. 预案模拟演练方案

演练是有计划的整体演练，主要目的是为了检验灾难发生时，灾备中心是否具备接管业务的必要条件，能否保证核心业务系统按既定目标准确切换、正常运行。对演练中发现的系统潜在问题，应立即组织查找原因，采取有效措施加以改进，从而消除安全隐患。同时，对提高信息技术团队的应急响应、协作能力和灾难恢复经验，完善技术保障流程具有重要意义。

北京海量智能数据技术有限公司

28

方案设计

6.1. 生产中心向备份中心切换流程演练

操作前提 生产中心 操作内容 备份中心 检查人员到位 确认人员到位 如有意外，停止切换 检查系统运行情况 确认系统正常 如有系统故障，停止切换 停止所有变更 应用参数等不再变化 停止服务成功 断开同步复制 停止备份中心的快照 确保当现数据复制至备份中心 修改环境参数修改脚本 恢复用于备份中心环境的数据库，应用等修改参数 系统环境恢复 数据库启 启动应用 顺序启动数据库 备份中心数据库启动 备份中心应用不成功，切换暂停。 不成功，切换 操作结果 备注 北京海量智能数据技术有限公司 29

方案设计

动 启动，但不对外服务 暂停。 应用启动 网络切换 停止对外服务的信息 启动对外服务的vlan信息 对外服务由生产中心切换至北备份中心 切换不成功，网络回切，切换暂停 切换成功

6.2. 容灾中心向生产中心切换流程演练

操作前提 操作内容 生产中心 1 检查人员到位 备份中心 确认人员到位 如有意外，停止回切 2 检查系统运行情况 确认系统正常 ） 如有系统故障，停止回切 3 停止所有变更 数据库\\应用参数等不再变化 4 断开生产中心至备份中心的镜像复制 5 镜像复制断开 建立备份中心至生产中心反向异步复制 6 停止服务成功 断开备份中心至生产中心的复制 确保当前数据复制至备份中心 数据由备份中心至生产中心 操作结果 备注 北京海量智能数据技术有限公司 30

方案设计

7 修改环境参数修改脚本 恢复用于生产中心环境的数据库，应用等修改参数 8 数据库启动 启动应用 生产中心应用启动，但不对外服务 不成功，回切暂停。 9 应用启动 网络切换 停止对外服务的vlan信息 启动对外服务的vlan信息 对外服务由备份中心切换至生产中心 切换不成功，网络切换回备份中心，回切暂停 10 切换成功

北京海量智能数据技术有限公司 31

方案设计

7 修改环境参数修改脚本 恢复用于生产中心环境的数据库，应用等修改参数 8 数据库启动 启动应用 生产中心应用启动，但不对外服务 不成功，回切暂停。 9 应用启动 网络切换 停止对外服务的vlan信息 启动对外服务的vlan信息 对外服务由备份中心切换至生产中心 切换不成功，网络切换回备份中心，回切暂停 10 切换成功

北京海量智能数据技术有限公司 31

本文来源：https://www.bwwdw.com/article/9zq3.html