高可用架构的故障域设计避坑实录

上周陪朋友处理完线上事故，凌晨三点在机房楼下的便利店买冰可乐，他还在骂运维组的人脑壳不清醒，把同一可用区的三个支付实例全塞在同一个机柜里。施工队挖断光纤的那一秒，整个支付链路直接挂了47分钟。

没人喜欢出事。

但你总不能每次都指望施工队挖光纤的时候刚好绕开你家的机柜，也不能指望云厂商的运维永远不会手滑敲错一条配置命令。很多团队天天把高可用挂在嘴边，真到做故障域设计的时候，全是纸上谈兵。

别把故障域当成纸上的隔离标签

故障域说白了就是一旦某一环出问题，会被连带搞挂的最大范围。很多人对故障域的理解还停留在“多买几个云主机，分布在不同的可用区”，架构评审的时候PPT上画个彩色的拓扑图，就敢说自己做了全链路隔离。

上次那个朋友的团队就是，PPT上明明白白写着三个可用区跨机房部署，没人去查底层的BGP出口是不是走的同一条运营商链路，也没人去问三个机柜的光纤是不是走的同一个地下管道。真出事的时候，三个可用区的实例全成了摆设，流量根本切不出去。

更坑的是逻辑层面的故障域。比如你们所有服务都依赖同一个配置中心，一次错误的灰度配置推下去，哪怕你把实例拆到全球各个角落，也一样会被同时打挂。我之前见过一个做短视频的团队，因为配置中心的权限没做隔离，一个实习生误删了核心的CDN配置，结果所有区域的用户都刷不出视频，连备用节点都因为同步了错误配置直接失效。

说实话，很多人做故障域设计的时候，只盯着看得见的物理资源，完全忽略了那些藏在链路深处的公共依赖。这不是设计，是自欺欺人。

真实业务里的故障域从来不是一刀切

我见过太多极端案例了。要么是为了省钱，所有服务全塞在同一个可用区的同一个机柜里，出一次事直接回到解放前；要么是为了追求所谓的“完美隔离”，把每个微服务都拆成10个独立的故障域，运维成本直接翻了三倍，每次发版要走10套审批流程，业务迭代慢到被竞品抢了半壁市场。

故障域的隔离粒度，从来都是和业务优先级绑定的。

你做电商的，核心链路是下单、支付、库存扣减，这些环节的故障域就得拆到极致——得跨机房，得跨机柜，甚至跨运营商，连底层的DNS解析都要做双供应商冗余。至于非核心的链路，比如用户评价、商品收藏、历史足迹，哪怕几个服务共用同一个故障域也没关系，真出问题的时候，大不了先把这些功能降级停掉，根本不影响核心交易。

之前有个做本地生活的客户，一开始为了省成本，把商家的核销系统和用户端的推荐系统放在同一个故障域里，结果推荐系统的一次缓存雪崩，直接把核销接口打挂，商家中午高峰期没法核销，当天被投诉了上千单。后来他们把核销系统的故障域拆出来，单独做了物理隔离，哪怕推荐系统全挂，核销功能照样能正常跑。

对吧？资源永远是有限的，你不可能把所有功能都按最高级别的隔离来做，把钱花在真的能影响营收的核心链路上，才是正经事。

落地的时候别漏了这些容易踩的暗坑

很多人觉得故障域设计完就万事大吉了？错。

先把所有依赖的公共服务列个清单，看看哪些是你自己控制不了的。比如你用的云厂商的对象存储，要是它出故障的时间超过10分钟，你有没有备选方案？之前有个团队把所有的商品图片都存在同一个云厂商的OSS里，结果OSS出了3小时的故障，整个电商平台的商品图全裂了，他们连个备用的存储都没有，只能干等着。

别光做设计，一定要做混沌演练。上次那个朋友的团队，之前从来没模拟过单机柜故障的场景，真出事的时候，流量调度策略根本没考虑过这种情况，切流量切了20分钟才搞定。后来他们每个月都做一次混沌演练，随机抽一个机柜、一个交换机、甚至一条配置链路，模拟故障，现在真出问题的时候，3分钟就能切完流量。

故障域的边界要和运维的值守范围绑定。别把一个故障域拆得跨了好几个运维小组的负责范围，真出事的时候，你都不知道该找谁来处理。之前有个团队的故障域设计得特别复杂，跨了三个云厂商、四个机房、两个运营商，结果出问题的时候，三个厂商的运维互相甩锅，扯了半小时才找到到底是哪一环出的问题。

不过话说回来，谁也不想天天处理线上事故。但你总不能指望运气永远站在你这边。

下次做架构评审的时候，别光看PPT上的漂亮图，拉着运维去机房数一遍机柜号，查一遍所有公共依赖的SLA，花半天时间做一次随机故障演练。这些事看起来费时间，真出大事的时候，能帮你省下来的，可能是几百万的营收损失，甚至是整个团队的年终奖。