大促流量是平时的几倍到几十倍，故障每分钟都是损失。本文讲如何用链路追踪找慢点、压测找瓶颈、按 SLO 设告警分级，并做好回滚限流预案。
大促保障最容易犯的错是只盯着扩容：加机器、加缓存、加带宽。但真正让人在大促夜里失眠的不是容量不够，而是「不知道瓶颈在哪、不知道什么时候开始变慢、出事之后不知道先回滚哪个」。这三件事，都是可观测性的问题。
容量可以通过压测提前算出来，但线上慢点、热点、依赖抖动是压测模拟不出来的，只能靠实时的链路追踪和指标来发现。可观测平台在大促里的角色，就是把「能加多少台机器」升级成「能多快发现问题、多快定位、多快恢复」。
大促前用全链路压测模拟峰值流量，压测数据进平台后，看的不只是整体吞吐，而是链路里每个服务的 P99 延迟和依赖关系。一个典型的发现是：整体 TPS 达标，但某个下游服务的 P99 已经顶到超时阈值，正式大促时它就会成为木桶最短的板。
下单 → 库存扣减 → 优惠计算 → 支付 → 订单落库
↑ P99 1.8s（超时阈值 500ms）定位到慢点后，再决定是加缓存、加实例还是改代码，而不是凭感觉全量扩容。
大促期间的告警要分得比平时更细。先给核心链路定 SLO，比如「下单成功率 ≥ 99.9%、P99 ≤ 500ms」，再把告警按影响分级：
关键是把阈值提前一天调严，避免「正式流量进来才报警」。同时把无关紧要的低优先级告警静默，让值班人只看到真正需要处理的。
故障快恢靠预案，预案要提前演练，演练要可观测。三个常见动作：
把这几个动作的观测指标提前建在仪表盘上，大促夜里就不用现拼数据。