TLS 1.3升级引发隐性故障：高可用不等于弹性

一个团队为满足合规要求，将公网入口负载均衡器升级至TLS 1.3，上线过程未出现异常信号：握手正常完成，服务保持健康，各项指标平稳。但随后用户流量被透明地重新路由到数千公里外的另一个区域，受影响地区延迟急剧上升，故障转移区域被迫扩容以应对未预估的负载。

问题根源在于控制平面：Route 53的HTTPS健康检查要求目标端点必须支持TLS 1.2，禁用TLS 1.2仅保留TLS 1.3后，健康检查器无法完成握手，将该端点标记为不健康。CDN据此判定该区域不健康并停止路由流量。而在该区域内部，服务在线、负载均衡器状态健康、应用持续处理请求，仪表盘没有任何异常，唯一可见的症状是流量不再流入。

合成监控最终发现了内部遥测系统无法捕捉的异常模式，实际问题约花了四十分钟才定位。故障并非发生在应用数据平面，而是发生在决定流量去向的控制平面。系统具备高可用性，却不具备弹性。

文章指出，高可用性面向预期故障，以最小中断应对实例崩溃、可用区故障等架构预设场景；弹性则要求系统从设计时未预料到的异常中恢复。现代云平台让高可用实现相对容易，但真实事故很少完全符合假设，一条从未演练过的故障切换路径算不上恢复策略。弹性问题既是架构问题也是组织问题，多数组织对可用性归属明确，却少有组织为恢复工作建立同等结构，缺乏指定的恢复负责人、定期演练和手册更新流程。