去年双11前一周的凌晨两点，我在公司茶水间灌第三杯冰美式的时候，运维的哥们冲进来拍我肩膀，说刚压测的核心下单链路，挂了。
不是那种小抖动。是整个华东可用区的专线光纤被施工队挖断，连带同机房的支付回调服务直接超时30%。
最绝的是，我们之前拍胸脯说做了多可用区容灾，结果流量切到备用区的时候，发现所有的库存扣减服务，居然和故障区的订单服务绑在同一个物理交换机下。
扯什么高可用。全白搭。
你以为的隔离，其实只是换了个名字的单点
很多团队做高可用的时候，第一反应就是买云厂商的多可用区资源，把服务实例往不同可用区一塞，就拍胸脯说我们做了容灾。
真不是。
我去年帮一个做本地生活的客户做架构巡检，翻完他们的部署拓扑直皱眉——三个可用区的服务实例确实打散了，但是所有的配置中心、链路追踪Agent、甚至连机房的出口防火墙策略，全是挂在同一个可用区的公共集群上。换句话说，只要那个公共集群出问题，三个可用区的服务根本拉不到正确的配置，连启动都成问题，谈什么容灾。
说出来好笑对吧？你花了几百万搭的跨可用区集群，可能败在一年几千块的公共依赖上。
很多人对故障域的理解有偏差，觉得故障域就是把服务切成几块，每块独立运行就行。根本不是。故障域的核心从来不是你把服务拆成多少个实例，而是要算清楚——一旦某个环节出问题，你的影响范围到底会蔓延到哪里。你以为的隔离，可能只是把同一个故障的影响范围，从一个机柜挪到了同一个机房的三个机柜，本质上还是单点。
划故障域别拿清单硬套，要顺着故障蔓延的路径走
之前我也见过很多团队，拿着网上的最佳实践清单划故障域，按可用区划，按机房划，按服务模块划，划完就锁在文档里再也不看。结果真出故障的时候，发现漏了八丈远的依赖。
上次我们团队重构核心链路的故障域边界，没找什么外部专家，拉了前后端、运维、DBA、甚至驻场的IDC工程师开了整整一下午的会，把整个下单链路的每个节点全列出来——从用户点提交按钮开始，经过的CDN节点、WAF策略、负载均衡层、订单服务、库存扣减接口、支付回调、消息队列、数据库主从，甚至连机房的UPS供电节点、接入的运营商专线、第三方短信服务商的调度节点，一个都没漏。
列完之后我们才发现，之前的消息队列集群，三个节点居然分布在同一个机柜的三个相邻交换机下，只要那个机柜的空开出问题，整个消息队列直接堵死，用户付了款但是库存没扣，客服能被投诉电话淹了。
当时我们做的调整也简单：把所有核心依赖的节点，强制打散到至少三个独立的故障域里。比如订单服务的实例，分别放在三个不同的机柜，跨两个可用区，甚至其中一个轻量的核心节点，直接部署在离主机房20公里的边缘小机房——别觉得边缘机房破，真到主机房因为消防演习断网、或者市政施工挖断专线的时候，那点破机房的价值，比你花几十万买的高级监控告警系统都大。
这里一定要提个容易踩的坑：很多团队划故障域的时候，只算自己部署的服务，完全不算第三方的依赖。你用的云厂商Redis，主从节点是不是在同一个物理机柜里？你买的对象存储跨区复制，是不是同步延迟超过5分钟？你用的第三方登录服务，是不是所有节点都集中在同一个地域？这些东西你不问清楚，真出问题的时候，你以为的备份，其实和主节点绑在同一根线上。
别追求100%零故障，要算清楚兜底的成本账
我见过太多团队走极端。要么完全不做故障域隔离，所有服务堆在同一个机柜里，出问题就全链路崩；要么就是砸钱追求极端的跨地域多活，花了几千万搭完，结果平时从来没人演练，真出问题的时候切流量都切不动。
之前接触过一个做在线教育的团队，他们花大价钱搭了三地五中心的架构，结果去年碰到一次机房网络抖动，要切流量的时候才发现，两个中心的数据库数据差了快十分钟，根本不敢切，硬生生扛了40分钟的服务不可用。算下来那次故障损失的营收，比他们这套容灾架构一年的折旧费用都高。
真没必要。故障域设计从来不是为了让系统永远不出故障，而是要保证出故障的时候，你损失的钱，永远比你为了防这个故障花的钱少。
我们现在对核心交易链路的要求很简单：把单个故障域的影响范围，控制在5%的用户以内。也就是说，哪怕某个故障域整个炸了，剩下95%的用户完全感知不到，而且故障域之间的自动切换时间控制在10秒以内，根本不用半夜爬起来接告警电话。
别信那些卖解决方案的吹的什么五个九的可用性，你要是真能把核心链路的可用性做到三个九，在中小团队里已经能拍着胸脯跟老板要奖金了。每个季度抽个下午，随机选一个故障域把整个集群打挂，看看系统的反应，找找漏的依赖，比你写十页架构文档都有用。
上次和一个在大厂做了十年基础架构的朋友吃饭，他说见过太多团队，把高可用架构做成了PPT上的漂亮拓扑图，每个模块都标着高可用，每个链路都画着容灾，真出故障的时候，手忙脚乱找不到问题在哪。
其实哪有那么多复杂的道理。
你就把每个可能出问题的地方，都当成早晚会炸的炸弹。
然后拆弹。
别等炸到自己头上才后悔。