凌晨两点四十，手机在枕头边震。我摸起来看，值班群里只有一句话：订单页 502。
那是我被拉进这个群的第三天。上一任负责人走得比谁都快，据说离职面谈只花了八分钟。
打开监控我愣住了。三台 Nginx，挂了一台。就一台。另外两台好好地喘着气。可整站白屏。
查到最后原因特别没劲：那三台的 upstream 权重是手工维护的，挂掉那台是 100，剩下两台各是 5。谁改的？没人记得。半年前某次压测临时调的，调完忘了改回来。
这就是高可用架构最常见的死法。不是机器不够硬，是人手太随意。
双机热备这个词害了不少人
架构评审会上画两台服务器，中间连一根线，写上双机热备四个字，老板点头，方案过了。
然后呢。
共享存储是不是单点？VIP 漂移上一次真机演练是什么时候，有人说得出来吗。切换脚本里那条 ssh 免密，运维换代之后还在不在。还有最阴的一个——数据库主从切过去了，三十秒搞定，可应用侧的连接池里全是指向老主库的死连接，业务层重连整整花了六分钟。
六分钟。对于电商来说，这已经够写一份事故复盘的第一版了。
我特别想吐槽的是，很多团队把「有备份节点」当成「高可用」。这两件事差着十万八千里。备用节点从来不接管流量，它就只是台安静的服务器，跟标本没区别。
真正难缠的是状态
无状态的接口好做，加机器就行。麻烦的永远是那些带着状态的东西。
Session 存在本地内存里。用户上传的图片落在 A 机的 /data/upload。定时任务三台机器同时跑，券被发了三遍。本地缓存各自为政，A 机看到的是新价，B 机还在卖昨天的数。
这些场景我见得太多，说白了就一句话：高可用架构的本质是「任何一台机器随时可以消失」，而不是「每台机器都很坚强」。
所以顺序大概是这样的——能无状态的做成无状态；做不成的往外抽，Session 扔 Redis，文件上对象存储；抽不出去的就加锁、加幂等、加去重，别指望它不出事，指望它出事了也不会重复扣钱。
对了，还有重试。很多雪崩不是被流量打死的，是被自己人的重试打死的。上游超时设 3 秒，下游降级后要 5 秒才回，于是所有请求都在重试，三倍流量糊在一台本来就快不行的服务上。限流、熔断、退避重试，这三样少一个都够呛。
预案躺在文档里就是一张许愿纸
我见过一个特别典型的团队。容灾预案写得极其完整，四十多页，放在 Confluence 里，目录清晰。我随手点开其中一个链接——404。
半年没人打开过。
这东西跟家里的灭火器一个道理，买回来不看压力表，真着火的时候拧半天喷不出东西。
我的建议很土：每个季度搞一次，直接在测试环境把主节点 kill 掉。别搞什么「模拟切换」的按钮，那个按钮本身就是最大的谎言。就看真实流量下多久能恢复，看谁第一个发现，看告警有没有炸到不该炸的人手机上。
有余力的，往生产环境做灰度故障注入。但一定先确认好回滚路径，别把演练做成事故。
演练完必须写东西。不是写「本次演练圆满完成」，是写：切了多久、卡在哪一步、哪个人当时不在线、脚本哪一行报错。这些细节下次才用得上。
可以今天就开始的几件小事
别搞大工程。先从这些开始：
把所有手工维护的配置抓进代码仓库，尤其是负载均衡权重、白名单、超时参数。这些藏在机器上，就是定时炸弹。
给核心链路列一张依赖表，标清楚哪一环没有冗余。通常列完你会发现，冗余看起来很多，真正关键的入口只有一个。尴尬。
把健康检查从「端口通不通」改成「业务能不能干活」。端口开着但线程池满了的服务，比直接挂掉还危险，它会把流量吸过去然后吐不出来。
告警降噪。一晚上两千条告警的团队，等于没有告警。
最后一条，可能也是最难的：让值班的人有权直接重启、直接切流，不用在群里等领导回消息。高可用架构不是买来的保险，是团队在凌晨三点还愿意爬起来、并且知道该干什么的那个习惯。
话说回来，真出了事，架构图救不了你。人才能。