第17章：给RPO与RTO加上能经受追问的边界

先说这次真的测到了什么

一次成功的实验CI中，MySQL实际版本为8.4.11，PITR从位置一百九十八回放到一千二百五十三，恢复一百二十三笔订单，余额九万九千七百四十。复制切换阶段源端独有订单五千零一没有进入新主，实际丢失一笔已确认事务。手工RTO约十点六秒，具体运行值以validation.json为准。

这些数字不是固定答案。新运行的快照时点、UUID、日志时间和停止耗时都会变化；订单构造和目标金额则保持相同。正式出版CI会重新执行，并将那次报告作为对应工件的证据。书中的一次观测用于解释读法，不会冒充所有运行都达到同样速度。

时间起点必须明确

程序在发起docker stop旧主前开始计时。因此旧主停止的等待包含在RTO内，十秒宽限后可能强杀，实际退出码保存在报告，之后还有检查隔离、提升、写入和完整核对。故障发现发生在程序外，没有测量。控制台人工审批、代理切流、DNS缓存、连接池重建和客户端重试也没有实现，所以报告明确排除这些部分。

如果生产要求“用户重新能够完成付款”为终点，就需要从独立客户端真实提交并验证业务回执，不能沿用本书的数据库客户端边界。若要求“所有订单查询与搜索恢复一致”，还需加入下游索引与缓存水位。指标名称可以相同，业务终点不同就不能直接比较。

RPO不要只写时间差

本书报告实际丢失事务数量和订单ID，再记录从副本前缀观测到源确认之间的单调时钟窗口。这个窗口不等于最后幸存业务的年龄，也不是源和副本时钟差。它只是本次故障注入阶段的观测间隔，不能升级成生产时间上界。

当业务吞吐变化很大时，相同一分钟可能对应一笔交易，也可能对应十万笔。恢复承诺最好同时描述时间、业务数量和价值范围。金融系统尤其需要明确确认金额与外部清算关系。用一个平均延迟秒数代表所有客户损失，会让指标失去业务含义。

把恢复时间拆成阶段

生产演练可记录发现、决策、隔离、数据准备、重放、校验、入口切换、业务验收。每一阶段保留起止事件与证据，最后用连续总时间表示用户受影响范围。若阶段重叠，要说明并行关系，不能把所有阶段最短值相加构造一个没有实际运行过的总数。

容量还会改变阶段占比。小库可能启动和控制面等待占主要时间，大库可能导入与建索引占主要时间。仅把本书订单数增加十倍，不一定能模拟生产IO、长事务与并发连接。容量演练应尽量保持数据分布、索引、硬件和实际恢复工具一致，结果才有可用参考。

失败也要进入指标记录

一次恢复因日志缺失失败，不能从统计中删除后只报告成功平均值。应该记录目标不可达、可恢复到哪个较早边界，以及追加修复需要什么输入。失败概率和最长恢复时间往往比平均成功耗时更影响承诺。连续多次演练的变化也能暴露工具升级或数据增长带来的退化。

本书先经历缺少mysqlbinlog和复制重连退避两个真实CI失败，再修复并重跑。它们说明文档中的命令必须在目标环境执行。成功证据与失败原因共同帮助建立手册，但最终Release只使用完整成功流水线工件，避免把失败时生成的部分文件当成正式交付。

指标改进需要对应措施

如果RTO主要消耗在获取备份，改善存储位置、预置环境或并行读取可能有效；如果主要耗在核对，优化规范化摘要和分块定位可能有效；如果RPO来自异步未接收窗口，需要改变确认与复制策略，而不是仅加快导入。措施必须对应已测瓶颈，否则只是换一个更复杂的工具名称。

任何提高可用性的改动都应重跑隔离与丢失负例。更快提升可能缩短等待，却增加旧主仍可写的风险；更积极保留日志可能增加磁盘压力；更强同步可能影响延迟与可用性。把收益与故障边界放在同一演练报告中，团队才能做清楚的工程选择。

写出一份可用的承诺

用一句话描述失败场景、保护范围、恢复终点和必要条件，再附最近演练记录。比如在单主故障且隔离控制面可用时，以某副本明确水位恢复数据库写服务，已知丢失集合需业务对账。它比“高可用、秒级恢复、零丢失”更长，却能指导下一次真实操作。