系统可靠性设计：别被"五个九"的鸡汤骗了
别拿可用性当可靠性，很多人从根上就错了
很多人张嘴就是五个九，说自己系统可用性99.999%，吹得天花乱坠。可你拆开看，可用性只算累计宕机时间，可靠性完全是另一回事。可靠性是你整个系统从硬件到软件，从网络到存储，在各种破事找上门的时候，还能把事儿干对的能力。
举个例子，AWS欧区去年那档子事，可用区整个炸了，有些做了跨区部署的系统，顺利切到了备用区，结果切过去之后数据对不上，订单差了上万条，用户付了钱没拿到货，客服电话被打爆。这种情况，你能说它可用性不够？它切成功了啊，可是可靠性完全不合格。
分布式系统可靠性与可用性差异对比图
说实话，很多公司做可靠性设计，从第一步就走歪了。钱都花在堆硬件、堆冗余上，核心逻辑的正确性根本没抠。我见过千万级日活的产品，核心支付链路没做幂等，一降级就出重单，最后赔了用户好几百万，老板脸都绿了。这种坑，真不是小公司才会踩。
落地可靠性设计的三个反常识细节
第一个，不要追求全链路无单点，要接受可控的单点。
行业里天天喊"单点就是原罪"，搞得很多新手不管什么模块都要拆成多实例，结果拆完之后分布式一致性问题搞不定，整体故障率反而翻了三倍。你的内部OA后台，一天没十个员工用，搞什么跨可用区多活？机器坏了换一台重启，俩小时修完都没人投诉你，把预算省下来给核心用户链路做优化，这不香吗？
第二个，故障注入要往疼了打，别搞温柔的过家家演习。
很多公司做混沌工程，走形式而已，就拔个无关紧要的静态文件服务器的网线，完事写个漂亮报告交差，真遇到核心数据库主库挂了，全公司没人知道切流的正确步骤。去年我帮一家做品牌电商的客户梳理架构，提议直接拔了主支付库的电源做真演练，结果技术总监当场脸色变了——演练完才发现，备份切换脚本三个月没更新，切完之后少了三天的支付数据，那场面，真是…终身难忘。
电商核心支付链路故障注入演练示意图
第三个，降级不是兜底方案，降级本身就是系统设计的一部分。
很多人写降级逻辑，图省事，直接返回500报错，或者干脆把整个功能关了。这哪叫降级，这叫投降啊。正确的降级思路，是哪怕出问题，也要尽量给用户留活路，也要把核心交易做完。比如你下单的时候优惠券系统炸了，别不让用户下单啊，你可以先让用户下单，后续再把优惠券补进去，哪怕你亏点优惠券的钱，也比丢了订单丢了用户强啊。
大模型流行的今天，可靠性设计有了新要求
大模型流行的今天，可靠性设计有了新要求
最近一年见了太多客户，把大模型接入了自己的业务，原来的可靠性设计逻辑完全不够用了。原来你只需要盯自己的服务器、自己的代码就行，现在多了一堆第三方依赖，大模型供应商限流了、推理超时了、甚至返回违规内容了，这个锅最后还是你的。
所以现在做系统可靠性设计，必须把第三方服务的可靠性也纳入整个体系里。你做AI客服，大模型供应商卡了，你得有个兜底的传统关键词匹配客服顶上，不能直接给用户甩一个"服务异常"就完事。你做AI生成海报，大模型推理超时了，你得让用户先等着，给个进度条，不能直接把用户的请求丢了，让用户重新填一遍信息，换谁谁不炸？
还有，大模型推理吃算力，现在大家都搞弹性扩缩容，按流量扩减机器，很多人只盯着资源利用率降成本，根本没考虑推理进程的优雅退出，缩容的时候直接把跑了一半的推理任务杀了，一半用户拿到半截子结果，骂骂咧咧就走了。这个坑，我最近三个月见了三次，真的是屡踩屡有。
不过话说回来，不管技术怎么变，怎么出新概念，可靠性设计的根从来没变过。你得把所有可能搞砸你业务的破事，提前都想一遍，然后给每个破事留好后路。别抱着"不会这么巧吧"的侥幸，互联网发展这么多年，你觉得不可能发生的事，大概率都会发生，只不过是早晚的问题。
上个月那个找我帮忙的初创公司，后来改了核心链路的幂等规则，做了核心支付库的一主多备，还砍了三个非核心模块的冗余，整体运维成本降了两成，可靠性反而上去了。上次大促一百万流量打进来，整个系统稳稳的，连个高危告警都没出。
做技术的，别总追着高大上的概念跑，把可靠性的细节抠到位，比什么花里胡哨的架构都管用。