从宕机3小时的支付系统复盘，谈系统可靠性设计的落地细节

去年深秋在苏州某银行的运维指挥中心，盯着屏幕上跳红的交易失败率，从0.02%飙到17.2%的那3个小时，现在想起来后颈还发僵。

当时的团队不是没做准备。核心交易集群按标准架构做了三机房热备，容灾切换手册写了整整42页，上线前的演练全过了一遍。结果流量刚过日常峰值的1.2倍，三个机房的集群同时触发限流，交易链路直接卡成了慢动作。

被高估的“冗余”，藏着最容易踩的隐性坑

很多人对冗余的理解还停留在“多备几台机器”的层面，觉得只要节点数量够多，系统就不会垮。那次复盘挖了半天才发现，三个机房的集群虽然物理上完全独立，但上线前同步配置的时候，所有人都忘了把测试环境里写死的限流阈值删掉——那个阈值刚好是日常峰值的1.2倍，相当于三个独立节点，被同一个埋在配置文件里的隐形开关绑在了一起。

跨节点配置的一致性校验，从来不是靠上线前的人工checklist兜底的。那次之后银行的团队把所有配置项的变更加了自动比对脚本，只要三个机房的同版本配置出现偏差，直接阻断上线流程，再也没出过类似的问题。

说个更离谱的案例。去年碰到一个做政务系统的团队，为了提高可靠性，给数据库做了双机热备，结果两台数据库服务器的电源，都插在同一个插线板上——运维拔插线板给新机器腾位置的时候，两台数据库同时断电，整个政务大厅的办事系统瘫了两个小时。你说这是冗余不到位？从硬件数量上看，他们确实做了双份备份，但从故障链上看，两台机器的故障概率，其实是100%绑定的。

故障的概率，从来不是线性叠加的

不少刚接触架构设计的人，算系统可靠性的时候总喜欢套中学物理的串并联公式：两个可用性99.9%的节点并联，就能算出整体可用性是99.99%，全年宕机时间不超过5分钟。这个公式在理想状态下没毛病，但真实世界里的系统，根本不存在完全独立的节点。

之前和某出行平台的架构师聊，他们的派单系统之前按这个公式算，三个99.9%可用性的依赖模块并联，全年宕机时间应该在4分钟以内。结果去年夏天，三个模块共用的跨运营商专线被施工队挖断，三个模块同时失联，整个派单链路宕了47分钟，算下来全年的宕机时间直接超了预估的10倍。

所有共享了同一物理依赖的冗余节点，本质上是串在同一条故障链上的。那个工作了12年的老架构师说，他刚入行的时候也犯过一模一样的错——为了省专线成本，把三个冗余模块的出口都接在同一条BGP线路上，看着是三重冗余，实则是把鸡蛋放在了同一个连缝隙都没留的篮子里。

很多人觉得冗余越多越好，其实不然。冗余节点越多，系统的依赖关系越复杂，反而容易引入新的故障点。比如为了做容灾，加了三层数据同步的链路，每次同步都要做数据一致性校验，光校验逻辑的bug就出过三次，每次都导致主备数据不一致，切换的时候反而出问题。

SLA里的数字，从来不是靠“不出错”实现的

大部分人对高可靠系统的想象，是系统永远不出错，每个请求都能正常响应。但真实的工业级系统里，故障是必然会发生的，没有任何一个系统能做到100%不出错。那些写在服务等级协议里的99.99%可用性，从来不是靠消除所有故障实现的，而是靠故障发生时，不影响核心业务的正常运转。

拿大家最熟悉的电商大促场景举例。某头部电商的订单链路设计里，根本不追求每个请求都成功，而是把整个链路拆成了12个可独立降级的节点：当库存服务的超时率超过5%的时候，自动切到最近10分钟的缓存库存快照，允许万分之一的超卖概率；当支付回调延迟超过2秒的时候，自动给用户发预约支付的提醒短信，不把用户卡在结算页；当推荐服务的响应时间超过300毫秒的时候，直接切到静态的热门商品列表，不影响用户下单的核心路径。

可靠性设计的核心，从来不是消除所有故障，而是给每个故障留好不影响核心体验的退路。

当然这套思路不是万能的，有非常明确的应用边界。比如医疗监护设备的嵌入式系统，就不能随便套用互联网的降级逻辑——你不能说监测病人心率的传感器超时了，就拿30秒前的历史心率值当当前值显示在屏幕上，那是要出人命的。这类场景下的可靠性设计，必须用完全独立的硬件冗余，连供电模块都要做物理隔离，不能靠软件降级兜底。之前见过一个做医疗设备的团队，硬抄互联网公司的降级方案，给病人监护仪的心率采集加了超时兜底逻辑，结果某次传感器真的断线了，屏幕上一直显示30秒前的正常心率，值班护士没注意，差点酿成严重的医疗事故。真的，不同场景的可靠性边界，差得能有十万八千里，别上来就照搬别人的成熟方案。

现在很多厂商在推AI故障预测的方案，说能提前几十分钟预测到磁盘故障、网络抖动，大幅降低宕机时间。这里也要泼点冷水。之前某云厂商的运维团队测试过一套AI故障预测模型，能提前12分钟识别磁盘的坏道风险，听起来很厉害。结果上线第一个月，模型把正常的磁盘IO波动全判定为故障，运维团队光拆机箱换根本没坏的磁盘，就换了200多块，光人工成本就花了十几万。AI辅助的可靠性观测，本质上还是要靠人工规则做兜底，不能全扔给模型做决策。

上次和那个在银行指挥中心熬了3小时的运维主管吃饭，他说现在他们团队做新系统设计的时候，第一件事不是写功能逻辑，是列“这个系统最坏能坏成什么样”的清单。我觉得挺对的。毕竟做系统的人，谁没见过几个看起来架构完美、指标漂亮的系统，一遇到真实流量就垮得稀碎的样子。