高可用不等于弹性：云系统为何在关键时刻失效

我曾共事过的一个团队，为满足合规要求，将公网入口负载均衡器升级到了 TLS 1.3 "。整个上线过程没有出现任何异常信号：握手正常完成，服务保持健康，一切指标也都平稳。 在撰写本文时， Route 53 HTTPS 健康检查 "要求目标端点必须支持 TLS 1.2。如果禁用了 TLS 1.2 且仅保留 TLS 1.3，健康检查器将无法完成握手，并将该端点标记为不健康。CDN 因此判定该区域不健康，并停止将流量路由到该区域。 在该区域内部，一切看起来都很正常。服务在线，负载均衡器状态健康，应用程序持续处理请求，仪表盘没有显示任何异常。唯一可见的症状是流量不再流入。 用户流量被透明地重新路由到了数千公里之外的另一个区域。受影响地区的延迟急剧上升。故障转移区域开始扩容，以便应对未曾预估的负载。合成监控最终发现了内部遥测系统无法捕捉到的异常模式。实际问题大约花了四十分钟才定位到。故障并非发生在应用数据平面，而是发生在决定流量去向的控制平面。 系统具备高可用性，但并不具备弹性。 这一区别的重要性远超大多数云架构所认知的程度。在实践中，这两个术语经常被互换使用，即使在工程文化很强的团队中也是如此。然而，它们描述的是不同的问题，有着不同的前提条件。高可用性是指以最小的中断来应对预期故障，而弹性则是指系统能从当初设计时并未明确预料到的异常场景中恢复。造成概念混淆的部分原因在于，可用性可以用正常运行时间百分比、故障转移时间和复制延迟等指标来衡量。弹性则很难用这种方式来衡量。许多故障模式只有在真实压力下才会暴露。有意义的恢复测试往往过于昂贵或风险过高，难以刻意重现。 可用性与弹性不是同一个问题 现代云平台让高可用的实现变得相对容易。一个具备多可用区故障转移的托管数据库、负载均衡器后方的自动扩缩容组，以及前置的 CDN，就能帮助大多数系统实现可观的正常运行时间。当故障局限在架构预设的场景内时——例如实例崩溃、可用区故障或依赖服务超时——这些标准方案效果很好。 问题在于，真实的事故很少完全符合这些假设。高可用性工程假设故障是孤立的且可预测的，而工程的出发点恰恰相反：最终某些关键组件会以没人建模过的方式发生故障。仅靠冗余无法抵御故障。一条从未演练过的故障切换路径，算不上恢复策略，它只是一个假设。下面三种典型场景直观体现了二者的差别。 跨冗余实例的关联故障 现代高可用性确实考虑到了一部分关联性故障，比如多可用区，它明确建模了整个可用区同时宕机的场景。但它没有考虑软件层面的关联性，例如向所有副本同时推送错误配置、所有读副本返回脏缓存记录、依赖库升级后悄悄破坏整个系统依赖的契约。一旦组件之间的独立性在这个层面被打破，冗余就不再是安全保障。 并非真正优雅的优雅降级 大多数系统都假设可以优雅降级，但很少在真实负载下测试过。当读副本的延迟在压力下持续增加时，缓存层是分担压力还是把压力放大压垮主库？没有经过演练前，优雅降级只是猜想，而非保证。 逐渐失效的恢复路径 系统已经运行了两年，在编写重建手册时，当前一半的依赖项还不存在。IAM 策略已经发生漂移，部署工具已经发生变更。恢复路径和其他代码路径一样，长期不用，就会腐化失效。 组织层面的问题在事故发生前早已存在 弹性问题既是架构问题，也是组织问题。架构问题更容易获得关注。画图表比落实运维责任容易得多。 我观察到一个反复出现的问题：即使可用性的归属责任很明确，恢复工作的归属权也往往模糊不清。大多数组织对可用性的归属很明确，比如值班轮岗、SLO 和升级渠道，但很少有组织为弹性建立同等的结构。没有指定的恢复负责人，没有定期的测试演练，也没有在基础设施演进过程中保持手册更新的流程。这个差别很少是刻意的决策，而是无人认领责任后自然形成的默认状态。 让这个差距持续存在的部分原因是弹性的建设成本十分高昂。测试真正关键的场景需要专门的工程时间，承担运维风险，以及一套只为大概率不会触发的灾难准备的基础设施。结果就会走入表演式弹性：架构图看起来是对的，备用区域存在，手册也存在，但实际的恢复能力只是假设，没有经过验证。这不是因为工程师粗心，而是因为严格验证需要真金白银、承担真实风险，且其价值只会在最不利的时刻体现。 在实践中，重大事故的前三十分钟往往浪费在梳理依赖关系上。员工发现权限已经漂移，手册引用的工具一年前就已退役，没人确定还有谁了解备用的环境。这些问题并不特殊，只是常规运维损耗。恢复路径因为极少演练而慢慢失效。 解决方案并不花哨，需要独立于值班体系的恢复负责人。值班负责事故响应，恢复负责人负责事前准备，包含流程、工具，以及保持两者持续更新的责任。如果把二者混为一谈，你会得到优秀的事故指挥官和十八个月没人打开过的操作手册。 恢复能力强的团队将故障转移演练视为一项持续的工程任务。他们从小处着手，先针对单个服务和单个可用区切换。每次演练都会发现一些问题，比如被撤销的权限、过时的手册或静默的告警。你通过执行流程来发现这些问题。这种转变是将恢复视为需要持续维护的东西，而不是架构图上默认自带的属性。 关于恢复能力的五个问题 想要开始测试弹性，不必重新设计整套架构，可以从以下五个问题开始： 最先失效的是什么？识别恢复路径依赖的控制平面组件：DNS、身份认证、路由、证书、配置、编排系统或是第三方服务。团队实际会观测到什么？针对每个故障场景定义异常信号。如果故障发生在请求抵达应用之前，应用面板显示正常绿色是不足以发现问题的。你能执行恢复流程吗？测试真实的执行机制，而不是只看图评审。如果故障切换依赖 DNS 变更、路由决策、控制平面 API，就要在贴近真实的环境下演练这条路径。谁负责恢复？值班工程师负责事故响应，但需要专人持续维护恢复机制、操作手册、依赖组件与相关测试。上次测试之后发生了哪些变更？记录故障点、意外现象、哪些假设被证明是错误的。把这些发现转化为工程任务，而不是仅仅留在事故笔记里，弹性才能得到改善。 目标不是测试所有可能的故障，而是定期挑战支撑恢复流程的各项假设，并将验证结果落地为系统变更。 架构图上不会画出的控制平面陷阱 大多数关于云故障转移的讨论集中在数据平面，即流量去向、哪个区域处理请求、实例宕机时会发生什么。而控制平面——决定流量应该流向何处的系统——得到的关注远少得多。上述的 TLS 1.3 事故正是这种差距直接导致的。 数据平面运行完全正常，控制平面却出了问题。 你无法从服务内部看到这一切。服务和负载均衡器都是健康的，但流量就是没有到达。合成监控显示了一种内部遥测无法捕获的差异，因为内部遥测只观察数据平面。故障只能从外部通过本身也是控制平面一部分的监控基础设施看到。 这就是控制平面依赖带来的结构性问题。正常运行时，它们是隐形的。大家不会把 CDN 健康检查看作服务的一部分，只会当成监控。但是，控制流量准入的监控属于业务链路的一环，哪怕它存在于控制平面中。一旦它发生故障，数据平面完好，服务却无法访问。 这种模式在云服务的各个领域反复出现。AWS STS 就是一个明显的例子。全局端点 sts.amazonaws.com “托管在单个 AWS 区域——美国东部（弗吉尼亚北部）。与其他端点一样，它不会自动故障转移到其他区域的端点”， AWS 文档明确指出了这一点 "。许多表面上的全局服务都带有区