首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >大促备战清单:从容量评估到预案演练的完整流程

大促备战清单:从容量评估到预案演练的完整流程

原创
作者头像
PikeTalk
发布于 2026-11-01 07:40:52
发布于 2026-11-01 07:40:52
870
举报

大促备战清单:从容量评估到预案演练的完整流程

每年大促,技术团队都会经历一次「备战」。有的团队从容不迫,大促当晚按表操课;有的团队通宵达旦,靠人肉盯着大盘救火。差别不在技术水平,而在备战流程是否体系化。本文按时间线梳理一份可以直接套用的大促备战清单——从大促前一个月到当晚的作战手册。

一、T-30 天:容量评估——先算清楚要扛多少

容量评估是一切备战的起点,算错了后面全错。三步走:

流量预估:从业务侧拿到大促的流量预估(运营活动的力度、投放渠道、去年同期倍数),按入口拆分。经验公式:大促峰值 ≈ 日常同时在线峰值的 N 倍(N 由活动力度决定,一般大促 3~5 倍,S 级大促 8~10 倍)。入口流量再按调用链路比例拆到每个服务——推荐位点击率、详情页到下单的转化率,用历史数据算,不要拍脑袋。

单机容量标定:每个核心服务做压测,拿到单实例的容量上限(QPS)。注意压测环境要与生产配置一致,压测数据要回放真实流量模型(读写比例 8:2 和 5:5 的容量完全不同)。标定结果写成容量卡片:服务、单机 QPS、生产部署数、总容量、预估需求、缺口。

缺口盘点与扩容:拿总容量对比预估需求,缺口部分提前扩容。扩容要预留发布验证时间——扩上去的机器要跑过一轮真实流量再睡得着。特别盘点三类资源:数据库连接数(扩应用容易把 DB 连接打爆)、消息队列的堆积能力、带宽(静态资源大促当晚上涨最凶的往往是带宽)。

二、T-15 天:全链路压测——验证不是估算

容量评估是算出来的,全链路压测是打出来的。在接近生产的规模上,用流量回放或模型压测验证全链路:

压测流量隔离:全链路压测必须有流量染色(压测标记随上下文透传全链路)、影子表或影子库(压测数据不污染真实数据)、下游挡板(不发真实短信、不真扣款)。这是压测体系的基本盘,没有隔离方案的全链路压测本身就是事故。

分级加压:从日常峰值的 1 倍开始,按 20% 阶梯加到目标容量的 120%(留 buffer)。每一级观察 10 分钟:错误率、RT 分位值、DB 连接数、缓存命中率。瓶颈会自己浮出来——通常是意料之外的点(某个没人在意的同步调用、某个无界队列)。

瓶颈修复与回归:每个瓶颈修复后重新压过该档位。压测报告归档,明确「系统在 X QPS 下可持续、1.2X 下出现 Y 瓶颈」——这是当晚容量决策的依据。

三、T-7 天:预案与降级清单——写好当晚的剧本

预案分级:把可能的故障场景写成剧本:某服务 RT 飙高 → 触发什么降级;DB CPU 90% → 限流阈值收到多少;MQ 堆积 → 哪些消费可以停。每个剧本四要素:触发条件(量化指标,不写「压力大」写「下单 RT P99 > 800ms 持续 5 分钟」)、执行动作、执行人、验证方式。预案落在预案平台上可一键执行,而不是文档里的命令行。

降级开关验证:所有降级开关逐一真实验证(在压测环境或低峰期生产开 10 分钟)。重点验证数据降级的恢复路径——降级容易恢复难,开关关掉之后,降级期间积压的异步数据有没有补写、对账任务能不能对平。

依赖方确认:对外依赖(支付渠道、短信通道、第三方登录)逐个确认大促容量和降级政策;对内确认跨团队的支持值班表。大促当晚最怕的消息是「这个依赖我们组没人值班」。

四、T-3 天:封网与作战室

封网变更:T-2 或 T-3 起停止一切非紧急发布。封网前把已知问题清零——带着已知 bug 进大促,当晚它一定会在最忙的时候跳出来。紧急修复通道预定义好(审批链路缩短、值班 TL 有权放行)。

值班安排:作战室(线上会议或线下会议室)排班表:每 2~4 小时一轮班,每班有总指挥、核心链路值班、DBA/中间件值班。值班表贴在显眼处,当晚任何人找得到对应的人。总指挥的职责明确:只做决策不做操作,所有跨团队动作经过总指挥,避免两个人同时按两个开关。

监控大盘:当晚作战大盘提前做好:核心链路的业务指标大盘(下单 QPS、成功率、支付成功率)放在最显眼处,比技术指标大盘优先——业务指标掉是结果,技术指标掉只是原因,先看结果再找原因。

五、当天:按表操课

整点巡检:从 19:00 开始每半小时一次全链路巡检(清单化:每个核心服务的错误率、DB/缓存水位、MQ 堆积),值班表轮转执行。整点高峰前(20:00 预售、0 点正式开抢)提前 30 分钟全员就位。

分级响应:P3(局部抖动、自动恢复)值班处理并记录;P2(单服务异常)值班 + 服务 owner 处理,通知总指挥;P1(核心链路下跌)全员响应,总指挥决定是否降级。所有决策走作战室群广播,关键动作(降级、扩容、限流)喊出来再做。

留证与复盘:当晚所有操作记时间线(谁在几点几分按了什么开关),监控大盘录屏。结束后 48 小时内复盘:瓶颈在哪、哪个预案起了作用、哪个预案没用上或失效——复盘结论写进下一年的容量评估输入,这是备战体系滚动变强的闭环。

结语

大促备战的本质是把「当晚的不确定性」在之前的 30 天里逐步消灭:容量算清(T-30)、瓶颈打实(T-15)、剧本写好(T-7)、变更锁死(T-3)。当晩需要临场发挥的东西越少,系统越稳。这份清单里的每一项都平平无奇,但每年都能完整走完的团队,大促当晚大概率在正常下班。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 大促备战清单:从容量评估到预案演练的完整流程
    • 一、T-30 天:容量评估——先算清楚要扛多少
    • 二、T-15 天:全链路压测——验证不是估算
    • 三、T-7 天:预案与降级清单——写好当晚的剧本
    • 四、T-3 天:封网与作战室
    • 五、当天:按表操课
    • 结语
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档