他们家做小众设计师女装的，平时日活才两万多，当天冲了次设计师直播，峰值直接干到18万。后台崩了四十分钟。
客服被骂到差点集体提离职，算下来那四十分钟的直接损失，快抵得上他们小半个月的利润。
你以为的高可用，可能只是在交智商税
别误会，我不是说高可用不重要。
只是太多小团队一提到高可用架构，第一反应就是抄大厂作业：买多少台高配置云服务器，上K8s集群，开通多可用区部署，把能加的冗余全加上，钱花了一大堆，真出问题的时候该崩还是崩。
就说我朋友那个团队，去年年初就花了八万多配了跨可用区的负载均衡，结果那次崩溃的根因，跟机房容灾半毛钱关系都没有——是他们的库存扣减接口没做幂等处理，直播的时候用户疯狂点提交按钮，同一个库存扣减请求重复打了几百次，数据库的行锁直接被打满，两个可用区的应用服务全堵在数据库连接上，整个链路直接僵死。
说实话，我当时看到他们的监控面板都气笑了。
面板上全是绿色的健康标识，CPU使用率才30%，内存占了不到一半，数据库连接池打满的时候，他们连对应的告警规则都没配——运维同事还在那傻乎乎盯着CPU使用率的曲线，以为系统一切正常。
真正的高可用，是先给链路做减法
很多人对高可用的理解走偏了，总觉得要把所有组件都做备份，所有链路都做冗余，链路拉得越长，系统就越稳。
扯。
链路越长，出问题的概率反而越高。
我朋友团队后来复盘的时候，把整个下单链路拆成了两块：一块是核心的下单、支付、扣库存流程，另一块是非核心的商品推荐、用户评价、物流时效预估。上次崩溃的直接导火索，就是非核心的推荐接口拖垮了整个连接池——那个接口一次要关联查3张数据表，直播流量上来之后，每个请求平均要跑两秒，占着数据库连接不撒手，核心的下单接口根本抢不到连接，直接超时。
后来他们做的改动说出来特别简单：给不同的业务模块配了独立的数据库连接池，非核心的推荐接口直接加了熔断规则，一旦流量超过阈值，直接返回提前配置好的静态推荐页，根本不实时查数据库。
就这一个改动。
他们之前总觉得要上最先进的服务网格，要搞全链路追踪，要把所有日志都接进大数据平台做智能分析，算下来光软件license就要十几万，结果最后真正解决问题的改动，加起来还不到两百行代码。
别觉得熔断是啥高大上的黑科技，他们最开始甚至都没引入专门的熔断组件，就是在Nginx层配了个简单的超时规则，推荐接口超过500毫秒没返回，直接切静态页。去年双11的时候他们峰值冲到32万，整个系统连个告警都没弹。
别等流量砸过来才想起做演练
我见过太多团队的高可用方案，全是写在内部文档里的漂亮话，从来没真刀真枪演练过。
之前碰到个做餐饮SaaS的团队，跟我拍胸脯说他们做了完整的高可用架构：数据库主从同步，应用多副本部署，跨可用区容灾。结果上个月市政施工把机房的光纤挖断，他们从库切了四十分钟才切过来。
为啥？
因为他们从来没真的做过主从切换演练。平时主从同步的延迟就有十几秒，真要切的时候，从库比主库少了快两千条交易数据，没人敢拍板切，怕丢了客户的订单数据惹麻烦，就对着屏幕干瞪眼。
我朋友那个团队后来做演练，根本不是搞那种声势浩大的全链路压测。就是每周三下午，随机挑一个线上服务，直接杀掉两个运行实例，看监控有没有反应，告警能不能及时发到群里，熔断规则能不能正常生效。
最开始演练的时候出过好多洋相。
有次把库存服务的实例杀了一个，发现告警群里连个消息都没有——之前配的告警规则，只在CPU超过90%的时候才触发，实例挂了根本没人管。还有次演练切数据库从库，发现从库的数据库账号权限不对，应用根本连不上，折腾了快半小时才修好。
说起来好笑，但真等线上出问题的时候，这些看起来不起眼的小漏洞，全是能要了业务命的大麻烦。
真没必要硬追什么四个九五个九的可用性指标。
对于小团队来说，能保证核心的下单支付链路不崩，非核心功能哪怕暂时打不开，用户也能理解，就已经够及格了。
你一个做小众女装的，没必要跟淘宝京东比可用性——人家一年几个亿的运维预算，你整个团队加起来才五个人，硬抄人家的架构，最后钱花了，人累个半死，系统还不稳。
很多时候你花在冗余硬件上的钱，远不如花在梳理核心链路、补全监控告警、每周做两次简单故障演练上的效果好。