有些课，只有生产环境在凌晨两点给你上。
下面这件事，发生在我们交付的一家大型制造客户身上。为了保护对方，细节做了脱敏，但教训是百分之百真实的。
事故时间线
23:47 客户夜班班长来电：排产系统全盘告警，车间大屏空白。
23:50 我们远程接入。主数据库心跳丢失，从库没自动接管——本该发生的“高可用切换”没有发生。
00:20 排查发现：主从之间的网络抖动触发了哨兵误判，哨兵把主库标记下线，却又因配置冲突没敢提升从库。系统卡在“主已死、从未立”的半死状态。
01:05 手动强制提升从库，业务恢复写能力。但部分在抖动期间写入主库、尚未同步的数据，需要人工核对。
02:30 数据核对完成，系统完全恢复。前后 2 小时 43 分。
三个被我们忽略的盲区
复盘会开得很安静。问题不在“没做高可用”，而在我们认为“做了就等于有了”。
盲区一：高可用组件本身也会误判。
哨兵、keepalived 这些“保命工具”，本质是另一个会出 bug 的软件。我们配了，却从没演练过“它误判时怎么办”。那晚它真的误判了，我们才发现自己对它的信任过头了。
盲区二：监控有死角。
我们监控了“数据库是否存活”，却没监控“主从数据延迟是否超过阈值”。结果故障前一个小时，从库就已经落后主库十几分钟，而没人看见。等切换发生时，这十几分钟成了必须人工修补的窟窿。
盲区三：出事了，没人敢拍板。
最耗时的不是修，而是“谁来决定强制提升从库”。流程文档里写的是“升级到值班经理”，可那晚经理在飞机上。我们卡在等待授权里，白白耗掉半小时。
我们把教训变成了三条护栏
复盘不是追责，是给下一次装护栏。
高可用要演练，不是配置。 现在每个关键系统上线前，我们强制做一次“拔网线演练”：真的把主库网络掐断，看从库能不能在约定时间内干净接管。演练发现的 bug，比线上事故温柔一万倍。
监控要盯“差距”，不只盯“生死”。 主从延迟、队列积压、磁盘剩余——这些“还活着但快不行”的指标，比心跳线重要得多。我们把它们全部纳入告警，且分了三级，避免半夜狼来了。
决策权要前置授权。 我们和客户重新签了一份“应急授权书”：达到某些明确阈值时，一线工程师有权直接执行强制切换，事后补报。把“等批准”从关键路径上拿掉。
写在最后
高可用从来不是买几个组件、勾几个选项就能兑现的承诺。它是可演练的流程、可观测的指标、以及有人在凌晨两点敢担责的系统工程。
那晚之后，我们内部多了一句口头禅：“配了”不等于“有了”，演练过才算。
金兰信息——专注为大中型企事业单位、科研院所及高端制造业提供定制化信息系统与智能解决方案。我们做的不只是能跑的系统，更是半夜不会把你丢下的系统。