系统维护通知

凌晨两点十七分，系统监控大屏上那根代表订单处理量的维护曲线突然像被人掐住了脖子，从峰值直直坠到谷底。通知值班的系统小陈后来说，他当时第一反应是维护去摸键盘，第二反应才是通知去抓手机——这个顺序说明，他脑子里已经默认了问题出在系统本身，系统而不是维护网络或者硬件。

事实也确实如此。通知数据库连接池在没有任何预警的系统情况下被打满了。日志里没有任何异常SQL，维护没有慢查询，通知没有死锁。系统就是维护连接数一路飙到上限，然后所有新的通知请求全部卡在等待队列里。订单接口超时，支付回调失败，用户端开始出现“系统繁忙”的提示。从第一个报错到全面不可用，只用了四分钟。

我们事后复盘的时候发现，问题出在一个很不起眼的地方。上周上线的一个促销活动配置，把某个商品的库存扣减逻辑从“同步扣减”改成了“异步队列”。代码本身没问题，测试环境也跑通了。但线上那个时间点的并发量是测试环境的几百倍，异步队列的消费者线程配置沿用了默认值——8个。8个线程去消费每秒数千条的库存扣减消息，队列瞬间堆积，然后开始阻塞上游的订单主流程。一个参数没改，整条链路崩了。

这不是第一次了。去年双十一前也出过一次类似的事故，那次是缓存穿透，原因是一个冷门商品的缓存过期时间被设成了0。运维团队连夜加了布隆过滤器，但这次的问题显然不在缓存层。每次事故看起来都是单一故障点，但背后暴露的是同一个问题：我们对配置变更的敬畏心不够。一个参数、一行代码、一个默认值，在低并发场景下完全正常，到了高并发场景就是雪崩的起点。

现在说回这次维护。我们决定在周六凌晨两点到五点之间做一次全量重启和配置修正。选择这个时间窗口是因为过去三个月的流量监控显示，这个时段订单量只有日常的百分之三左右，支付成功率几乎为零——没人会在凌晨两点买东西。但即便如此，我们还是会提前四十八小时在官网、APP弹窗和短信三个渠道发通知。短信只发给过去三十天内有交易记录的用户，避免打扰已经流失的账号。

维护内容主要有三项。第一，把库存扣减的消费者线程数从8调到128，同时增加队列长度监控和自动扩容策略。第二，清理所有超过三十天未更新的活动配置，这些配置占用了大量内存但几乎不会被触发。第三，升级数据库连接池的监控粒度，从现在的五分钟一次采样改成十秒一次，这样下次再出现连接数异常，我们至少能在三十秒内收到告警而不是等用户投诉。

维护期间，订单创建和支付功能会暂停，但商品浏览、搜索、用户登录这些读操作不受影响。如果你在凌晨两点到五点之间下单，系统会提示“服务升级中”，然后引导你加入购物车，维护结束后自动恢复。已经生成的订单不会丢失，支付回调会在服务恢复后重新排队处理。物流信息查询接口会降级返回缓存数据，可能延迟几分钟，但不会完全不可用。

我知道很多人看到“系统维护通知”第一反应是划走。这很正常，就像你看到“道路施工请绕行”的牌子，除非你每天走那条路，否则根本不会在意。但如果你恰好是那个凌晨两点还在刷手机想买点什么的用户，或者你是那个被半夜叫起来处理故障的运维，这件事就跟你有关。我们尽量把维护窗口压短，也尽量提前通知，但有些问题确实只能靠停服来解决——热更新的风险我们试过，上次热更新一个配置导致了一半的服务器内存泄漏，比停服三小时严重得多。

周六凌晨见。如果你醒着，看到APP弹出维护提示，不用截图发客服，也不用在社交媒体上问“是不是崩了”。就是我们在干活。五点之前会恢复，恢复之后我会在状态页面更新一条记录，写清楚这次改了什么、为什么改、下次维护大概在什么时候。不写套话，就写事实。