容灾演练必须围绕rto和rpo指标展开，覆盖接入、业务、存储三层故障验证，并在隔离环境中闭环问题、优化预案。

容灾演练不是走流程，而是验证系统在真实故障下能不能活下来。重点不在“有没有备份”，而在“切换是否自动、数据是否一致、业务是否感知”。

明确RTO和RPO指标再动手

没目标的演练等于无效测试。RTO（恢复时间目标）决定你最多能停多久，比如支付服务要求RTO≤5分钟；RPO（恢复点目标）决定你能丢多少数据，比如订单库RPO必须为0或≤15秒。这些数值直接决定你用什么技术：MySQL异步复制RPO可能达分钟级，强一致场景就得上半同步或分布式数据库（如TiDB）。所有演练动作都要围绕这两个数字展开，不能模糊说“尽快恢复”。

搭建隔离但等效的演练环境

严禁在生产环境直接断服务。推荐三种方式：

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

• 用KVM或Docker快速拉起一套与生产同构的模拟集群，包括相同版本OS、内核参数、网络拓扑和中间件配置
• 通过Ansible批量部署，确保配置零偏差；把最近一次全量备份+增量日志导入演练环境，验证可恢复性
• 资源紧张时可用“影子演练”：非高峰时段将1%流量切到备用站点，观察API响应、日志采集、监控告警是否正常

按故障类型分层验证关键链路

只重启服务不算演练。要覆盖三层核心环节：

• 接入层：手动关闭主Keepalived节点，看VIP是否3秒内漂移到备机，curl访问是否无中断；模拟网络分区，验证脑裂防护（如Pacemaker的fencing是否触发强制关机）
• 业务层：kill掉一个Pod或进程，确认Kubernetes是否30秒内拉起新实例，且从Redis加载Session不丢失；故意注释掉某段代码引发panic，看熔断机制是否生效
• 存储层：对主库执行pg_ctl stop -m immediate，验证Patroni是否30秒内完成failover；删掉从库的WAL归档目录，确认主库binlog同步是否持续、无中断

每次演练必须记录并闭环问题

演练不是终点，而是优化起点。过程中要记清三件事：

• 每个步骤实际耗时（比如VIP漂移花了2.3秒，但应用重连用了8秒——说明DNS缓存没清理）
• 暴露的依赖盲点（如切换后发现Nacos配置中心没同步，导致新实例读不到路由规则）
• 权限与协作卡点（比如执行sys_ctl promote需要sudo权限，但运维账号没配，靠临时找DBA耽误2分钟）

演练后48小时内更新切换checklist，把人工操作封装成Ansible Playbook，并把新发现的故障场景加入ChaosBlade注入清单。每季度至少做一次全链路演练，别让预案躺在文档里睡大觉。