大促流量是平时几十倍，出问题窗口只有几分钟。本文给出一份可落地的改造清单，讲清日志、链路、告警三者在高峰期如何协同定位与止损。
大促和平时的区别不在技术栈，而在容错窗口。平时一个接口慢了，用户多点几次，你第二天再查也来得及；大促当天流量是平时几十倍，一个慢 SQL 就能拖垮整条下单链路，几分钟就是上百万的损失。
所以改造之前，先回答三个问题：第一，如果下单链路卡了，我能在 5 分钟内定位到是哪个服务、哪个方法吗？第二，如果数据库连接池打满，我能在用户投诉前收到告警吗？第三，压测报错时，我能一眼看出错误是集中在某几个接口还是全局性的吗？答不上来的，就是这次要补的短板。
日志改造的第一原则是统一字段。至少保证每条请求日志带四个字段：trace_id、service、method、status。有了这四个字段，跨服务串日志就是一条 SQL 的事，而不是人肉 grep 十几个文件。
SELECT * FROM logs WHERE trace_id = 'a1b2c3' ORDER BY ts ASC第二原则是分级。把 ERROR 留给真正需要人介入的，业务预期内的失败（如库存不足）记 WARN，别让日志一锅粥。第三原则是结构化，把耗时、下游耗时、返回码都写成 key-value，别堆在 message 里靠正则解析。
大促前做一轮全链路压测，重点看两件事：一是 P99 延迟突变的节点——往往是某个没加索引的查询或没设超时的下游调用；二是依赖的扇出数，一个接口底层串行调 10 个下游，高峰期必然排队。
用链路视图按 service 分组看耗时分布，比翻代码找瓶颈快得多。压测时把采样率临时调到 100%，别让采样把你最想看的慢请求漏掉。
大促期间 CPU、内存这些机器指标反而不敏感——流量翻十倍，机器指标可能还在安全线内，但某个下游依赖已经超时了。所以告警要挂到业务指标上：
再配合降级开关：告警触发后能一键把非核心功能（推荐、猜你喜欢）降级，把资源让给核心链路。
大促结束后，把峰值 QPS、各服务 P99、错误率做一次归档，作为下次的基线。告警阈值据此校准，压测目标据此设定。可观测性不是一次性的改造，是每轮大促都在滚动的资产。