上周二晚上十一点，我盯着屏幕上转了四十圈还在转的加载圆圈，感觉自己的太阳穴也在跟着那个小圆圈一起转动。离客户提案还有9个小时，我们的数据看板突然连不上业务数据库了。群里运维老张发了一句这就是突发状况，我差点把手机摔了。但我心里清楚，这根本不是突发。三天前测试环境的慢查询日志就出现过同样的报错，当时老张在群里提了一句，大家谁也没当回事，包括我自己。我们都在等一个确切的爆发点，好把这个错误包装成不可抗力，这真挺讽刺的——我们的应急预案写着数据链路每隔五分钟自动健康检查，可实际上，那个监控按钮自打上线就没人验证过它真的会发告警。
老张花了四十分钟才排查出问题，远程服务器的连接池被某个幽灵连接占满了，像是某种内存泄漏。每次线上崩了，我们都习惯甩锅给突发流量，然后追加服务器预算，却根本不看我们那套早已过时的架构里，藏着多少没人敢碰的祖传代码——你知道最老的那行代码是哪年写的吗？2016年。今年是二零二五年了，那行代码还在生产环境里跑着，像一颗定时炸弹。我们管这叫系统稳定，其实只是还没炸到脸上而已。
这类事情多了以后我开始思考，也许整个预案体系就是在教我们把精力放在假想敌上。我们花好几个通宵去预演那种百年一遇的大地震式事故，然而在现实里，最常见的突发状况其实是某个key绑定错了列，某封邮件发出去半小时后发现附件是旧版本——这些小事根本不需要动用应急方案，它们只是在一天之内把你的计划撕碎三次，然后逼你重新组装。真正的突发无法提前演练，因为它的特征就是打破你对常态的理解。比如上周的瞬间，我脑子里闪过的念头很奇怪：不是数据出了什么错，而是我居然不假思索地默认了明天早上八点的评审一定会准时开始。这个期待让我没能在看到报错的第一步就喊停，我的预案只是让我在事故发生后，对了一遍流程清单。
后来一个在咨询公司做事的朋友跟我讲，他们那边解决这类问题有一个更狠的做法：任何安全事故的复盘里，第一个被提审的对象永远是写预案的那个人，如果他们根本没预见到这个场景，就说明他们对自己的系统理解停留在三年前。所以说，我们的问题不只是运行时的失控，更多是一种认知上的懒惰——我们把数据做到所谓的五个9（年停机五分钟左右）的可用性，还以为这个数字意味着一个不可撼动的承诺。我却越来越觉得，那些爆掉的项目，多半是死在一个更隐蔽的维度：预案本身就在暗示你这套流程是完美的，可现实世界每一秒钟都在局部腐烂，你预案里所谓的最坏情况，其实远远坏不过系统真正的脾性。
凌晨五点，DBA那边终于通过杀掉那两个占着连接不撒手的进程，让服务恢复了。群里的消息从炸锅变成ok，老张发了个奋笔疾书的黄豆表情。提案最后按时上线，客户夸我们反应迅速，安全落地。我看着那群深夜爬起来连吐槽都没顾得上的人，忽然很想问一句：我们想保全的，到底是业务的连续性，还是我们在紧急处理时那种被需要的幻觉？这两个问题在平常看起来一摸一样，但在突发状况里，它们把人逼向不同的选择——前者让我们去检查连接池、翻日志、找到那只弄死连接池的手，而后者，只是想让整条船的洞看起来没那么大。奇怪的是，那个早上会议室特别安静，往常这种时刻，大家早就七嘴八舌地讨论下次得加监控了，但这次没有，每个人都在喝咖啡。天知道那个差点把看板搞垮的幽灵进程是什么来头，而我们下次是否还有理由管它叫突发。
