9.5 灾难恢复与业务连续性

概述与动机

早晚有一天，某个你未曾预料的事件会导致系统宕机：一次波及整个区域的云服务中断、一次手滑执行的 DROP TABLE、数据中心的一场洪灾、一次勒索软件的引爆，或是一家供应商一夜之间消失。问题从来不是中断会不会到来，而是你能多快恢复，以及在这个过程中会损失多少。本章要讨论的，就是如何在坏日子到来之前做好准备。

有两门学科共同回答”如何做好准备”这个问题，但它们并不是一回事。业务连续性规划（BCP）让整个组织在中断期间维持运转：人员、办公场所、通信、薪酬发放，以及客户所依赖的关键业务流程。灾难恢复（DR）则是范围更窄的技术性工作，即在 IT 系统和数据发生故障后将其恢复。连续性是目标，恢复只是实现这一目标的手段之一。你完全可以恢复每一台服务器，却依然辜负客户（）如果没有人知道谁有权宣布进入灾难状态，或者不知道如何联系到相关人员。本章将 DR 视为一项工程实践，而将 BCP 视为它所服务的业务框架。

对于大型团队而言，风险随规模同步放大。企业背负着监管层面的恢复义务、多区域布局，以及集中在少数几家供应商身上的集中度风险。政府则承担着为公民维持基本职能的法定义务，这一义务被明文规定为”业务持续运行”（continuity of operations）。二者都处在严格监督之下，一份从未经过检验的计划，是你只会在最糟糕的时刻才会发现的隐患。恢复正是可靠性（第 9.1 章）与事件响应（第 9.3 章）相互交汇之处，也是二者共同面对”如何在无法通过设计规避的故障中幸存下来”这一更棘手问题的地方。

关键原则

连续性的范围比恢复更广。 恢复服务器不等于让业务持续运转。
两个数字驱动一切。 恢复时间目标（RTO）与恢复点目标（RPO）由业务影响决定，决定着每一项决策的规模。
未经检验的备份不是备份。 一次从未执行过的还原，只是一种期望，而不是一种能力。
假定备份本身就是攻击目标。 勒索软件会优先猎取你的备份，因此要让副本保持不可变并离线保存。
从代码而非记忆中重建。 如果你无法从源代码重新创建基础设施，就无法可靠地恢复它。
绘制依赖关系图。 你的恢复速度取决于你最慢的上游依赖项。
像对待其他系统一样衡量恢复能力。 依据真实演练得出的实际 RTO 和 RPO，而不是写在幻灯片上的数字。

建议

依据业务影响分析设定 RTO 和 RPO

每一项恢复决策都源自两个数字，所以要先把它们定对。恢复时间目标（RTO） 指系统可以承受多长时间的中断而不至于造成不可接受的损害。恢复点目标（RPO） 指你能承受损失多少数据，以你能还原到的最后一份可用副本的”陈旧程度”来衡量。一个支付账本系统可能要求 RTO 以分钟计、RPO 接近于零；而一个内部分析看板则可能允许两者都以一天为限。这两个数字不应由工程团队自行拍板，而应源自一份业务影响分析（BIA），它按业务流程中断所带来的成本对各流程排序，并将每个流程回溯到它所依赖的系统和数据。目标定得越紧，成本就越高，因此正是 BIA 让你不至于给一个无关紧要的服务过度加固，却让一个关键服务保护不足。

把备份做对：3-2-1 原则、不可变性与测试

备份是任何恢复策略的基石，而大多数组织做得都比自己以为的要差。请遵循被称为 3-2-1 原则 的备份纪律：至少保留三份数据副本，存放在两种不同的介质或系统上，其中一份存放在异地。现代威胁又带来了两项额外要求：至少保留一份不可变副本（在保留期内只能写入、无法删除），并且最好做到离线或物理隔离，因为如今的勒索软件会在露出真容之前，先蓄意加密或删除它能够触及的备份。最重要的是，要按计划定期测试还原。未经测试的备份不是备份，而是一个未经验证的假设，你在演练中发现的问题（损坏的归档文件、丢失的加密密钥、备份错了卷）恰恰就是在真实事件中会要了你命的那些问题。

在成本与速度的取舍谱系中选择 DR 策略

DR 策略是在用金钱换取恢复速度，因此你应当依据每个系统各自的 RTO 和 RPO 逐一选择，而不是为所有系统统一购买同一档位。四种模式构成了这条谱系的锚点。备份与还原（Backup and restore） 成本最低、速度最慢：灾难发生时从备份重建，RTO 以小时甚至天计。引燃灯（Pilot light） 让一个最小化的核心（数据库保持复制、核心配置就位）保持”温着”但处于缩容状态，随时可以扩容。热备（Warm standby） 运行一份规模较小、始终在线的完整技术栈副本，故障切换时再扩容，将 RTO 压缩到分钟级。多站点主动-主动（Multi-site active-active） 在两个或更多地点以全容量运行、同时承接实时流量，能以最高的成本和复杂度换来接近零的 RTO。要把档位与业务方认可的数字相匹配，不要为一个只需要引燃灯档位的系统去支付主动-主动的价钱。

复制数据时牢记一致性的取舍

恢复速度取决于备用数据的新鲜程度有多高，而这正是你从分布式系统（第 3.3 章）那里继承来的难题。同步复制 会在第二个位置确认每一次写入之后才应答，能带来接近于零的 RPO，代价是增加写入延迟，并对距离有硬性限制。异步复制 在本地确认后再传输变更，因此速度快、地理部署灵活，但会留下一段复制延迟窗口，在故障切换时你会损失这段窗口内的数据。这里没有免费的选择：更强的一致性以延迟为代价，更弱的一致性以数据为代价。应针对每个数据存储依据其 RPO 做出决定，并清楚了解你典型的复制延迟，因为在糟糕的那一天，这个延迟才是你真正的 RPO，而不是设计文档里写的那个数字。

用基础设施即代码从代码重建

你无法可靠地恢复一个靠手工搭建起来的环境，因为没有人能记住每一次点击操作。把你的环境定义为基础设施即代码（第 8.2 章），这样整套技术栈就能从受版本控制的源代码，以一个已知良好的状态被重新创建出来。这会把恢复从一场考古工作变成一次可重复执行的流水线运行，让你的备用区域保持诚实（当两个区域都由同一份代码构建时，漂移会更少），并且在遭到入侵之后，也能让你在一个全新的账户或区域中干净地搭建起恢复基础设施。要把代码、密钥引用和操作手册存放在即便丢失主环境也能幸存下来的地方。

提前绘制依赖关系图，而不是等到需要时才做

系统是以网状方式失效的，而不是孤立地失效，恢复工作往往卡在那个被你遗忘的依赖项上。梳理每个关键系统运行所需要的一切：上游服务、DNS、身份与身份验证、证书颁发机构、消息队列，以及第三方 API 和 SaaS 提供商。记录好恢复顺序，因为在数据库或身份提供商之前先把应用拉起来，只会制造出第二次故障。要特别关注外部供应商，因为你的恢复速度受限于他们的恢复速度，而你往往对此毫无可见性。这项梳理工作与韧性和优雅降级（第 3.5 章）直接相关：一个系统的硬依赖越少，它就能恢复得越快。

把恢复测试当作一种实践，而不是一次性的活动

一份从未演练过的 DR 计划就是虚构的。构建一个层层递进的测试阶梯。桌面演练（tabletop exercise） 让团队在纸面上走一遍某个场景，找出角色分工、决策和沟通上的漏洞。game day 会在一个接近真实的环境中注入一次真实的、可控的故障。完整故障切换演练 则真正切换到恢复站点并在其上运行。要按固定节奏开展这些演练，轮换演练场景（包括损失某个关键人员或供应商的情形），并衡量结果：记录你实际达到的 RTO 和 RPO，并与目标值对比。所测得的恢复能力与承诺的恢复能力之间的差距，是你所拥有的最诚实的可靠性指标，而缩小这一差距，正是演练的全部意义所在。

把网络安全恢复当作独立场景来规划

勒索软件和破坏性网络攻击打破了普通 DR 的种种假设，因此需要单独对待。在自然灾害中，你的数据完好地保存在别处；而在勒索软件事件中，你的数据、乃至你的备份本身往往就是武器，你的恢复环境本身也可能已经被攻陷。要规划一次洁净室式恢复（clean-room recovery）：在一个隔离的、可信的环境中，从不可变副本中还原，扫描入侵痕迹，并在重新连接任何东西之前先重建身份和凭据体系。要清楚哪一份备份是你最后一个已知干净的时间点，并且要预料到，找出这个时间点所需要的取证时间，是你平常的 RTO 从未预算进去的。这正是不可变离线副本发挥其价值的地方，也与事件管理（第 9.3 章）以及数据泄露处置方面的合规与治理义务（第 4.6 章）紧密相连。

权衡：利与弊

DR 策略	优点	缺点
备份与还原	成本最低；简单；持续成本低	RTO 慢（数小时到数天）；RPO 较大
引燃灯	成本低；核心数据保持温热、随时可用	需要人工扩容；恢复仍需真实耗时
热备	RTO 快（分钟级）；完整技术栈已验证	需要持续维持第二套运行环境的成本
多站点主动-主动	RTO 接近于零；不存在单站点故障	成本和复杂度最高；一致性难以保证
同步复制	RPO 接近于零	写入延迟；受距离限制；耦合更紧密
异步复制	快速、灵活、不受地理限制	数据丢失窗口等于复制延迟

核心张力在于，恢复速度和数据新鲜度都需要花钱、都会带来复杂度，在任何档位上都不是免费的。应当逐个系统去化解这一张力，而不是在整个组织层面一刀切：让业务影响分析为每个关键系统分配 RTO 和 RPO，然后精确购买能够满足它的策略。把主动-主动的钱花在一个报表工具上，就是在克扣那个真正需要这笔钱的账本系统，反过来也一样是失职。这门学科的核心，就是让投入与业务方认可的数字相匹配，并随着系统重要性的变化而不断重新审视这种匹配关系。

需要与团队讨论的问题

你的每个关键系统的 RTO 和 RPO 分别是多少，又是业务方的哪位负责人签字认可的？ 如果这些数字完全是工程团队自己凭空想出来的，那它们就是猜测，而猜测得到的资源要么过多、要么完全没有。恢复时间目标和恢复点目标应当是业务影响分析的产物，该分析按中断成本对各业务流程排序，因此账本系统得到的是分钟级目标，而内部维基得到的是一天。带上你当前的分级方案，问一问每个业务流程的责任人是否真的能接受你为其设计的数据丢失量和停机时长。在大型组织中，正是这样的对话才能避免”平均保护所有系统”这种代价高昂的错误，因为那样做其实谁都保护不好。如果工程团队之外没有人能说出这些数字，那你拥有的还不是目标，而只是一些期望。
你上一次执行真实还原是什么时候，是否测量了实际达到的 RTO 和 RPO？ 一份从未还原过的备份只是一个未经验证的假设，而真正会致命的那些故障模式（损坏的归档文件、丢失的加密密钥、备份错了卷、一个怎么也拉不起来的依赖项）只有在你真正尝试时才会浮现。带上你最近一次完整故障切换演练（而不是桌面演练）的日期和结果，以及你实际达到的恢复效果与你承诺的恢复效果之间的差距。对于大型团队而言，一个系统的一次成功还原并不能证明其他系统同样可行，所以要问一问在过去一年里，究竟有多大比例的关键系统真正经历过端到端的恢复。这个被测量出来的差距，是你最诚实的可靠性数字，如果你说不出来，那么在被证明之前，你的计划就只是虚构。
如果今晚勒索软件加密了你的生产环境并波及了你的备份，你最后一个已知干净的副本是哪一份，你会在哪里重建？ 普通的灾难恢复默认你的数据安全地保存在别处，而一次破坏性的网络攻击恰恰打破了这个假设（）它把你的数据、乃至你的备份本身变成了武器。要问一问：是否至少有一份备份副本是不可变且离线的，你将如何确定最后一个干净的还原点，以及当生产环境本身已被攻陷时，一个可信的洁净室环境将从何而来。这种场景需要取证时间，而这段时间从来都不在你正常的 RTO 预算之内，所以要带上一个诚实的估计：找到一个干净的时间点究竟需要多久。对企业和政府团队而言，这同时也是一起合规事件（第 4.6 章），与之并行运转的还有数据泄露通知的时钟。如果得到的答案是”我们会还原最新的备份”，那说明你根本没有为这种情况做过任何规划。
你的哪些系统正在为一个业务影响分析并不支持的恢复档位买单，又有哪些系统正处于危险的保护不足状态？ 恢复速度和数据新鲜度在每一个档位上都要花钱，因此”一刀切”的政策要么把主动-主动的预算浪费在一个报表工具上，要么克扣了那个真正需要它的账本系统。这种对立是真实存在的：对许多团队而言，统一一个标准档位要简单得多，而按系统分级虽然能让投入与价值相匹配，却需要随着系统重要性的变化持续维护。带上每个关键系统当前的 DR 策略、其目标 RTO 和 RPO、其备用环境和复制所产生的月度成本，以及上一次依据最新影响分析重新审视分级的日期。在企业或政府场景下，一个错配的档位会在各个区域中被成倍放大，审计部门会要求你既说明所花的钱，也说明所承担的风险敞口，因此一笔说不清道理的主动-主动账单，和一个毫无保护的关键服务，二者同样难以自圆其说。
你是否真正了解关键系统的恢复顺序，以及你的恢复工作在多大程度上依赖着那些你根本无法测试的供应商？ 系统是以网状方式失效的，而不是孤立地失效，恢复工作会卡在那个没有人梳理过的依赖项上：在数据库、身份提供商或 DNS 之前就把应用拉起来，只会制造出第二次故障。梳理依赖关系是件乏味的工作，而且这份地图会不断过时，但另一种选择是在真正的故障切换过程中临场发现恢复顺序，而集中在少数几家 SaaS 提供商身上的集中度风险，也要等到它们一起出故障、把你的恢复速度死死限制在它们的水平上时，才会显现出来。带上一份当前的依赖关系图、已记录的恢复顺序，以及一份外部供应商清单，注明它们各自承诺的恢复能力，以及你是否曾经验证过其中任何一项。对大型或公共组织而言，供应商连续性和集中度风险正日益成为采购和监管层面关注的问题，因此这些恢复义务应当以可审计的形式写入合同，而不是停留在供应商的宣传材料里。
如果今晚恢复了每一台服务器，业务真的能够继续运转吗？又是谁有权宣布进入灾难状态？ 灾难恢复恢复的是 IT，而业务连续性维持的是整个组织的运转：人员、沟通、薪酬发放，以及那些依赖于”有人被授权做出决定”这一前提的各项决策。你完全可以恢复每一个系统，却依然辜负了客户（）如果没有人知道谁能宣布进入灾难状态，或者在常规渠道也一并中断时不知道如何联系到员工。恢复工作归工程团队所有，但连续性却横跨设施管理、人力资源、沟通团队以及领导层的继任安排，而正是这些部门之间的缝隙，才是一份计划悄悄腐烂的地方。带上宣布权限和上报链条、备用沟通方案、指定的继任者和备用办公场所，以及业务方（而不仅仅是 IT）上一次演练该计划的日期。政府背负着法定的业务持续运行义务，需要指定继任者和基本职能；企业则面临监管层面的连续性义务，因此二者都会被依据”业务能否挺过糟糕的一天”来评判，而不仅仅是服务器有没有恢复。

行业视角

创业公司。 团队规模小、资金跑道短，你负担不起一个热备的第二区域，因此要在那些依然能救你的低成本环节上有的放矢。设定一个诚实的恢复档位，用自动快照遵循 3-2-1 原则，至少保留一份连自己的管理员都无法删除的不可变副本，并将整个环境定义为基础设施即代码，以便能从源代码重建。跳过繁复的计划文档，转而每个季度在一个临时环境中执行一次真实的还原，因为一次限时演练所带来的收获，远超一本没人翻阅的活页夹。

小型企业。 没有专职的连续性专家，预算也很紧张，应把恢复能力当作一种购买来的能力，而不是自建的能力。多依靠云服务商的托管备份、快照和跨区域复制功能，而不是自建定制化的 DR 基础设施，并选择那些备份不可变、且其还原流程你自己也能真正操作的供应商。把整个工作围绕两个不需要专家也能回答的问题来展开：我们能承受损失多少数据，我们能承受停机多久，并在真正信任之前先证明一次还原确实可行。

企业。 到了这个规模，问题就变成了跨多个团队的组合治理：一份为每项服务分配 RTO 和 RPO 的业务影响分析、从备份还原到主动-主动分级排布的恢复策略，以及一个能够看清上游和供应商依赖关系（包括集中度风险）的中央视图。要明确为备用环境、复制和不可变副本的成本编列预算，按固定节奏开展有监管方见证的完整故障切换，并将实际恢复效果与目标值的比对作为一项被持续追踪的可靠性指标。要把网络安全恢复维护成一个独立项目，配备不可变的保险库副本和洁净室操作手册，并与自然灾害演练分开独立测试。

政府。 采购规则、透明度和公共问责制塑造着每一个选择，而连续性往往是一项法定义务，而非一种偏好。要建立一套业务持续运行（COOP）计划，识别基本职能、为其恢复排序，并指定继任者和备用办公场所，确保决策不会因为找不到被授权的人而停滞，同时使其与 NIST SP 800-34 等公认指南保持一致，以支持 FISMA 相关义务。要保留物理隔离的备份副本，将基础设施定义为代码以便在备用区域重建，并每年开展一次完整演练，外加勒索软件桌面演练，将测得的结果上报给监督机构，作为基本服务能够挺过灾难的证据。

示例

创业公司。 一家十二人规模的 SaaS 公司负担不起一个热备的第二区域，因此在低成本环节上有的放矢。它设定了一个诚实的档位：客户数据库的 RTO 为四小时，RPO 为十五分钟。它用自动快照遵循 3-2-1 原则，一份副本复制到第二个云区域，另一份是带有锁定保留期、连自己的管理员都无法删除的不可变副本。它的整个环境都是基础设施即代码（第 8.2 章），因此可以从源代码搭建起一套全新的技术栈。每个季度的某个周五下午，它都会在一个临时环境中执行一次真实还原，记录耗时并整理一份简短记录。第一次演练耗时九个小时，还发现了一个缺失的迁移步骤；正是这个修复，让下一次演练只用了三个小时。

企业。 一家跨国银行在监管层面的恢复要求下运营，这些要求强制其关键服务必须具备经过测试的连续性。它为核心银行平台在第二区域运行热备，在同城对之间采用同步复制以获得接近于零的 RPO，并向远距离区域进行异步复制以应对区域性灾难。一份业务影响分析为每项服务分配了 RTO 和 RPO，一个中央团队梳理了上游依赖关系，其中两家 SaaS 提供商被标记为集中度风险。它每年两次执行有监管方见证的完整故障切换，将实际结果与目标值对比，并把差距反馈到下一个周期中。另一个独立的网络安全恢复项目维护着不可变的保险库副本和洁净室操作手册，与自然灾害演练分开独立测试。

政府。 一个负责发放福利的国家级机构维持着一套业务持续运行（COOP）计划，旨在任何中断期间维持其基本职能。它遵循业务持续运行实践，以及支撑其 FISMA 相关义务的 NIST SP 800-34 应急规划指南，识别基本职能、为其恢复排序，并指定继任者和备用办公场所，确保决策不会因为缺少被授权的人而停滞。面向公民的系统都有明确记录的 RTO 和 RPO，备份遵循 3-2-1 原则并配有物理隔离的副本，基础设施被定义为代码以便在备用区域重建。每年一次的完整演练，加上针对勒索软件场景的桌面演练，都会依据实测的恢复效果对计划进行检验，测试结果会上报给监督机构，作为基本服务能够挺过糟糕一天的证据。

商业论证：动机、投资回报率与总拥有成本

DR 和连续性建设带来的回报，是避免了一场灾难，而这种回报在真正需要它之前很难量化，一旦真正用上了，又会变得异常具体而沉重。应当把它当作风险管理来构建论证：一次中断的预期成本等于其发生概率乘以其影响，而对大型组织而言，这种影响涵盖从每小时停机所损失的收入，到监管罚款、数据泄露通知成本，乃至比中断本身持续更久的声誉损害。单单一次无法恢复的勒索软件事件，就曾让企业倒闭，也曾在公共部门让面向公民的基本服务瘫痪数周之久。相比之下，一套经过测试的恢复能力所需要的成本是有限而可预知的。

总拥有成本（TCO）是真实且持续存在的：备用基础设施、复制所需的带宽、备份存储（还要乘以不可变副本和离线副本的数量），以及用于构建自动化和开展演练所投入的工程时间。这正是为什么你应当按 RTO 和 RPO 分级，而不是在所有地方都购买主动-主动方案的原因所在（）这样一来，投入才能跟随每个系统的价值走，而不是执行一刀切的政策。要向领导层说明这一点，就把计划翻译成他们能理解的语言：这是我们今天能够承受的停机时长和数据丢失量，这是我们与目标之间的差距，这是弥补这一差距所需要的成本，而这是如果我们不采取行动所要承担的风险敞口。最具说服力的证据，是一次经过测量的演练，因为一次已经证明过的恢复能力，是领导层可以信任的数字，而一份从未经过测试的计划，只是伪装成资产的负债。

反模式与常见陷阱

未经测试的备份。 一次从未执行过的还原只是一种期望；演练正是你发现损坏、丢失密钥和错误卷的地方。
备份能够从生产环境直接访问。 如果勒索软件能够加密或删除你的备份，那你实际上只有一份副本，而不是三份。要让其中一份保持不可变并离线。
所有系统共用一个 RTO 和 RPO。 一刀切的档位会过度保护无关紧要的系统，却保护不足关键系统；应依据业务影响分析进行分级。
把 DR 和 BCP 混为一谈。 恢复了每一台服务器，却没有人知道谁能宣布进入灾难状态、如何联系员工，这是一次恢复成功的系统，却是一次失败的业务。
手工搭建的恢复环境。 无法从代码重建的基础设施会发生漂移，而漂移往往是在故障切换过程中才被发现的。
被忽略的依赖关系。 在数据库、身份提供商或 DNS 之前先恢复应用，只会制造出第二次故障。
计划腐烂。 一本只写过一次、从未演练过的活页夹，描述的是一个早已不复存在的系统。
供应商盲区。 你的恢复能力受限于关键供应商的恢复能力，而集中度风险要等到它们一起出故障时才会显现出来。

成熟度模型

第 1 级，启动： 恢复工作是临时且被动的。备份或许在运行，但还原从未经过测试。没有商定的 RTO 或 RPO，没有业务影响分析，恢复工作是在事件发生期间临场拼凑出来的。一次严重的数据丢失或勒索软件事件很可能无法恢复。
第 2 级，发展： 基本实践已经存在，但在各团队之间并不一致。部分关键系统的备份遵循了 3-2-1 原则，最重要的服务有明文记录的 RTO 和 RPO，也存在一份基础的 DR 计划，偶尔会测试还原。覆盖是不完整的，依赖关系没有被梳理，演练是临时性的，某个团队的纪律并不意味着下一个团队也同样如此。
第 3 级，标准化： 恢复实践在整个组织范围内被明文记录并强制执行。业务影响分析驱动着各系统分级的 RTO 和 RPO，恢复策略与这些档位相匹配，环境采用基础设施即代码，依赖关系和恢复顺序已被梳理，按既定节奏运行着桌面演练、game day 和故障切换等各类演练。一份配有不可变离线副本的网络安全恢复计划已被明文记录，并被一致地贯彻执行，而不是任由各团队自行其是。
第 4 级，管理： 恢复能力依据基线被衡量和管控。每一次演练都会记录实际达到的 RTO 和 RPO，并追踪与目标值的差距，还原成功率、过去一年内真正经历过端到端恢复的关键系统比例、备份覆盖率与不可变性，以及被作为真实 RPO 加以监控的复制延迟等指标，都会展示在仪表盘上。出现偏差就会触发相应行动，分级依据系统实际使用情况的数据被重新推导，是否放行的决策依据的是证据，而不是写在幻灯片上的数字。
第 5 级，编排： 恢复能力被持续改进、在整个组织范围内实现集成，并具备自适应能力。故障切换和网络安全恢复的洁净室还原作为常规工作被反复演练，供应商和集中度风险被主动管理，连续性与可靠性（第 9.1 章）和事件响应（第 9.3 章）实现了整合，从而使组织能够从从未见过的故障中可预测地恢复过来，并随着系统版图和威胁态势的变化，不断重新界定其恢复态势。

讨论思路

你的哪些关键系统从未经历过端到端的还原，要证明它能够做到，需要付出什么？
如果你的主云区域整天不可用，哪些业务流程会停摆，你会按什么顺序把系统恢复上线？
你的恢复工作有多大程度上依赖于那些你自己既看不到、也无法测试其恢复能力的供应商？
你在哪些地方为一个业务影响分析并不支持的恢复档位买单，又在哪些地方保护不足？
如果你的备份今晚被人访问并加密，你真正意义上最后一个已知干净的还原点是哪一个？
你承诺的 RTO 和 RPO，与你上一次演练实际达到的数值之间，真实的差距有多大？

关键要点

连续性是目标，恢复是手段。 业务连续性规划维持着组织的运转；灾难恢复恢复的是组织所依赖的 IT 系统。
RTO 和 RPO 驱动一切，二者都应源自业务影响分析，而不是工程团队的凭空猜测。应对系统分级，而不是对所有系统一视同仁地保护。
未经测试的备份不是备份。 遵循 3-2-1 原则，保留至少一份不可变且离线的副本以应对勒索软件，并按计划定期测试还原。
让 DR 策略与那个数字相匹配： 备份还原、引燃灯、热备，或是主动-主动，选择依据是每个系统各自的 RTO 和 RPO。
复制是在用一致性换取新鲜度（第 3.3 章）；你真正的 RPO 是你的复制延迟，而不是设计文档里的数字。
从代码重建，采用基础设施即代码（第 8.2 章），并在真正需要之前就先梳理好依赖关系。
通过桌面演练、game day 和完整故障切换演练来测试，衡量实际达到的 RTO、RPO 与目标值之间的差距。
把网络安全恢复单独规划，采用洁净室式还原，并把整套实践与可靠性（第 9.1 章）、事件响应（第 9.3 章）和合规（第 4.6 章）连接起来。

参考资料与延伸阅读

ISO 22301，Security and resilience: Business continuity management systems: Requirements（业务连续性管理体系的国际标准）。
National Institute of Standards and Technology，SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems（面向政府系统的 RTO、RPO 与恢复策略）。
National Institute of Standards and Technology，SP 800-61 Rev. 2: Computer Security Incident Handling Guide（事件与网络安全恢复处置）。
U.S. Federal Emergency Management Agency，Continuity Guidance Circular 及联邦 COOP 相关指南（基本职能与业务持续运行）。
Federal Financial Institutions Examination Council (FFIEC)，Business Continuity Management 手册（金融机构的监管性恢复要求）。
Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy 编，Site Reliability Engineering: How Google Runs Production Systems（可靠性与灾难测试）。
Kelly Shortridge、Aaron Rinehart，Security Chaos Engineering（有意地演练故障与恢复）。
Cybersecurity and Infrastructure Security Agency (CISA)，#StopRansomware Guide（勒索软件的预防与恢复实践）。