| 时间 | 异常现象 | 可能原因 | 处理动作 |
|---|
| 03:12 | 用户登录报错502 | 网关超时，异常后端线程池打满 | 重启节点，分析扩容2台 |
| 03:15 | 数据库连接数飙到80% | 慢查询堆积，报告表格索引失效 | kill长事务，异常补索引 |
| 03:20 | 缓存命中率骤降15% | 热点key过期，分析穿透到DB | 加互斥锁，报告表格预热数据 |
| 03:26 | 错误日志出现OOM | 堆内存分配不足，异常GC频繁 | 调大Xmx，分析排查内存泄漏 |
| 03:31 | 用户反馈页面白屏 | 前端JS资源加载失败 | 回滚CDN配置，报告表格刷新缓存 |
这张表是异常我凌晨三点半爬起来填的。当时手机震了七八下，分析群里喊“线上挂了”。报告表格
我揉着眼睛打开电脑，异常第一件事不是分析看表，是报告表格看监控曲线——那玩意儿比任何报告都诚实。登录失败率从0.2%直接跳成一条直线冲上去，像心电图室颤。 先说最刺眼的那个502。03:12，网关层日志刷了满屏红色。我第一反应是“又他妈是流量突刺？”结果查了上游，发现根本不是流量问题——是后端某个微服务的线程池被一个死循环任务堵死了。那任务是个定时扫描，写代码的人用了`while(true)`没设退出条件，凌晨的批处理一跑就卡住，占满所有工作线程。你问我怎么定位的？看线程dump，一堆`RUNNABLE`状态堆在同一个方法名上，那名字我认得——`scanExpiredCoupons`。真讽刺，过期优惠券没扫掉，先把服务扫死了。 然后是数据库。03:15那会儿连接数涨得吓人，但CPU才30%。典型的锁等待，不是计算瓶颈。我拉出慢查询日志，发现一条SQL执行了11秒——`SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC`。user_id字段没索引？不对，有索引，但表数据量到了2亿行，旧索引的基数统计偏了，优化器选了全表扫描。处理也简单，`ANALYZE TABLE` 重新统计，再强制走索引。秒回。这种问题最气人，明明加个分号就能解决的事，偏要等到凌晨给你演一出。 缓存那块更有意思。03:20，Redis命中率掉了15个百分点。我盯着监控想了半分钟，突然意识到——那个死循环任务不仅堵了线程池，它还在循环里反复查同一个key，每次查不到就去DB捞，捞完又因为过期时间设了30秒，刚写进去就没了。等于拿大炮打蚊子，把缓存击穿了个洞。我当时骂了一句脏话，然后手动把那个key的过期时间改成1小时，再往DB层加了一层互斥锁。锁的粒度要细，别锁整个表，不然又得炸。 最后那个白屏，其实是前端的锅。03:26的OOM导致后端返回了非标准JSON，前端解析直接抛异常，整个React应用挂掉。但有意思的是，等后端恢复了，前端还是白屏——因为CDN上缓存了那个坏掉的JS文件，用户浏览器拿的是旧版本。我让运维强制刷新边缘节点，又等了五分钟，页面才慢慢活过来。这提醒我一个事：异常报告不能只看后端指标，前端感知才是用户的真实体感。你后端修得再快，用户那边卡了十分钟，体验分就掉没了。 填完这张表，天已经蒙蒙亮。我盯着最后一行“处理动作”发了会呆——其实每个格子背后都是人的失误：那个死循环是实习生写的，没code review就合了；索引失效是DBA上周做归档时动了表结构，没通知应用组；缓存穿透则是架构设计时没考虑热点key的防护。技术问题到最后全是管理问题，这话我信了。 表格交上去，领导回复“辛苦了”。我没回。我在想明天得开个复盘会，但复盘的重点不该是“谁的责任”，而是——为什么我们的监控没有在03:00就预警线程池占用率？为什么慢查询的告警阈值设得那么高？这些问题不解决，下次凌晨三点，我还会爬起来填一张类似的表。
