无聊的故障转移胜过聪明的故障转移
那些依赖控制平面健康的恢复计划，往往在最关键的时刻掉链子。
去年我们花了大量时间收拾一次失败的故障转移。这次事故本身并不特别——一个主区域宕机，自动化预案启动，三小时后流量恢复到了备用区域。但原本预期三十分钟就能搞定的预案手册，硬生生拖到了五十分钟，因为负责协调故障转移的控制平面就部署在刚刚宕机的那个区域里。
这就是我不断看到的问题：那些「聪明」的故障转移设计，都假设指挥流量的调度机制不会受到导致主工作负载宕机的那个故障的影响。画架构图时很容易做出这个假设——控制平面盒子画在边上，用虚线连接，看起来很重要但又似乎独立。
但在实践中，那些虚线是 TCP 连接，会超时；控制平面运行在和 etcd 已经失去仲裁的同一个 Kubernetes 集群上；DNS 更新接口又被上游限速，供应商根本不知道你现在正在经历紧急情况。
复盘中的发现
- 编排层启动不了，因为它需要访问一个位于故障区域的数据库。
- DNS 传播预计五分钟，实际花了四十二分钟，把十分钟的故障转移拖成了五十分钟。
- 预案手册里有一行命令指向一台两年前就已经退役的服务器。
我们的建议
- 优先降级而非编排。减少承载流量的区域数量，几乎总是比启动一套恢复流程更可靠。
- 确保恢复流程依赖的组件不超过一两个，并把它们写下来。
- 定期对真实路径进行演练，然后根据演练结果修复预案手册。
目标就是让故障转移变得足够无聊，以至于没人需要为此半夜爬起来。