1. 课程导入与故障演练认知
Redis 在生产环境中往往承担缓存、会话、排行榜、分布式锁、消息队列等关键职责。它一旦出现主节点宕机、主从切换失败、内存打满、热 Key 拖垮实例、持久化阻塞或集群分片失衡，故障会沿着调用链迅速放大，最终表现为接口超时、订单失败、页面白屏甚至数据不一致。因此，本课程关注的不是"Redis 命令怎么用"，而是当生产故障真实发生时，团队能否在有限时间内完成发现、定位、止损、恢复、复盘这一整套动作。
故障演练（Chaos Drill / Game Day）正是把这种能力提前"练出来"的手段。它的核心目标不是制造事故，而是在可控、可观测、可回滚的前提下，主动注入 Redis 相关故障，验证监控告警是否灵敏、应急预案是否有效、人员分工是否清晰、恢复时间是否达标。演练的价值在于把"纸面预案"变成"肌肉记忆"：当真实故障来临时，团队不需要现场讨论方案，而是按既定角色和步骤执行。
演练与恢复工程的整体框架
恢复工程可以理解为一条从"故障注入"到"能力沉淀"的闭环链路。它包含五个关键环节：演练设计（确定故障场景、影响范围、成功标准）、故障注入（在受控环境或生产灰度中触发故障）、观测与判定（通过监控指标判断故障是否被及时发现）、恢复执行（按预案完成止损与数据修复）、复盘改进（沉淀为新的预案、告警规则和自动化脚本）。这条链路不是一次性的，而是每轮演练后都会更新下一轮的输入。
核心原则：安全、真实、可度量
演练不是"随便搞一下"，必须遵守三条核心原则。第一是安全可控：任何注入都必须有明确的爆炸半径（Blast Radius）和回滚方案。例如，在生产环境演练主从切换时，应选择从库延迟低、业务低峰期、且已确认哨兵配置正确的实例；如果演练涉及数据写入，必须提前准备好数据校验脚本。第二是贴近真实：故障场景要来源于真实事故或高风险路径，而不是为了演练方便而设计的"假故障"。比如"Redis 主节点被 kill -9"比"手动执行 shutdown"更接近真实宕机。第三是可度量：每次演练都要记录 MTTD（平均发现时间）、MTTR（平均恢复时间）、告警准确率、预案执行完整度等指标，否则无法判断能力是否提升。
恢复工程的关键角色与协作
恢复工程不是一个人的事。典型演练中需要四类角色：演练指挥负责决策注入时机、范围和终止条件；SRE/运维负责执行故障注入、操作 Redis 集群、执行恢复预案；研发/业务负责确认业务影响、执行降级或限流、验证数据一致性；观察员/记录负责记录时间线、决策点和异常现象，输出复盘报告。角色可以一人多岗，但职责必须提前明确，避免故障发生时互相等待。
以一次"Redis 主节点宕机"演练为例，实际执行过程大致如下：指挥确认业务低峰期后下达注入指令；SRE 在目标实例上执行 kill -9 <redis-pid> 模拟进程崩溃；观察员记录注入时刻；监控系统应在 10 秒内触发"Redis 主节点不可达"告警；哨兵开始选举并提升从库为主库；研发确认业务接口是否出现超时或错误；SRE 检查新主库的 INFO replication 输出，确认从库已同步；最后指挥宣布演练结束，团队进入复盘。整个过程的关键不是"有没有切换成功"，而是"切换过程中业务是否可感知、告警是否及时、恢复动作是否按预案执行"。
down-after-milliseconds、failover-timeout 等参数符合预期。如果 down-after-milliseconds 设置过大，故障发现会延迟；设置过小，则可能因网络抖动误判。建议在演练前用 CONFIG GET 核对关键参数，并记录基线值。
从演练到恢复能力沉淀
一次演练的结束，恰恰是恢复工程迭代的开始。复盘时要回答几个问题：告警是否在预期时间内触发？预案中的命令和步骤是否可直接执行？角色之间是否存在信息断层？数据是否出现丢失或不一致？根据答案更新三样东西：告警规则（阈值、抑制、升级策略）、恢复预案（命令、判断条件、回滚步骤）、自动化脚本（一键切换、数据校验、流量摘除）。下一轮演练再验证这些更新是否有效，形成"演练—复盘—改进—再演练"的正向循环。