后台信息

凌晨两点十七分，后台信息我盯着后台那条报错日志看了整整三分钟。后台信息不是后台信息看不懂，是后台信息没想到——一个跑了四年的定时任务，突然在某天凌晨开始返回空数据。后台信息没有代码变更，后台信息没有服务器迁移，后台信息连数据库连接池的后台信息配置都没动过。它就那么悄无声息地坏了。后台信息

这种事在后台系统里太常见了。后台信息前台用户看到的后台信息永远是"加载中"转两圈然后正常显示，没人知道背后可能有个接口正在疯狂重试，后台信息或者某个队列已经堆积了上万条消息。后台信息后台信息就是后台信息这样，平时没人看，后台信息出事了才有人翻。

我见过最离谱的一次，是某电商平台的订单状态同步。用户付了钱，订单显示"待发货"，但仓库系统里压根没收到这条记录。查了两天才发现，消息队列的消费者线程池被一个死循环卡住了，新消息全堵在通道里。那两天产生的订单，全靠人工从日志里一条条捞出来补录。技术团队后来加了个监控，专门盯队列积压量。但你知道的，监控这东西，加的时候都觉得自己会看，真跑起来谁天天盯那玩意儿。

后台信息有个特点：它不撒谎，但也不说全。日志里写着"请求超时"，可能是网络问题，可能是下游服务挂了，也可能是你自己的线程池满了。错误码给的是"参数校验失败"，但具体哪个参数、为什么失败，得自己翻代码。我养成了一个习惯，看到报错先别急着改，把前后三十行日志都拉出来看一遍。十次里有三次，问题根本不在报错那一行。

还有权限。后台系统的权限设计往往比前台复杂十倍。一个运营人员要改商品价格，得先有"商品编辑"权限，再有"价格修改"权限，如果价格变动超过阈值，还得触发"调价审批"流程。这些权限在数据库里就是几张关联表，在代码里就是一堆if-else。改错一个判断条件，要么该拦的没拦住，要么该放的放不出去。我见过一个后台，因为权限校验写反了，普通客服能看到所有用户的完整手机号。发现的时候已经跑了三个月。

数据一致性是另一个坑。后台经常要同时写好几张表，订单表、库存表、流水表，少写一张就是事故。分布式事务太重，本地事务又跨不了库。最后大家默契地选择"最终一致性"——先写主表，发个消息，让下游慢慢同步。这中间的延迟窗口，就是各种脏数据的温床。有次大促，库存扣减和订单创建之间差了整整八秒，结果超卖了四百多单。技术复盘的时候，有人说"八秒而已"，运营那边直接拍了桌子。

我现在的习惯是，每次上线后台功能，先问三个问题：出错了怎么知道？知道了怎么查？查到了怎么修？这三个问题答不上来，功能就不算做完。监控、日志、回滚方案，一个都不能少。听起来很基础，但真到赶进度的时候，最先砍的就是这些"基础"的东西。

后台信息不会主动告诉你哪里有问题。它只是安静地记录着一切，等着你去发现。有时候是凌晨的一条报错，有时候是用户的一条投诉，有时候什么征兆都没有，直到某个数字对不上。做后台久了，人会变得有点疑神疑鬼。看到"成功"两个字，第一反应是"真的成功了吗"，第二反应是"让我查查日志确认一下"。

这种不信任感，大概是后台留给我的职业病了。