高可用架构的真实生存逻辑

去年618前一周的凌晨三点，我被生鲜客户的技术总监一个电话炸醒。

对方声音哑得像砂纸磨过，说压测跑到8000并发的时候，整个下单链路直接崩了。

我赶过去的时候。

满屋子的人都在抽烟。

屏幕上的报错红得刺眼。

别被SLA数字骗了

很多团队做高可用的第一步，就是把SLA写进项目PPT里，99.99%是起步，敢写99.999的都能在行业交流会上吹半小时。

但没人真的算过这笔账——99.99%的可用性，折算下来一年的允许宕机时间是52分35秒。要是这52秒刚好砸在大促零点的流量峰值上，按生鲜客单价40块算，一秒钟少接1000单，就是4万的直接损失，还不算用户流失的隐性成本。

电商大促凌晨压测运维现场截图

那个生鲜客户之前就是被这个数字坑了。他们花了六十多万买了大厂的多可用区部署方案，从网关到数据库全做了双活，PPT里的SLA标得比谁都高，结果压测的时候，缓存主节点切换的40秒里，所有下单请求全卡在了库存校验环节。

真的。

他们之前甚至连核心链路的监控都没做，等告警弹出来的时候，数据库连接池已经打满了。

冗余不是堆出来的

我当时站在他们机房的走廊里，看着墙上贴的”高可用誓师大会”的海报，差点笑出声。

这哪是做高可用，这是把钱往没用的地方堆。他们连用户头像上传的服务都搞了三个可用区的冗余，结果最核心的库存扣减逻辑，用的还是单库强一致事务，连个熔断都没加。

说实话，大部分团队对高可用的投入都搞反了优先级。冗余的投入必须和业务损失成正比，你一个内部OA系统，宕机三个小时都没人找过来，犯得着花几十万做多活？但你要是下单链路的核心服务，哪怕多花一分钱兜底都值得。

后来帮他们梳理核心链路的时候，我们直接把服务按优先级拆成了三档：P0是下单扣库存，P1是商品详情展示，P3是用户评价上传。所有的冗余资源全往P0倾斜，甚至给P0链路做了三级降级：第一级扣库存失败直接切本地内存兜底（哪怕偶尔超卖一点，大促时超卖的损失远比宕机小），第二级熔断非核心的优惠券校验服务，第三级直接砍掉备注、发票这些非必要字段，只留最核心的收货信息。

改完之后再压测，同样的8000并发，数据库连接池的使用率从100%直接掉到了32%。当时他们的技术总监拍着我肩膀说，之前花的那六十多万，还不如这几行降级代码管用。

不过话说回来，也不能全怪他。市面上太多卖高可用方案的厂商，上来就给你推全套的多活、冗余，根本不管你是什么业务体量，最后钱花了，坑还在。

别忘了人是最大的单点

很多技术方案聊到最后，全是服务器、数据库、中间件，好像把这些东西堆够了，系统就永远不会挂。

但我见过太多的宕机事故，最后栽的根本不是技术，是人。

之前有个做城配的客户，所有的运维操作权限都攥在一个资深运维手里。去年冬天那个运维发烧住院，刚好赶上系统扩容，整个团队等了三个小时才联系上人，那段时间系统负载已经冲到了92%，差点直接宕掉。

还有更离谱的，某个团队的告警通道直接绑在了已经离职的运维的企业微信上，数据库主节点挂了两个小时，没人收到告警，等用户投诉到客服的时候，损失已经上百万了。

故障演练是成本最低的高可用投入，这话我在多少个技术分享会上说过，就是没人真的听。很多团队一年到头都不做一次故障演练，真出问题的时候，连告警该发给谁都搞不清楚，更别说快速恢复了。

哦对，还有那个周五下午上线的破习惯。我见过太多团队，喜欢在周五下午改高可用的相关配置，结果出问题的时候，运维都在下班的地铁上，连VPN都登不上，只能眼睁睁看着系统挂一整个周末。

前几天和那个生鲜客户吃饭，他说今年618的时候，系统扛住了平时12倍的流量，整个过程只抖了三秒，用户根本没感知。

他现在再也不盯着PPT上的SLA数字看了，每次大促前就拉着团队过一遍核心链路，看看哪个点可能挂，提前把兜底的方案做好。

对吧。