大促保障:预案、压测与值守全流程 — editorial cover photo

大促零事故背后,是一整套保障体系

双 11、618 这种大促,拼的不只是平时系统建设,更是一整套保障体系。

2025年9月27日·返回文章列表
文章大纲

系统在平时跑得稳,不代表大促扛得住。这是很多团队吃过亏才明白的道理。大促的流量是平时的几十倍,平时藏着的所有问题,容量不足、单点依赖、慢 SQL、连接池打满,在流量洪峰下会被成倍放大并集中爆发。平时一个跑五十毫秒的慢查询,平时无所谓,大促时几千 QPS 压上去,数据库连接池瞬间耗尽,整个链路雪崩。

大促保障的核心,是一套从一个月前就开始的系统工程,绝非事发后的临时救火。平时建设打底,赛前准备排雷,赛中值守兜底,赛后复盘沉淀,四个阶段缺一不可。靠这套体系,才能把一个平时撑得住的系统,在特定的一天里稳定撑住几十倍的流量。

PlantUML
正在加载图表…
PlantUML diagram

图:大促保障四阶段全流程——赛前准备排雷、赛中值守兜底、赛后复盘沉淀

T 减三十天,容量评估与全链路压测

准备工作从大促前一个月开始。第一步是容量评估,根据历史大促数据和今年预期,预估峰值 QPS。然后是全链路压测,在生产环境用真实流量模型验证系统能不能扛住这个峰值。

全链路压测不是简单地发点请求。它要模拟真实用户的访问路径,下单、支付、查物流,整条链路打通,用影子库隔离压测数据,靠流量染色保证压测请求不污染真实业务。压测分阶段推进,基线摸底、容量探顶、稳定性长时间跑、极限破坏,逐步把系统的真实极限逼出来。

压测的价值在于提前暴露瓶颈。哪些是单点,哪些服务扛不住,哪些 SQL 在高压下变慢,这些在大促当天发现就来不及了,必须在压测阶段逐个修复。修复完重新压,直到系统稳定扛住目标 QPS。重点要盯那些不易快速扩容的层,数据库、缓存、带宽,这些扩容慢的资源一旦在大促时成为瓶颈,没时间救。

T 减十五天,预案全部预配置

PlantUML
正在加载图表…
PlantUML diagram

图:四类应急预案——降级、限流、扩容、熔断,全部预配置进配置中心,一键触发

预案是大促时能一键触发的应急手段,分几类。降级预案,关闭非核心功能如评论、推荐、统计,压力大时把资源让给核心交易。限流预案,入口限流阈值预设多档,正常、警戒、极限,按压力逐级收紧。扩容预案,弹性资源预先备好,一键扩容脚本就绪。熔断预案,依赖故障时自动熔断快速失败,防止级联雪崩。

预案的灵魂在于预配置。大促当天没时间现想降级什么、怎么降,所有开关在大促前就配进配置中心,值班人员根据大盘压力一键触发。临时想方案是来不及的,预案的全部价值就在于提前想好,到时候直接执行。

预案要配更要演

预案配好不等于能用。降级开关配了但代码里有 bug 触发不了,熔断阈值设了但实际不生效,这些只有演练才暴露。T 减七天必须实战演练,模拟各类故障,逐一验证降级、熔断、告警、值守流程都真的有效。配了不演的预案,大促时大概率掉链子,那时候才发现开关失灵已经晚了。

T 减七天,演练与排班

预案不能配了就放着。T 减七天组织实战演练,模拟数据库挂掉、缓存雪崩、核心服务超时等各类故障,验证降级开关是否真生效,熔断是否如期触发,监控告警是否及时,值守流程是否跑得通。演练发现的问题,开关不生效、告警延迟、人员配合脱节,立刻修补。

值守排班也在这个阶段定下来。大促值守是多角色协作,总指挥负责全局决策,何时降级、何时扩容、何时熔断。各系统技术负责人现场处置故障。DBA 和运维保障基础设施。业务和客服处理业务侧响应。还有专门的沟通角色负责故障的对内对外通报。每个核心岗位都要有人在现场或随时到位,不能大促时现找人。

大促当天,监控与分级响应

PlantUML
正在加载图表…
PlantUML diagram

图:大促当天四大实时大盘投屏 + P0/P1/P2 分级响应机制

大促当天,多个大盘实时投屏。业务大盘看 GMV、订单量、支付成功率,这是业务健康度。技术大盘看各服务 QPS、RT、错误率。资源大盘看 CPU、内存、带宽、数据库负载。应急大盘看哪些功能已降级、哪些熔断已触发、活跃告警有哪些。值班人员盯着这些大盘,任何异动第一时间发现。

应急响应要分级。P0 级别影响核心交易的故障,必须总指挥决策,执行预案,通报相关方。P1、P2 级别值班直接处置,事后记录。分级是为了让总指挥的注意力集中在真正要命的故障上,而不是被一堆小问题淹没。所有处置过程都要记录,便于事后复盘。

最考验人的时刻是流量超出预期。预估的容量不够了怎么办。应对顺序是固定的,先扩容,资源有余量就扩。扩不动了就限流,调低入口阈值保护后端。还扛不住就降级,关掉非核心功能。核心原则只有一条,保交易。宁可关掉评论推荐,也要保住下单和支付这条命脉。这个取舍在大促前就要对齐,不能当天才争论要不要降级某个功能。

T 加一天,复盘沉淀

大促结束不等于任务结束。复盘是经验沉淀的关键环节。数据复盘,对比实际和预估,容量预估准不准。故障复盘,出了什么问题怎么处置的,响应够不够快。预案复盘,哪些预案用上了,哪些没用上,没用的要不要保留。最后产出改进项,系统、流程、预案的优化,而且要跟踪落地,不能复盘完就束之高阁。

每次大促的复盘都是宝贵经验。第二次大促比第一次从容,靠的就是第一次的复盘沉淀。这套保障体系做透了,受益的不只是大促那几天,平日的稳定性建设也会水到渠成。大促保障是对系统能力和工程纪律的一次极限压测,能扛住大促的系统,平日里自然更稳。我做过的营销侧大促,把零资损作为硬目标,正是靠这套预案、压测、值守、复盘的闭环一点点磨出来的。

Continue Reading

关联文档推荐

查看全部
降级开关治理:统一管控与一键熔断 — editorial cover photo容量治理:水位监控与弹性伸缩 — editorial cover photo缓存雪崩与击穿的系统化防御 — vibrant cover for technical blog article
作者:archy.shawn
声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。