大促是电商可观测能力最集中的考试。这篇讲压测容量基线、实时大盘、告警降噪、降级预案四件事怎么做，加上全链路压测与弹性扩容，以及链路追踪如何支撑降级决策。
大促是电商可观测能力最集中的一次考试。平时跑得好好的系统，流量翻几倍之后，隐藏的瓶颈会一次性暴露。这篇讲大促前后可观测平台要做的几件事：压测容量基线、实时大盘、告警降噪、降级预案，再加上全链路压测与弹性扩容，以及它们各自的具体做法。
大促前的第一件事不是加机器，而是压测。用可观测平台记录压测期间的指标，建立容量基线：
压测数据沉淀成基线后，大促当天就能实时对照：某个接口的 QPS 一旦逼近基线的 80%，提前预警，而不是等它被打挂。注意压测要尽量贴近真实流量模型——纯读接口压得再高，也代表不了下单链路里的写放大。
单接口压测只能暴露单点瓶颈，大促真正的问题是链路级放大——下单会带起库存、优惠、风控、支付一串下游。全链路压测要把真实业务流量（或回放的线上流量）打进整条链路，观察每个下游的 QPS 和延迟，找出木桶的最短板。回放流量要脱敏，避免把真实用户数据打进压测环境。
大促期间值班盯屏，屏幕上的图不是越多越好。建议就盯五个数：核心下单链路成功率、支付成功率、核心接口 p99、库存与优惠券服务健康度、错误率突增告警。其余信息按需下钻，避免噪声淹没真正的问题。大盘要提前建好、提前演练，别到大促当天才发现某个面板的数据源没接上。
流量翻倍时，告警也会翻倍，很多其实是"误报"：CPU 高是因为正常扩容，慢查询是因为预热。提前把告警规则按场景分组，大促期间启用专门的静默窗口和聚合策略，只保留影响交易的关键告警，值班的人才能看清真正的火情。
有了基线，扩容就不靠拍脑袋。把核心接口的 QPS 基线接入伸缩策略，QPS 逼近 80% 时自动扩容，回落到 40% 以下自动缩容，既扛住峰值又不白烧钱。扩容要先于流量到达，因为新实例有冷启动、连接池建立的开销，别等到已经打挂再扩。伸缩阈值要结合基线的拐点来设，而不是拍一个固定百分比。
大促最怕的是雪崩。链路追踪在这里的价值是：当某个下游扛不住时，你能从 span 树看清楚"砍掉这一跳会牵连多少入口"。降级决策要有数据依据——先砍非核心的推荐、积分这些旁路，保住下单和支付主链路。降级开关要提前演练，不能到当天临时找开关。
大促结束不是终点。把当天的真实峰值、瓶颈点、降级决策记录回基线，下一次大促的压测目标和扩容阈值就更有依据。可观测平台把这些数据保存下来，复盘时按时间轴回看每个关键时刻的指标和链路，比事后靠记忆靠谱得多。大促的稳定性就是这样一轮一轮堆出来的。