前段时间看到一个案例，某团队做合规升级，把入口负载均衡切到了 TLS 1.3，禁用了 1.2。上线过程一切正常，握手成功，服务健康，仪表盘全绿。

然后流量没了。

原因很隐蔽：他们用的 CDN 健康检查要求目标端点支持 TLS 1.2。禁了 1.2 之后，健康检查握手失败，CDN 判定整个区域不健康，静默地把流量全部切到了几千公里外的备用区域。从服务内部看什么都正常——服务在线，负载均衡健康，应用还在处理请求，只是没人注意到进来的请求已经没了。

这个故障花了四十分钟才定位。不是因为团队能力不行，而是因为故障不在他们能看到的地方。

高可用和弹性，真不是一回事

这个案例让我想明白了一件事：很多团队把“高可用”和“弹性”当同一个词在用，但它们其实是两种完全不同的问题。

高可用解决的是预期内的故障——实例挂了、可用区宕了、依赖超时了。这些场景都有成熟方案：多可用区、自动扩缩容、故障转移。做对了这些，大部分系统能拿到不错的运行时间。

弹性解决的是另一类问题：当初设计时根本没想到的场景。比如健康检查协议没适配新版本把自己切走了，比如一次配置推送同时影响了所有副本，比如恢复路径上依赖的工具一年前就已经下线了。

冗余挡不住这类问题。因为在软件层面，组件之间的独立性被打破了，再多的副本也没用。

我之前见过一个类似的事：某个团队花了不少精力做了监控全覆盖，告警规则、Dashboard、值班轮转一应俱全。后来某次升级改了告警规则的数据格式，几条关键告警静默失效了两个星期。不是没配监控，是监控系统自身的一致性没人验证。表面上全覆盖，实际上最关键的那几条没在报。

看不见的东西最先出问题

前面那个 TLS 的案例，还有一个值得注意的地方：故障出在控制平面，不在数据平面。

所谓控制平面，就是那些决定“流量该去哪”、“谁有权限访问”、“配置怎么下发”的系统。正常运行时它们几乎不可见，不会出现在服务依赖图里，也不会在架构评审时被重点讨论。

但控制平面出问题时，数据平面再健康也没用。CDN 健康检查把流量切走了，服务内部一片祥和，没人知道外面已经没人能访问了。事后还发现：CDN 把整个区域流量切走时没触发告警，负载均衡入站流量归零也没告警。两个关键指标全程静默。

我自己在项目中也踩过类似的坑。之前有个内部配置中心，写入端做了多活，但下发端依赖了一个只在单机房部署的消息推送服务。配置写得进去，但推不到业务节点。那个机房的网络抖动了十五分钟，所有新配置都下不去了。已经跑着的服务不受影响，但新上的灰度和开关变更全部延迟。事后排查才发现，没人把配置下发链路当成关键路径保护过。

控制平面的依赖就像建筑的地基。图纸上不一定会标注地基用了什么标号，但地基出了问题，上面的楼层再结实也没用。

弹性没人领

很多团队在架构层面做得不少，多可用区、故障转移、备份策略都有。但弹性真正卡住的往往不是架构，是组织。

最典型的问题是所有权模糊。高可用通常有人管——值班表在那，SLO 在那，出了问题有人响应。但弹性不一样：谁负责维护恢复手册？谁负责定期演练？谁负责在基础设施变更时同步更新依赖关系？

大部分团队的答案是：不知道。或者说“大家都在管”，实际上等于没人管。

我见过一个场景：一份故障恢复手册半年没人更新过，因为当初写这个手册的人已经转岗了。手册里列的某个依赖服务早已下线，但没人知道，因为没人“拥有”这份手册。后来有一次真需要做故障切换，操作到那一步才发现走不通，整个恢复流程卡在了一个没人预想到的环节。

还有一个团队做过一次全链路故障演练，结果发现恢复手册里提到的三个内部工具，有两个因为安全策略变更已经不能用了。工具一年前就被新的安全策略禁掉了，只是平时没人去用所以没人发现。

恢复路径会腐化。跟代码一样，长期不跑就会失效。区别是代码失效有报错，恢复路径失效没有——只有在事故中真正执行时才会发现走不通。

表演式弹性和真弹性

有一个判断方法，我觉得挺准的：做过真弹性的人和只在 PPT 里画过弹性的人，聊几分钟就能分辨出来。

没做过的人把弹性当属性。“我们多可用区、有备份、有故障转移，所以我们是有弹性的。”就像买了一张健身卡，然后说自己有健身习惯。

做过的人把弹性当能力。他们会告诉你上次演练时发现了什么、哪些假设被推翻了、哪些手册需要重写。就像真去健身的人会说上周练腿的时候发现左边膝盖有点不对。

这两种态度在架构评审中体现得很明显。前者看到“双活架构”的图就放心了。后者看到同样的图会问几个很具体的问题：切换决策谁来做？上次验证切换是什么时候？切换依赖的第三方服务有没有单点？如果检测切换的组件自己挂了怎么办？

这不是谁更聪明的问题，是有没有真正做过的问题。做过的人知道，架构图上画得再漂亮，真到切换那一刻，什么意外都可能发生。

比较务实的做法

我自己觉得比较可行的思路是：不用追求验证所有可能的故障，而是定期挑战支撑恢复流程的关键假设。

每次演练一定会发现一些之前没注意到的东西——被撤销的权限、过时的手册、没人维护的告警规则、被遗忘的第三方依赖。这些发现就是弹性的真正来源。不是架构设计，是这些琐碎的、不起眼的、没什么技术含量的维护工作。

还有一个观察：弹性好的团队，通常会指定一个专门的“恢复负责人”，跟日常值班分开。值班负责当下响应，恢复负责人负责事前准备——维护手册、更新依赖、组织演练。如果这两个角色混在一起，你会得到很好的事故指挥官，和一份十八个月没人打开过的手册。

说到底，弹性跟其他工程能力一样，不是一次性投入，是持续维护的习惯。只是它的回报只有在最糟糕的时刻才看得到——这让它在所有优先级排序中天然吃亏。什么时候开始练不重要，重要的是别等到那一天真来了，才发现手里那份手册已经过期了。