第18章 灾难恢复计划
18.1 灾难的本质
18.1.1 自然灾难
灾难恢复计划应当针对这两类灾难准备相应的处理机制，这两种机制可以是逐渐形成响应力，也可以是立即响应突然出现的紧急危机。
1. 地震
地震由大陆板块的移动引发，全世界的任何地方都可能发生，而且没有预警。
不过，在已知的断层上发生的可能性更大，这样的断层在世界很多地方都存在。
San Andreas断层就是其中很有名的一个，它给美国西部的部分地区带来了相当大的危险。
如果住在可能出现地震的断层附近，那么DRP应当说明在地震导致正常操作中断时人们要执行的程序。
你可能对这样的事实感到惊讶：全球有一些地区被认为更可能发生地震。
美国联邦应急管理署(FEMA)对美国50个州按中级、高级或极高级别地震风险进行划分;
50个州中88%(44个) 随时都可能出现中级或以上的地震事件。
2. 洪水
洪水随时都可能发生。
一些洪灾是由于河流、湖泊和其他蓄水体中的雨水逐惭增多，然后溢出堤坝淹没乡镇、村落造成的。
某个地区的地表在短时间内无法容纳突然增加的降雨量，就会出现另一种类型的洪水，如山洪暴发。
堤坝在受损时也可能发生洪水。
地震活动导致的巨浪或海啸则会形成令人畏惧的洪水般的力量和破坏性，例如2011年在日本发生的大海啸。
海啸十分彻底地展示了洪水的破坏力，影响了经济和各种业务，引发了福岛前所未有的核灾难。
根据美国政府统计，美国每年由于洪灾对商业和家庭造成的损失超过8亿美元。
当洪水袭击业务设施时，DRP能做出恰当响应是非常重要的。
尽管理论上全球各地都可能发生洪灾，但某些区域发生的可能性会更大。
FEMA的国家洪灾保险计划负责对全美的洪灾风险进行评估，为民众提供地理形式的数据。
可从http://msc.fema.gov/portal 查看洪灾地图。
这个网站还提供地震、飓风、暴风雨、冰雹和其他自然灾害的有价值的历史信息，帮助组织准备风险评估。
在查看洪灾地图时，你在地图中会发现有两种风险经常出现，它们是“百年洪泛区”和“五百年洪泛区”。
这些评估说明美国政府预计这些地区每100年或500年至少会发一次洪水。
3. 暴风雨
暴风雨有很多形式，给业务带来的风险也不尽相同。
具有严重威胁的飓风和龙卷风，它们的风速超过了每小时100英里，
对建筑物结构的完整性造成了威胁，并将普通物体(如树木、割草机甚至汽车)变成致命的飞弹。
冰雹带来了从天而降的破坏性冰块。
许多暴风雨还伴随闪电，可能严重毁坏敏感的电子设备。
因此，业务连续性计划应该详细描述防止闪电危害的恰当机制，
并且灾难恢复计划应当为可能在闪电袭击中出现的电力中断和设备损坏提供足够的防护。
永远都不要低估暴风雨可能带来的破坏。
2017年，4级大西洋飓风哈维(Harvey)是登陆美国大陆造成损失最大、最致命、最强的飓风之一。
它破坏了得克萨斯的交通线路，破坏了自然和人造物。
哈维造成的经济损失预估超过1250亿美元，直接导致至少63人死亡。
4. 火灾
发生火灾的原因有很多种，既可能是人为的，也可能是自然引起的，但它们带来的危害是相同的。
在BCP和DRP处理过程中，应评估火灾带来的风险，
并采取最基本的措施来缓解这些风险，在关键性设施发生灾难性火灾后恢复业务。
世界上某些地区在高温季节容易发生撩原大火。
这些火灾一旦发生，根据可预测的一些蔓延模式，
火灾专家和气象学家会对火势的可能蔓延路径进行相对准确的预报。
5. 其他地区性事件
世界上某些地区会发生区域性的自然灾难。
在BCP/DRP处理过程中，评估团队应当分析组织所有的运营地区，并且评估这类事件可能对业务造成的影响。
例如，世界上很多地区都会出现火山爆发。
如果在靠近活火山或休眠火山的地区开展业务，DRP就应当考虑这种可能性。
其他的区域性灾难事件还包括亚洲的季风、南太平洋的海啸、高山地区的雪崩和美国西部的泥石流。
如果业务分布在不同的地区，就应当明智地在策划团队中包括地区政府。
最起码，利用像政府紧急事件预备队、城市防御组织和保险索赔办公室这样的当地资源将有助于指导工作。
这些组织拥有丰富的知识，通常更愿意帮助组织应对意外事件。
毕竟，每个成功经受住自然灾害的企业都是灾害发生后较少需要恢复资源的企业。
18.1.2 人为灾难
成熟社会的复杂交流可能造成很多潜在的、有意和无意的人为灾难。
1. 火灾
很多较小的火灾是由于人为原因造成的，例如粗心、接错电线、不正确的防火措施或其他一些原因。
来自保险信息协会的研究显示，美国每天至少有1000幢建筑物发生火灾。
如果其中一处火灾袭击了你的企业，你有足够的预防措旅快速遏制火灾吗?
如果火灾破坏了你的设施，灾难恢复计划多久才能使企 业在其他地方恢复经营?
2. 恐怖行为
自2001年9月11日的恐怖袭击发生以来，业务活动对恐怖威胁带来的风险越来越受到关注。
由于缺乏足够的确保企业持续生存的业务连续性计划/灾难恢复计划，9.11恐怖袭击导致很多小企业最终关门。
很多较大的企业都经历过由于长期破坏导致的极大损失。
保险信息协会在恐怖袭击发生一年后发布了一份研究报告，
这份报告对纽约市由于恐怖袭击造成的破坏进行了全面评估，损失高达400亿美元!
恐怖行为具有不可预测性，为DRP团队带来了特殊挑战。
在2001年9.11恐怖袭击发生前，很少有DRP团队认为飞机撞击总部的威胁大到值得去缓解的程度。
而现在很多公司正在自问很多新的关于恐怖行为“如果......会怎样”的问题。
通常，这类问题在促进业务成员之间提出有关潜在威胁的对话方面是有益的。
相反，灾难恢复计划的策划者则必须强调稳健的风险管理原则，
并确保没有针对恐怖威胁过度分配资源，以免影响那些为防护更可能发生的威胁而进行的DRP/BCP行为。
3. 爆炸/煤气泄漏
煤气泄漏可能来自很多人为因素。
煤气泄漏使房间/建筑物里充满爆炸性气体，被点燃将会引发破坏性爆炸，某些区域发生爆炸还会引发公众担忧。
从灾难计划的观点出发，爆炸和煤气泄漏与那些大型火灾引发的灾害有着相似的结果。
然而，计划避免爆炸的影响更困难，并且依赖物理安全措施。
4. 电力中断
即使是最初级的灾难恢复计划，也包括了怎样应对短时间电力中断的威胁。
通常用不间断电源(UPS)设备保护关键业务系统，这些电源使你至少有足够长的时间关闭系统或开启应急发电机。
然而，企业是否有应对长时间电力中断的能力呢?
2017年，哈维飓登陆后，得克萨斯数百万人失去了电力。
你的业务连续性计划是否包括在没有电力的清况下让你的企业在这么长时间内保持生存的内容?
你的灾难恢复计划是否做好了及时恢复电力的准备工作，即使商业电网仍然不可用?
如今的技术型组织对电力的依赖程度越来越高，BCP/DRP团队应当考虑备用电源，
从而能够在不确定的时间段内为业务系统提供电力。
一台胜任的备用电机可能意味着在生死攸关的时刻对业务持续运营产生很大的影响。
5. 网络、公共设施和基础设施故障
当计划编制者考虑公共设施停止运转可能对企业造成的影响时，他们首先会想到的自然是电力中断造成的影响。
但是，还应该考虑其他公共设施。
是否有依赖于水、下水道、天然气或其他公共设施的关键业务系统呢?
当然还要考虑地区性的基础设施，如公路、机场或铁路。
这些系统中的任何一个都可能出问题，而这些问题与本章中提到的天气或其他条件并不相关。
很多业务依赖于基础设施中的一个或多个来调动人员或运输物品。
他们出问题可能瘫痪你的业务待续运行能力。
此外，还必须把互联网看作公共设施。
你的网络连接有足够的冗余吗?
它们能让你生存下来或从灾难中迅速恢复吗?
如果你有备用运营商，他们存在单点故障吗?
例如，它们是否都位于一个可被切断的光纤管道中?
6. 硬件/软件故障
不管是否愿意，计算机都会出现故障。
硬件可能由于磨损或受到物理损坏而无法继续运行。
软件也会有bug, 或者输入了不正确/意外的操作指令。
因此，BCP/DRP团队必须在系统中提供足够的冗余。
如果强制要求零宕机时间，那么最好的解决方案是在具有不同通信链路和基础设施的地方使用全冗余故障恢复服务器。
如果一台服务器被破坏或损坏，那么另一台将立即接管其正在处理的负载。
由于财务上的限制，维持全冗余系统并非总能实现。
这些情况下，BCP/DRP团队应该说明如何快速获得和安装需替换的部分。
在本地零件库中应该保存尽可能多的零件以备快速替换，这对那些很难找到而必须依赖进口的零件来说尤为重要。
毕竟，在关键PBX组件从国外进口并安装的那些日子里，能有多少企业可以不接听电话呢?
7. 罢工示威抗议
在编制业务连续性计划和灾难恢复计划时，
不要忘记在紧急事件计划中指出人为因素的重要阻常被忽视的一种人为灾难可能是罢工或其他劳工危机。
如果大部分员工在同一时间罢工，会对业务造成什么影响呢?
能承受在某个区域没有固定的专职员工工作的时间有多长?
BCP和DRP团队应该考虑这些问题，从而提供在劳工危机出现时的备选计划。
8. 盗窃/故意破坏
在前面，我们看到恐怖行为给组织带来的威胁。
偷窃、故意破坏与恐怖行为具有相同点， 只是规模小一些。
但大多数情况下，组织更可能受到偷窃或故意破坏的影响，而不是恐怖袭击。
保险为这些事件提供了一些经济保护(受限于免责和限制条款)，但这些行为可能会在长期或短期对业务带来严重破坏。
业务连续性计划和灾难恢复计划应当包括充分的预防措施，从而控制这些事件的发生频率，
此外，还应当包括紧急事件计划来减轻偷窃和故意破坏对正在进行的工作的影响。
18.2 理解系统恢复和容错能力
作为CIA安全三要素(保密性、完整性和可用性)的核心目标之一，
增加系统应变能力和容错能力的技术控制会直接影响到可用性。
系统恢复和容错能力的主要目标是消除单点故障。
任何组件都可能发生单点故障(Single Point Of Failure, SPOF)，导致整个系统崩溃。
如果计算机的单个磁盘上存有数据，那么该磁盘发生故障就会导致计算机不可用，所以磁盘是故障发生的单点。
如果基于数据库的网站有多台Web服务器，但这些服务器使用同一台数据库服务器，那么该数据库服务器就是故障发生的单点。
容错能力是指系统在发生故障的清况下仍可继续运行的能力。
容错能力是通过增加冗余组件实现的，如廉价磁盘冗余阵列 (RAID)中的额外磁盘或故障转移集群配置中的额外服务器。
系统恢复能力指的是系统在发生负面事件时仍保待可接受的服务水平的能力。
这可能是容错组件托管的硬件错误，或者可能是由诸如有效入侵检测和预防系统的其他控件引发的攻击。
某些清况下，指的是在发生负面事件后系统还原的能力。
例如，如果故障转移集群中的一台主服务器崩溃，
容错能力能将系统故障转移到另外的服务器上，而系统恢复能力则是在原系统修复后，该集群能够返回原服务器。
18.2.1 保护硬盘驱动器
在计算机中添加容错和系统恢复组件的常见方法是使用RAID。
RAID包括两个或以上磁盘，即使其中一个磁盘损坏，大多数RAID也都能继续运行。
一些常见配置如下:
RAID-0也称为条带。
它使用两个或以上磁盘，它提高了磁盘子系统的性能，但不提供容错能力。
RAID-1也称为镜像。
它使用两个磁盘，每个磁盘保存相同的数据。
如果一个磁盘损坏，另一个磁盘仍保存完整的数据，这样在一个磁盘损坏后，系统仍能继续运行。
系统可能会在不需要人工干预的情况下继续运行，也可能需要手动配置以使用没有损坏的磁盘，这取决于使用的硬件以及损坏的驱动器。
RAID-5也叫作奇偶校验。
它使用三个或更多磁盘，相当于一个磁盘，其中包含奇偶校验信息。
如果一个磁盘损坏，磁盘阵列会继续运行，但速度会慢一些。
RAID-10也被称为RAID1+0或条带镜像。
它是在条带(RAID-0)配置上再配置两个或以上的镜像(RAID-1)。
它至少需要4个磁盘，当然也可以更多，增加磁盘数以偶数计。
即使多个磁盘损坏，只要每个镜像中有一个驱动器是好的，它就能继续运行。
例如，如果有三个镜像集(称为M1、M2、M3)，则共有6个磁盘。
如果M1、M2、M3中分别有一个驱动器损坏了，该阵列将继续运行。
然而，如果某个镜像集中两个驱动器都坏了，如 M1的两个驱动器，整个阵列将无法继续运行。
RAID可基于软件，也可基于硬件。
基于软件的系统需要操作系统管理阵列中的磁盘，这会降低系统的整体性能，
但相对便宜一些，因为不需要除磁盘以外的其他硬件。
基于硬件的磁盘阵列系统通常更有效、更可靠。
虽然基于硬件的磁盘阵列更昂贵，但当使用这种阵列以增加某些关键组件的可用性时，收益大于成本。
基于硬件的磁盘阵列通常含有可在逻辑上添加到磁盘阵列中的备用驱动器。
例如，基于硬件的 RAID-5 如果有5个磁盘，RAID-5阵列中有3个磁盘处于工作状态，另外两个是备用磁盘。
如果一个工作磁盘损坏，硬件检测出故障，就可在逻辑上将发生故障的磁盘替换为备用磁盘。
此外，大多数基于硬件的阵列支持热插拔，不必关机就可以更换损坏的磁盘。
冷插拔的RAID要求系统关机后才能更换损坏的驱动器。
18.2.2 保护服务器
可通过故障转移集群将容错功能添加到关键服务器中。
故障转移集群含有两个或以上的服务器，如果其中一台服务器出现故障，
集群中的其他服务器可通过称为故障转移的自动化过程接管其负载。
故障转移集群可包含多台服务器(不只是两台)，它们可为多个服务或应用提供容错功能。
作为故障转移集群的一个例子，如图 18.2所示。
图中多个组件组合在一起，为使用数据库的大量网站访问提供了可靠的Web访问方式。
DB1和DB2是配置在故障转移集群中的两台数据库服务器。
在任何时间，只有一台服务器作为活动数据库服务器，而另一台服务器将不处于活动状态。
例如，如果DB1是活动服务器，它将负担网站所有的数据库服务。
DB2监视DB1以确保其正常运行。
如果DB2检测到DB1损坏，集群中的负载将自动转移到DB2上。
如图18.2 所示，DB1和DB2都能访问数据库中的数据。
这些数据存储在RAID磁盘阵列上，这为磁盘提供了容错能力。
此外，三台Web服务器被配置在网络负载均衡集群中。
负载均衡可基于软件，也可基于硬件，它平衡三台服务器上的负载。
可添加额外的Web服务器来处理增加的负载，同时平衡所有服务器之间的负载。
如果某台服务器发生故障，负载均衡器可感知故障并停止向其发送数据。
虽然网络负载均衡主要用来增加系统的扩展性，使它可处理更多数据，但也提供了容错能力。
如果你正在使用云服务商提供的服务器，那么可充分利用他们提供的容错服务。
例如，许多IaaS提供商提供负载均衡服务，在需要时自动缩放资源。
这些服务还包括健康检查，可以自动重启运行异常的服务器。
同样，在设计云环境时，一定要考虑数据中心在世界各地的可用性。
如果已经对多个服务器进行负载平衡，那么除了可伸缩性之外，
你还可将这些服务器放在这些区域(Region)内的不同地理区域和可用区 (Availability Zone, AZ)中，以增加弹性。
18.2.3 保护电源
可为不间断电源(UPS)、发电机或它们两者提供容错能力。
一般情况下，不间断供电电源提供5到30分钟的短时间供电，而发电机可提供长期电力。
使用UPS的目的是为完成系统的逻辑性关闭提供足够时间，或在发电机提供稳定电源前维待电力供应。
理想悄况下，电力是稳定的、无波动的。
但现实中，商业供电存在各种各样的问题。
激增：电压快速升高。
下滑：电压突然快速降低。
电涌：电力长时间维持在高压状态。
电力不足：果长时间处于低压状态。
瞬变：有时还会出现噪音，这种情况被称为瞬变，瞬变有多种原因。
最基本的不间断电源(也被称为离线或备用电源)提供电涌保护和电池备份。
它接入商业电源中，比较关键的系统会接入UPS系统中。
如果电源发生故障，备用电池会为系统提供短时间供电。
在线互动式的不间断电源越来越受欢迎，除了基本功能外，它们还增加了其他功能。
它们含有可变电压互感器，在不使用电池电景的情况下可对高低电压做出调整。
当断电时，电池能为系统短时间供电。发电机能在长时间断电期间为系统供电。
发电机供电时长取决于燃料，只要发电机有燃料 且正常运转，就能依靠发电机获得稳定电力。
在2017年波多黎各飓风Inna的漫长余波中，需要发电机延长运行时间，但它们在连续运行数周和数月后开始失效。
发电机需要稳定的燃料供应，他们通常使用柴油、天然气或丙烷
除了确保你手里有足够的燃料，你还应该采取措施确保在定期交付燃料的情况下，延长紧急情况。
请记住，如果灾难涉及面很广，将出现燃料供应的巨大需求。
如果你与供应商签订合同，就更可能及时收到燃料。
18.2.4 受信恢复
受信恢复保证系统在发生故障或崩溃后，能够还原到之前的状态。
根据故障的类型，还原可以分为自动还原和管理员手动干预还原。
然而，不论哪种还原方式，系统都应该被预置，以确保还原的安全性。
系统可被预置成在损坏后处于故障防护状态或应急开放状态。
处于故障防护状态的系统会在故障发生时保待防护状态，禁止所有访问。
应急开放系统会在发生故障时保持开放状态，授权所有访问。
对二者的选择取决于故障后更注重系统的安全性还是可用性。
例如，防火墙通过允许和拒绝网络访问来维持安全性。
防火墙配置了隐式否认体系，只允许明确指定可以进入的流量信息进入。
防火墙通常被设计为故障防护状态，支持隐式否认体系。
如果防火墙发生故障，所有流量都会被禁止。虽然这消除了防火墙通信的可用性，但很安全。
相比之下，如果通信的可用性比安全性更重要，防火墙就应该配置为应急开放状态，
允许所有流量通过，这虽然不安全，但网络通信不会被禁止。
恢复过程的两个要素能够确保可信解决方案的实施。
第一个要素是失败准备。除了可靠的 备份解决方案外，还包括系统恢复及容错方法。
第二个要素是系统恢复的过程。系统必须重新 启动到单用户、非特权状态。
这意味着系统应该重新启动，使正常账户能够登录系统，且系统不再授权非授权用户登录的状态。
系统恢复还包括在发生故障或崩溃时，恢复系统中所有受影响的文件和服务。
恢复丢失或受损文件，更正变更分类标签，检查重要的安全文件的设置。
通用标准(CC,第8章)中有一节是对受信恢复的叙述。恢复过程与系统恢复能力及容错能力相关。
具体而言，共定义了4种类型的受信恢复:
手动恢复
如果系统崩溃，系统并没有处于故障防护状态。
相反，在系统故障或崩溃后， 管理员需要手动执行必要措施以恢复系统。
自动恢复
对于至少一种类型的系统故障，系统能自动执行受信恢复。
例如，RAID硬盘可恢复硬盘驱动器故障，但不能恢复整个服务器故障。
一些类型的故障需要手动恢复。
无过度损失的自动恢复
这类似于自动恢复，对于至少一种类型的系统故障，系统能自动执行恢复过程。
然而，其中包括一些能够保护特定对象免受损失的机制。
无过度损失的自动恢复的方法包括对数据及其他对象的恢复。
可能包含其他机制，以恢复受损文件、重建日志数据以及验证密钥系统和安全组件的完整性。
功能恢复
支持功能恢复的系统能自动恢复某些功能。
这种状态能确保系统成功地完成功能恢复，否则系统将回到变更前的故障防护状态。
18.2.5 服务质量
服务质量(QoS)控制能够保护负载下的数据网络的完整性。
许多因素有助于提升最终用户体验的质量，服务质量对这些要素进行管理，从而创造出能够满足商业需求的环境。
有助于服务质量提升的一些因素如下。
宽带：可供通信的网络容量。
延迟时间：数据包从源到目的地所需的时间。
抖动(Jitter)：不同数据包之间的延迟变化。
数据包丢失：一些数据包在源和目的地之间传送的过程中可能丢失，需要重传。
干扰：电噪声、故障设备等因素可能会损坏数据包的内容。
除了控制这些因素外，服务质量系统往往优先考虑某类业务，其中包括对干扰容忍度较小和/或有较高业务需求的业务。
例如，QoS设备可能设置为：行政会议室的视频流优先于实习生电脑的视频流。
18.3 恢复策略
当灾难导致公司业务中断时，灾难恢复计划应该能几乎全自动起作用，并开始为恢复操作提供支持。
应该以下面这种方式设计灾难恢复计划:即使正式的DRP团队成员未到达现场，
灾难现场的第一位员工仍能有组织地立即开始恢复工作。
接下来将讨论精心设计有效的灾难恢复计划时所涉及的关键子任务，
它们将对迅速恢复正常业务过程和重新开始主要业务地点的活动进行指导。
除了提高响应能力外，购买保险也能减轻经济损失。
选择保险时，一定要购买足够责任范围的保险，以便能够从灾难中恢复过来。
简单的定额责任范围可能不足以包括实际的更换成本。
如果财产保险包括实际现金价值(Actual Cash Value, ACY)条款，
该受损财产的受损日公平市场价值减去从购买之日起的累计折旧价值就是能够得到的偿。
这里有一个很重要的关键点，就是除非在保险合同中列有更换费用的条款，否则组织将自掏腰包。
许多保险公司提供网络安全责任条款，特别包含了保密性、完整性和可用性的违反。
有效凭据保险责任范围为记名的、打印的和书面的文档与手稿以及其他打印的业务记录提供保护。
不过，这种保险的责任范围并不包括钞票和纸质安全证书的损坏。
18.3.1 确定业务单元的优先顺序
为尽可能有效地恢复业务运营，必须精心设计灾难恢复计划，从而最先恢复优先级别最高的业务单元。
必须识别和优化重要业务功能，定义灾难或错误发生后想恢复哪个功能或以什么样的顺序恢复。
要完成这一目标，DRP团队必须首先标识业务单元，并决定它们的优先顺序，
在业务功能方面也是如此(注意主要业务单元并不福要执行所有的业务功能，
所以最终分析结果可能是主要 业务单元和其他选择单元的集合)。
该过程应该听起来很熟悉！
因为这与第3章讨论过的在业务影响评估期间由BCP团队执行的优先级划分任务非常相似。
事实上，大多数组织把业务影响评估(BIA)作为业务连续性规划过程的一部分。
这种分析能够检测漏洞、建立策略来降低风险，最终生成一份 BIA报告以描述组织面临的潜在风险并确定重要的业务单元和功能。
BIA还评估故障可能造成的损失，其中包括现金流损失、更换设备的费用、加班费、利润损失、无法获得新业务的损失等。
根据财务状况、人员、安全、法律合规性、合同履行、质量保证以及货币条款等方面的潜在影响，对这些损失进行评估，同时进行评估比较以制订预符。
有了所有BIA信息，便可使用生成的文件作为优先级任务的陆础。
作为最低要求，这个任务完成后的结果应该是一张业务单元优先级列表。
然而，更有用的可交付使用的应该是一张详细的、被拆分为具体业务过程的、按优先级排序的列表。
这个面向业务过程的列表更真实反映了现状，但需要付出相当大的额外努力。
无论如何，它在恢复工作中会发挥巨大作用，但毕竟不是所有最高优先级的业务单元所执行的每个任务都具有最高优先级。
在试图开始完全恢复工作前，在组织内最好先恢复最高优先级业务单元50%的运营能力，
然后继续恢复优先级别较低的业务单元，使之达到最小限度的运营能力。
同样，关键的业务流程和功能也必须完成相同的步骤。
这其中不仅涉及多个业务单元，还定义了在发生系统崩溃或其他业务中断后，必须恢复的操作要素。
这里，最后的结果应该是按优先级顺序列出清单，并列出风险和成本评估，
同时还应列出平均恢复时间(MTTR)及相关恢复目标和里程碑。
这包括称为最大可容忍中断(MTO)的度量。
这是企业在不遭受重大破坏的情况下能够承受服务不可用的最大时间。
业务连续性规划者可比较MTTR和MTO的值来识别需要干预和附加控制的情况。
18.3.2 危机管理
如果灾难袭击了你的组织，很可能引起恐慌，与之斗争的最好方法是启用灾难恢复计划。
对于公司中最先可能注意到发生了紧急情况的人(可能是保安、技术人员等)，
应该对他们进行完整的灾难恢复措施培训，让他们知道适当的通知措施和立即响应机制。
许多事情可能看起来属于常识性问题(如在美国发生火灾时拨打电话911)，但在紧急情祝下，恐慌中的员工想到的只是迅速逃离。
处理这种情况的最好方法是进行连续的灾难诙复职员培训。
回到火灾的例子，应该培训所有的员工在发现火灾时，启动防火警报装置或与紧急情况办公室联系(当然，此后应该采取适当的措施来保护自己的安全)。
毕竟，即使消防队接到了组织中10个不同人员拨打的报警电话，也比每个人都假设其他人会关注火灾，自己不必打电话的情况好得多。
危机管理是一门科学和技术。如果培训预算允许，对主要员工进行危机培训是个好主意。
这样做至少能确保有一些员工知道如何使用正确的方法处理紧急情况，并对那些受到灾难恐吓的同事起到重要的现场领导作用。
18.3.3 应急通信
当灾难来袭时，组织能在内部与外部之间进行通信是很重要的。
重大灾难很容易曝光，如果组织无法与外部保持联系，及时向外部告知恢复状况，公众很容易感到害怕并往最坏处想，进而认为组织无法恢复正常。
灾难期间，组织内部进行沟通也非常重要，这样员工就知道他们应该做些什么，例如：是回去工作，还是向另一个地点汇报情况?
某些情形下，灾难可能破坏一些或所有的正常通信手段。
猛烈的暴风雨或地震可峔毁坏了通信系统，此时再试图找到与内部和外部进行通信的方法为时已晚。
18.3.4 工作组恢复
在设计灾难恢复计划时，记住目标是让工作组恢复到正常状态并且重新开始他们在日常工作地点的活动是非常重要的。
很容易把工作组恢复变为次要目标，并认为灾难恢复只是IT人员的工作，IT部门重点负责将系统和过程恢复正常。
为推动这项工作，有时为不同的工作组开发独立的恢复设施是最佳选择。
例如，如果有几家子公司分布在不同地点，并且执行的任务与你所在办公室的工作组类似，
那么可能希望临时安置这些工作组到其他地点工作，并使他们通过网络通信和电话与其他业务单元保持联系，
直至他们准备好回到主运营设施中来。
较大的组织找到能够处理整个业务运营的恢复设施可能很困难，因此这也是不同的工作组适合独立恢复环境的另一个佐证。
18.3.5 可替代的工作站点
灾难恢复计划中最重要的要素之一是：在主要工作站点无法使用时选择可替代的工作站点。
在考虑恢复设施时，有许多可供选择的方案，方案的多少只受灾难恢复计划编制者和服务提供人员创新能力的限制。
接下来将讨论在灾难恢复计划中常用到的几类站点:冷站点、温站点、 热站点、移动站点、服务局以及多站点(云计算)。
注意: 选择替代工作站点时，一定要确认该场所远离主站点，避免与主站点一起受到同一灾难的影响。
但不能太远，最好是在一天的车程内。
1. 冷站点
冷站点只是备用设施，它有足够大的地方开展组织的运营工作，并有适当的电子和环境支持系统。
冷站点可能是仓库、空的办公大楼或其他类似的建筑物。
然而，站点内没有预先安装计算设施(硬件或软件)，并且没有可供使用的网络通信线路。
许多冷站点可能有一些铜质电话线，某些站点可能有备用线路，从而可使用最低限度的通知设备。
优点：比较便宜，也就是说没有需要维护的计算基础设备，如果站点未使用，就没有每月的通信费用。
缺点：很明显，即从决定启用该站点到实际准备好能够支持业务运营之间，存在着巨大的时间滞后问题。
首先必须购买服务器和工作站，然后进行安装配置。
必须从备份中还原数据。必须启用或建立通信链路。
冷站点从启用到正式投入使用的时间通常需要数个星期，
因此及时完成恢复过程是不太可能的，并且经常会给人以安全的假象。
所需的大量时间、精力和费用来激活冷站点和传输操作是值得观察的，这也使这种方法很难得到测试。
2. 热站点
热站点与冷站点恰好相反。这种类型的建筑中具有固定的被维护的备用工作设施，
并且附带完备的服务器、工作站和通信线路，准备承担主站的运营职责。
服务器和工作站都是预先配置好的，并已安装了适当的操作系统和应用软件。
主站点服务器上的数据会定期或持续复制到热站点中对应的服务器上，从而确保热站点中所有的数据都是最新的。
根据两个站点之间可以使用的带宽，热站点中的数据可以立刻被复制。
如果能够做到这一点，操作人员一旦接到通知就可以迁移到热站点进行操作。
如果无法做到这 一点，那么灾难恢复管理人员通过下列三种可选择的方法来启用热站点:
• 如果在主站点关闭前有充足的时间，可在操作控制转换前强制在两个站点之间进行数据复制。
• 如果做不到这样，可将主站点事务日志的备份磁带搬到热站点，并以手工方式恢复自上次复制以来发生的事务。
• 如果没有任何可用的备份并且无法强制进行复制，那么灾难恢复团队只能接受部分数据丢失的损失。
热站点的优点相当明显，这种类型的场所能提供的灾难恢复程度是非常好的，然而成本也非常高。
一般来说，为维护热站点，组织购买硬件、软件和服务的预算会增加一倍，而且需要额外的人力进行维护。
如果组织希望维待一个热站点，又想减少设备和维护费用的支出，那么可选择使用外部承包商管理的共享热站点设施。
然而这些设施内在的危险是在灾难大范围发生时，它们可能不堪重负，从而不能为所有用户提供服务。
如果组织考虑这种方式，那么双方在合同签署前、合同期间一定要定期彻底调查这些问题。
另一种减少热站点费用的方法是把热站点作为开发或测试环境。
开发人员可实时将数据复制到热站点，既用于测试，又提供生产环境的实况副本。
这降低了成本，因为热站点即使没有用于灾难操作，也为组织提供了有用的服务。
3. 温站点
温站点介于热站点和冷站点之间，是灾难恢复专家可选择的中间场所。
这种站点往往包含快速建立运营体系所需的设备和数据线路。
与热站点一样，这些设备通常是预先配置好的，并准备就绪可运行合适的应用程序，以便支持组织的业务运作。
然而，与热站点不同，温站点一般不包含生产数据。
使温站点完全处于运营状态的主要要求是将合适的备份介质送到温站点，并在备用服务器上还原。
灾难发生后，重新激活温站点至少需要12个小时。
这并不意味着能在12个小时内激活的站点就是热站点。
然而，大多数热站点的切换时间都在几秒或几分钟内，完成交接时间也很少超过一个或两个小时。
温站点能避免在维护操作环境的实时备份方面耗费的通信及人工费用。
有了热站点和冷站点，也可通过共享基础设施得到温站点。
如果选择这种方式，请确保在“无锁定“政策中注明， 即使在高需求时期，仍有合适设备的使用权。
深入了解此概念并检查合伙人操作计划，以确定设备能够备份“无锁定“保证。
4. 移动站点
对于传统的恢复站点而言，移动站点属于非主流的替代方案。
它们通常由设备齐全的拖车或其他容易安置的单元组成。
这些场所拥有为维持安全计算环境需要的所有环境控制系统。
较大的公司有时以“移动方式“维护这些站点，随时准备通过空运、铁路、海运或地面运输，在全世界任何地点部署它们。
小一些的公司可与移动站点供应商联系，这些供应商提供的服务是以客户的随时需求为基础的。
根据要支持的灾难恢复计划，移动站点一般可以被配置为冷站点或品站点。
当然，移动站点也可以配置为热站点，但并不经常这样做，原因在于通常不会提前知道移动站点会部署在哪里。
5. 服务局
服务局是出租计算机时间的公司。
服务局拥有大量的服务器群，通常也有大量工作站。
任何组织都可与服务局签署合同，从而使用他们的处理能力。
访问可以是联机的，也可以是远程的。
在发生灾难时，服务局工作人员通常能为你的所有IT需求提供支持，工作人员甚至还能使用他们的台式机。
与服务局签署的合同往往包含测试和备份以及响应时间和可用性。
不过，服务局往往投机，不会同时履行所有合约而超卖实际容量。
因此，当出现严重的灾难时存在潜在的资源竞争。
如果公司位于行业密集的区域，那么一定要考虑这个因素。
为确保有权使用处理设施，可能需要同时选择本地和远程的服务局。
6. 云计算
许多组织现在把云计算作为首选的灾难恢复选项。
基础设施即服务(laaS)提供商，如亚马逊AWS、微软的Azure、谷歌云计算，以较低成本按需提供服务。
希望保留自己数据中心的公司，可以选择使用这些laaS服务作为备份服务提供商。
在云中存储准备运行的镜像是经济实惠的，在云站点激活前能节省大部分运营成本。
18.3.6 相互援助协议
相互援助协议(Mutual Assistance Agreement, MAA)也称为互惠协议，在灾难恢复的文学作品中非常流行，但在真实世界中很少被实施。
理论上，相互援助协议提供了优秀的可供选择的方案。
在MAA下，两个组织承诺在灾难发生时通过共享计算设施或其他技术资源彼此援助。
这个协议似乎具有相当的成本效益，即任何一个组织都无须维持昂贵的替代工作场所(如热站点、温站点、冷站点和移动站点)的费用。
事实上，许多MAA被设计成能提供18.3.5节中描述的其中一种服务级别。
在冷站点的情况中，每个组织可能只维护他们工作设施中的一些开放空间，其他组织在发生灾难时可使用这些空间。
在热站点的清况下，组织可能通过完全 冗余的服务器为彼此提供服务。
然而，相互援助协议存在许多缺点，这妨碍了它的广泛使用:
• MAA很难强制实施。
协议参与各方要彼此信任，在灾难发生时能给予实际的支持。
但当真正出现灾难时，非受害方可能会拒绝履行协议。
受害方只能通过法律手段取得赔偿，但这样对灾难恢复工作并没有任何帮助。
• 相互合作的组织地理位置应该相对接近，以便于不同场所之间员工的交通便利。
但是，地理位置靠近意味着两个组织可能遭受相同的威胁。
如果你所在的城市发生了地震，协议双方的工作场所都遭到破坏，MAA也就没有任何意义了。
• 出于对保密性的考虑，公司通常会阻止将自己的数据交给其他公司。
这是出于法律考虑(如医疗或财务数据的处理)或商业考虑(如商业机密或其他清报财产问题)。
除了这些需要关心的问题外，对组织来说，MAA可能是一种很好的灾难恢复解决方案，尤其当成本是最重要的考虑因素时。
如果无法负担任何一种替代工作设施的实施费用，那么在业务遭到灾难袭击时，MAA能提供一定程度的保护。
18.3.7 数据库恢复
许多组织依靠数据库来处理和跟踪对待续运行非常关键的运营、销售、物流和其他活动。
出于这个原因，在灾难恢复计划中包括数据库恢复技术是很重要的。
在DRP团队中包含数据库专家，他们可对各种不同的意见提供技术可行性分析，这样做十分明智。
毕竟，在技术上至少需要大半天时间才能完成还原工作时，肯定不希望分出好几个小时还原数据库备份。
接下来将讨论用于创建远程数据库内容备份的三种主要技术手段：电子链接、远程日志处理和远程镜像。
每一种技术各有优缺点，这需要分析组织的计算需求和可供利用的资源，然后选择最合适的方法。
1. 电子链接
在电子链接这种情况中，数据库备份通过批量传送的方式转移到远处的某个场所。
远处场所可以是专用的替代性恢复场所(如热站点)，也可以是只由公司或承包商管理的、用于维护备份数据的远程场所。
如果使用了电子链接，需要记住，从宣布灾难开始到数据库准备好当前的数据准备运营，可能有相当长的时间延迟。
如果决定启用恢复站点，技术人员需要从电子链接中检索适当的备份数据，并恢复到即将投入使用的生产服务器上。
无论哪类备份场景，一定要定期测试电子链接设置。
测试备份解决方案的一种好方法是让灾难恢复人员进行一次“突击测试“，要求他们从某一天开始还原数据。
2. 远程日志处理
远程日志处理以一种更快的方式传输数据。数据传输仍以批量方式进行，但更频繁，通常每小时或更短时间一次。
与电子链接不同，在数据库备份文件被转移时，远程日志处理设置传输数据库事务日志的副本，
其中包括从上次批量传输以来发生的事务。
远程日志处理与电子链接类似，传输到远程站点的事务日志不是应用于实时数据库服务器，而是使用备份设备进行维护。
当宣布发生灾难时，技术人员找到合适的事务日志并将其应用于生产数据库，使数据库达到当前的生产状态。
3. 远程镜像
远程镜像是最先进的数据库备份解决方案。当然，不必惊讶，也是费用最昂贵的!
远程镜像使用的技术水平超过了远程日志处理和电子链接。
使用远程镜像时，实时数据库服务器在备份站点进行维护。
将数据库修改应用于主站点的生产服务器时，远程服务器同时收到副本。
因此，镜像服务器准备好在接到通知时，接管运营服务器的角色。
远程镜像是组织寻求实施热站点时一种流行的数据库备份策略。
然而，在衡量远程镜像解决方案的可行性时，一定要考虑所需要的支持镜像服务器的基础设施和人员成本，
以及附加在镜像服务器上的每个数据库事务的处理开销。
18.4 恢复计划开发
一旦为组织建立业务单元优先级并获得合适的替代恢复场所的办法，就该起草实际的灾难恢复计划了。
不要指望一坐下来就能写出全部计划。
在最终形成书面文档前，DRP团队可能要反复修改文档，以满足关键业务单元的运营需求。
计划中要考虑灾难恢复预算对资源、时间和 费用的限制，以及可获得的人力资源。
接下来将讨论灾难恢复计划中应该包括的一些重要内容。
根据组织的规模大小和参与DRP的人员数量，维护几种针对不同读者的不同类型的计划文档是一个不错的主意。
下面列出一些 需要考虑的文档类型:
• 执行概要，提供对计划的高度概括具体部门的计划
• 针对负责实现和维护关键备份系统的IT技术人员的技术指导
• 灾难恢复团队的人员清单
• 为重要灾难恢复团队成员准备的完整计划副本
在灾难发生或即将来临时，使用特别定制的文档变得尤为重要。
在波及组织各个部门的灾难恢复过程中，想要使自己保持头脑清醒的人员能参考他们所在部门的计划。
灾难恢复团队的 重要成员有一份清单，这份清单在混乱环境中能指导他们的行为。
IT人员有一份技术指南，帮助他们建立和启用替代场所。
最后，经理和公关人员有一份简单文挡，不用与灾难恢复工作直 接相关的团队成员解释，
这份文档使他们能大致了解当前的灾难恢复工作是如何协调在一起的。
18.4.1 紧急事件响应
灾难恢复计划中应当包含重要人员在识别出灾难或灾难即将来临时应立即遵守的简单清晰的指令。
根据灾难的性质、对事件做出响应的人员种类，以及在需要撤离设施和关闭设备之前可用的时间，这些指令于差万别。
例如，对于大规模火灾的指令，就要比迎接预计将在48小时后，在运营地点附近登陆的飓风袭击的指令更加简明。
紧急事件响应计划通常以提交给响应者的清单的形式放在一起。
在设计这些清单时，需要记住一条重要的设计原则：对清单的任务进行优先级安排，最重要的任务排在第一位！
记住这些清单将在危机发生时被执行是很有必要的。
响应者很可能无法完成整个清单中的任务，特别是在仓促通知灾难发生时。
出于这个原因，应该把最重要的任务(例如，"触发火警") 放在清单中的第一位。
列表中级别越低的条目，在撤离/关闭之前未完成的可能性就越大。
18.4.2 人员通知
灾难恢复计划中还应该包括一份人员名单，以便在发生灾难时进行联络。
通常，这些人员包括DRP团队中的重要成员和那些在整个组织内执行关键灾难恢复任务的人员。
这份响应清单应该包括可选的联系方式(如呼机号码、手机号码等)，每一位角色还要有一位后备联系人，
以防主要联系人无法联系上或出于某种原因不能到达恢复场所的情况。
在面对灾难时，清单是非常宝贵的工具。在灾难引发的混乱中，清单提供了一系列有条理的指令。
花费一定的时间确保响应清单为最初的响应者提供清晰的指示，从而保护生命与财产的安全，并确保操作的连续性。
针对建筑物火灾的响应清单通常包括下列步骤:
(I) 启动建筑物警报系统。
(2) 确保有序撤离。
(3) 离开建筑物后，使用移动电话呼叫911(在美国范围内)，以确保应急机构接到警报通知。为必要的紧急响应提供额外信息。
(4) 确保受伤人员接受适当救护。
(5) 启动组织的灾难恢复计划，以确保业务操作的连续性。
在收集和分发电话通知列表前，出于对隐私的尊重，一定要询问组织内个人的意见。
在清单中使用家庭电话号码和其他个人信息时，可能需要遵守特殊的策略。
通知清单应该提供给所有可能对灾难做出响应的人员，这样做能够迅速通知到主要人员。
许多公司用“电话树”形式组织他们的通知清单，即树上的每一个成员联系他下面的人，
这样就把通知任务分散到团队的成员之中，而不是靠一个人拨打多个电话。
如果选择使用电话树通知方案，一定要添加安全网，
让每条链中的最后一个人联系第一个人，确保整个链条上的人都被通知到了。
这能让你放心，证明灾难恢复团队的激活正在顺利进行中。
18.4.3 评估
当灾难恢复团队抵达现场时，他们的首要任务之一就是评估现状。
这通常以滚动方式进行: 第一响应者进行非常简单的评估、分类活动并启动灾难响应。
随着事件的发展，更详细的评估将用于衡量灾难恢复工作的有效性以及资源分配的优先级。
18.4.4 备份和离站存储
灾难恢复计划(尤其是技术指南)应该完整地说明组织要求的备份策略。
实际上，这是任何业务连续性计划和灾难恢复计划中最重要的组成部分。
许多系统管理员熟悉各种不同的备份类型，
在BCP/DRP团队中有一位或几位在这方面拥有技术专长的专家会使组织受益匪浅。
目前存在下列三种主要的备份类型:
完整备份
顾名思义，完整备份存储着受保护设备上包含的数据的整个副本。
无论归档位如何设置，完整备份都会复制系统中的所有文件。
一旦完整备份完成，每个文件的归档位都会被重置、关闭或设置为0。
增量备份
增量备份只复制那些自最近一次完整备份或增量备份以来修改过的文件。
增量备份只复制归档位被打开、启用或设置为1的文件。
一旦增量备份完成，被复制的文件的归档位都会被重置、关闭或设置为0。
差异备份
差异备份复制那些自最近一次完整备份以来修改过的所有文件。
差异备份只复 制归档位被打开、启用或设置为1的文件。
不过，与完整备份和增量备份不同的是，差异备份过程并不改变归档位。
增量备份和差异备份之间最重要的差异在于：发生紧急事件时还原数据所需的时间。
如果组合使用完整备份和差异备份，那么只需要还原两个备份，也就是最近的完整备份和最近的差异备份。
另一方面，如果组合使用完整备份和增量备份，就需要还原最近的完整备份以及最近一次完整备份以来所有的增量备份。
要根据创建备份所需要的时间做出权衡:差异备份的还原时间短，但所需时间比增量备份长。
备份介质的保存同样至关重要。
我们可以方便地将备份介质保存在主操作中心或附近，以便轻易满足备份数据的请求，
但肯定需要至少在一个离站位置保管备份介质的副本，从而在主操作位置突然受到破坏的情况下能够提供冗余。
许多组织使用的一种常见策略是将备份存储在地理上冗余的云中。这允许组织从灾难后的任何位置检索备份。
请注意，当信息驻留在不同的司法管辖区时，使用位于不同地理位置的网站可能引入新的监管要求。
系统出现故障时，许多公司都使用两种常用方法之一从备份中还原数据。
在第一种情况下，公司在周一晚上进行完整备份，然后在一星期内每隔一个晚上进行差异备份。
如果故障发生在星期六早晨，那么公司需要先还原周一的完整备份，然后只需要还原周五的差异备份。
在 第二种情况下，公司在周一晚上进行完整备份，然后在一星期内每隔一个晚上都进行增量备份。
如果故障发生在星期六早晨，那么公司需要先还原周一的完整备份，然后按时间顺序依次还原每个增量备份(也就是周三、周五的增量备份等)。
大多数组织采取的备份策略都会使用多种备份，并有介质循环使用计划。
这允许备份管理人员充分访问备份数据以满足用户的请求，并在尽量减少购买备份介质支出的同时提供容错能力。
较常用的一种备份策略是：每个周末进行一次完整备份，每天晚上进行增量备份或差异备份。
具休备份方式和详细的备份流程取决于组织的容错要求。
如果无法容忍少莹的数据丢失，那么容忍故障的能力较低。
然而，如果数小时或数天的数据丢失都没有严重后果，那么容忍故障的能力就比较高了。
1. 备份介质格式
物理特征和轮换周期是有价值的备份解决方案应当跟踪和管理的两个因素。
物理特征是使用中的磁带驱动器的类型，它定义了介质的物理形状。
轮换周期是备份的频率和受保护数据的保留时间。
通过查看这些特征，可确保有价值的数据保存在可用的备份介质上。
备份介质有最大使用限制:在丧失可靠性前，备份介质可能被重写5、10或20次。
2. 磁盘到磁盘(D2D)备份
在过去10年中，磁盘存储变得越来越便宜。
现今，驱动能力已经开始用百万兆字节(TB) 来测量，磁带和光盘已无法应付数据揽的要求。
很多企业在灾难恢复策略中应用磁盘到磁盘 (D2D)备份方式。
许多备份技术是围绕磁带范式设计的。
虚拟磁带库 (VTL)通过使用软件把磁盘虚拟成磁带，使备份软件可使用这些磁盘。
一个重要的注意事项：采用完整的磁盘到磁盘备份方法的组织，必须确保地理多样性。
一些磁盘需要异地保存。许多组织通过租用托管服务来管理远程备份位置。
3. 最佳备份做法
无论采用哪种备份解决方案、介质或方法，都必须解决一些常见的备份问题。
例如，备份和还原活动可能庞大而缓慢。这样的数据移动会显著影响网络性能，在工作时间内更是如此。
因此，备份应当被调度在空闲时间(如晚上)进行。
备份数据量随着时间的推移会增加，导致每次的备份(和还原)过程都比之前花费更长时间，并且占用备份介质上的更多空间。
因此，需要在备份解决方案中设计足够的容量来处理合理时间段内备份数据的增长。
这里，是否合理完全取决于具体环境和预算。
在定期备份的情况下(也就是说每隔24小时进行一次备份)，总有可能存在自备份以来的数据丢失的现象。
墨菲定律表明服务器在成功备份之后不会立即崩溃，而往往在下一次备份开始前发生。
为避免定期备份存在的问题，需要部署某些实时连续的备份形式，例如 RAID、集群或服务器镜像。
最后，请记住测试组织的恢复流程。
企业往往出现的情形就是备份软件报告备份成功而恢复尝试却失败了，然而检测到有问题时已经太晚了。
这是备份失败的最大原因之一。
4. 磁带轮换
备份常用的几种磁带轮换策略包括：祖父-父亲-儿子 (Grandfather-Father-Son, GFS)策略、 汉诺塔策略以及六磁带每周备份策略。
这些策略相当复杂，在使用很大的磁带组时更是如此。
可通过使用一支铅笔和一本日历来人工实现这些策略，也可通过使用商用备份软件或全自动分层存储管理(Hierarchical Storage Management, HSM)系统来自动实现这些策略。
HSM系统是自动化的机械备份换带机，由32或64个光学或磁带备份设备组成。
HSM系统中的所有驱动器元 素都被配置为单个驱动器阵列(有些像 RAID)。
18.4.5 软件托管协议
软件托管协议是一种特殊的工具，可以对公司起到保护作用：避免公司受软件开发商的代码故障的影响，
以便为产品提供足够的支持，还可以防止出现由于软件开发商破产而造成产品失去技术支持的情况。
如果组织依赖定制开发或小公司开发的软件，可能需要考虑开发这类协议，将其作为灾难恢复计划的一部分。
在软件托管协议下，软件开发商将应用程序源代码的副本提供给独立的第三方组织。
然后，第三方用安全的方式维护源代码副本备份的更新。
最终用户和开发商之间的协议具体定义了什么是“触发事件”，
如开发商无法满足服务水平协议(SLA)条款或开发音的公司破产。
当触发事件发生时，第三方会向最终用户提供应用程序源代码的副本。
之后，最终用户可通过分析源代码来解决应用程序的问题或升级软件。
18.4.6 外部通信
在灾难恢复期间，很有必要与组织外部不同实体间进行通信。
需要联系供应商提供物资，以便在需要时他们能够支持灾难恢复工作。
客户会与你联络，从而确认仍在运营。
负责公关的领导可能需要联系媒体或投资公司，经理可能需要与政府的管理机构进行会谈。
出于这些原因，灾难恢复计划中必须包括数量充足的与外部联络的通信渠道，以便满足公司的运营需求。
通常，在灾难期间由CEO充当发言人不是合理的业务实践或恢复实践。
公司应当雇用和培训媒体联络人员，以便随时准备担当此任。
18.4.7 公用设施
如本章前面所述，组织要依靠一些公用设施来提供自身基础设施的关键要素，如电力、水、天然气和管道服务等。
因此，灾难恢复计划中应该包括联系信息和措施，以解决这些服务在灾难发生过程中出现的问题。
18.4.8 物流和供应
灾难恢复操作过程中有关物流的问题是值得关注的。
此时，你会突然面临调拨大量人员、 设备和供应物资到备用恢复场所的问题。
人员可能会在那些场所内生活很长一段时间，并且灾难恢复团队会负责给他们提供食物、水、避难所和适当的设施。
如果这些情况恰好发生在预期操作范围之内，那么灾难恢复计划中就应该包括这样的条款。
18.4.9 恢复与还原的比较
有时，区分灾难恢复任务和灾难还原任务是很有用的。
在估计恢复工作要花费很长时间时，这尤为重要。
在灾难恢复团队被指派执行和维护恢复场所工作时，一支救助团队被指派还原主场所的运营能力，
应当依据组织的需要和灾难的类型来分配这些任务。
恢复涉及将业务操作和过程还原至工作状态;
还原涉及将业务设施和环境还原至可工作状态。
灾难恢复团队成员可操作的时间范围很短，他们必须尽可能迅速地应用DRP和还原IT能力。
如果灾难恢复团队不能在MTD/RTO内还原业务过程那么公司会遭受损失。
一旦人们相信原有场所是安全的，那么抢救团队就开始工作。
他们的工作是将公司还原至最初的全部能力，并在必要时还原至原始位置。
如果原始位置不复存在，就需要选择新地点。
抢救团队必须重构或修复IT基础设施。
因为这个活动基本与构建新的IT系统相同，所以从可替代的恢复场所返回至最初的主要场所的活动本身就有风险。
此外，抢救团队的工作时间多于恢复团队的工作时间。
抢救团队必须确保新的IT基础设施的可靠性。
通过将最小关键任务进程返回至被还原的原有场所，进而对重构的网络进行压力测试，抢救团队就可实现这个目标。
一旦被还原的场所展现了自己的恢复能力，那么更重要的进程会被转移至原有场所。
关键任务进程返回原有场所时存在严重的脆弱性。返回原有场所的动作可能导致自身的灾难。
因此，只有在全部的正常操作都返回至被还原的原有场所后，才能宣告紧急状态结束。
在结束所有灾难恢复工作之后，就需要在原有场所执行还原操作，并终止灾难恢复约定下的任何处理场所操作。
DRP应当指定能够确定何时适合返回原有场所的标准，并且指导DRP恢复和抢救团队进行有序转移。
18.5 培训、意识与文档记录
与业务连续性计划一样，对所有涉及灾难恢复工作的人员进行培训是十分重要的。
培训所要求的程度根据每个人在公司中的职位和角色而有所不同。
在制订培训计划时，应该考虑下面这些要素:
• 对全体新员工进行定向培训。
• 对第一次担任灾难恢复角色的员工进行基本培训。
• 对灾难恢复团队的成员进行详细的复习培训。
• 对所有的其他员工进行简要的复习培训。
(可以作为会议的一部分或通过像电子邮件的时事新闻这样的形式发送给所有员工)。
灾难恢复计划还应该进行完整的文档记录。
本章前面讨论了几种可供使用的文档记录方式。
一定要实现必要的文档记录程序，并在计划发生改变后修订文档。
基于灾难恢复计划和业务连 续性计划快速变化的本质，可以考虑在内网发布有保证的部分。
DRP应被视为极其敏感的文档，并且只在分隔和“知其所需"的基础上提供给个人。
参与计划的人员应当完全理解其角色，但是不必知道或访问整个计划。
当然，确保DRP团队关键成 员和高级管理人员知晓整个计划和理解实现细节是必不可少的。
不必让每位参与计划的人员都了解所有内容。
需要记住，灾难可能导致内网不可用。
如果选择通过内网分发灾难恢复计划和业务连续性计划，
那么一定要确保在主要场所和替代场所都保存足够数量的打印副本，并且只保存最新的副本。
18.6 测试与维护
每一种灾难恢复计划都必须定期进行测试，以确保计划的条款是可行的并且符合组织变化的需要。
可以实施的测试类型依赖于能够使用的恢复设施的类型、企业文化和灾难恢复团队成员的可用性。
本章余下的部分将讨论5种主要的测试类型:通读测试、结构化演练、模拟测试、并行测试和完全中断测试。
18.6.1 通读测试
通读测试是其中最简单的，但也是最重要的一种测试。
在这类测试中，只需要向灾难恢复团队成员分发灾难恢复清单的副本，并要求他们审查。
这样做可以同时实现下列三个目标:
• 清单确保关键人员意识到他们的职责并定期复习知识。
• 为人员提供了审查清单中过时信息的机会，并根据组织的变化更新需要修改的内容。
• 在大型组织中，清单可帮助标识这样的情况:
重要的人员已经离开公司，并且没有人清单确保关键人员意识到他们的职责并定期复习知识。
为重新分配他们的灾难恢复职责而负责！这也是为什么灾难恢复职责应该包含在岗位描述中的原因。
18.6.2 结构化演练
结构化演练执行进一步的测试。在这种经常称为“桌面练习"的测试类型中，
灾难恢复团队成员聚集在一间大会议室中，不同的人扮演灾难发生时的不同角色。
通常，确切的灾难情景只有主持人知道，他在会上向团队成员描述具体情况。
然后，成员通过参考他们的灾难恢复计划对特定的灭难进行讨论，进而得出适当的响应办法。
18.6.3 模拟测试
模拟测试与结构化演练类似。模拟测试向灾难恢复团队成员呈现清景并要求他们做出适当的响应措施。
与前面讨论的测试不同，其中某些响应措施随后会被测试。
这种测试可能会中断非关键的业务活动并使用某些操作人员。
18.6.4 并行测试
并行测试表示下一个层次的测试，涉及将实际人员重新部署到替换的恢复场所并实施场所启用过程。
被重新部署到该场所的员工，以灾难实际发生时的方式履行他们的灾难恢复职责。
唯一的差别在于不会中断主要设施的运营，这个场所仍然处理组织的日常业务。
18.6.5 完全中断测试
完全中断测试与并行测试的操作方式类似，但涉及实际关闭主场所的运营并将其转移至恢复场所。
这类测试有很大的风险，因为它们要求停掉主站点的操作，并转移到恢复站点。
测试完成后，在主站点执行恢复操作的反向过程。
由于这个原因，完全中断测试非常难以安排，通常会遇到来自管理层的阻力。
18.6.6 维护
需要记住，灾难恢复计划是一份灵活的文档。
随着组织需求的变化，必须对灾难恢复计划进行修改以适应这些变化。
通过使用组织好的和协调一致的测试计划，我们会发现灾难恢复计划中需要修改的地方。
细微的变化经常会通过一系列的电话交谈或电子邮件进行，
然而重大变化可能需要整个灾难恢复团队进行一次或几次会议商讨。
灾难恢复计划编制人员应当借鉴组织的业务连续性计划，把它作为恢复工作的模板。
这个模板和所有支待性素材都必须遵守美国联邦的法规并反映当前的业务需求。
业务过程(如薪水和订单生成)应当包含映射到支持性IT系统和基础设施的特定度量。
大多数组织都应用正式的变更管理过程，这样在IT基础设施发生更改时就能更新和检查所有相关的文档，以便反映变更。
通过调度常规的消防训练和演练来确保DRP的所有元素都被正确使用，从而对所有职员进行培训，并且是将变更集成到日常维护和变更管理措施中的一次极佳机会。
每次设计、实现和记录变更时，都需要重复这些过程和实践。
一定要了解所有设施的位置，并且正确维护 DRP工作的所有元素，在出现紧急情况时，就需要使用恢复计划。
最后,要确保所有职员都经过培训，从而提高现有支持人员的技能，并且确保新员工尽快了解相应的工作。
第18章 灾难恢复计划相关推荐
- 第18章：MYSQL分区
第18章:分区 目录 18.1. MySQL中的分区概述18.2. 分区类型 18.2.1. RANGE分区18.2.2. LIST分区18.2.3. HASH分区18.2.4. KEY分区18.2. ...
- 计算机软件项目管理第1-8章课后题
计算机软件项目管理第1-8章课后题 如何理解项目的定义及其含义?项目定义:是一个特殊的将被完成得有限任务,它是在一定时间内,满足一系列特定目标的多项相关工作的总称.项目三重约束条件:时间.费用.性能. ...
- 制定灾难恢复计划时易忽略的九件事
每一位IT经理都知道用有一个有效的灾难恢复(DR)计划的重要性.那么,在部署灾备方案的时候,有哪些重要的因素被忽视了?基于对数以千计的中小型用户的调查,我们列出了大家最易忽略的九件事. 1. 没有考虑 ...
- 第18章 类加载机制与反射
第18章 类加载机制与反射 18.1 类的加载.连接和初始化 18.1.1 JVM和类 18.1.2 类的加载 18.1.3 类的连接 18.1.4 类的初始化 18.1.5 类初始化的时机 18.2 ...
- Spring - Java/J2EE Application Framework 应用框架 第 18 章 使用Quartz或Timer完成时序调度工作
第 18 章 使用Quartz或Timer完成时序调度工作 18.1. 简介 Spring提供了支持时序调度(译者注:Scheduling,下同)的整合类.现在, Spring支持内置于1.3版本以来 ...
- 复现经典：《统计学习方法》第18章 概率潜在语义分析
第18章 概率潜在语义分析 本文是李航老师的<统计学习方法>一书的代码复现.作者:黄海广 备注:代码都可以在github中下载.我将陆续将代码发布在公众号"机器学习初学者&quo ...
- project 模板_不会绘制横道图？18个施工进度计划横道图模板，可一键自动生成，方便快捷易操作，直观形象，相当好用...
横道图是通过条状图来显示项目,进度,和其他时间相关的系统进展的内在关系随着时间进展的情况,相当形象直观,在建筑广泛应用. 这18个施工进度计划横道图模板包括7个Excel模板和11个project模板 ...
- 软件开发计划_敏捷软件开发实践：估算与计划读书笔记123第21章 关于计划的沟通...
<敏捷软件开发实践:估算与计划>第21章 关于计划的沟通,重点和要点的思维导图及文字内容. 第21章 关于计划的沟通 The more elaborate our means of com ...
- 信安教程第二版-第18章网络安全测评技术与标准
第18章网络安全测评技术与标准 18.1 网络安全测评概况 379 18.1.1 网络安全测评概念 379 18.1.2 网络安全测评发展 379 18.2 网络安全测评类型 380 18.2.1 基 ...
最新文章
- R语言构建xgboost模型：模型的特性重要度计算及可视化、模型对应的结构树（文本文件）
- spring+Quartz定时任务
- 网友投诉顺丰快递员私拆快递物品摆拍、言语骚扰 官方处理来了...
- IP地址专题二：子网掩码入门
- 两台笔记本的操作系统都为xp的共享上网教程
- linux： 空指令(:)
- Rhadoop的安装
- 双轴旋转云台plc控制_基于STM32的双轴监控云台精准控制系统设计
- Uhuntu搜狗拼音输入法安装详细过程
- Isilon旧机器重新初始化
- 算法——最短路径应用
- Promise then的嵌套
- 轮换对称性实质 和差化积公式之sinθ+cosθ推导 rd原理，二重积分坐标系转化为什么多了个r； 二重积分几何意义： 二重积分物理意义： 二重积分求导：
- ubuntu 火狐浏览器找不到服务器
- 关于GMac和FLOPs讨论
- 数据脱敏（Data Masking）学习
- 计算贷款的每月支付额。程序要求用户输入贷款的年利率、总金额 和年数，程序计算每月支付金额，并将结果显示输出。计算贷款的月支付额公式如下：（Java课本练习题 题目要求 ）
- maven打包时本地的jar包打不进去
- Android studio 3.0 Appt2的异常问题 不一定需要关闭才能通过编译
- Java多线程创建方式初探