负责业务连续性的IT负责人，在验收混合云灾备方案时要回答一个具体问题：备库已经启动，订单却仍写不进去，这算恢复了吗？如果全量双活的改造预算批不下来，怎样证明另一套方案也能接住业务？

第三条路是分级容灾：允许短时停单的核心交易先评估温备，可重建的数据走冷备，连续服务要求再推动局部双活；各级都要单独证明数据损失边界。关键不是少买一套机器，而是把“恢复成功”写成可以验收的结果。

先把恢复后的样子写下来

比如，一套内部订单系统主站在自建机房，备用站在公有云；以下目标和时间均为演示用的假设数据。业务允许短时停单，恢复后可以先关闭报表，但订单创建、库存扣减和查询必须可用。

验收单先填成这样：

故障范围：主站整体不可服务，备用站可独立运行。 恢复目标：业务中断起30分钟内恢复下单，按每分钟600单连续验收4分钟，验收结束不晚于第30分钟。 数据目标：最多接受故障前60秒内的订单记录缺失，缺失订单须可识别并进入核对流程。 成功条件：新订单可查询，同一业务请求重试不重复扣库存，外部扣款状态有核对结果；报表允许延后。 交接责任：值班负责人判定事件，平台组提供旧站隔离与容量证据，DBA确认数据边界，业务负责人验收订单。

RTO是可接受的业务中断时间，RPO是可接受的数据损失时间窗口。Google Cloud的容灾规划指南特意区分了时间窗口与数据数量：60秒并没有告诉你丢了多少单，更没有说明这些单能否补偿。

所以计时从业务中断开始，到约定吞吐和正确性恢复为止；数据库进程启动只是中间状态。报表可以晚恢复，订单依赖的身份认证、密钥和库存接口却必须进入同一个验收范围。

把认证入口、域名解析、镜像仓库、密钥服务逐项标出依赖位置。两套业务都要经过同一条专线回机房鉴权，机房故障仍会同时阻断它们。故障域，指的就是一次故障可能共同影响的范围。

倒过来选：灾难发生前，哪些东西必须在运行？

这里的双活指两站平时都承接业务，并不意味着同一份数据库允许两边任意写入。温备是备用站平时已运行功能完整的业务副本，容量可以缩小；冷备则在故障后恢复数据并启动业务。

四个维度放在一张表里，先比较要解决的工作，不给架构名称贴固定分钟数：

评审维度

双活

温备

冷备

RTO：还剩什么动作

摘除故障站、重连与承接其负载

确认数据、接管写权、扩容与放流

准备环境、恢复数据、启动并验收

RPO：靠什么保证

取决于提交确认与复制语义

取决于复制、持久化和可恢复日志

取决于备份及连续日志的可用边界

数据一致性：难点在哪

写入归属、冲突或跨站协调

单写交接、缺口核对和重试去重

恢复点一致性及下游状态校正

演练成本：要证明什么

单站承载、网络分区与回切

隔离、提升、扩容、补偿与回切

完整恢复耗时、备份可用与环境重建

AWS的容灾白皮书把温备描述为缩小但功能完整的副本；只保留核心数据设施、应用临时启动的方式则称为pilot light。评审供应商方案时，让对方写清哪些组件常驻、哪些临时创建，比争论“温”还是“冷”更有用。

对这套订单业务，可先评估单写数据库配温备应用；报表由可重建的数据恢复。若报表和订单共用同一个数据库实例，不能仅靠贴不同等级标签就省下数据库资源，需要先确认实际隔离边界。

预算也按这些动作报价：双活增加跨站流量治理、写入归属和兼容发布工作；温备要维护两端配置、复制监控和扩容脚本；冷备要持续证明备份、安装包和恢复流程仍然有效。

比较年度总成本时，把常驻资源、跨云传输、备份保留、软件许可、值班和演练工时放在同一口径下，另列故障期扩容支出。没有实测恢复耗时和人员投入，不宜直接宣称温备比双活便宜某个百分比。

30分钟目标，拆到每一次交接

把恢复时间按实际依赖顺序拆开。这套订单系统先用串行预算审视：发现与判定3分钟，隔离旧站4分钟，数据确认与提升6分钟，扩容与重连8分钟，业务验收4分钟，合计25分钟，给30分钟目标留5分钟余量。

若扩容阶段由8分钟变成16分钟，总时长就是33分钟，方案超标。存在并行动作时，应按最长依赖路径计时，而不是把所有组件耗时机械相加。

判定阶段，先区分站点故障与复制通道故障。值班负责人要拿到业务失败探测和站点可达性证据。只有跨云链路断开、旧站仍在正常服务时，自动提升备用站会制造两个写入入口；此时应先处理复制中断，并记录数据保护能力已经下降。

隔离阶段，交付的是旧站失去写入能力的证据。平台组可以通过预置的停机、存储隔离或写入入口封锁机制完成隔离，但只改域名不足以证明旧连接和后台任务都已停止写入。实际生产接管应由授权值班人员按已批准预案执行；没有隔离回执，就停在提升之前。

数据阶段，DBA必须同时回答“有什么”和“缺什么”。以PostgreSQL 18为例，WAL是恢复数据库修改所依赖的预写日志；备库接收并回放日志，默认流复制是异步的。主站返回成功时，远端可能还没有对应记录。

备库已持久化的位置决定数据能恢复到哪里，已回放的位置决定还要处理多少日志。故障前“延迟很低”的截图不能证明缺口。本例拟由订单服务在返回成功前，把业务号、确认时间及订单内容同步持久化到云端独立回执库；保存失败就不返回成功，该库不依赖主站认证。

这样客户端收到成功的订单必有回执；回执已存但响应丢失的订单也纳入核对。DBA按故障时点封存回执快照，以业务号集合比对恢复库，而非拿最新订单时间相减。比如10:00:00故障，同一时钟基准下，09:59:20及以前的回执全部匹配，其后缺3笔，损失窗口上界为40秒。

这3笔进入补偿清单；回执覆盖无法证明就填“未知”，暂停提升，由业务负责人决定是否接受另案风险，不标记RPO达标。回执库本身增加跨云提交等待和运维成本，须计入方案；6分钟只是核对与提升的预算，演练测不下来就重分预算或改方案。

数据边界确认后才提升。PostgreSQL 18的Failover章节不提供完整接管编排，pg_promote()只触发提升。本文建议平台组把事件号、阶段、隔离回执、数据结论和执行人持久保存到云端恢复工单；值班负责人交接该工单。

脚本中断或提升超时后，由DBA核验目标库是否仍在恢复、旧站隔离是否有效：已提升就跳过该动作，仍在恢复且门禁有效才重试，状态不明则停下，不能凭超时直接重发提升。

容量阶段，要在旧站不可用的条件下扩容，并验证依赖可独立使用。平台组核对云端配额、可用容量、镜像和凭据，再让应用重建数据库连接。平时保留的小容量温备能响应探测，不代表它能承担约定的每分钟600单；需要故障状态下的负载验证。

业务验收阶段，拿业务流水而不是健康页判定成功。本例由订单服务同库事务保存订单与去重记录，库存服务独立保存扣减流水，两者不假定恢复点一致。比如O-101重试时订单丢失，但库存服务能确认该业务号已扣，订单组凭回执补订单及去重记录，库存组不再扣减。

若库存流水缺失，不能据此补扣：库存组先核对独立库存账，证明确未扣减才执行一次扣减；证据不全则冻结该业务号，返回待核对，不确认订单成功。补记和补扣都按同一业务号去重。应用组另用新单验证创建与查询；支付成功而订单丢失时，同样凭支付方流水核对，不重复扣款。

容量阶段先以隔离测试订单验证负载，测试不触发真实扣款；随后业务验收阶段逐步放入生产请求，以真实完成订单达到每分钟600单并连续4分钟通过正确性检查的终点停止RTO计时。流量不足时，只能记容量测试通过，不能声称已完成这项生产验收。

吞吐或正确性失败就暂停新增订单、继续计时并修复，不回放流量到被隔离旧站。验收通过后DBA重建备用副本，平台组保留旧站隔离；旧站校正与回切另走验收。

▲ 恢复链的先决条件与失败停止点

用六问决定钱该补在哪，再安排演练

把下面六问直接带到方案评审，每一问都要求留下责任人与证据：

1

恢复的究竟是哪项业务？从什么时间开始计时，恢复到什么吞吐，哪些依赖不能降级？

2

允许失去的是哪些数据？已确认订单能否丢失，窗口如何测量，外部副作用由谁核对？

3

两站会一起失去什么？专线、认证、密钥、控制入口是否存在共同故障点？

4

备用站如何取得唯一写权？谁出具旧站隔离回执，隔离失败和数据缺口未知时停在哪里？

5

备用容量怎样按时到位？配额、镜像和许可是否验证，扩容超时后能否按约定降低负载？

6

谁证明恢复并接手后续？谁验收真实交易，谁重建冗余，谁承担补偿与回切？

若第二问的答案改成“已确认订单零丢失”，就要重审提交确认条件。PostgreSQL同步复制应配置为：故障域之外、实际接管的备库持久化后才确认提交；仅远端写入不等于持久化。代价包含跨站往返等待，这仍可以是单写主备。应用双活本身补不上未复制的数据。

年度演练可以按证据成熟度推进：第一季度做依赖梳理和备份恢复，确认环境能独立起来；第二季度在隔离环境完成订单恢复与缺口核对；第三季度验证故障状态下的容量和扩容耗时；第四季度演练完整接管、补偿和回切。重大依赖变更后补做相关环节，不等年底统一验收。

把演练中最慢交接与超标原因写回下一版预案。

下次评审先填一份恢复验收单：若温备能在预算内完成隔离、数据核对和交易验收，就有理由不把整套业务改成双活。允许短时中断、可以界定数据损失并执行补偿的业务，值得先验证温备；必须连续服务或无法接受数据损失的业务，则应收紧提交与故障切换设计，再判断哪些部分值得双活。

IT架构师联盟

面向架构师与工程同行，解析AI Agent、系统架构与可靠性，讲清技术机制、工程边界和实践方法。