面向电商大促的可观测性方案：从流量预估、全链路压测到实时监控告警和故障演练，覆盖预热、秒杀、下单、支付全链路，给出可落地的时间表与关键指标。
大促和平时的区别不是“流量大了”，而是“流量形态变了”。秒杀场景里，流量在开抢后的几秒内冲到平时的几十倍，再迅速回落；预热、抢购、下单、支付几条链路在不同时刻轮流承压。传统监控按固定阈值配告警，在大促期间要么被刷屏淹没，要么对“流量突然掉到零”这种更危险的信号没反应。方案要解决的，是让团队在峰值之前就知道系统扛不扛得住，峰值期间 30 秒内发现异常，事后能复盘每一笔订单。
大促前两周，先从业务侧拿到预估峰值——通常是平时峰值的 3 到 5 倍，再乘以 1.2 的安全系数。用这个目标做全链路压测：不是压单个接口，而是模拟真实用户从“进首页 → 浏览 → 加购 → 下单 → 支付”的完整链路，压测工具按比例混合各环节流量。压测时重点看三个指标：接口 P99 延迟是否在 SLO 内、错误率是否低于 0.1%、下游依赖（数据库、缓存、消息队列）的饱和度。压测要用隔离的染色流量，并在可观测平台上打上 loadtest=true 标签，方便事后单独过滤分析，别和真实流量混在一起。
大促期间的告警策略要抓两头：既抓指标冲高（CPU、延迟、错误率超阈值），也抓指标骤降——订单量、支付量突然掉到零或掉一半，往往比飙高更危险。动态基线在这里很有用，因为大促的流量形态和平时完全不同，固定阈值必炸。建议给核心链路（下单、支付）单独建一套大促告警规则，P1 告警走电话加短信直接打到当班负责人，响应目标定在 1 分钟内确认、5 分钟内定位。同时把关键指标投到大屏，值班人员盯峰值时段的实时曲线，而不是一条条翻告警。
大促前一周做故障演练，别等到真出问题。演练清单至少包含：数据库主从切换、缓存击穿、消息队列积压、限流降级。每项演练都在可观测平台上制造真实故障（比如用混沌工程工具注入延迟），观察告警是否及时触发、值班人是否按预案响应、降级开关是否生效。演练产出的不是“我们演练过了”，而是一份更新的 runbook：每个故障对应谁负责、做什么动作、依赖哪个开关。
建议按这个节奏：T-14 天完成流量预估和压测准备，T-7 天完成全链路压测并修复暴露的瓶颈，T-3 天完成故障演练和 runbook 更新，T-1 天冻结变更、全员待命，峰值当天实时盯盘。已落地的客户里，大促期间 MTTR 普遍从小时级压到分钟级，秒杀链路的错误率控制在 0.05% 以下。可观测性在这里的作用不是事后查问题，而是事前就知道扛不扛得住、事中 30 秒内反应、事后有据可复盘。