电商大促的可观测保障：容量、告警与追踪的实战清单

大促的可观测难题

大促流量是平时的 3~10 倍，而且集中在几分钟内爆发。平时没问题的代码，在洪峰下会暴露连接池耗尽、锁竞争、GC 停顿等各种问题。可观测系统的任务不是「事后查日志」，而是让团队在秒级看到异常、分钟级定位根因。下面这套清单是我们在多个电商客户那里沉淀下来的，挑适合自己架构的用。

战前：压测校准容量与阈值

大促前三周开始压测，把结果反哺到两处：

1. 容量基线：按压测得到的 QPS 峰值，确认数据库连接数、线程池、网关并发上限，留 30% 余量。压测显示连接池 1200 就到顶，大促时就不要跑到 1150；
2. 告警阈值：把告警阈值从「日常值」换成「大促值」。日常 CPU 70% 就告警，大促时 85% 才算异常，否则告警会先把你淹死。

阈值不是拍脑袋，是用压测数据算出来的。比如压测表明 90% CPU 时 P99 延迟开始劣化，就把 CPU 告警定在 85%，把延迟告警定在 P99 开始爬坡的那个点。

战前：配置静默、值班与一张大屏

把发版、预热、压测的时间段全部配上静默窗口，避免误报消耗精力。值班表按「黄金 5 分钟」设计：一线同学 5 分钟内无法定位，立刻升级到二线架构同学；同时约定一个「止损优先」原则——先回滚、限流、扩容止损，再查根因。这个原则要贴在值班同学看得见的地方，压力之下它是最容易被忘掉的。

另外提前做好一张「大促大屏」：全局错误率、Top 5 最慢服务、队列深度、当前告警数，一屏看完。值班同学先看这张屏，服务详情页是第二步的事。

战中：用链路追踪快速定位

大促中故障，最怕「一个接口慢，几十个服务都有慢日志」。用链路追踪按 trace id 串联调用链，直接看耗时分布：是数据库慢、下游慢、还是某次 GC 停顿。炬鲸 OBSERVE 支持按慢请求聚合出 Top N 的耗时段，点开就能看到具体是哪个方法、哪条 SQL 拖慢了整条链。

排障顺序建议固定下来：先看大盘错误率 → 找到爆发的服务 → 取一条慢 trace → 定位耗时段 → 定向修复或降级。这个顺序练熟了，分钟级定位是能做到的，而这正是「五分钟的小抖动」和「高峰期十五分钟事故」之间的差别。

战后：复盘沉淀

大促结束后 48 小时内做复盘，把「哪些告警有用、哪些是噪音、哪些阈值要调」落到文档里，下次大促直接复用。可观测平台的配置应该像代码一样版本化，每年大促在此基础上迭代，而不是从零开始。一本扛过了一次大促的 runbook，比任何通用最佳实践文档都值钱。