一场「深夜捉虫」引发的活动拯救计划

上周三凌晨三点，我刚哄完发烧的小女儿入睡，手机突然像警报器似的震动起来。工作群里弹出十几条消息：「用户反馈抽奖按钮失灵！」「优惠券领取接口返回500错误！」我抓起眼镜冲进书房，睡衣都没来得及换就加入了这场线上「捉虫大战」。

一、那些让用户跳脚的Bug现场

根据客服部门凌晨2:47提交的紧急工单，活动页面的异常主要集中在三个环节：

• 幸运大转盘：用户点击抽奖按钮后，35%的请求返回「服务器开小差」
• 新人专享券：部分用户领取时提示「该优惠券不存在」
• 活动主会场在iOS设备上出现布局错位，重要入口按钮被遮挡

异常模块	影响用户占比	高峰时段	数据来源
抽奖系统	18.7%	22:00-02:00	内部监控系统v3.2
优惠券服务	9.3%	00:30-01:15	第三方监测平台DataWatch
前端展示	iOS用户31%	全天持续	《2023年线上活动稳定性白皮书》

1.1 数据库里的「幽灵优惠券」

在检查优惠券服务日志时，我们发现有个奇怪的现象：当用户ID尾号为双数时，领取请求总会查询到某个不存在的券码。这就像超市货架上明明写着「买一送一」，货架却是空的。

二、技术团队的24小时极限救援

从凌晨三点到次日下午五点，我们完成了三次重要迭代：

2.1 第一阶段：紧急止血（03:00-05:30）

• 对抽奖接口实施流量削峰，将QPS从1200降至800
• 临时关闭新人专享券领取功能
• 发布前端热修复包，强制iOS端使用备用布局方案

2.2 第二阶段：根因排查（06:00-10:00）

在数据库慢查询日志里揪出了元凶——某个新上线的分页查询语句，在特定条件下会触发全表扫描。这就像图书管理员找书时，非要把整个图书馆的书架都摸一遍。

优化前查询时间	优化后查询时间	索引命中率
872ms	23ms	从47%提升至92%

2.3 第三阶段：全面升级（12:00-17:00）

我们给数据库做了个「大手术」：

• 将用户数据按尾号拆分成8个物理分库
• 为优惠券表增加组合索引（user_id,status）
• 读写分离中间件升级到2.1.4版本

三、天亮后的用户反馈

第二天上午十点，客服主管在群里发了张截图：用户「爱吃草莓的兔子」在微博上说：「昨晚以为要错过优惠了，早上起来居然自动到账了，给技术小哥加鸡腿！」市场部同事打趣道，这波修复反而提升了活动的好评率。

指标	修复前	修复后	变化幅度
页面错误率	4.8%	0.3%	-93.7%
接口响应时间	1.2s	210ms	提升82.5%
客服投诉量	127件/小时	9件/小时	-92.9%

窗外飘来楼下早餐店的油条香味，运维小哥在工位上发出轻微的鼾声。我看着监控大屏上平稳运行的曲线，给妻子发了条消息：「今天能正常下班，记得留我的饭。」