面向电商大促的稳定性方案：用历史数据建基线、压测找瓶颈、链路追踪定位慢节点、分层告警防止值班人被淹没，以及大促后复盘沉淀为明年基线，覆盖大促前中后三个阶段。
大促不是流量翻倍那么简单。流量是脉冲式的：秒杀开始的前 60 秒，下单接口的 QPS 可能瞬间从 2000 涨到 20 万，然后回落。这种脉冲对数据库连接池、缓存、消息队列的冲击，比稳定的高流量更难扛。而且大促期间不能随便重启、不能随便回滚，留给故障处理的时间窗口以分钟计。
可观测平台在大促前的作用，是帮你把“感觉扛得住”变成“有数据撑腰”。三步：
OBSERVE 里可以用 SLO 给核心接口定目标，压测时盯着错误预算的消耗速度，提前暴露瓶颈。
大促当天，最怕的是“整体变慢但不知道慢在哪”。一次下单要经过网关、订单、库存、支付、物流十几个服务，任何一个环节抖动都会拖慢整条链路。
OBSERVE 的 Trace 会把一次下单的完整调用链串起来，每个 Span 记录耗时、状态和下游调用。排查时先按延迟排序找出最慢的 Trace，再定位到具体 Span——是库存服务的 Redis 慢查询，还是支付网关的下游超时，几分钟就能锁定。
配套的做法是给核心链路设延迟告警：当 P99 超过阈值持续 3 分钟，自动触发告警并附带慢 Trace 采样，值班人打开告警就能看到现场。
大促期间告警量会暴涨，如果所有告警都打到同一个人，值班人很快会麻木。建议三层：
OBSERVE 的告警收敛可以把同一个根因引发的多条告警合并成一条，附带受影响的服务列表，避免“一个数据库挂了，几十条告警刷屏”。
大促结束后，把当天所有的告警、慢 Trace、容量数据拉出来做复盘：哪些告警是误报、哪些瓶颈没提前发现、哪些容量估算偏差大。把这些结论沉淀成明年的基线，可观测的价值才会逐年累积，而不是每年从零开始。