第18章：把一次恢复练习变成持续可交付的能力
读完命令并成功跑过一次，只完成了起点。数据库版本会升级，数据会增长，权限会收紧，备份位置和密钥服务也会变化。恢复能力需要随着这些变化重新验证。本章把书中的实验、证据与出版流程连接起来，形成一套可以持续复用的演练工作方式。
先保存一份最小恢复清单
清单应列出目标故障、业务保留集与排除集、备份标识、日志范围、工具版本、目标环境、写入隔离方法和验收条件。每个字段都能对应实际文件或操作。不要把“由资深同事确认”当作唯一恢复依据；经验可以帮助判断，但关键结果应留下其他人能复核的证据。
随书程序体现了这个清单的可执行部分：随机独占资源、固定软件来源、实际备份导入、封口归档、停源回放、GTID等待、真实只读拒绝、隔离后提升和完整业务比较。它没有把手册所有内容自动化，尤其没有实现生产业务确认与外部路由，但实现范围是清楚而可重复的。
版本变化触发重新演练
升级MySQL客户端可能改变默认参数或输出字段，服务器升级可能影响复制认证与日志格式。固定digest避免无意变化，不代表永远无需升级。升级时应主动选择新版本，核对官方变化说明，再完整执行场景和负例。只把镜像标签改成latest然后观察能启动，不足以证明恢复能力延续。
业务结构变化也应触发更新。新增外键、事件、加密列或跨库事务后，原来的简单账本检查可能不覆盖新风险。应为每个重要业务对象添加可验证样本，确认备份包含它、恢复能重建它、回放保留正确顺序。验证器不是一成不变的证书，而是随着业务共同维护的代码。
独立实验包防止隐藏依赖
源码目录里可能留有本地文件，使实验看似完整。正式构建把所有实验脚本、工具Dockerfile和说明打入ZIP，解压到新临时目录，再运行完整真实四实例实验。十个场景必须全部PASS，没有跳过。这个检查直接证明读者下载的包具备运行所需文件，而不是仅检查ZIP里有几个熟悉的文件名。
包不包含镜像和客户端RPM，这些从固定官方地址获取并校验来源。网络或地址不可用时实验失败，不能假装离线可用。若生产恢复要求完全离线，应把验证过的软件放到独立可达仓库，并把获取失败纳入演练。本书的下载依赖已明确写入实验说明。
正式证据来自同次发布
完整CI先执行真实实验，保存validation.json，再生成网页、EPUB和实验包，检查内容与导航，执行EPUBCheck和浏览器验收。发布到Pages的目录与创建Release所用的book-downloads来自同一个成功运行。公开下载后重新计算摘要，确认读者拿到的EPUB与CI工件字节相同。
后续交付说明使用不触发构建的文档提交，避免仅更新报告就重新生成一个未经过同样发布核验的EPUB。若正文或代码需要修改，则走新的完整流水线和补丁版本，不覆盖旧Release资产。这个纪律保存了“哪份书对应哪次实验”的可追溯关系，读者也能回到自己下载的版本。
演练频率由变化与风险决定
可以定期运行，也应在大版本升级、备份策略改变、权限调整和重大业务迁移后运行。周期不必机械一致：高价值账务可能需要更密集的恢复抽查，低频配置库也需要覆盖密钥和人员变化。关键是不要等事故发生才第一次验证新的恢复路径。
演练应轮换执行人员。让没有写过原脚本的人根据说明重做，能发现隐含知识与模糊步骤。将失败记录转成具体改进，例如增加归档缺口检测、明确只读错误断言或补充重连预算。避免只记录一次成功截图，下一次仍依靠同一个人临场判断。
守住破坏性操作范围
恢复练习可以逼真，但破坏必须可控。任务资源随机命名、端口不公开、清理只针对本次创建对象，是本书的基本约束。生产规模预演应使用脱敏数据与独立环境，若需要生产演练，则建立与业务授权匹配的更严格流程。不能把教学中的公开口令、root管理和容器停止直接搬过去。
最值得保留的习惯，是每次都先问这一步将证明哪项业务事实。备份文件存在证明输入可定位，日志连续证明范围可能重建，隔离证明写入权明确，恢复核对证明目标状态达成。把这些事实连起来，恢复能力才会从一句承诺变成可以反复交付的工程结果。