电商大促是对系统容量与团队预案的一次集中考试。临时抱佛脚式的加机器效果有限，容量评估要在活动定档后立刻启动，按清单推进。
## 流量预估块
以历史大促与日常峰值为参照做流量预估：日常峰值乘以活动放大系数，再按去年同级活动校准。预估要拆维度：页面浏览、下单接口、支付回调的放大倍数不同，接口层通常比页面层放大更猛。核心链路单独标注，商品详情、库存查询、下单支付三条链路按最高标准准备。
## 压测验证块
预估需要实测验证。在隔离环境按预估流量的梯度加压，观察各链路的响应时间拐点与错误率，找到系统实际的容量上限，与预估值对照，缺口就是扩容的依据。压测要覆盖读与写两类路径，只压首页不压下单是常见的假阴性来源。
## 扩容与降级预案块
扩容提前执行，活动前完成资源到位与预热，临开场加机器是最被动的局面。降级预案同样重要：非核心功能在压力超阈值时自动或手动关闭，保住下单主链路；限流与排队机制提前配置并演练。预案的价值在于压力真实到来时不必临场决策。
## 监控值守块
活动期间专人值守监控：核心接口的成功率与延迟、库存与支付的队列深度、带宽与连接数曲线。告警阈值提前调优，避免告警风暴淹没真实异常。顺云控制台的监控告警可以直接覆盖这些基础指标，带宽与连接数的异常抬升也能第一时间看到。
大促结束后做复盘：预估值与实际值的偏差、降级预案的触发情况、资源浪费点，整理成下一次活动的基线数据。容量评估是滚动迭代的过程，每一场大促都在为下一场校准。