凌晨两点十七分，服务手机在床头柜上震了一下。器出我翻了个身没理它。服务过了十秒，器出又震。服务然后是器出连续不断的嗡嗡声，像只被踩了尾巴的服务猫。摸过来一看，器出监控群里炸了锅——“API响应超时”“502 Bad Gateway”“数据库连接池满了”。服务得，器出服务器出事了。服务

这种事你躲不掉。器出干这行十年，服务我总结出一个规律：服务器永远不会在你精神饱满、器出阳光明媚的服务周二上午十点出问题。它专挑你刚睡着、刚端起饭碗、刚坐上回家的末班车时发作。像某种有脾气的活物，专治各种不服。

爬起来开电脑，屏幕蓝光刺得眼睛发酸。SSH连上去，top命令一敲，CPU负载飙到78，内存吃掉92%。日志文件刷得比弹幕还快，全是同一个错误反复报。我盯着那几行字看了半分钟，脑子里把最近上线的代码过了一遍。下午刚推了个新版本，改了个数据同步逻辑。当时测试环境跑得好好的，谁能想到生产环境一上量就崩。

回滚。敲下命令那一刻，手指头有点抖。生产环境回滚不是闹着玩的，搞不好数据不一致更麻烦。但没别的选择。等了大概四十秒，监控曲线开始往下走。群里有人发了句“恢复了？”我没回，又盯了五分钟确认稳定，才在群里打了个“嗯”。

关掉电脑躺回去，睡不着了。脑子里开始复盘：为什么测试没发现？因为测试数据量太小，那个同步逻辑在低并发下根本不会触发死锁。这是老毛病了，每次都觉得“这次应该没问题”，每次都被现实抽一巴掌。

第二天到公司，第一件事不是写事故报告，是把那个同步逻辑重写了一遍。加了重试机制，改了锁粒度，又写了个脚本模拟高并发场景。跑了一下午，没再复现。但我知道这不算完。服务器这东西，你永远不知道下一个坑埋在哪。可能是某个中间件的默认配置，可能是某次系统升级后的内核参数变化，也可能就是机房那台破空调又坏了导致硬盘过热。

中午吃饭时跟同事聊起来，他说他上家公司更离谱——服务器放在一个改造过的储物间里，有次保洁阿姨拖地，水桶碰掉了网线。整个公司断网四十分钟，老板脸都绿了。后来他们买了台带锁的机柜，钥匙挂在自己裤腰带上。

你看，服务器出问题，有时候是代码的事，有时候是人的事，有时候纯粹是运气的事。你能做的就是把能控制的控制好：监控告警配全，日志别省，回滚方案提前写好，别等到出事再临时想。剩下的，就看你半夜被叫醒时手够不够快了。

现在我的手机还是二十四小时不静音。但每次它响，我心里都会先咯噔一下。这大概就是干这行的职业病——你永远在等下一只靴子掉下来。