故障模型、RPO（恢复点目标）、RTO（恢复时间目标）与容灾恢复

适用边界：本册讨论依赖失效、网络分区、数据损坏、误操作、区域故障和供应商故障，以及单活、主备、双活、多活、备份恢复、切换回切、数据校验与业务恢复。所有数量、时长、比例、成本和效果均为 E3（演练证据），只用于复算机制、失败窗口与验收方法，不代表真实生产指标、SLA（服务等级协议）或项目承诺。

正式图的 PlantUML（开源建模工具）源见 reliability-failure-dr.puml。

正式恢复图

本册包含 13 张 Mermaid（图表语法）图，其中 10 张为时序图；每张图均与一张比较表、一组可复算数据演绎和业务验收条件对应。正式 PlantUML（开源建模工具）图展示从检测、写栅栏、切换、日志补齐、业务核验到回切的完整链路，重点不是“备机启动”，而是恢复到可证明、可继续承担业务的正确状态。

1. 故障模型先固定对象、范围、时间、可见性与恢复证据 {#53-03-k01}

故障模型不是“系统可能宕机”的泛称，而是一份可验证合同：什么对象以何种方式失效，影响落在哪个故障域，持续多久，监控能否及时看到，允许损失哪些数据，采取什么隔离与恢复动作，又用什么证据宣布结束。进程崩溃、节点断电、网络单向中断、共享存储损坏、凭据失效和区域不可达的恢复路径完全不同；若演练只杀一个进程，就不能外推区域容灾能力。还要区分独立故障与相关故障，共享账号、发布系统、域名、密钥和人员操作会让看似独立的副本同时失效。

flowchart LR
    A[业务路径与不变量] --> B[故障对象与故障域]
    B --> C[触发方式与持续时间]
    C --> D[可见信号与检测延迟]
    D --> E[隔离 切换 恢复动作]
    E --> F[数据位置与业务校验]
    F --> G{停止条件满足}
    G -->|是| H[分批恢复业务]
    G -->|否| I[保持降级并扩大取证]

图解读：节点从业务不变量进入故障对象、信号、动作和验收；箭头表示每个恢复结论都要回到前置假设。前提是故障域和权威源已登记；正常路径经校验后分批恢复，失败路径在证据不足时保持降级。结论是故障注入强度、检测范围与恢复承诺必须一致。

数据演绎 1：检测延迟会直接侵蚀恢复时间

E3（演练证据）：某关键路径的 RTO（恢复时间目标）候选为 30 分钟。故障发生后，外部探测 3 分钟才确认影响，事故决策与写冻结用 5 分钟，提升与路由收敛用 8 分钟，业务校验用 10 分钟，总计 3 + 5 + 8 + 10 = 26 分钟，只剩 4 分钟余量。若监控同故障域失效导致检测延迟变为 12 分钟，总耗时升至 35 分钟，即使提升脚本仍为 8 分钟也已超标。状态从不可见故障到受控恢复；观测信号是故障时刻、检测时刻、冻结时刻、切换时刻和验收时刻；结论是 RTO（恢复时间目标）必须覆盖发现、决策和校验，不只是机器启动时间。

热门面试题

1. 问题：故障模型至少要包含哪些字段？
   • 考点：对象、范围、时间、可见性、数据与证据。
   • 回答思路：把故障从抽象风险转成可注入、可观测、可恢复的合同。
   • 详细答案：至少声明故障对象与模式、影响范围与相关性、开始和持续时间、检测信号与盲区、数据损失窗口、隔离和恢复动作、责任角色、验收及停止条件。缺少任一项，演练结果都可能无法外推到真实故障。
   • 进阶追问：为什么还要写相关故障？
   • 进阶回答：副本可能共享存储、账号、发布、域名或人员操作，同一根因会同时击穿多个看似独立节点。
2. 问题：进程重启演练能证明区域容灾吗？
   • 考点：注入强度与结论边界。
   • 回答思路：比较进程、节点、网络、控制面和区域依赖。
   • 详细答案：不能。进程重启通常保留网络、存储、账号、域名和同区依赖，只证明局部拉起与连接恢复。区域故障还会影响路由、跨区容量、复制位置、密钥、供应商入口和事故协同，必须另行演练。
   • 进阶追问：局部演练还有价值吗？
   • 进阶回答：有，可验证单一假设并降低风险，但必须明确结论只覆盖该故障模式。
3. 问题：为什么监控失明也要进入故障模型？
   • 考点：可见性与决策风险。
   • 回答思路：说明检测延迟和错误切换会消耗恢复窗口。
   • 详细答案：监控与业务共享故障域时，指标缺失可能被误判为流量下降或全站宕机；错误判断会延迟止血，甚至在原系统仍写入时提升副本造成脑裂。需用外部探测、业务审计和至少两类独立信号互证。
   • 进阶追问：两类证据冲突怎么办？
   • 进阶回答：先限制高风险写、固定现场和水位，再引入第三类证据，不仓促切换或覆盖数据。

2. 依赖失效要按慢、错、拒绝、未知和级联放大建模 {#53-03-k02}

依赖失效不只是连接失败。下游可能变慢、返回错误、限流拒绝、部分成功、响应丢失或返回语义错误；最危险的是结果未知，因为本地无法判断副作用是否发生。恢复设计先区分读取、可重放写和不可重放外部动作，再设置超时预算、有界并发、熔断、降级、幂等查证和重试上限。缓存、数据库、消息、对象存储、支付渠道和海外仓的失败成本不同，不能共享无限线程池和统一重试策略。级联故障的核心是依赖服务时间上升后，在途、超时和重试同时放大。

sequenceDiagram
    participant U as 业务入口
    participant S as 核心服务
    participant D as 外部依赖
    participant Q as 查证与补偿
    participant V as 业务验收
    U->>S: 携带稳定业务键请求
    S->>D: 在剩余超时预算内调用
    alt 明确成功
        D-->>S: 返回权威标识与结果
        S-->>U: 提交本地终态
    else 明确失败或限流
        D-->>S: 返回可分类错误
        S-->>U: 降级、排队或明确失败
    else 超时或响应丢失
        D--xS: 结果未知
        S->>Q: 按原业务键查单
        Q->>D: 查询既有副作用
        D-->>Q: 成功 失败或仍未知
        Q->>V: 补记、补偿或人工接管
    end

图解读：节点覆盖入口、核心服务、依赖、查证和业务验收；箭头区分明确结果与未知结果。前提是依赖支持稳定业务键或替代对账证据；正常路径直接闭环，失败路径先查证再重试。结论是重试策略必须服从副作用可逆性和下游剩余容量。

数据演绎 2：慢依赖如何放大在途与重试

E3（演练证据）：跨境仓创建入口为 200 次/秒，正常依赖服务时间 0.2 秒，平均占用约 200 × 0.2 = 40 个在途。故障时服务时间升至 3 秒，在途升为 600；若 30% 请求超时后立即重试一次，尝试率变为 260 次/秒，在途约 780。连接池只有 300 时，至少 480 个请求在池外排队，继续推高超时。止血应先停止立即重试、限制问题仓并发并保持未知态，而不是把池扩到 800。观测信号是依赖服务时间、池等待、超时、重试放大和最老未知年龄；结论是扩池可能把故障转移给下游。

热门面试题

1. 问题：依赖超时为什么不能直接判失败？
   • 考点：未知结果与外部副作用。
   • 回答思路：区分没有收到响应和对方没有执行。
   • 详细答案：请求可能已经到达并提交，只是响应在网络或客户端读取阶段丢失。对支付、仓单、退款和通知，直接重做会造成重复副作用；应保持处理中或未知，用原业务键查单或对账后再决定。
   • 进阶追问：依赖没有查单能力怎么办？
   • 进阶回答：降低自动重试，串行化高风险请求，保存完整证据并通过账单、回执或人工核验形成替代确认路径。
2. 问题：为什么不能为所有依赖设置同一重试策略？
   • 考点：错误分类、时效和可逆性。
   • 回答思路：按读写、副作用和配额分别设计。
   • 详细答案：读请求通常可安全重试，但写请求可能重复；明确参数错误不应重试，限流要退避，未知结果要先查证。不同供应商的配额、恢复速度和幂等能力也不同，统一策略会放大最脆弱依赖。
   • 进阶追问：重试预算由谁决定？
   • 进阶回答：由端到端超时、下游配额、业务时效、重复成本和人工接管能力共同决定。
3. 问题：依赖变慢时为什么先看池等待而不是只看错误率？
   • 考点：饱和前兆与级联故障。
   • 回答思路：说明服务时间先上升，错误往往后出现。
   • 详细答案：下游变慢会先增加线程、连接和在途，业务错误可能尚未明显；池等待和最老请求年龄能更早显示饱和。若等错误率升高再动作，重试和队列通常已经把多个上游拖入故障。
   • 进阶追问：扩连接池是否能止血？
   • 进阶回答：只有下游仍有余量且瓶颈确在本地池时才可能有效，否则会增加对下游的并发冲击。

3. 网络分区必须用多数派、领导任期与写栅栏处理脑裂 {#53-03-k03}

网络分区不是所有节点都离线，而是部分节点彼此不可达、单向可达或到客户端的视图不一致。系统必须预先决定分区期间优先保持一致性还是允许受限可用，并明确哪些写可以接受冲突。对库存、支付和任务租约等强不变量，通常只允许满足多数派与最新任期的一侧写入；旧主即使进程存活，也要通过网络、账号、存储和业务版本四层栅栏失去写能力。对购物车、设备最近状态等可合并数据，可在业务规则允许时多点接收，但要保存冲突版本和收敛证据。

sequenceDiagram
    participant C as 客户端
    participant O as 旧主故障域
    participant M as 多数派控制面
    participant N as 新主故障域
    participant F as 写栅栏与校验
    O--xM: 网络分区
    M->>N: 选举并增加领导任期
    M->>F: 撤销旧主入口与凭据
    C->>N: 携带新任期写入
    N-->>C: 条件更新成功
    C->>O: 缓存旧地址继续写
    O->>F: 尝试提交旧任期
    F--xO: 拒绝旧任期和旧版本
    O->>N: 网络恢复后请求加入
    N->>O: 隔离、比较位置并重建
    F->>N: 校验缺口与重复副作用

图解读：节点包含客户端、旧主、多数派、新主和写栅栏；箭头展示分区、选举、旧地址访问和重建。前提是任期可持久化且关键写带条件；正常路径只由新主提交，失败路径由栅栏拒绝旧历史。结论是负载均衡和服务发现不能替代数据层与业务层防脑裂。

数据演绎 3：少数派继续写的冲突成本

E3（演练证据）：三节点主备集群在分区后形成 2 + 1。多数派新主每秒写 500 条库存流水，少数派旧主若错误开放 120 秒，又接收每秒 80 条，则产生 9,600 条分叉写。即使其中 95% 可按业务键判定重复，仍有 480 条需逐单裁决；若包含库存释放与出库扣减，不能按时间戳简单取新。正确方案是在新任期产生时立即撤销旧主写入，并在恢复后将旧主从新主重建。观测信号是任期、双主写入计数、条件更新拒绝和业务差异；结论是写栅栏的价值远高于事后冲突合并。

热门面试题

1. 问题：网络分区和节点宕机有什么区别？
   • 考点：局部可达与多视图。
   • 回答思路：强调分区两侧都可能认为自己可服务。
   • 详细答案：节点宕机通常是单点停止，网络分区时进程和存储可能都正常，只是节点间、客户端间或控制面间互不可见。若双方继续写，会形成分叉历史和重复副作用，因此更依赖多数派、任期与栅栏。
   • 进阶追问：网络恢复后能自动合并吗？
   • 进阶回答：只有业务明确支持可交换、可结合、可幂等的合并规则时才可能；资金与库存通常需单主历史和人工裁决差异。
2. 问题：为什么服务发现不能防脑裂？
   • 考点：路由控制与写权限边界。
   • 回答思路：说明旧连接、缓存和旁路入口仍可能存在。
   • 详细答案：服务发现只影响新路由，客户端可能缓存旧地址，旧主也可能通过内部任务或共享凭据继续写。关键写必须在数据层或业务条件更新中校验领导任期，并同步撤销网络和账号权限。
   • 进阶追问：任期字段放在哪里？
   • 进阶回答：应进入权威写条件和任务结果提交合同，且由多数派控制面持久化生成，不能只保存在进程内存。
3. 问题：双活系统遇到分区是否总要停止一侧？
   • 考点：一致性需求与冲突可合并性。
   • 回答思路：按业务不变量分类，而不是按拓扑下结论。
   • 详细答案：支付入账、库存扣减等不可安全合并的写应限制为单一权威侧；只读、可重建投影或有确定合并规则的数据可继续受限服务。双活不是所有数据都双写，必须按领域划分写入权。
   • 进阶追问：如何验证合并规则？
   • 进阶回答：注入重复、乱序、并发更新与时钟偏差，比较最终状态、冲突日志和业务不变量，而不是只看复制收敛。

4. 数据损坏要区分介质错误、静默损坏与逻辑污染 {#53-03-k04}

数据损坏可能来自磁盘或文件错误、传输损坏、内存或软件缺陷，也可能是合法写入了错误业务值。前者常能被校验和、页验证或读取错误发现，后者语法和复制均正常，却破坏库存、账务或状态机不变量。复制会把逻辑污染快速传播到所有在线副本，因此恢复不能先假设“另一个副本一定健康”。处置顺序是冻结受影响范围、保存坏样本、确定首个异常位置、判断污染是否已复制，再选择健康副本、独立备份或业务重建；恢复后同时验证物理完整性和业务语义。

sequenceDiagram
    participant W as 权威写入
    participant P as 主数据域
    participant R as 在线副本
    participant B as 独立备份
    participant V as 校验与业务对账
    W->>P: 写入数据与业务版本
    P->>R: 复制当前变化
    alt 介质或传输损坏
        R--xV: 校验和或读取失败
        V->>B: 选择健康对象与连续日志
    else 逻辑错误合法写入
        P->>R: 同步传播错误值
        V->>V: 不变量或业务聚合发现污染
        V->>B: 恢复到污染前一致点
    end
    B->>V: 隔离恢复并重放安全增量
    V->>P: 定向回补或切换新实例
    V->>R: 从健康历史重新建立副本

图解读：节点覆盖写入、主数据域、副本、独立备份和校验；箭头区分可检测介质损坏与会被正常复制的逻辑污染。前提是备份与在线副本权限、时间和保留独立；正常路径从健康材料重建，失败路径是把污染副本继续作为恢复源。结论是物理校验和业务不变量必须形成两类独立证据。

数据演绎 4：三副本同时拥有同一错误

E3（演练证据）：库存调整脚本把 5,000 个商品的预占量错误清零，在线三副本在 20 秒内全部复制成功。副本健康率仍为 100%，但订单承诺合计 18,000 件，库存快照少记录 18,000 件预占，业务守恒差异不为零。若直接从任一副本恢复，错误仍存在；应在隔离环境恢复脚本执行前的基线，重放安全流水并跳过错误批次，再按订单、预占和出库逐键补偿。观测信号是脚本批次、复制位置、库存流水与快照差；结论是副本数量不能替代历史恢复点。

热门面试题

1. 问题：为什么三副本仍可能同时数据错误？
   • 考点：复制与逻辑污染。
   • 回答思路：区分高可用副本和独立历史备份。
   • 详细答案：副本会忠实传播合法提交，包括误删、错误脚本和应用缺陷；如果共享软件、账号和当前历史，三个副本只是三份同样的错误。需要独立保留的历史基线、连续日志和恢复演练应对污染。
   • 进阶追问：只读副本能防误删吗？
   • 进阶回答：不能，它仍会应用主库删除，只是拒绝客户端直接写入。
2. 问题：校验和通过是否代表业务正确？
   • 考点：物理完整与语义正确。
   • 回答思路：说明错误值也可以拥有正确摘要。
   • 详细答案：校验和只能证明字节按预期保存或传输，错误金额、错误库存和非法状态同样可以生成正确摘要。还需用借贷平衡、库存守恒、版本单调和唯一副作用等业务不变量验证。
   • 进阶追问：业务校验是否都要逐行？
   • 进阶回答：关键主键与高风险对象可逐笔，其他可用稳定分桶摘要和全量聚合定位差异桶后再逐行。
3. 问题：发现数据损坏后为什么先冻结而不是立即修？
   • 考点：证据保全与污染范围。
   • 回答思路：避免继续传播和覆盖首个异常点。
   • 详细答案：立即重写可能破坏坏样本、推进复制位置并让污染范围扩大。先隔离受影响键或写入口，保留对象、日志、版本和时间线，确认物理还是逻辑损坏，再选择可回滚修复路径。
   • 进阶追问：冻结全站还是局部？
   • 进阶回答：按权威键和故障域缩小范围；若无法证明边界或涉及资金不变量，应优先扩大冻结而非冒险继续写。

5. 误操作是权限、变更、时间点恢复与业务合并的联合问题 {#53-03-k05}

误删、误更新、错误配置和错误脚本通常通过合法权限执行，监控不会自动把它识别为攻击或介质故障。治理要在事前设置最小权限、职责分离、危险语句门禁、批次上限、演练环境和可撤销变更；事中记录操作者、审批、脚本摘要、影响行数与业务范围；事后先确定污染起止、受影响对象和事故后合法新写，再在隔离环境做 PITR（时间点恢复）并以受控合并回补。把整个生产库直接倒回误操作前会删除事故后合法交易，尤其不适合支付、库存和履约。

sequenceDiagram
    participant O as 操作人员
    participant G as 变更门禁
    participant P as 生产权威库
    participant R as 隔离恢复库
    participant V as 差异与业务校验
    O->>G: 提交脚本、范围与回滚计划
    G->>P: 小批执行并记录批次水位
    P--xV: 业务不变量或影响量异常
    V->>G: 停止后续批次并冻结相关写
    G->>R: 恢复基线并重放到误操作前
    R->>V: 提供正确历史对象
    P->>V: 提供事故后合法新写
    V->>V: 按业务键和版本生成合并清单
    V->>P: 审批后小批回补与补偿
    P->>V: 再次校验不变量和差异

图解读：节点从操作、门禁、生产、隔离恢复到差异校验；箭头强调时间点恢复只产生参考历史，真正回生产要合并事故后合法写。前提是日志保留覆盖发现延迟；正常路径小批回补，失败路径由异常门禁立即停批。结论是恢复对象通常是受影响业务事实，不是把整个系统时钟拨回过去。

数据演绎 5：整体回退会误删合法新写

E3（演练证据）：误更新从 10:00 持续到 10:04，影响 12,000 条订单；直到 10:20 才发现，期间又产生 48,000 条合法新订单和 6,000 次状态推进。若生产整体恢复到 09:59，至少会丢掉这 54,000 个事故后合法变化。正确路径是在隔离库恢复到 09:59，提取 12,000 个受影响业务键，与生产当前版本比较，排除已退款、已出库等不可覆盖状态，再分批生成补偿。观测信号是脚本批次、事务位置、当前业务版本和差异分类；结论是 PITR（时间点恢复）是取证与重建工具，不等于直接替换生产。

热门面试题

1. 问题：误删后为什么不直接把生产恢复到删除前？
   • 考点：事故后合法写与时间线合并。
   • 回答思路：说明整体回退会同时删除后续正常交易。
   • 详细答案：发现误删通常有延迟，事故后仍有订单、支付、库存和履约变化。整体回退会把这些合法事实一起抹掉；应在隔离环境恢复历史点，提取受影响对象，再按业务键和版本受控合并。
   • 进阶追问：什么时候可以整体切换恢复库？
   • 进阶回答：只有业务已停写、恢复点后无须保留的新事实，或已能完整重放并验证全部增量时才可评估。
2. 问题：如何缩短误操作的真实 RPO（恢复点目标）？
   • 考点：发现延迟、日志保留与批次控制。
   • 回答思路：从减少污染量和提高可定位性回答。
   • 详细答案：使用小批执行、影响行数阈值、业务不变量告警、连续日志和脚本批次水位，把污染限制在少量对象并准确定位。单纯增加备份频率不能减少发现前已传播的逻辑错误。
   • 进阶追问：备份越频繁越好吗？
   • 进阶回答：还要权衡存储、日志链、恢复速度和校验能力；频繁但不可恢复的备份没有价值。
3. 问题：危险操作审批为什么不能只看语句语法？
   • 考点：业务范围与不可逆副作用。
   • 回答思路：把技术语句翻译成业务对象、状态和数量。
   • 详细答案：语法正确的更新仍可能跨租户、越过状态机或破坏资金与库存。审批应展示命中业务键、状态分布、影响金额或数量、批次上限、停止条件和补偿路径，而不是只确认语句可执行。
   • 进阶追问：如何验证预览结果可信？
   • 进阶回答：固定同一快照或条件版本，执行时继续校验版本与影响上限，避免预览后数据变化导致范围漂移。

6. 区域故障要求数据、控制面、容量、依赖和人员同时可用 {#53-03-k06}

区域故障可能同时影响计算、存储、网络出口、域名解析、密钥、监控、发布平台和现场人员。跨区副本存在不等于可切换：恢复区还要有足够容量、可用凭据、路由权限、独立监控、供应商白名单和经过演练的业务最小集。设计时应按“一个约定区域完全不可用”计算故障余量，并把恢复分层：先恢复支付查单、库存裁决、订单查询等关键能力，再恢复搜索、报表和批任务。跨区同步越强，正常写延迟与分区期间可用性代价越高。

sequenceDiagram
    participant P as 主区域
    participant R as 恢复区域
    participant C as 全局路由
    participant K as 密钥与配置
    participant D as 外部依赖
    participant V as 业务验收
    P->>R: 复制权威日志与配置清单
    P--xC: 区域整体不可达
    C->>R: 启动候选切换并限制入口
    R->>K: 获取独立应急凭据
    R->>D: 验证支付、仓库和通知白名单
    alt 数据位置、容量和依赖均通过
        C->>R: 开放关键业务小流量
        R->>V: 执行库存、账务和未知态校验
        V-->>C: 允许分批放量
    else 任一前提失败
        V--xC: 保持只读或降级
        C->>P: 等待恢复或改用备份路径
    end

图解读：节点覆盖两个区域、全局路由、密钥配置、外部依赖和业务验收；箭头显示切换依赖不仅是数据复制。前提是恢复区不共享关键控制面；正常路径小流量验证后放量，失败路径保持降级。结论是区域容灾必须按完整业务链而非单个数据库验收。

数据演绎 6：恢复区容量不能按日均准备

E3（演练证据）：正常两区域按 60% + 40% 分担，每区可用容量分别为 900 和 700 请求/秒，业务峰值为 1,200 请求/秒。若承载 60% 的区域失效，恢复区只有 700，容量缺口为 500 请求/秒。即使弹性在 10 分钟后增加到 1,100，仍低于峰值；应在切换前把报表、导出和低优先级查询降级 200，并将关键入口限到 1,000，再结合排队时效决定是否可用。观测信号是可用实例、依赖配额、入口分级和用户结果；结论是区域恢复容量要按故障峰值与业务优先级计算。

热门面试题

1. 问题：有跨区副本为什么仍不能立即切换？
   • 考点：完整业务链依赖。
   • 回答思路：列出容量、路由、密钥、监控和供应商前提。
   • 详细答案：数据副本只解决部分数据可用性，恢复区还可能缺计算容量、账号、证书、域名权限、外部白名单和独立监控。任何一项缺失都可能让数据库已提升但业务不可用或不可验证。
   • 进阶追问：最先验证什么？
   • 进阶回答：先验证旧区写栅栏、恢复位置和关键外部依赖，再用小流量检查业务不变量。
2. 问题：区域切换时为什么要先恢复最小业务集？
   • 考点：RTO（恢复时间目标）分层与资源竞争。
   • 回答思路：按不可替代性和损失优先级排序。
   • 详细答案：支付查单、库存裁决和订单查询直接影响资金与承诺，搜索、报表和批任务通常可后置。分层恢复能把有限容量和人员集中到关键路径，缩短最小可用业务的 RTO（恢复时间目标）。
   • 进阶追问：最小业务集如何验收？
   • 进阶回答：为每条关键路径定义明确入口、权威数据、依赖、用户结果和不变量，不以单个组件启动作为完成。
3. 问题：双区域各一半流量是否就有区域余量？
   • 考点：故障容量与峰值。
   • 回答思路：计算任一区域失效后的剩余能力。
   • 详细答案：如果两区平时都接近一半且各自只有一半容量，失去一侧后另一侧仍无法承担峰值。必须预留、快速弹性、降级或限流，并验证扩容速度与下游配额，不是流量均分就天然容灾。
   • 进阶追问：弹性扩容能完全替代预留吗？
   • 进阶回答：不能，启动、调度、预热和依赖扩配都有时间，关键路径需保留能覆盖这段窗口的即时容量。

7. 供应商故障要覆盖配额、控制权、数据可携带与退出路径 {#53-03-k07}

供应商故障包括接口中断、限流、语义变更、账单错误、账号冻结、区域退出、控制台不可用和企业停止服务。多供应商只有在协议、数据、账号、网络和运营流程都可切换时才真实有效；若两个渠道共用同一上游、域名、支付清算方或通知运营商，仍可能相关失效。关键设计是防腐层、稳定业务键、渠道状态映射、配额隔离、未知态查单、数据导出、合同恢复目标和退出演练。支付、物流和通知的外部副作用不能通过简单日志重放迁移。

sequenceDiagram
    participant B as 业务服务
    participant A as 供应商适配层
    participant V1 as 主供应商
    participant V2 as 备用供应商
    participant L as 本地权威账本
    participant R as 对账与退出流程
    B->>L: 记录稳定业务意图和渠道选择
    B->>A: 携带同一业务键发起
    A->>V1: 调用主供应商
    V1--xA: 超时、限流或账号不可用
    A->>R: 先按原渠道查证未知结果
    R->>V1: 查询或获取账单
    alt 已产生外部副作用
        R->>L: 补记原渠道结果
    else 明确未执行且允许切换
        A->>V2: 以新渠道尝试号执行
        V2-->>L: 返回新渠道权威标识
    end
    R->>L: 对账两渠道并关闭重复风险

图解读：节点包括业务、适配层、两个供应商、本地账本和对账退出流程；箭头强调未知结果必须先查原渠道，不能直接切备用。前提是本地保存稳定业务意图和渠道尝试关系；正常路径明确后切换，失败路径由对账关闭重复。结论是多供应商提高选择权，但也增加状态、成本与运营复杂度。

数据演绎 7：备用渠道未必能承接全部流量

E3（演练证据）：主支付渠道平时处理每秒 300 笔，备用渠道合同配额为每秒 120 笔，且新渠道首次风控通过率候选只有 85%。主渠道故障后若全量切换，至少每秒 180 笔先被配额拒绝，备用渠道可评价成功仅约 120 × 85% = 102 笔。应把支付意图保持待处理，按商户、金额和时效分级，优先放行 120 以内高价值请求，并对原渠道未知结果查单。观测信号是分渠道配额、拒绝、未知态和对账差异；结论是备用供应商容量、账户和运营流程必须提前验证。

热门面试题

1. 问题：接入两个供应商就算消除供应商单点吗？
   • 考点：相关故障与可切换前提。
   • 回答思路：检查上游、账号、网络、数据和运营是否独立。
   • 详细答案：不一定。两家可能共享清算、运营商或云区域，备用账号可能未实名、无配额或无白名单，历史数据也可能无法迁出。只有端到端切换和退出演练通过，才算降低单点风险。
   • 进阶追问：怎样发现共享上游？
   • 进阶回答：在采购评审、网络路径、状态页、合同和联合故障演练中核对，不只看品牌名称不同。
2. 问题：主供应商超时后能否立即切备用？
   • 考点：跨渠道重复副作用。
   • 回答思路：先确认原渠道是否已经执行。
   • 详细答案：不能默认立即切换。原请求可能已成功，直接换渠道会重复扣款、重复仓单或重复通知。应保留原尝试号，查单或对账明确未执行后，再创建关联同一业务意图的新渠道尝试。
   • 进阶追问：查单长期未知怎么办？
   • 进阶回答：限制自动切换，按金额和时效进入人工或延迟核验，并向用户展示处理中而非失败。
3. 问题：供应商退出能力应验证哪些内容？
   • 考点：数据可携带、兼容和运行接管。
   • 回答思路：从数据、接口、账号、路由、账单和人员流程回答。
   • 详细答案：要能导出完整历史、配置和审计，转换字段与状态，重建回调和白名单，核对未结算业务，切换流量并在窗口内回滚。还要确认合同、密钥、权限和支持联系人不依赖原控制台。
   • 进阶追问：多久演练一次？
   • 进阶回答：按供应商风险和变更频率设周期，重大接口、账号、区域或合同变化后必须重新演练。

8. 单活与主备用单一写入权换取较低冲突成本 {#53-03-k08}

单活只有一个故障域承担读写，架构简单但恢复依赖备份和异地材料；主备则让备用端持续接收数据，在主端故障时提升。两者共同前提是单一写入权、明确复制位置、可靠故障检测、旧主栅栏、客户端路由和备用容量。同步主备可缩小已确认写丢失窗口，却增加写延迟并在跨区分区时影响可用；异步主备正常性能更好，但提升时必须接受或补齐复制缺口。备用若长期不接真实流量，配置、权限、数据和容量会悄悄漂移。

flowchart TB
    A[单一写入权] --> B{备用形态}
    B -->|无在线副本| C[单活加独立备份]
    B -->|持续复制| D[主备]
    C --> E[恢复基线和日志]
    D --> F[检查副本位置与健康]
    E --> G[建立新主并路由]
    F --> H[撤销旧主后提升]
    H --> G
    G --> I[业务不变量与差异校验]
    I --> J{通过停止条件}
    J -->|是| K[分批放量]
    J -->|否| L[保持受限服务]

图解读：节点从单一写入权分到单活备份与主备复制，再会合到路由和业务校验；箭头显示两种方案的恢复速度与数据路径不同。前提是旧主可可靠撤权；正常路径校验后放量，失败路径保持受限。结论是主备缩短常见故障恢复，但不替代历史备份和业务验收。

数据演绎 8：异步主备提升的数据缺口

E3（演练证据）：主端每秒确认 2,000 个订单状态，副本正常落后 3 秒，故障检测、冻结和提升共 40 秒。若故障瞬间副本仍落后 3 秒，理论尾部缺口上限为 2,000 × 3 = 6,000 个状态；40 秒属于服务 RTO（恢复时间目标），不能改变这 6,000 个 RPO（恢复点目标）候选缺口。若订单事件日志独立保存全部意图，可按幂等键重放并对账；若没有重建源，就不能宣称零丢失。观测信号是主确认位置、副本应用位置、事件日志和业务版本；结论是 RPO（恢复点目标）与 RTO（恢复时间目标）必须分别验收。

热门面试题

1. 问题：主备和备份分别解决什么？
   • 考点：在线冗余与历史恢复。
   • 回答思路：用节点故障和误删对比。
   • 详细答案：主备通过持续复制和提升缩短节点或故障域中断，但也会复制误删和逻辑错误；备份保存独立历史点，用于误操作、污染和长期恢复。关键系统通常两者都需要。
   • 进阶追问：热备能替代备份吗？
   • 进阶回答：不能，热备仍共享当前历史、软件缺陷和部分控制面风险。
2. 问题：异步主备怎样解释数据不丢？
   • 考点：确认位置与业务重建源。
   • 回答思路：不能只看副本，要说明已确认写如何保留或补齐。
   • 详细答案：异步复制本身存在尾部窗口。若业务要求接近零丢失，需让确认等待更强复制条件，或有独立持久事件、幂等重放和对账补齐；否则只能诚实声明可接受的 RPO（恢复点目标）。
   • 进阶追问：同步复制就绝不丢吗？
   • 进阶回答：还受存储契约、法定成员配置、相关故障和逻辑污染影响，必须针对最强故障模型演练。
3. 问题：备用长期空闲为什么危险？
   • 考点：配置漂移和恢复真实性。
   • 回答思路：说明不接流量就难暴露权限、数据与容量问题。
   • 详细答案：备用可能证书过期、账号失效、配置漂移、数据落后、缓存未预热或容量缩水。应持续做合成探测、只读影子、恢复抽检和定期切换，而不是事故时第一次使用。
   • 进阶追问：影子流量能证明写切换吗？
   • 进阶回答：只能证明部分读取和处理，写权限、栅栏、外部副作用与业务不变量仍需专门演练。

9. 双活与多活只有在写入权、冲突规则和成本可证明时成立 {#53-03-k09}

双活或多活不是“多个区域都能访问”，而是多个故障域同时承接真实业务。必须先回答写入权如何分配：按租户、仓、账户或业务键归属单区，可避免同键并发冲突；同一键多区写则要定义版本、因果、唯一性和可合并规则。强同步能减少冲突却受跨区延迟和分区影响，异步复制性能较好却会产生陈旧读、唯一键碰撞和双边副作用。多活还增加全局路由、数据驻留、容量碎片、回切、对账、值班和演练成本。资金、库存和 Runner（执行器）租约通常应保持单一权威写，查询与可重建投影可以多地服务。

sequenceDiagram
    participant U as 用户与全局路由
    participant A as 区域甲
    participant O as 写入权目录
    participant B as 区域乙
    participant C as 冲突与对账
    U->>O: 按租户或业务键查询归属
    O-->>U: 返回当前区域与任期
    U->>A: 携带归属和任期写入
    A->>B: 异步复制业务版本
    alt 同键仍归区域甲
        B-->>U: 读投影或转发到甲
    else 受控迁移写入权
        A->>O: 冻结键并提交最终水位
        B->>A: 追平并校验版本
        O->>B: 提升归属和新任期
    end
    B->>C: 报告碰撞、陈旧和重复副作用
    C->>O: 不变量失败时撤销放量

图解读：节点包含全局路由、两个区域、写入权目录和对账；箭头展示单键归属与受控迁移。前提是目录强一致且关键写校验任期；正常路径按归属避免冲突，失败路径由对账撤销放量。结论是多活可以分摊故障域，却不能消灭数据所有权。

数据演绎 9：按租户归属比同键双写更可控

E3（演练证据）：两区域各处理 600 请求/秒，其中 10% 为同一批热点库存键。若允许热点键双区写，候选冲突率为 2%，每秒约有 600 × 10% × 2 = 1.2 个冲突，一小时约 4,320 个；即使自动合并 90%，仍有约 432 个需业务裁决。若按仓和商品键固定归属，一侧故障时只迁移受影响键，并用最终水位和新任期切换，可把常态同键冲突降为零，但需要目录高可用与故障容量。观测信号是归属版本、跨区复制延迟、冲突数和迁移键数量；结论是多活设计优先减少冲突来源。

热门面试题

1. 问题：双活和多活最难的是什么？
   • 考点：数据所有权、冲突与外部副作用。
   • 回答思路：不从流量路由讲起，先讲同一业务事实由谁写。
   • 详细答案：难点是分区和并发时仍保持唯一写入权或可证明合并，尤其资金、库存、任务租约与外部调用不能按最后时间覆盖。还要承担跨区复制、路由、容量、配置、对账和回切的持续成本。
   • 进阶追问：只做读多活是否简单很多？
   • 进阶回答：是，但仍要标注数据水位、处理读己之写和故障回源，不能让陈旧投影裁决资金或库存。
2. 问题：如何避免多活冲突？
   • 考点：按键归属与受控迁移。
   • 回答思路：优先让同一键只有一个权威区域。
   • 详细答案：可按租户、仓、账户或商品键分配写入区域，关键请求携带归属任期；迁移时先冻结旧侧、取最终水位、追平校验，再提升新侧。确需多点写的数据必须有业务可接受的合并代数和冲突审计。
   • 进阶追问：按时间戳取最新可以吗？
   • 进阶回答：通常不能用于资金和库存，时钟偏差与并发语义会丢掉合法动作，必须按业务版本和不变量裁决。
3. 问题：为什么多活常比主备贵很多？
   • 考点：隐性运行成本。
   • 回答思路：覆盖资源、平台、数据和组织成本。
   • 详细答案：除多份计算存储外，还要全局路由、写入权目录、跨区复制、冲突处理、双边发布、独立监控、数据驻留、值班与频繁演练。若业务损失不足以覆盖这些成本，主备可能更合适。
   • 进阶追问：怎样证明多活值得？
   • 进阶回答：用可用性损失、区域故障概率、恢复目标、关键业务收入与全周期成本比较，并通过故障演练验证真实收益。

10. RPO（恢复点目标）和 RTO（恢复时间目标）要按业务事实分层定义 {#53-03-k10}

RPO（恢复点目标）约束故障点与最后可恢复正确状态之间允许丢失的时间或业务量，RTO（恢复时间目标）约束从事故确认到约定业务能力恢复的总时长。两者不是数据库级统一数字：支付账务、库存预占、物流轨迹、导出文件和报表的可补偿性不同。目标还要写清计时起点、结束条件、故障模型、数据类别和业务最小集。零 RPO（恢复点目标）通常要求更强确认或独立重建源，但不代表零 RTO（恢复时间目标）；恢复很快也可能带着缺口或重复副作用。

sequenceDiagram
    participant F as 故障时刻
    participant D as 检测与决策
    participant R as 数据恢复
    participant S as 最小业务服务
    participant V as 业务验证
    F->>D: 故障发生并开始影响
    D->>D: 确认范围、冻结写和选择方案
    D->>R: 选择最后安全位置
    R->>R: 恢复基线并重放增量
    R->>S: 启动关键读写与依赖
    S->>V: 提交恢复位置、缺口和积压
    alt 不变量、用户结果和时限通过
        V-->>D: RPO 与 RTO 同时验收
    else 数据缺口或耗时超标
        V--xD: 继续事故并执行降级
    end

图解读：节点覆盖故障、检测、数据恢复、最小业务和验证；箭头表明 RTO（恢复时间目标）包含检测、决策、恢复与校验，RPO（恢复点目标）由安全位置和业务缺口证明。前提是计时边界预先定义；正常路径双目标通过，失败路径继续事故。结论是两个目标必须独立量化、联合验收。

数据演绎 10：同一故障下不同数据目标不同

E3（演练证据）：区域故障时，支付每分钟 3,000 笔、库存预占每分钟 6,000 条、轨迹每分钟 20,000 条。异步复制落后 2 分钟，则候选缺口分别为 6,000、12,000 和 40,000 条。支付可通过渠道查单和账务事件补齐，目标接近零已确认损失；库存要由订单和流水重放；轨迹允许稍后向供应商补拉。若最小支付与库存能力 25 分钟恢复、轨迹查询 90 分钟恢复，可以分别验收，而不能给整个系统写“RTO（恢复时间目标）为 25 分钟”。观测信号是最后安全位置、各类缺口、恢复耗时和用户结果。

热门面试题

1. 问题：RPO（恢复点目标）和 RTO（恢复时间目标）有什么区别？
   • 考点：数据损失与恢复时长。
   • 回答思路：一个看恢复点，一个看业务恢复时间线。
   • 详细答案：RPO（恢复点目标）回答最多允许丢到哪个位置或多少业务变化，RTO（恢复时间目标）回答事故确认后多久恢复约定能力。系统可能恢复很快但丢数据，也可能数据完整却恢复很慢，必须分别证明。
   • 进阶追问：零 RPO（恢复点目标）是否意味着同步复制？
   • 进阶回答：不只一种路径，也可用独立持久事件、渠道查单和幂等重建，但必须证明已确认事实最终无缺口。
2. 问题：为什么不能给整个系统一个 RTO（恢复时间目标）？
   • 考点：业务分层恢复。
   • 回答思路：按最小业务集和派生能力区分。
   • 详细答案：支付查单、库存写、订单查询、搜索和报表的损失与依赖不同。统一数字会迫使低价值能力过度建设，或掩盖关键能力恢复过慢；应定义分层结束条件和依赖顺序。
   • 进阶追问：对外如何表达？
   • 进阶回答：可汇总为服务承诺，但内部必须保留各能力目标、排除规则和业务验收证据。
3. 问题：RTO（恢复时间目标）从什么时候开始计？
   • 考点：计时边界。
   • 回答思路：说明业务影响、检测和宣布灾难的差异。
   • 详细答案：应在目标中明确，保守口径通常从业务影响开始或至少同时记录故障、检测、决策和恢复四个时刻。只从工程师点击脚本开始会隐藏监控和决策延迟，无法代表用户损失。
   • 进阶追问：结束是接口能通吗？
   • 进阶回答：不是，还要关键路径可用、历史积压受控、数据缺口可解释且业务不变量通过。

11. 复制不等于备份，备份也必须通过真实恢复证明 {#53-03-k11}

复制保存当前状态并支持在线冗余，会传播误删、勒索和逻辑污染；备份要在独立故障域保存历史一致基线、连续增量、元数据、权限、密钥、证书、配置和对象清单。备份任务成功只说明流程运行过，不能证明介质可读、日志连续、版本兼容、密钥可用或恢复速度达标。恢复演练必须在隔离环境完成下载、解密、还原、日志重放、索引或投影重建、技术校验和业务查询，并记录每阶段耗时。保留期要覆盖误操作发现延迟和多个备份失败周期。

sequenceDiagram
    participant P as 在线主副本
    participant B as 独立备份库
    participant L as 连续增量日志
    participant R as 隔离恢复环境
    participant V as 技术与业务校验
    P->>B: 写入一致基线、元数据与依赖清单
    P->>L: 持续归档可重放增量
    B->>B: 校验、加密、保留与跨域复制
    B->>R: 恢复指定健康基线
    L->>R: 连续重放到安全停止点
    R->>V: 提交对象摘要、位置和阶段耗时
    V->>V: 执行库存、账务、任务和删除校验
    alt 全部通过
        V-->>B: 形成可恢复证据
    else 缺密钥、断日志或不变量失败
        V--xB: 标记备份链不可用并修复
    end

图解读：节点包括在线副本、独立备份、增量日志、隔离环境和校验；箭头表明恢复依赖完整材料集合。前提是账号、地域和生命周期独立；正常路径形成可恢复证据，失败路径暴露缺密钥、断档或业务错误。结论是备份能力的产物是成功恢复记录，不是备份文件数量。

数据演绎 11：恢复吞吐决定真实 RTO（恢复时间目标）

E3（演练证据）：全量备份 4 太字节，恢复链路有效吞吐 250 兆字节/秒，仅下载理论需约 4 × 1024 × 1024 ÷ 250 ÷ 3600 ≈ 4.66 小时；解密与还原 2 小时、增量重放 1.5 小时、关键校验 1 小时，总计约 9.16 小时。若目标为 6 小时，不能删掉校验凑数，应提高并行恢复、缩小关键数据基线、准备近线副本或分层开放业务。状态从备份存在变为恢复超时；观测信号是各阶段吞吐、剩余字节、重放位置和差异数；结论是容量模型必须包含灾难恢复带宽与临时空间。

热门面试题

1. 问题：为什么复制不等于备份？
   • 考点：当前冗余与历史恢复。
   • 回答思路：用误删和逻辑污染说明。
   • 详细答案：复制把当前变化传给其他副本，能应对单节点故障，但误删和错误写也会同步传播；备份保存独立历史点、增量和依赖，可回到污染前状态，并受独立权限与保留策略保护。
   • 进阶追问：跨地域复制算备份吗？
   • 进阶回答：若只保留当前状态仍不是完整备份，还需历史版本、独立权限、保留和恢复验证。
2. 问题：备份任务每天成功为什么仍可能无法恢复？
   • 考点：介质、依赖、连续性和速度。
   • 回答思路：列出文件之外的恢复前提。
   • 详细答案：文件可能损坏，日志可能断档，密钥或插件可能缺失，版本可能不兼容，权限也可能在事故时不可用；即使能还原，耗时还可能超过目标。只有隔离恢复演练能证明可用。
   • 进阶追问：抽样恢复够吗？
   • 进阶回答：抽样适合高频发现问题，仍需周期性全规模恢复验证真实吞吐、临时空间和业务校验时间。
3. 问题：备份保留期怎样确定？
   • 考点：发现延迟与日志覆盖。
   • 回答思路：从最晚发现、失败周期和审计要求倒推。
   • 详细答案：保留要覆盖误操作或污染的最晚发现时间、至少多个基线失败周期、增量日志连续窗口、节假日审批和恢复演练时间；还要满足合规删除，不能只按磁盘还能存几天决定。
   • 进阶追问：长期保留越多越安全吗？
   • 进阶回答：会增加泄露、成本和删除合规风险，应按数据等级、密钥和生命周期分层管理。

12. 切换与回切都要经历写冻结、位置确认、业务校验和灰度 {#53-03-k12}

切换不是把域名指向备用，回切也不是故障区域一恢复就切回。切换前要确认故障范围、冻结或分流高风险写、确定最后安全位置、撤销旧主权限并记录决策；切换后先开放最小流量，校验数据位置、重复与缺失、积压、外部未知态和业务不变量。回切前应把旧区从新主重建或单向追平，禁止双向盲合并；先只读影子，再小比例写，观察完整业务周期。若当前新区域稳定，回切本身是一次高风险变更，可以延后到低峰而不是追求拓扑“归位”。

sequenceDiagram
    participant C as 事故指挥
    participant O as 旧主区域
    participant N as 新主区域
    participant R as 路由
    participant V as 数据与业务校验
    C->>R: 冻结高风险写并缩小入口
    C->>O: 撤销旧主写权限和旧任期
    O->>N: 提交最后可用复制位置
    C->>N: 提升并记录新任期
    R->>N: 小流量开放最小业务
    N->>V: 提交缺口、重复、积压与未知态
    V-->>R: 校验通过后分批放量
    O->>N: 旧区恢复后从新主重建
    O->>V: 只读影子和位置校验
    alt 回切收益大于风险且观察通过
        C->>R: 小比例回切并保留回滚
    else 新区稳定或任一门禁失败
        C->>R: 保持当前主区并延后回切
    end

图解读：节点覆盖指挥、旧区、新区、路由和校验；箭头展示切换与回切都是受控迁移。前提是新任期和单向历史明确；正常路径灰度放量，失败路径延后回切。结论是恢复拓扑不是目标，持续正确的业务状态才是目标。

数据演绎 12：过早回切会制造第二次事故

E3（演练证据）：首次切换用 18 分钟恢复关键业务，新区稳定处理 1,000 请求/秒。旧区在 40 分钟后网络恢复，但还落后 2,400,000 条事件；净追平能力为每秒 2,000 条，至少需 1,200 秒 = 20 分钟，再加摘要和业务校验 15 分钟。若网络恢复即回切，会把至少 35 分钟的重建与校验窗口压掉。正确做法是保持新区为主，旧区单向追平、只读影子并观察完整周期，只有收益明确才回切。观测信号是剩余位置、净追平率、差异、用户结果和回切风险；结论是旧区可达不等于可承担写。

热门面试题

1. 问题：故障切换前为什么要冻结写？
   • 考点：确定最终位置与防止双写。
   • 回答思路：说明持续写会让安全边界移动。
   • 详细答案：在故障范围和复制位置不清时继续高风险写，会扩大缺口并让旧主、新主同时接受请求。冻结或分级限流可以固定水位、撤销旧主权限并让提升后的差异可计算。
   • 进阶追问：必须全站停写吗？
   • 进阶回答：不一定，可按业务键、租户或能力分级，只读和可安全排队的入口可保留，但边界必须可证明。
2. 问题：为什么回切不是越快越好？
   • 考点：二次变更风险。
   • 回答思路：把回切当作新迁移而非复位。
   • 详细答案：旧区恢复后可能数据落后、配置漂移、缓存未预热和依赖未验证。当前新区若稳定，急于回切只会增加第二次路由、写入权和数据迁移风险，应先重建、影子和灰度。
   • 进阶追问：可以永不回切吗？
   • 进阶回答：可以评估长期驻留，但要更新容量、成本、合规、运行手册和下一次容灾拓扑。
3. 问题：切换成功的业务证据有哪些？
   • 考点：技术健康与业务恢复。
   • 回答思路：按缺口、重复、积压、未知态和不变量回答。
   • 详细答案：要证明关键读写成功、最后安全位置符合目标、缺失和重复均可解释、历史积压在收敛、外部未知态有查证、库存与账务等不变量通过，并且小流量到全量观察无新增差异。
   • 进阶追问：监控恢复绿色是否足够？
   • 进阶回答：不足，监控可能只反映新请求，事故窗口的历史缺口和外部副作用仍需对账。

13. 恢复演练以停止条件、不变量和项目话术形成闭环 {#53-03-k13}

恢复演练要有业务负责人、事故指挥、数据负责人和外部依赖联系人，预先写明注入、观察、止损、停止、恢复与复盘。停止条件不是“脚本报错”，而是任何资金、库存、租约或严重报警不变量失败，差异持续增长，旧主仍能写，恢复速度无法在剩余窗口达标，监控失真或人工负荷超过控制能力。演练通过也不能只看当次恢复，应把检测、决策、下载、重放、校验和放量时间写回 RPO（恢复点目标）与 RTO（恢复时间目标）模型。项目表达遵循背景、故障模型、权威源、动作、证据、取舍与结果边界，所有数字保留 E3（演练证据）标签。

stateDiagram-v2
    [*] --> 准备
    准备 --> 注入: 责任人 备份 回滚 止损齐备
    注入 --> 观察: 记录故障和检测时刻
    观察 --> 停止: 不变量失败或差异增长
    观察 --> 恢复: 影响符合预案
    停止 --> 保全证据
    保全证据 --> 受控回滚
    恢复 --> 校验: 数据 依赖 业务
    校验 --> 停止: 任一门禁失败
    校验 --> 灰度: 全部通过
    灰度 --> 停止: 新增错误或未知态
    灰度 --> 复盘: 完整观察窗通过
    受控回滚 --> 复盘
    复盘 --> [*]

图解读：节点从准备、注入、观察、恢复、校验、灰度到复盘，停止分支贯穿全过程；箭头表示停止不是失败，而是预设的风险控制动作。前提是回滚和证据保全可执行；正常路径通过完整观察窗，失败路径受控回滚。结论是没有停止条件的演练是在制造事故。

数据演绎 13：停止条件保护演练不演变为事故

E3（演练证据）：IoT（物联网）报警恢复演练回放每秒 10,000 条事件，严重报警候选每秒 50 条。开始 4 分钟后，严重报警通知差异从 0 增至 12，未知通知每分钟再增 3；预设停止条件为“任一严重报警漏发”或“未知持续两个窗口增长”，因此立即停回放并保持通知隔离。若继续跑满 30 分钟，按当前斜率未知至少再增 78。停止后用报警实例键查证、修复规则版本并从检查点重放。观测信号是严重报警覆盖、重复通知、未知年龄和人工队列；结论是演练目标是验证控制能力，不是强行跑完脚本。

热门面试题

1. 问题：恢复演练为什么必须有停止条件？
   • 考点：爆炸半径和风险控制。
   • 回答思路：说明演练环境也可能触发真实副作用或污染证据。
   • 详细答案：故障注入会改变路由、写权限、队列和外部调用，若差异增长或不变量失败仍继续，演练会变成真实事故。停止条件让团队在预设证据点回滚、保全现场并修正方案。
   • 进阶追问：停止是否算演练失败？
   • 进阶回答：机制按预期停止本身是控制成功，但恢复目标未通过，必须记录缺口并修复后重演。
2. 问题：容灾演练最重要的业务不变量有哪些？
   • 考点：项目恢复验收。
   • 回答思路：分别绑定支付、库存、Runner（执行器）和 IoT（物联网）。
   • 详细答案：支付要求借贷平衡且不重复扣款，库存要求可售不负且预占、释放、扣减可解释，Runner（执行器）要求旧租约不能提交，IoT（物联网）要求严重报警不漏且通知不重复；物流状态不能倒退。
   • 进阶追问：技术校验还需要吗？
   • 进阶回答：需要，位置、摘要、日志连续、权限和依赖是恢复前提，但不能替代业务不变量。
3. 问题：如何在面试中讲一次容灾设计？
   • 考点：结构化项目表达与事实边界。
   • 回答思路：按背景、故障、目标、方案、切换、验证、停止和取舍展开。
   • 详细答案：先声明真实事实与 E3（演练证据）边界，再说明业务不变量和故障域；给出 RPO（恢复点目标）、RTO（恢复时间目标）、单活或多活选择、复制与备份、写栅栏、切换回切、数据校验、外部副作用对账、停止条件和成本，最后说如何演练更新模型。
   • 进阶追问：最容易被追问的取舍是什么？
   • 进阶回答：同步强度与延迟、主备与多活成本、快速放量与业务校验、自动恢复与人工控制边界。

综合题使用说明

以上 13 个带 kb:knowledge 标记的小节构成本册知识正文；本小节不配置 kb:knowledge 标记，只负责终止知识小节审计范围。下面 26 道综合题用于训练完整口述，不重复计入知识小节。

综合题库

1. 问题（综合题）：请完整设计一套容灾与恢复方案。

   • 口述答案：我会先从业务事实而不是机房数量开始。第一步识别权威源和不变量：支付要保证借贷平衡、不重复扣款，库存要保证可售不为负且预占、释放、扣减可解释，任务要拒绝旧租约结果。第二步建立故障模型，覆盖依赖变慢或未知、网络分区、数据损坏、误操作、区域和供应商失效，并写清范围、检测、相关故障和证据。第三步按损失分层定义 RPO（恢复点目标）与 RTO（恢复时间目标），明确计时起点、最小业务集和结束条件。拓扑选择上，单活加备份成本低但恢复慢；主备保持单一写入权并用复制缩短切换；双活或多活只有在按键归属、冲突规则、跨区容量和持续成本可证明时使用。数据层同时建设在线复制与独立历史备份，备份必须包含基线、连续增量、元数据、密钥和权限。切换前冻结高风险写、确认最后安全位置、撤销旧主任期；切换后先小流量开放，核验缺失、重复、积压、未知态和业务不变量。旧区恢复后从新主单向重建，影子验证后再决定是否回切。演练预设停止条件，任何资金、库存或严重报警不变量失败立即收回流量。最终用恢复位置、各阶段耗时、差异清单、业务签收和完整观察窗证明方案，而不是用“备机启动”作为结论。所有量级若无现场证据只标 E3（演练证据）。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。
   • 追问 1：最先恢复什么？
   • 直接回答 1：先恢复权威数据、写栅栏和支付查单、库存裁决等最小业务集，搜索报表后置。
   • 追问 2：为什么复制和备份都要有？
   • 直接回答 2：复制应对在线节点故障，备份应对误删、污染和历史回退，两者故障模型不同。
   • 追问 3：怎样证明恢复成功？
   • 直接回答 3：同时验证位置、日志、摘要、外部副作用、业务不变量、积压收敛和用户结果。
   • 详情：故障模型合同

2. 问题（综合题）：如何建立可演练的故障模型？

   • 口述答案：可演练故障模型必须把“会挂”翻译成具体合同。我先列业务路径和权威对象，再按进程、节点、网络、存储、数据、账号、控制面、区域和供应商分类；每类写明失效方式，例如完全不可达、单向分区、持续变慢、返回错误、结果未知、静默损坏或合法逻辑污染。然后确定故障域和相关性：两个副本是否共享存储、账号、域名、发布平台、密钥和人员操作，避免把同源冗余当独立容灾。时间线上记录故障发生、检测、决策、冻结、切换、校验和放量时刻，因为检测与人工决策同样消耗 RTO（恢复时间目标）。数据影响要区分已确认、在途、派生和外部副作用，并说明最后安全位置、可能缺口和重复窗口。每个模型还要给正常信号与盲区，至少准备外部探测和业务审计两类独立证据。演练脚本写清注入范围、责任人、回滚点、停止条件和禁止外推的边界；杀进程只能证明进程级恢复，不能证明区域故障。验收回到 RPO（恢复点目标）、RTO（恢复时间目标）、业务不变量、历史积压和用户结果。复盘把真实检测延迟、恢复瓶颈和人工步骤写回模型，形成下一轮门禁，而不是只记录演练“成功”。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：相关故障最常被漏掉什么？
   • 直接回答 1：共享账号、共享存储、统一发布、同一域名控制面和同一供应商上游。
   • 追问 2：故障模型是否越多越好？
   • 直接回答 2：不是，应按业务损失和可信威胁排序，先覆盖高影响且可验证的模型。
   • 追问 3：证据冲突怎么办？
   • 直接回答 3：先限制写和爆炸半径，固定现场，引入第三类证据后再决定切换。
   • 详情：故障对象与恢复证据

3. 问题（综合题）：外部依赖持续变慢并出现超时，如何止血和恢复？

   • 口述答案：我先把超时定义为结果未知而不是失败，并区分读取、可重放写和不可重放副作用。排查从用户结果、依赖服务时间、线程与连接等待、在途、超时、重试放大和最老未知年龄开始，确认是单供应商、单租户还是全局问题。止血顺序是停止立即重试，按依赖和任务类型隔离并发，缩短非关键请求预算，暂停报表、批量和低优先级入口，让关键查单与确认保留独立配额；不能先盲目扩连接池，因为这可能把更多压力推给下游。明确失败按错误类型返回或排队，限流使用退避和抖动，未知写使用原业务键查单，确认未执行才允许重试；支付、仓单和退款不能换新键重做。若依赖没有查单能力，就保存脱敏请求、尝试号和时间窗，降低自动动作，通过账单、回执或人工形成替代证据。恢复时先验证下游真实容量与配额，再小批释放积压，控制净消化率，防止新流量加历史重放再次压垮依赖。业务验收不仅看错误率下降，还要让未知态、积压和差异持续收敛，确认没有重复支付、重复仓单或漏通知。最后调整超时预算、有界队列、隔离池、重试分类和供应商合同，并用相同故障强度复演。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：为什么不直接熔断全部请求？
   • 直接回答 1：查单和关键确认可能是恢复必需，应按能力分级而不是一刀切。
   • 追问 2：连接池等待高能否扩池？
   • 直接回答 2：只有下游仍有余量且瓶颈在本地池时才可评估，否则会加剧级联。
   • 追问 3：何时宣布依赖恢复？
   • 直接回答 3：新请求稳定、未知态和积压收敛、外部对账无新增差异时。
   • 详情：依赖失效与级联

4. 问题（综合题）：网络分区时如何防止脑裂和数据分叉？

   • 口述答案：网络分区的危险在于双方进程和存储都可能正常，只是彼此不可见，因此不能用“服务存活”决定写入权。我会先按业务分类：支付账务、库存扣减、Runner（执行器）租约等不可安全合并的事实，只允许满足多数派与最新领导任期的一侧写；可重建读模型或有明确合并规则的数据可以受限服务。控制面选举新主后，立即提升持久化任期，并通过网络入口、账号、存储权限和业务条件更新四层栅栏撤销旧主。关键写携带任期和业务版本，即使客户端缓存旧地址或旁路任务触达旧主，也会在最后写路径被拒绝。切换前记录主副位置和在途请求，切换后小流量验证缺口、重复和外部未知副作用。网络恢复时旧主不能直接重新接流或双向合并，而要先隔离、比较历史，从新主重绕或重建；旧分支仅作为取证材料。若多活场景允许同键多点写，必须事先证明合并规则在重复、乱序、时钟偏差和并发更新下仍满足业务不变量。验收要看任期唯一、旧主零有效写、复制历史连续、业务差异清零和用户结果稳定，而不是看两个区域重新互通。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：服务发现为什么不够？
   • 直接回答 1：它只影响新路由，缓存连接、旁路任务和共享凭据仍可能触达旧主。
   • 追问 2：旧主数据如何处理？
   • 直接回答 2：保留取证，按业务键裁决必要差异，再从新主重建，禁止直接双向同步。
   • 追问 3：少数派能提供只读吗？
   • 直接回答 3：可在明确陈旧水位且不用于资金库存裁决时受限提供。
   • 详情：网络分区与写栅栏

5. 问题（综合题）：如何处理数据损坏，为什么不能直接切到副本？

   • 口述答案：我先区分介质错误、静默损坏、传输损坏、模式错误和逻辑污染。介质或传输问题可能由页校验、读取错误和对象摘要发现；逻辑污染却是合法事务写入错误金额、库存或状态，在线副本会快速复制，因此副本绿色不等于数据健康。发现后第一步冻结受影响业务键或写入口，保留坏样本、版本、日志和首个异常时间，避免立即修复覆盖证据。第二步用两类证据定范围：产品内部位置、校验和与读取错误是一类，库存守恒、借贷平衡、状态版本和外部对账是另一类。第三步确认污染是否传播、哪个副本或备份仍处于健康历史；若在线副本均污染，就在隔离环境恢复独立基线，连续重放到污染前安全点，再选择性应用事故后合法变化。回生产时按业务键、版本和补偿流水小批合并，不能整体覆盖当前库，也不能按最后时间戳简单取新。恢复后从健康历史重建其他副本，执行物理摘要、主键集合、关键聚合、逐笔高风险对象和外部副作用核验。只有差异清零或每项都有受控处置、没有新增污染，才逐步放量。复盘补充周期扫描、备份独立权限、脚本门禁和不变量告警。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：校验和通过说明什么？
   • 直接回答 1：说明字节或对象按预期保存，不说明金额、库存和状态语义正确。
   • 追问 2：为什么先保留坏样本？
   • 直接回答 2：便于定位根因、首个异常和传播范围，避免修复动作破坏证据。
   • 追问 3：副本何时可以作为恢复源？
   • 直接回答 3：位置连续、物理校验和业务不变量均证明未受污染时。
   • 详情：数据损坏与逻辑污染

6. 问题（综合题）：生产误删或误更新后如何恢复且不丢后续合法数据？

   • 口述答案：误操作通常通过合法权限完成，所以处理重点是污染时间线和业务合并。我先停止后续批次，冻结受影响租户、表或业务键，保留操作者、审批、脚本摘要、影响行数、事务位置和执行前后样本。然后确定误操作开始、结束、最晚发现时刻和受影响对象，核对连续日志是否覆盖整个窗口。恢复不直接作用于生产，而是在隔离环境选择误操作前一致基线，执行 PITR（时间点恢复）到安全停止位置，得到正确历史参考。接着把恢复库中的受影响业务键与生产当前版本比较，保留事故后新增订单、支付、退款、出库等合法变化；已进入不可逆终态的对象不能用旧值覆盖，要通过冲正、补记、库存补偿或人工审核处理。合并清单按风险分批审批，每批使用版本条件和稳定补偿号写入，并立即复算主键集合、金额、库存、状态机和外部对账。任何差异增长或状态倒退都触发停止。恢复结束后继续观察完整业务周期，确认没有遗漏的下游投影和异步任务。长期治理包括最小权限、双人复核、只读预览、小批上限、自动停止阈值、业务不变量告警和定期误操作恢复演练。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：为什么不能整体回退生产？
   • 直接回答 1：会同时抹掉误操作后产生的合法订单、支付和状态推进。
   • 追问 2：PITR（时间点恢复）的作用是什么？
   • 直接回答 2：在隔离环境重建安全历史点，供差异提取和业务合并，不是自动替换生产。
   • 追问 3：恢复批次怎样停止？
   • 直接回答 3：影响量超限、不变量失败、版本冲突或差异增长时立即停批。
   • 详情：误操作与时间点恢复

7. 问题（综合题）：如何设计和执行一次区域级容灾切换？

   • 口述答案：区域级容灾不能只检查数据库副本。我会先把计算、存储、网络出口、全局路由、密钥、证书、配置、监控、发布平台、供应商白名单和人员协同列成故障域清单，确认恢复区不共享关键控制面。容量按一个完整区域失效后的峰值计算，并预设最小业务集：优先支付查单与账务、库存裁决、订单查询，搜索、报表、导出和低优先级任务后置。故障发生后用外部探测和业务审计确认影响，冻结高风险写，记录主副最后位置并撤销旧区任期与账号。恢复区取得独立应急凭据，验证支付、仓库、对象存储和回调入口，再提升数据和路由。第一批只开放内部或少量租户，观察用户结果、写入延迟、依赖配额、数据缺口、重复、未知态和业务不变量；通过后按批次放量，同时限流非关键入口。若数据位置不满足 RPO（恢复点目标）、恢复速度无法满足剩余 RTO（恢复时间目标）、旧区仍能写或差异增长，立即停止并保持只读或降级。旧区恢复后从新主单向重建，不急于回切。演练记录各阶段耗时、人工步骤和供应商协作，更新容量、凭据、路由和运行手册。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：恢复区容量不足怎么办？
   • 直接回答 1：先降级低价值能力、限流并保护关键路径，再结合弹性扩容和依赖配额逐步放量。
   • 追问 2：最容易遗漏的控制面是什么？
   • 直接回答 2：域名、密钥、发布、监控和供应商白名单常与主区域相关失效。
   • 追问 3：旧区网络恢复就回切吗？
   • 直接回答 3：不回，先重建、只读影子和完整观察，再比较回切收益与风险。
   • 详情：区域故障与最小业务集

8. 问题（综合题）：如何治理支付、物流或通知供应商的单点风险？

   • 口述答案：我不会把“接两家”直接当容灾，而是先拆供应商故障模型：接口中断、持续变慢、配额耗尽、账号冻结、语义变更、账单错误、控制台不可用、区域退出和企业停止服务。对每家建立防腐层，统一本地业务意图、渠道尝试、状态映射和错误分类，保留供应商权威标识、脱敏请求响应、查单与账单证据。多供应商要核对是否共享清算、运营商、云区域或网络上游，并提前验证备用账号、白名单、配额、风控和人员流程。主供应商超时不能立即切备用，因为原渠道可能已成功；必须用原尝试号查单或对账，明确未执行后，才以关联同一业务意图的新尝试切换。故障期间按金额、租户、时效和风险分级，给查单与高价值请求保留独立配额，普通请求进入可查询的处理中状态。恢复时分批释放积压，对两渠道按业务意图、金额和外部标识全量对账，关闭重复扣款、重复仓单和重复通知。退出能力还要周期导出历史、配置和审计，演练字段转换、回调迁移、未结算业务、密钥撤销和回滚。最终以真实切换耗时、容量、差异和业务结果证明，不以合同写有备用条款作为完成。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：两家供应商不同品牌就独立吗？
   • 直接回答 1：不一定，可能共享清算、运营商、区域或网络上游，需核对和演练。
   • 追问 2：备用渠道长期不用有什么风险？
   • 直接回答 2：账号、配额、白名单、风控和接口兼容可能失效，应持续探测和小流量验证。
   • 追问 3：供应商数据如何退出？
   • 直接回答 3：周期导出历史、配置、账单和审计，在独立环境验证可导入、可查询和可对账。
   • 详情：供应商故障与退出

9. 问题（综合题）：单活、主备、双活和多活该如何选择？

   • 口述答案：选择从业务损失、写入权和恢复目标开始，而不是从拓扑名称开始。单活加独立备份最简单，适合可接受较长恢复、数据量和变更可控的能力，但必须证明基线、日志和完整恢复速度。主备用持续复制换取更短切换，保持单一写入权，冲突成本较低；异步主备要接受复制尾部或准备独立重建源，同步主备则承担跨区延迟与分区可用性代价。双活或多活适合区域故障损失高、业务可按租户或键分区、跨区容量和运维成熟的场景。优先采用同键单归属，通过写入权目录和任期迁移，避免资金、库存和任务租约同键双写；只有业务数据具有确定、可验证的合并规则时才允许多点写。比较时我会列正常延迟、RPO（恢复点目标）、RTO（恢复时间目标）、容量余量、冲突与外部副作用、数据驻留、路由、回切、值班、演练和全周期成本。搜索、报表和缓存可以读多活，权威资金与库存仍可单主。最后做敏感性分析：若主备已满足损失目标，就不为“架构高级”上多活；若区域中断损失远超持续成本，再通过故障演练证明多活收益。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
   • 追问 1：同步主备一定更好吗？
   • 直接回答 1：不一定，会增加写延迟并在跨区分区时影响可用性，要按业务损失权衡。
   • 追问 2：读多活有什么边界？
   • 直接回答 2：必须展示数据水位并处理读己之写，陈旧投影不能裁决资金库存。
   • 追问 3：多活何时不值得？
   • 直接回答 3：主备已满足目标，或冲突、组织和持续成本高于区域故障预期损失时。
   • 详情：单活与主备

10. 问题（综合题）：双活或多活如何处理一致性、冲突和成本？

• 口述答案：我先定义数据所有权。对支付账户、库存键、Runner（执行器）任务等强不变量对象，按租户、仓、账户或业务键固定一个权威区域，请求携带归属任期；迁移时冻结旧侧、取得最终水位、让新侧追平并校验，再提升新任期。这样多个区域可以同时承接不同键，却避免同键并发写。对确需多点写的数据，必须写出冲突模型：唯一键碰撞、乱序、重复、时钟偏差、删除与外部副作用，并用业务版本或可交换、可结合、可幂等的合并规则处理，不能简单按最后时间覆盖。跨区同步越强，确认延迟越高，分区时越可能停止写；异步复制则必须接受陈旧、冲突队列和对账。路由层要处理用户就近、归属转发和故障迁移，容量上每个剩余区域要能承担关键业务，不能只做平时流量均分。成本不止双份机器，还包括全局目录、跨区带宽、数据驻留、双边发布、配置漂移、冲突平台、值班、演练和回切。验收通过分区、旧主复活、热点键迁移和供应商未知态演练，确认同键有效写唯一、冲突有界、外部副作用不重复且业务不变量通过。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
• 追问 1：最后写入获胜是否可用？
• 直接回答 1：只适合业务明确允许覆盖的数据，资金库存通常会丢合法动作，不能使用。
• 追问 2：按租户归属还是多活吗？
• 直接回答 2：是，多个区域同时活跃承接不同租户，只是同一键保持单一写入权。
• 追问 3：如何控制热点迁移？
• 直接回答 3：冻结目标键、固定水位、限速追平、校验后切任期，并保留快速回滚。
• 详情：双活多活冲突模型

11. 问题（综合题）：如何为支付、库存、物流和异步任务制定 RPO（恢复点目标）与 RTO（恢复时间目标）？

• 口述答案：我不会给整个系统套一个数字，而是按业务事实、可补偿性和最小业务集分层。支付已确认资金事实要求接近零缺口，但外部渠道超时形成的未知态也要纳入目标；恢复结束不是数据库启动，而是查单、补记、账务和对账可运行。库存预占要求已承诺订单不无解释丢失，恢复后条件更新、释放、扣减和对账能继续；如果副本有窗口，就用订单、库存流水和持久事件幂等重建。物流轨迹允许短时延迟，但版本不能倒退，可从运单事件和供应商查询补拉。异步导出要求任务、查询口径和源水位不丢，文件可重建，已交付通知要去重。Runner（执行器）要保住任务、租约和任期，旧执行结果不能提交。每个目标写清故障模型、计时起点、最后安全位置、可接受业务量缺口、最小功能和验证查询。RTO（恢复时间目标）包含检测、决策、下载、重放、依赖启动、校验和灰度，不只算脚本。演练用接近规模的数据测阶段耗时，并把缺口换算成订单、金额、任务或事件数量；若目标成本过高，由业务确认降级或投资，不能只改文档数字。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
• 追问 1：零 RPO（恢复点目标）如何实现？
• 直接回答 1：可用更强复制确认或独立持久事件、查单和幂等重建，但必须证明已确认事实无缺口。
• 追问 2：搜索索引目标如何定？
• 直接回答 2：通常允许从权威源重建，重点定义可接受陈旧、降级查询和重建完成时间。
• 追问 3：目标由技术单独决定吗？
• 直接回答 3：不，业务定义损失与优先级，技术提供成本、机制和演练证据共同决策。
• 详情：分层恢复目标

12. 问题（综合题）：为什么复制不等于备份，高可用也不等于可恢复？

• 口述答案：复制、高可用、备份和可恢复性是四个层次。复制把当前变化送到其他副本，用于在线冗余和读扩展，但会同步传播误删、错误脚本、勒索和逻辑污染。高可用在复制之上增加故障检测、选主、旧主栅栏和路由收敛，主要缩短节点或区域中断；它不提供任意历史点。备份在独立账号、介质或地域保存一致基线、连续增量、元数据、权限、密钥、证书和配置，用于回到污染前状态。可恢复性则要求这些材料在目标时间内真正恢复出可承担业务的系统。三副本可能共享同一软件、管理员账号和当前错误，每日备份任务也可能文件损坏、日志断档、无密钥或恢复太慢。因此我分别建设指标：复制看位置和陈旧，高可用看检测、提升和旧主拒写，备份看基线、连续性、保留和对象校验，可恢复性看隔离演练、各阶段耗时、业务不变量与用户结果。事故时节点故障优先主备切换，逻辑污染优先独立历史恢复，两者路径不能混淆。只有定期全规模演练证明 RPO（恢复点目标）与 RTO（恢复时间目标），才能说系统可恢复。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
• 追问 1：跨区三副本够吗？
• 直接回答 1：不够，仍可能同步逻辑错误，还需历史保留、独立权限和恢复演练。
• 追问 2：高可用能缩短 RTO（恢复时间目标）吗？
• 直接回答 2：能缩短常见故障切换，但完整业务恢复仍含校验、依赖和历史积压。
• 追问 3：谁签收可恢复性？
• 直接回答 3：平台、数据、安全和业务共同签收，业务必须验证不变量和用户路径。
• 详情：复制与备份边界

13. 问题（综合题）：如何证明一套备份恢复方案真的满足目标？

• 口述答案：证明必须从端到端恢复演练产生，而不是看备份平台绿色。先把目标写成可测合同：针对哪种故障、最后允许恢复到哪个位置、从哪个时刻计时、哪些关键业务必须在何时可用。备份目录至少包含一致基线、连续增量、表和索引元数据、账号权限、密钥证书、插件配置、对象清单与校验摘要，并与在线系统隔离账号、地域和生命周期。演练在隔离环境选接近生产的数据规模和日志速率，随机选择基线，验证读取、解密、版本兼容和临时空间，再连续重放到指定停止位置。全程记录下载、解密、还原、重放、启动、投影重建和校验耗时，计算剩余量与预计完成时间。技术校验比较文件、对象、主键集合、日志连续和关键查询；业务校验复算库存守恒、借贷平衡、状态单调、任务唯一和删除范围，并对支付渠道、仓库和通知外部副作用查单。演练还要故意损坏一份快照、撤销权限、缺失一段日志或使用旧密钥，验证是否能自动换源或明确停止。最终以最后安全位置证明 RPO（恢复点目标），以关键业务签收时刻证明 RTO（恢复时间目标），任何断档、差异或超时都形成改进项并重演。 执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
• 追问 1：抽样恢复能否证明 RTO（恢复时间目标）？
• 直接回答 1：不能完全证明，规模、吞吐、临时空间和校验时间需周期性全量演练。
• 追问 2：校验能否为赶时间删减？
• 直接回答 2：不能，应分层恢复业务或提升恢复能力，不能用未校验数据冒充达标。
• 追问 3：日志断档怎么办？
• 直接回答 3：固定最后可证明位置，声明真实 RPO（恢复点目标），建立新基线并修复连续性。
• 详情：备份恢复证据链

14. 问题（综合题）：故障切换的完整步骤和门禁是什么？

• 口述答案：故障切换先确认业务影响和证据可信度，再决定是否切。第一阶段用外部探测、内部位置和业务审计界定故障域，冻结高风险写，保留只读、查单和可安全排队能力；同时记录旧主最后确认位置、副本应用位置和在途业务键。第二阶段撤销旧主的网络入口、账号、存储权限与领导任期，确保缓存旧地址的请求也会被业务条件更新拒绝。第三阶段检查候选恢复端的数据位置、容量、密钥、配置、监控和外部供应商，缺任一前提都不提升。提升后只开放最小业务集和少量租户，按支付、库存、任务等权威键核对缺失、重复、未知和外部副作用，再观察积压净收敛。通过门禁后分批放量；若旧主仍写、位置退化、差异增长、不变量失败或剩余时间无法满足 RTO（恢复时间目标），立即停止并回到只读或降级。切换完成也要保留事故状态，直到历史缺口全部闭环。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：切换是否必须人工批准？
• 直接回答 1：高风险写与复杂故障应由事故指挥批准，自动化可执行已预演的局部动作。
• 追问 2：路由切完就算成功吗？
• 直接回答 2：不算，还要数据位置、外部副作用和业务不变量通过。
• 追问 3：候选副本落后怎么办？
• 直接回答 3：若超出 RPO（恢复点目标），应补日志、从备份恢复或保持降级，不能冒充达标。
• 详情：切换与灰度门禁

15. 问题（综合题）：故障区域恢复后如何安全回切？

• 口述答案：回切首先是一项新的高风险迁移，不是拓扑复位。我会先问当前新区是否稳定、回切收益是否足以承担二次变更；若没有合规、成本或容量必要，可以延后或长期驻留。准备回切时，旧区继续隔离写，从当前新主获得一致基线或连续增量，单向追平到明确水位，禁止双向同步分叉历史。然后核对版本、配置、密钥、证书、供应商白名单、监控和计算容量，执行只读影子查询，比较主键集合、摘要、业务聚合和数据水位。通过后选择低峰和小租户灰度，重新应用与首次切换相同的写冻结、任期、旧主栅栏、业务校验和回滚门禁。观察至少一个完整业务周期，确认用户结果、积压、未知态和差异稳定，再逐批扩大。任何写入权不唯一、复制倒退、状态机倒退或外部重复副作用都立即收回流量。回切后原新区成为备用时，也要从新主建立单向历史并更新下一次故障预案。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：为什么不能双向追平？
• 直接回答 1：双方可能包含不同新写，盲目双向同步会覆盖顺序并制造第二条历史。
• 追问 2：旧区可达能说明什么？
• 直接回答 2：只说明网络部分恢复，不说明数据、容量、权限和依赖可承担业务。
• 追问 3：何时不回切？
• 直接回答 3：当前区域稳定且回切收益低于风险，或任何门禁未通过时。
• 详情：回切与旧区重建

16. 问题（综合题）：容灾恢复后如何设计数据校验？

• 口述答案：数据校验分四层。第一层是介质与对象完整性，检查文件、页、对象摘要、日志连续和恢复停止位置；它只能证明技术材料可读。第二层是结构与集合，比较表、索引、权限、主键集合、删除集合、各状态数量和版本分布，避免行数相同却一缺一重。第三层是业务不变量：库存按仓和商品复算可售、预占、释放、扣减，支付按币种复算借贷、退款和渠道差异，Runner（执行器）检查任务、租约和任期，IoT（物联网）检查严重报警覆盖和通知唯一。第四层是外部世界，对支付渠道、海外仓、对象交付和通知记录逐笔或分桶查证，因为数据库恢复不能撤销外部副作用。校验先用全量聚合和稳定分桶快速定位，再对高风险对象逐笔；抽样只能辅助发现，不能替代关键集合与金额的全量门禁。每个差异要有分类、负责人和截止时间，无法解释的差异不得随放量扩大。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：行数一致为什么不够？
• 直接回答 1：缺一条和重复一条会抵消，字段错位与状态错误也不改变行数。
• 追问 2：校验和是否要全量？
• 直接回答 2：关键对象和稳定分桶应全量，差异桶再逐行定位。
• 追问 3：外部对账为何单独做？
• 直接回答 3：渠道扣款、仓单和通知已发生在系统外，内部数据一致不能证明它们唯一。
• 详情：物理与业务双校验

17. 问题（综合题）：如何用业务不变量决定恢复顺序和放量？

• 口述答案：恢复顺序由不可替代性和错误成本决定。先列权威源：支付是不变账务流水、支付单和渠道标识；库存是快照、预占与变更流水；物流是运单和版本事件；异步导出是任务、分片和源水位；Runner（执行器）是任务、租约、任期和结果；IoT（物联网）是遥测事件、规则版本和报警实例。第一层恢复这些权威事实及写入栅栏，第二层恢复余额、当前库存、任务状态和报警状态，第三层再重建搜索、报表、缓存、文件和聚合，最后核对通知、扣款、仓单等外部副作用。每层设置不变量：借贷平衡、不重复扣款、可售不负、状态不倒退、旧租约不可提交、严重报警不漏。只有上层不变量通过，下一层才可接流；技术组件启动但不变量失败时保持只读或人工接管。放量按业务键和风险切片，比较新请求与事故历史，避免“当前成功率正常”掩盖旧缺口。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：为什么搜索最后恢复？
• 直接回答 1：它通常可从权威源重建，且不能反向裁决资金库存。
• 追问 2：不变量由谁定义？
• 直接回答 2：业务与领域负责人定义语义，技术团队落实可计算证据。
• 追问 3：某个不变量无法计算怎么办？
• 直接回答 3：保持受限服务并补建权威记录或人工核验，不能跳过。
• 详情：不变量与停止条件

18. 问题（综合题）：如何设计一次有停止条件的恢复演练？

• 口述答案：演练前先确定目标故障模型、业务范围、RPO（恢复点目标）、RTO（恢复时间目标）和不允许外推的结论，并指定事故指挥、数据、业务、安全和供应商联系人。准备阶段验证备份、回滚点、应急账号、监控、测试数据和外部副作用隔离；若任一缺失，不进入注入。注入时记录故障、检测和决策时刻，控制租户、区域和流量爆炸半径。观察阶段同时看技术位置与业务结果，停止条件至少包括旧主仍能写、资金或库存不变量失败、严重报警漏发、差异连续增长、人工队列超限、恢复速度无法在剩余时间达标或监控失真。触发停止后立即收流、保持只读、固定证据和水位，按预案回滚；这说明控制机制有效，但恢复目标未通过。未触发停止则继续恢复、校验和灰度，完整观察窗通过后再结束。复盘逐段计算检测、决策、下载、重放、校验和放量耗时，形成明确整改和复演日期。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：停止是否算失败？
• 直接回答 1：停止机制成功，但恢复目标未通过，修复后必须重演。
• 追问 2：能否在生产演练？
• 直接回答 2：可以受控小范围，但要隔离真实外部副作用并有立即回滚能力。
• 追问 3：演练频率怎么定？
• 直接回答 3：按风险和变更频率，重大拓扑、版本、账号或供应商变化后重演。
• 详情：演练状态机

19. 问题（综合题）：WMS（仓储管理系统）库存如何设计容灾恢复？

• 口述答案：WMS（仓储管理系统）库存先明确权威源是库存快照、预占、释放、扣减流水、订单承诺和仓单回执，不是缓存或搜索。核心不变量是可售不为负，同一业务键最多一次有效预占、释放和出库，快照可由流水解释，已出库事实不能被回退。常态采用单一权威写和异地主备，已确认流水通过更强复制或独立持久事件保护，历史备份应能恢复误删和错误脚本。切换前按仓、货主和商品冻结高风险写，记录主副位置并撤销旧主；新区先开放查询和少量条件更新。恢复后从订单、流水与消息事件补齐复制窗口，拒绝旧版本和重复业务键，对外仓超时先按客户单号查单，不能直接释放库存或重复建仓单。校验按仓和商品全量复算可售、预占、分配、出库与实物差异，高风险差异进入人工。搜索、报表和缓存最后重建。回切前旧区从新主单向追平，影子校验完整业务周期。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：库存副本缺少尾部流水怎么办？
• 直接回答 1：从订单和持久事件按业务键重放，无法证明的键保持冻结并人工核验。
• 追问 2：为什么不能先恢复缓存？
• 直接回答 2：缓存不可解释库存承诺，可能把陈旧值暴露给新订单。
• 追问 3：外仓已出库但本地缺记录怎么办？
• 直接回答 3：保留出库事实，补记流水和状态，禁止释放库存。
• 详情：WMS（仓储管理系统）库存方案

20. 问题（综合题）：支付资金系统如何做到接近零数据损失并可恢复？

• 口述答案：支付的目标不是数据库一行不丢，而是已对用户和渠道确认的资金事实最终不缺、不重且可审计。权威源包括支付意图、支付单、渠道尝试号、不变账务分录、退款与对账记录；核心不变量是借贷平衡、金额币种一致、累计退款不超原支付和同一意图不重复扣款。提交链可采用更强本地持久化与跨故障域复制，另保存可重放事件和独立历史备份；外部渠道结果通过稳定请求号查单和账单补齐，形成接近零 RPO（恢复点目标）的业务证据。切换时先冻结新扣款或降为受理，撤销旧主写权，提升满足位置的副本；对复制窗口内每笔未知按渠道号查单，成功则补记分录，失败才允许受控重试，仍未知进入人工。恢复后按币种、渠道、商户和日期全量对账金额、笔数、手续费与退款，任何差异阻断放量。报表与余额投影从分录重建，不能反向改流水。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：同步复制就能零丢失吗？
• 直接回答 1：还要覆盖存储、相关故障和外部渠道未知态，不能只靠副本。
• 追问 2：渠道超时算失败吗？
• 直接回答 2：不算，必须按稳定请求号查单或对账。
• 追问 3：账务差异如何修？
• 直接回答 3：新增补记或冲正分录，不覆盖原始资金事实。
• 详情：支付资金恢复

21. 问题（综合题）：跨境物流与海外仓供应商故障如何恢复？

• 口述答案：跨境履约的权威事实是客户订单、履约单、下游稳定请求号、仓单映射、面单对象摘要和轨迹版本事件。供应商调用按明确成功、明确失败和未知分类；超时后本地保持下发中，用原请求号查单，确认未创建才重试，避免重复仓单、面单和费用。常态按仓或承运商隔离线程、队列、配额和故障域，多供应商通过防腐层统一状态，但切备用前仍需查原渠道未知结果。区域切换时先恢复订单和请求账本，再恢复查单、回调与轮询能力；面单文件按对象摘要验证，轨迹按事件身份去重并保护签收等终态不倒退。外仓已出库是不可逆事实，本地恢复不能释放对应库存，应补记出库与费用或进入人工。积压恢复按供应商配额限速，严重时优先订单状态与异常件，历史普通轨迹可延后。验收比较订单、仓单、面单、轨迹版本、库存动作和费用，不以接口成功率代替履约完成。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：供应商不支持查单怎么办？
• 直接回答 1：降低自动重试，保留请求证据，使用账单、回执和人工核验。
• 追问 2：轨迹可否从搜索恢复？
• 直接回答 2：搜索是投影，应从运单与原始轨迹事件重建。
• 追问 3：备用仓能全量接管吗？
• 直接回答 3：必须提前验证配额、库存、地址能力、白名单和运营流程。
• 详情：跨境履约恢复

22. 问题（综合题）：异步导出系统的备份恢复如何避免重复交付？

• 口述答案：异步导出的权威源是任务、查询条件与口径版本、源数据水位、分片清单、租约任期、每片结果摘要和交付状态；文件是可重建产物，通知是外部副作用。容灾备份必须保存任务账本和对象清单，源水位保留期要覆盖恢复窗口。切换后调度器增加任期，旧 Runner（执行器）结果因旧租约被拒绝；灾难时未完成分片不立即全部重发，先检查对象是否已生成、摘要是否匹配和交付记录是否存在。缺失或损坏文件按同一任务与分片身份重建，不能创建新任务绕过幂等。恢复校验比较分片集合、行数、关键字段摘要、金额聚合、对象大小与摘要；只有全部分片一致才推进完成。已发送下载链接按任务、用户和版本查证，只补发仍有效且未交付的通知，避免恢复日志全量重放造成多次交付。数据库、对象存储和源查询分别限速，先恢复任务查询与取消，再恢复大文件吞吐。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：文件是不是权威源？
• 直接回答 1：通常不是，它应由任务口径、源水位和分片结果验证重建。
• 追问 2：租约过期能直接重跑吗？
• 直接回答 2：不能，旧任务可能仍生成文件，要用任期栅栏和对象查证。
• 追问 3：源水位已过期怎么办？
• 直接回答 3：标记任务不可重建并人工告知，不能生成不同口径文件冒充原结果。
• 详情：异步导出恢复

23. 问题（综合题）：Runner（执行器）调度系统如何容灾并拒绝旧任务结果？

• 口述答案：Runner（执行器）的权威状态包括任务定义、分片、领取者、租约截止、领导任期、尝试次数、执行结果和外部副作用标识。调度主节点切换时先撤销旧主调度入口并增加持久化任期，新领取返回包含任务、分片和任期的栅栏令牌；结果提交在权威库做“仍运行且任期相同”的条件更新，因此旧 Runner（执行器）即使网络恢复或长任务迟到也不能覆盖新结果。灾难时对未过期租约先查证外部执行结果，确认完成则补记，明确失败或安全过期后才按同一任务键重试，未知进入延迟查证或人工。备份恢复保留任务、检查点与审计，运行指标和搜索可以重建。容量恢复按任务类型隔离，关键支付查单、库存释放优先，报表和批量后置，避免积压同时放大下游。验收要求同一分片只有一个有效提交、重复尝试不重复业务副作用、旧任期拒绝数符合注入且最老任务持续下降。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：租约为什么还要栅栏？
• 直接回答 1：租约过期时旧任务可能仍运行，栅栏在提交端拒绝旧任期。
• 追问 2：结果提交超时怎么办？
• 直接回答 2：按任务键查权威状态，用同任期重试或进入未知处理。
• 追问 3：旧主只读够吗？
• 直接回答 3：不够，还要撤销调度、凭据和旧任期提交能力。
• 详情：Runner（执行器）调度恢复

24. 问题（综合题）：IoT（物联网）报警系统灾难恢复如何避免漏报和通知风暴？

• 口述答案：IoT（物联网）报警的权威源是可回放遥测、设备与规则版本、报警实例和状态迁移，搜索与聚合是派生，短信和电话是外部副作用。恢复先装载原始事件和对应规则版本，按事件时间、水位与允许迟到重建窗口，只生成报警候选，不直接重放通知。报警身份由租户、设备、规则版本、报警实例和状态迁移组成，查询既有发送记录，仅对当前仍有效、严重且未通知的状态补发；普通历史报警进入审计，不制造过期风暴。容量上为严重报警预留独立队列、消费者和供应商配额，普通事件按租户限速重算，持续观察净积压和最老事件。重复事件按稳定键去重，乱序旧版本不能让已恢复或已确认状态倒退。演练停止条件包括任一严重报警漏发、重复通知增长、规则版本不匹配或人工队列超限。验收比较原始事件唯一数、窗口计数、报警实例、状态转换、通知集合和用户确认，而不是只看总吞吐。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：为什么不补发所有历史报警？
• 直接回答 1：多数已失去时效且会形成风暴，应按当前有效性和严重级别决定。
• 追问 2：规则变化后如何重算？
• 直接回答 2：按规则版本和事件水位隔离重算，校验后再发布状态。
• 追问 3：通知渠道故障怎么办？
• 直接回答 3：保持报警事实，分级排队并查发送结果，不能换新键盲目重发。
• 详情：IoT（物联网）报警恢复

25. 问题（综合题）：容灾切换后监控恢复但业务仍异常，如何排查？

• 口述答案：我先保持事故状态，因为监控绿色通常只说明新请求或组件健康，不能证明事故窗口已闭环。第一步固定切换时间线、旧主与新主位置、路由批次、配置版本和外部依赖状态，确认没有旧主旁路写或数据位置倒退。第二步按业务键拆新流量与历史存量：检查缺失、重复、最老未知、消息积压、补偿队列和人工单，避免平均成功率掩盖少量高损失对象。第三步用两类证据交叉，技术侧看复制、日志连续、线程连接、队列和对象摘要，业务侧看库存守恒、借贷平衡、状态单调、任务任期和严重报警覆盖。第四步核对支付、海外仓、对象存储和通知等外部副作用，超时结果先查单。若差异来自派生索引，暂停其业务裁决并从权威源重建；若权威源不变量失败，立即收回写流量、冻结相关键并进入恢复或人工。修复后用原时间窗和同一查询重算，确认差异与积压持续收敛，再分批恢复，而不是因告警消失结束事故。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。 恢复结论还必须由业务负责人基于权威查询签收，不能由单一组件健康、脚本完成或监控变绿自动升级。
• 追问 1：先看什么指标？
• 直接回答 1：先看用户结果、最老未知、差异和积压斜率，再下钻组件。
• 追问 2：如何排除监控失真？
• 直接回答 2：用外部探测、权威业务查询和供应商账单等独立证据互证。
• 追问 3：何时重新放量？
• 直接回答 3：根因受控、历史差异收敛、不变量通过且小流量观察稳定后。
• 详情：事故响应与业务验证

26. 问题（综合题）：如何向面试官讲清容灾方案的取舍、成本和停止条件？

• 口述答案：我会先声明事实边界：真实拓扑、量级和事故数据待现场核对，示例只用 E3（演练证据）。然后从业务损失开场，说明支付、库存、履约或报警的权威源和不变量，给出依赖、网络、数据、误操作、区域与供应商故障模型。目标层分别定义 RPO（恢复点目标）和 RTO（恢复时间目标），明确最小业务集。方案比较不追求名词高级：单活加备份成本低但恢复慢，主备以双份资源和复制换较短切换，双活或多活还要写入权目录、冲突处理、跨区容量、数据驻留、值班与回切，只有区域损失足够大时才值得。无论拓扑，都建设独立备份、旧主栅栏、切换灰度、数据与业务双校验、外部副作用对账。停止条件明确为旧主仍写、资金库存不变量失败、严重报警漏发、差异增长、恢复预测超时或监控失真。最后用演练结果说明检测、决策、恢复和校验瓶颈，并讲为缩短目标需要投入的容量、带宽、自动化和人员成本；若业务不接受成本，就调整业务降级或目标，而不是虚报能力。执行过程中还要把责任人、输入位置、输出水位、影响对象、回滚点和审批写入事故时间线；监控同时展示新请求、历史积压、最老未知、差异数量与预计收敛时间。放量按租户或比例推进，任一业务不变量失败就立即停止并保全证据。恢复后持续观察一个完整业务周期，把实际耗时、人工步骤、供应商协作和容量瓶颈回写预案，再以同一故障强度复演。所有数量和效果在没有现场证据时只表达为 E3（演练证据）。
• 追问 1：多活是否一定更可靠？
• 直接回答 1：不一定，冲突和运维复杂度也会引入新故障，必须用演练证明净收益。
• 追问 2：成本最容易漏什么？
• 直接回答 2：跨区流量、冲突平台、数据治理、值班、演练、回切和供应商备用账号。
• 追问 3：停止条件为什么值得讲？
• 直接回答 3：它体现架构师能控制爆炸半径，不会为完成脚本牺牲业务正确性。
• 详情：恢复演练与项目话术

复习与审计清单

• 能按对象、故障域、时间、可见性、数据影响、动作和证据建立故障模型。
• 能区分依赖变慢、明确失败、限流、结果未知和语义错误，并设计不同恢复动作。
• 能说明网络分区下多数派、领导任期、四层写栅栏和旧主重建。
• 能区分介质损坏、静默损坏、逻辑污染与误操作的恢复路径。
• 能比较单活、主备、双活和多活的前提、一致性、冲突、容量与全周期成本。
• 能按支付、库存、物流、导出、Runner（执行器）和 IoT（物联网）分层制定 RPO（恢复点目标）与 RTO（恢复时间目标）。
• 能解释复制不等于备份，并用隔离恢复证明备份链可用。
• 能完整复述写冻结、位置确认、提升、灰度、校验、放量、旧区重建和回切。
• 能用库存守恒、借贷平衡、状态单调、租约任期和严重报警覆盖验收业务恢复。
• 能设计恢复演练的角色、注入、停止、回滚、证据保全和复盘。
• 能在面试中明确 E3（演练证据）边界，不把示例数字包装成真实生产事实。