灾难恢复与业务连续性规划：在系统突然宕机之前做好准备

某天早上，收银系统打不开了。后屋的服务器因为电力故障而宕机，或者企业使用的存储服务发生重大中断，又或者某位员工因为打开了一封欺骗性邮件的附件，不小心把全部数据加密了。几秒钟之内浮现的问题总是一样的：没有这个系统我们还能运转多久，又该如何把它恢复？

大多数企业在事情真正发生之前，从不思考这个问题。然而对于工作依赖数字系统的企业，无论是网店、诊所、分销还是服务公司，仅仅几个小时的中断，就可能意味着订单流失、客户失望，以及难以挽回的损失。

本文用实用的语言介绍灾难恢复与业务连续性规划。我们将看看两者的区别、如何决定系统需要多快恢复、需要准备什么、如何演练计划，以及如何在资源有限的情况下起步，而无需建设昂贵的基础设施。

摘要

• 业务连续性是让运营保持运转；灾难恢复是恢复技术系统
• 确定两个数字：能容忍多长时间的中断，以及允许丢失多少数据
• 从未测试过的备份不是备份，只是一种期望
• 书面计划、明确的角色和定期演练，比昂贵的设备更重要
• 从最关键的系统开始，再分阶段扩展

两个常被混淆的术语

业务连续性是指组织在中断期间及之后继续履行其基本职能的能力。它涵盖人员、流程、场所、供应商和技术。问题很宽泛：如果办公室无法使用，客户如何继续得到服务？如果主要供应商停业，由谁来替代？

灾难恢复是更窄的一部分，即在中断之后恢复信息技术系统和数据的计划。它回答的是：服务器、应用、数据库和网络如何恢复，按什么顺序，由谁来做，从哪份备份恢复。

两者相辅相成。如果员工在系统宕机期间不知道如何服务客户，再完美的技术恢复计划也没有用。反过来，好的连续性计划需要能够在合理时间内恢复的系统。

哪些情况可算作灾难

“灾难”一词常让人联想到洪水或火灾。现实中，大多数业务中断源自更为普通的事件。认识最有可能发生的类型，有助于您准备成比例的应对措施，而不是只为戏剧性的场景做准备。

• 硬件故障：服务器、存储或网络设备损坏
• 人为失误：数据被删除、配置错误，或更新导致故障
• 网络攻击：勒索软件、账号被盗或拒绝服务
• 服务商中断：云服务、互联网、电力或支付服务宕机
• 实体灾害：火灾、洪水、地震或设备被盗
• 关键人员流失：重要知识只掌握在某一个人手中

对每种类型，思考其发生的可能性及对您业务的影响。简单的评估，哪怕只是一张带有高、中、低的表格，就足以确定优先级。您不必一次准备所有事情；只需从最可能发生、危害最大的开始。

决定一切的两个数字：RTO 与 RPO

这两个技术术语非常有用，因为它们把抽象的讨论变成具体的决策。恢复时间目标（RTO）是系统在影响变得不可接受之前允许宕机的时长。恢复点目标（RPO）是允许丢失多少数据，以从中断时刻向前回溯的时间来衡量。

如果收银系统的 RPO 是一小时，意味着您可以承受丢失最后一小时的交易，因此至少需要每小时备份一次。如果它的 RTO 是四小时，系统必须在中断后四小时内重新运行。数字越严格，方案就越昂贵。

并非所有系统都需要相同的数字。收银和订单处理可能需要快速恢复，而月度报表系统可以等一天。按关键程度对系统分级可以节省成本，因为最好的资源用在最重要的地方。

值得信赖的备份策略

备份是恢复的基础。常用的规则是至少保留三份数据副本，存放在两种不同的介质或位置，其中一份位于主站点之外。目标很简单：任何单一事件，无论是火灾、盗窃还是勒索软件，都不可能一次性抹去所有副本。

勒索软件改变了人们对备份的看法。攻击者现在常常先寻找并破坏备份，然后再加密主数据。因此，部分副本应当不可更改或与主网络断开，使日常所用的同一批账号无法触及它们。

• 按 RPO 安排的自动化备份，而不是依赖某个人的记忆
• 异地副本，或存放在访问方式不同的独立服务商处
• 在一定期限内不可更改的副本，以对抗勒索软件
• 备份加密，并把密钥存放在安全且独立的地方
• 监控备份是否成功，失败时发出警报
• 全面覆盖：数据库、文件、配置和应用密钥

从未测试过的备份只是一种期望

许多企业每晚都在运行备份，因而感到安全。直到真正需要时，他们才发现文件已损坏、不完整，或没有人知道如何恢复。知道备份是否有效的唯一办法，就是尝试恢复它。

定期安排恢复测试。从简单的开始：从备份中随机恢复一个文件，确认能够打开。然后提升难度：把一个数据库恢复到测试环境并检查其内容。在最高层级，模拟恢复整个系统并测量实际需要多长时间，再与 RTO 比较。

记录每次测试的结果：什么成功了、什么失败了、花了多长时间。测试的发现是改进计划最有价值的素材。演练中测得的时间往往远比估计的长，早点知道总比危机时才知道好。

编写真正会被使用的计划

存放在宕机服务器上的恢复计划用处不大。把计划的副本放在主系统不可用时也能访问的地方：打印出来、放在独立的存储中，以及关键人员的手机里。计划还必须足够简短清晰，以便在压力之下阅读。

1. 01系统和服务清单，按关键程度分组，并注明各自的 RTO 和 RPO
2. 02谁有权宣布进入紧急状态并启动计划
3. 03联系人清单：内部团队、服务提供商、供应商和主管部门
4. 04每个系统按正确顺序排列的恢复步骤，包括系统之间的依赖关系
5. 05备份位置、访问方式，以及谁掌握凭据
6. 06在系统尚未恢复期间，员工和客服临时的工作方式
7. 07面向员工、客户和合作伙伴的沟通计划

恢复顺序很重要。数据库通常要在依赖它的应用之前恢复；身份服务和网络往往必须先于一切。提前把这些依赖关系写下来，可以避免在高压之下出现混乱和时间浪费。

运营连续性：系统宕机时如何工作

最重要的问题往往不是如何恢复服务器，而是在此期间工作如何继续。商店需要记录销售的方式，仓库需要出货的方式，客服需要在无法访问数据时回答问题的方式。一套简单的手工备用流程，往往足以应付几个小时。

• 打印表单或离线工作表，用于记录临时交易
• 主系统不可用时收款的方式
• 单独保存的重要客户和供应商联系人清单
• 系统恢复后，不重复地补录手工数据的流程
• 向客户说明中断情况和预计恢复时间的标准信息
• 系统宕机期间，谁有权做出特殊决定的规则

这些手工流程至少每年演练一次。从未尝试过的员工，在真正需要时会不知所措。演练还会暴露被遗漏的小事，比如表单用完了，或电话号码已经失效。

基础设施选项及其成本

要实现严格的 RTO，有一系列选项。在简单的一端，异地备份和手工恢复流程，对于能容忍一天或更久的系统已经足够。在中间，云端预先准备的待命环境可在需要时启动，RTO 为数小时。在昂贵的一端，双活系统在两个地点并行运行，RTO 接近于零。

云服务让中间选项比以前便宜得多，因为您只为待命资源在使用时付费。但云并不消除对计划的需要。云的可用性是共同责任：服务商维护基础设施，而您的配置、数据和备份仍由您负责。

选择与系统价值相称的级别。为可以等一周的报表系统投入巨额恢复费用是浪费，而忽视一个会让全部销售停摆的系统则是风险。请每年检视这些选择，因为业务价值和需求会变化。

预防与恢复并行

恢复计划并不取代预防，两者相辅相成。每一次成功预防的中断，就是一次无需进行的恢复演练。一贯执行的基础预防措施，往往比半心半意实施的复杂方案更有影响力。

• 为操作系统和应用定期进行安全更新
• 为重要账号和远程访问启用多因素认证
• 网络分段，使一台被感染的设备无法触及所有系统
• 培训员工识别欺骗性邮件和链接
• 限制访问权限，使失误或入侵不至于破坏整个系统
• 对异常活动进行监控和早期预警

简单的预防加上经过测试的恢复，造就务实的韧性。您无法保证什么都不会发生，但可以确保事件不会演变成让业务停摆的灾难。

危机中的人员与沟通

技术只是恢复的一部分，其余的是人。确定谁领导响应、谁负责沟通、谁进行技术恢复，以及如果这个人无法到位时由谁顶替。只有一个人掌握知识，本身就是一个故障点。

诚实而及时的沟通能维系信任。客户通常会理解中断，只要被告知发生了什么以及预计何时恢复；但被晾在一边没有消息时，他们会失望。为各种情形准备信息模板，让团队不必在压力下从头撰写。

事件之后，召开不追究责任人的复盘。发生了什么、为什么、哪些做得好、哪些需要改进。这样的复盘把每一次中断都变成能强化下一份计划的学习。

把恢复与供应商和合作伙伴关联起来

您的业务依赖其他各方：网络服务商、云服务、支付处理方、快递以及货物供应商。其中任何一个出现中断，即使您的内部系统一切正常，也可能让您的运营瘫痪。这份外部依赖清单需要写入计划，并在可能时附上替代方案。

向关键服务商询问可用性保证、恢复流程，以及发生中断时如何通知客户。同时检查是否有可以快速启用的替代方案，例如备用的互联网连接或第二家支付服务商。对非常重要的功能只有单一路径，是值得重新考虑的风险。

在资源有限的情况下起步

1. 01列出在用的系统，并找出对业务最关键的三个
2. 02与流程负责人一起，为这三个系统设定粗略的 RTO 和 RPO
3. 03确保在独立的位置有自动化备份，并测试一次恢复
4. 04写一份一到两页的计划，包含联系人、角色和主要步骤
5. 05为最重要的业务功能准备简单的手工流程
6. 06每年进行一次桌面推演：讨论一个场景，并一起走查计划
7. 07每当系统或关键人员发生变化时，检视并更新计划

桌面推演是一种成本低又有效的起步方式。召集关键人员，描述一个场景，例如“主服务器在高峰时段宕机”，然后一步一步走查会采取什么行动。通常只需一小时的讨论，就能暴露重要的缺口。

常见错误

• 以为有备份就等于能恢复，却从未测试
• 把备份存放在与主系统相同的位置和相同的网络上
• 计划只存在于某个人的脑海中，或存放在可能宕机的系统里
• 系统和人员变动后没有更新计划
• 只考虑技术，而忘了工作方式和沟通
• 认为云服务会自动解决所有恢复事宜

结语

没有哪家企业能免于中断，但几小时内恢复的企业与瘫痪数天的企业之间差别巨大。这种差别几乎总是在于事件发生之前从容做好的准备，而不在于最昂贵的设备。

从小处开始：找出最关键的系统，设定容忍数字，确保备份确实可以恢复，写一份简短的计划，并加以演练。每一步都在减少不确定性，当中断真正到来时，您的团队就会知道该怎么做。