评估必须从真实流量模型推导，资源申请必须分三批走，第一批提前两周锁定，第二批压测后调整，第三批大促前三天兜底，任何拍脑袋的翻倍预估都是在浪费预算或制造故障。
大促容量评估怎么做：别拍脑袋，用数据反推流量模型
容量评估的第一步不是算服务器要加多少台，而是算大促当天你的系统到底要扛多少QPS，行业共识认为大促流量不是均匀分布的，而是集中在开场15分钟、整点秒杀、晚间三个高峰，你需要把这些峰值时段单独拎出来算,不能拿全天均值当依据。
拉取历史数据作为基准线
打开你的监控系统，把最近三次大促（或S级活动）的流量曲线调出来,重点看这几个指标：
- 峰值QPS：入口网关层的真实QPS，不是业务层估算的
- 单机水位：峰值时刻CPU、内存、带宽的实际使用率
- 接口RT变化：RT从平日的多少毫秒涨到多少毫秒，超过200ms的接口往往就是瓶颈
- 资源消耗Top榜：哪个应用、哪个数据库实例最先扛不住
以历史峰值为基准，叠加业务增长系数，增长系数怎么定？不是拍脑袋，看两个数据：近半年日均UV增长率和营销部门预估的流量增幅。
用压测数据校准预估系数
历史数据是基础，但大促往往有新的营销玩法，比如新增了直播带货入口或跨店满减活动,这时候就需要压测来校准。
压测环境建议独立于生产环境，但数据模型和生产保持一致，实际操作路径：先按预估系数压一遍，逐步增加并发数，直到出现RT拐点或错误率超过0.1%，记录这个临界点的实际QPS,然后拿它和预估峰值做对比。
预估峰值 = 历史峰值QPS × （1 + 业务增长系数） × 营销活动加成系数
如果压测临界点低于预估峰值的80%，你得扩容预算就得往上调，对应的大促扩容方案也要重新做，这个系数校准必须在T-2周之前完成,留出资源调整时间。
区分核心链路和非核心链路
容量评估最容易犯的错误是全链路平摊资源，正确的做法是划分优先级：
- P0链路：登录、加购、下单、支付、库存扣减，这些一挂全完蛋，容量必须预留到预估峰值的5倍到2倍
- P1链路：商品详情、优惠券计算、购物车列表，允许降级，容量按预估峰值的2倍到1.5倍准备
- P2链路：个性化推荐、用户评价、物流查询，这些可以用弹性资源，随时扩缩容
下单链路和商品详情对资源的需求完全不同，下单对数据库的压力大，商品详情对缓存和带宽的压力大，你得按链路线路单独评估,不是给整个集群统一加机器。
大促资源申请流程：分三批提，每批有明确目标和审批规则
资源申请是很多团队的痛点，提多了财务不批，提少了技术背锅，核心矛盾在于预算审批节奏vs容量确认节奏，实际操作中,申请节奏应该和容量评估的成熟度挂钩。
第一批申请：T-2周锁定基数
这一批申请的是确定性资源，来自历史数据推导的基线容量，不需要等人拍板,直接用去年的峰值数据加上明确增长系数做测算。
- 申请量：预估基础负载的80%
- 资源类型：包年包月为主，预留实例为辅
- 审批重点：附上历史三年的大促曲线图，以及计算过程，让审批人看到数据依据
提前两周这个时间点是有讲究的，国内主流云厂商的包年包月资源扩容一般需要1-3个工作日完成，但大促期间所有企业都在抢资源，云厂商的库存也紧张，越是临近大促，资源越紧张,价格反而越高。
第二批申请：压测结果出来后动态调整
压测结束后，你会拿到实际的容量瓶颈数据，这时候需要做一个关键对比：压测发现的瓶颈点 vs 第一批申请的资源是否匹配，如果差距在10%以内，第二批申请就做微调就行，如果差距超过30%,需要重新审视预估模型。
这一批的资源类型建议全部用按量付费或弹性伸缩组，因为这些资源是临时性的，大促结束后要释放，申请时注意看云厂商的库存余量，如果你所在的区域资源紧张,可以考虑：
- 切换同区域的其他可用区
- 使用竞价实例或Spot实例跑非核心链路
- 提前把镜像和启动脚本准备好，缩短扩容时间
第三批申请：T-3天的兜底资源
有些团队会把批资源留到大促前一周再提，这是个危险操作，大促前三天所有的机房和云厂商资源都会进入高度紧张状态,这时候申请资源的审批周期比平时长得多。
第三批申请通常只做两件事：
- 运维巡检产出的临时性负载：比如日志收集任务、监控系统本身的资源占用
- 人工兜底资源：例如为数据库准备的只读副本，为缓存准备的备用分片
审批规则：这批资源不需要走预算流程，走紧急资源申请通道，如果你在第一批和第二批申请中已经做了充分准备，第三批资源量应该控制在总资源的10%以内,超过这个比例说明前面的评估有问题。
大促云服务器临时扩容价格对比
成本控制是大促扩容中躲不开的话题，包年包月单价最低，但大促后剩余时长就浪费了，按量付费单价高，但灵活性好。
竞价实例单价最低，但可能被中断回收。
| 资源类型 | 适用场景 | 成本特征 | 风险等级 |
|---|---|---|---|
| 包年包月 | P0链路基础容量 | 单价最低，存在浪费 | 无 |
| 按量付费 | 弹性扩展的峰值容量 | 单价较高，按秒计费 | 低 |
| 竞价实例 | 非核心链路或可容错任务 | 单价极低，约为按量1-2折 | 较高，可能被回收 |
大促结束后，要在一周内完成资源释放，很多团队大促结束忘了释放按量资源,结果下个月账单直接翻倍。
容量评估与压测的配合节奏：先评估后压测，压测倒逼评估修正
容量评估和压测不是两件事，而是循环校验的关系，评估给出一个预期值，压测验证这个预期是否可靠,一个标准节奏是：
第一步：静态评估（T-3周）
纯从历史数据和业务计划推导，不做任何线上操作，产出物是《容量预估表》，包含各链路预估峰值、资源缺口、预算预估，这个阶段重点做的是业务侧沟通，了解大促期间的促销计划、流量引入渠道、预期转化率。
第二步：全链路压测（T-2周）
按预估值的70%、100%、130%三档进行压测，70%档看系统整体表现是否稳定，100%档找瓶颈点，130%档验证缓冲容量是否够用，压测中重点关注数据库连接池、缓存命中率、消息队列积压量这三个指标。
压测的问题在于容易和真实流量有差异，存在一定的失真风险，这就是为什么压测发现的能力不能完全当作线上能力，需要乘以一个85左右的置信系数。
第三步：评估修正（T-1周）
拿压测结果和最初的静态预估做对比，修正资源申请量，如果压测发现某个服务单机性能低于预期，就需要在容量预估表中调高该服务的资源配额，修正完成后，输出最终版《大促容量评估报告》,包含：
- 预估峰值QPS及各模块分布
- 各链路的扩容比例和资源类型
- 弹性伸缩策略配置
- 应急降级方案
第四步：预案与封网（T-3天）
系统进入封网状态，不再做重大变更，容量评估工作收官，转入监控和应急值守，封网期间能做的只有扩容操作，不能改代码、不能调配置，运维团队按提前做好的伸缩策略执行，关注水位和容量,有问题走紧急预案。
容量评估的常见误区：宁可多申请也不要少申请，但成本不是从单台看出的
容量评估和资源申请在成本和保障量之间永远是博弈关系，少申请省了钱，但出了故障的损失更大，多申请浪费了预算，但保障了用户体验，在实际工作中,我见过太多团队在两者之间走极端。
只算平均负载，不算峰值
用全天平均QPS去估算资源需求，导致大促开场就把服务打垮，容量评估看的是峰值15分钟的水位，不是日平均值,这是最常见也是最致命的问题。
忽略单实例规格的差异
申请资源时，评估的是虚机规格、数据库规格、带宽规格的综合表现，很多团队只看了CPU核数和内存大小，忽略了磁盘IOPS和网络带宽的限制，压测中可能发现4核8G的虚机扛不住500QPS，需要换成8核16G才行,这就是规格差异带来的结果。
把全部资源放在一个地域节点
大促流量有明显的区域聚集性，你可以通过CDN调度和就近接入的原理，把部分流量分流到其他节点，但如果所有计算资源都在一个地域，到时候想扩容都没地方加,规划时就要考虑双地域或多可用区部署。
弹性伸缩规则只按CPU设置
系统表现的瓶颈不一定是CPU，内存泄漏会导致频繁GC，磁盘写满会导致业务无响应，弹性伸缩规则要有多维度触发条件：CPU超过70%、内存超过80%、RT超过500ms、队列积压量超过阈值,这些指标任何一个触发都应该扩容。
大促资源申请相关Q&A
大促容量评估怎么做最准确？
最准确的方式是三层数据叠加：历史大促流量曲线还原当天QPS形态，结合压测数据校准单机容量数值，再叠加业务增长系数和营销玩法加成系数，三类数据缺一不可，且整个流程要在T-2周之前跑完，经过这套流程得出的评估结果，准确度一般在80%至90%之间,剩下的误差通过弹性伸缩兜底。
大促前资源申请提前多久合适？
第一个时间节点是T-2周，申请基础包年包月资源；第二个时间节点是压测出结果后的T-1周，申请按量付费弹性资源；第三个时间节点是T-3天，申请兜底资源和预案资源，第一波太晚会遭遇云厂商资源紧张，第三波太早会浪费预算，因为大促前的最后三天是所有公司集中申请资源的时间窗口,审批效率和资源价格都会失去优势。
大促云服务器临时扩容价格贵吗？
按量付费的单价通常是包年包月的数倍，但总成本不一定更高，当你只用24小时或48小时，按量付费显然更划算，如果大促跨度三天以上且之后还要做复盘和运维观察，用按量付费或包周包月的方式更接近最优成本，竞价实例价格最低，但存在资源回收风险，只适合非核心链路或支持任务断点续跑的作业，用来跑数据分析、日志处理。