服务器异常requestidd1244bab4f6b1a2b

那个深夜两点十七分，服务我盯着屏幕上那行红色小字，器异骂了一句脏话。服务

requestid：d1244bab4f6b1a2b。器异一串十六进制字符，服务像病历单上的器异编号，冷冰冰地宣判：服务器异常。服务说真的器异，搞了六年运维，服务我早该习惯这种半夜被叫醒的器异滋味。可每次看到这串随机生成的服务id，还是器异忍不住烦躁——它太像某种命运暗号了，你永远不知道背后藏着什么破事。服务

先查日志。器异这串id是服务网关层分配的，意味着请求已经穿过防火墙，过了负载均衡，在应用服务器入口处被拦下。不是网络问题，不是DNS问题，是业务代码抛了异常。我一边敲命令一边想，这用户也是够倒霉，凌晨两点还在提交订单，可能是个加班到崩溃的程序员，或者失眠刷购物车的夜猫子。然后他的请求撞上了我的值班夜。

堆栈打印出来了。NullPointerException，第47行，一个订单状态判断。我盯着那行代码看了十秒，突然笑出声。这不就是上个月我review时提过的那段逻辑吗？当时我说，状态字段可能为null，得加个默认值。负责这个模块的小张拍着胸脯说不会，数据库有约束。

数据库有约束。呵。结果呢？某个接口直接往表里插了条脏数据，状态字段空着，成功绕过了所有校验。现实总比段子更荒诞，你设计得再严谨，总有办法被钻空子。就像你锁好门窗，小偷非要撬你家狗洞。

我翻了翻那个请求的完整链路。用户从客户端发起，经过三次重试，每次都拿到同一个requestid。这设计倒还行，至少幂等性做对了。但问题在于，重试时参数没变，状态还是那个空值，所以三次都撞上同一堵墙。系统没有自动降级，没有兜底方案，就这么硬扛着，把错误原封不动地抛给用户。

说句难听的，这种异常就该在测试阶段被拦住。但测试环境数据太干净，压根复现不了这种脏数据场景。生产环境才是真正的照妖镜，什么妖魔鬼怪都藏不住。

我手动把那条脏数据的状态字段补了个默认值，然后重放请求。这次通过了。整个过程花了四十分钟，其中半小时在排查，十分钟在修复。真正动手改的代码就一行。

凌晨三点，我关掉终端，给自己倒了杯凉白开。想起白天开会时产品经理还在说，要保证系统稳定性达到99.99%。我就想笑。四个九听起来很牛，可换算下来，一年允许宕机五十二分钟。今晚这四十分钟，已经用掉大半份额了。

后来我把这个requestid的排查过程写了篇内部文档，标题就叫《一次由脏数据引发的血案》。小张看了之后默默在代码里加了个空值校验。挺好，至少下次再有人踩坑，能少掉几根头发。

但我知道，这事还没完。明天，后天，总有新的requestid冒出来，带着新的惊喜。服务器这玩意儿，就像个永远长不大的熊孩子，你永远不知道它下一秒会给你整出什么幺蛾子。而我，就是那个半夜爬起来给它擦屁股的倒霉蛋。

不过话说回来，这种跟bug斗智斗勇的深夜，倒也挺有意思。至少比白天开那些没完没了的会强。

本文地址：http://www.79wt.cn/news/1055e0199893.html