TLS 1.3升级致控制平面故障转移失效

作者指出高可用性（High Availability）与弹性（Resilience）常被混淆，前者针对预期故障，后者针对未预料场景。一个典型事故是团队将负载均衡器升级为仅支持 TLS 1.3，导致依赖 TLS 1.2 的 Route 53 HTTPS 健康检查失败。CDN 判定区域不健康并停止路由流量，尽管应用数据平面运行正常且仪表盘无异常，用户却遭遇数千公里外的延迟激增。 该案例暴露了控制平面（Control Plane）的结构性风险：决定流量去向的系统（如 DNS、健康检查）往往比数据平面更脆弱。许多全局服务（如 AWS STS）存在区域依赖，若检测组件降级，故障转移机制本身就会失效。此外，组织层面缺乏专门的恢复负责人和定期演练，导致手册过时、权限漂移，使得恢复路径在真实压力下腐化。 针对此类问题，作者对比了基于 DNS 的传统故障转移与 AWS ARC（应用恢复控制器）。DNS 方案成本低但受限于传播延迟和控制平面依赖；ARC 以秒级切换和准备状态检查提供更高信心，但增加了运维复杂性。务实策略是对关键路径采用分层方法，结合两者优势，并将恢复视为需要持续维护的工程任务而非静态属性。