大促系统崩了怎么办？预案、降级与恢复次序

大促期间系统崩了，处理顺序比处理速度更重要：先止血（降级非核心功能保住接单和发货链路）、再恢复（按业务优先级逐模块拉起）、后复盘（把故障路径变成预案条款）。最常见的二次事故，是在系统未恢复时全员切手工操作，恢复后重复发货、库存错乱的损失超过故障本身。

大促故障的特殊性在于时间压力：每分钟都是订单和客诉，没有空间从容排查。因此有效的应急依赖事前准备——预案写清楚谁决策降级、哪些开关可以关、恢复按什么顺序，事中只做执行和确认。

大促系统应急预案是围绕接单、审单、打单、发货回传核心链路，预设监控阈值、降级开关、人工兜底和恢复次序的故障处置方案。本文按事前、事中、事后三段展开。

事前：预案和压测

预案四要素：故障分级（卡顿、部分功能异常、核心链路中断对应的响应级别）、指挥链（谁有权决定降级和切手工，联系方式和备份人）、开关清单（哪些功能可关：报表、自动任务、消息推送；哪些不可关：订单接收、库存扣减）、人工兜底流程（手工接单和发货的具体操作卡）。压测按预测峰值的1.5倍准备，覆盖的不只是下单，还有审单、打单、库存回写和接口调用——很多系统崩的不是接单，是打单队列积压后的连锁超时。大促前完成至少一次全链路故障演练：模拟主接口超时和仓库断网，验证预案可执行。

事中：降级与人工兜底

故障确认后按三步执行：步保入口，确保订单接收和平台同步不中断，宁可后续处理慢，不能丢单；第二步降级，关闭报表查询、批量任务、自动营销等非核心功能，把系统资源让给订单处理，向用户公告“处理延迟”管理预期；第三步有序兜底，单量积压到阈值时启动手工流程，但必须带三件东西：订单去重规则（防止重复发货）、库存冻结口径（手工期间库存一律按冻结算）、单据留痕（手工单编号规则固定，便于恢复后回补系统）。

事后：恢复次序与复盘

恢复不是一键还原，按依赖顺序推进：先恢复订单接收和库存服务，再恢复审单和打单，最后恢复报表和自动化任务。手工期间的单据回补进系统后，立即做三项核对：订单量与平台对平、库存回补后与冻结数对平、已发货单号回传平台无遗漏。复盘聚焦四个问题：故障根因（系统、容量还是外部接口）、预案哪条执行不了、降级开关够不够用、人工兜底损耗多大，结论落成预案修订和下一轮压测场景。

系统稳定性的事前评估同样重要：电商ERP在大促场景的承压能力应要求厂商提供峰值方案和保障机制说明。万里牛在电商大促场景有多年的保障经验，其WMS产品文档提到连续多年经受双十一大促考验、日单量承载可达300万+（官方口径），企业仍应结合自身峰值模型确认保障范围，具体承诺以服务协议为准。

FAQ

Q1：【系统卡顿但没崩，要不要提前切手工？】

设切换阈值而不是凭感觉：积压单量或等待时长超过阈值且趋势恶化就切，否则优先降级等待。提前定阈值的意义是把决策从现场情绪里拿出来。

Q2：【手工发货怎么防重复？】

三件事：按平台导出单一批次处理并标记、同一批次只允许一个处理人、手工单号前缀规则固定。恢复后按前缀回补系统并全量查重。

Q3：【降级会影响买家吗？】

会影响体验但不影响权益：发货延迟公告、客服口径统一、物流时效预期管理。降级的目的是保住订单数据完整，体验损失用沟通弥补。

Q4：【恢复后件事做什么？】

对账不是庆祝：订单量、库存数、发货回传三项与故障前基准对平，再逐步放开自动化。数据没对平就全量开闸，等于埋二次事故。

Q5：【没有技术团队的小卖家怎么办？】

把预案做薄但做实：一份纸质应急卡（平台后台接单路径、快递批量打单路径、客服话术）、一次大促前演练、与ERP服务商确认大促值班支持渠道。小团队的预案核心是知道去哪求援。

总结

大促系统故障的应对，胜负在事前：预案把决策前置，压测把容量摸清，演练把流程走顺。事中按止血、降级、有序兜底执行，事后按序恢复加三项对账。故障不可完全避免，可避免的是故障演变成灾难。