几年前秋天的一个凌晨两点多，我的手机响了。电话那头是一家 3PL 客户的运维主管，嗓子都哑了：WCS 刚升完版，输送线不动了，两台堆垛机停在巷道中间，出库任务在屏幕上越积越多。仓库里二十来个人站在传送带边上干等，天亮前还有两班卡车要走，晚一班就要被客户扣 SLA 分。
他们这次选的是整系统停机升级，图省事，一口气换完。结果新版 WCS 和旧版 PLC 驱动在握手协议上有个版本差，测试环境数据量小没暴露，生产一上，通信直接炸了。最后只能回滚，折腾到天亮，卡车排队，罚款照单全收。
这事之后我给所有客户立了条规矩：生产环境的 WCS，再小的版本也按滚动升级走。下面就是这套打法的完整复盘。
美国的仓库普遍老，世邦魏理仕的数据说十年以上的仓库占了全美仓库库存的 89%，平均房龄 34 年。老仓配老系统，WCS 升级是迟早的事。而行业里有个测算可以参考：一家 75 万平方英尺的仓库，计划外停机一小时的损失约 1 万美元。这就是 WCS 升级不敢停机的根本原因，停不起。
升级前夜：快照和备份才是真底气
滚动升级的第一步不是升级，是给自己留后路。
升级前夜要做三件事。第一，给 WCS 做完整快照：系统配置、任务调度规则、接口映射、PLC 程序版本号，一个都不能少。WCS 是承上启下的系统，上面接 WMS 和 ERP，下面连 PLC、输送线、堆垛机，任何一个环节的版本对不上，升级后都可能出怪问题。快照就是升级前的全家福，出事了按图索骥。
第二，数据库全量备份，外加一个明确的恢复点。光备份不够，还要在测试环境里实际恢复一次，确认备份是能用的。我见过太多备份了但恢复不了的惨案。恢复演练花半天，关键时刻能救命。
第三，准备两套安装包：升级包和回滚包。回滚包不是旧版本安装文件，而是带着数据逆向迁移逻辑的完整回退方案。如果新版改了数据库结构，回滚时必须能把结构和数据恢复到升级前。这一步很多人第一次都想不到。
还有一条：升级方案提前发给仓库运营负责人过目，让他知道每个阶段业务会受什么影响。技术方案再完美，业务方不知道你在干什么，升级当晚你的电话会被打爆。
升级当晚：备机先升，流量一点点往过挪
升级当晚我固定用一套时间线，屡试不爽。
晚上十点，业务进入低峰，先升备机。WCS 一般都有主备架构，备机升到新版之后跑一轮冒烟测试：入库、出库、盘点各走一单真实任务，看任务下发、设备响应、回告全链路通不通。这一步不碰生产流量，错了也不心疼。
十一点左右，冒烟测试通过，开始切一小部分流量。挑一条非关键的输送线，或者一个巷道，把它的任务切到新版 WCS 上跑。观察窗口至少覆盖一个完整的出库波次，波次里有订单释放、任务分配、设备执行、异常处理全套流程，一个波次跑顺了，新版的基本盘才算稳。这个阶段旧版还在跑大头业务，新版只是个试点。
午夜过后，开始逐节点铺开。一个节点升完，留出观察期，确认任务成功率、设备响应时间这些指标没有劣化，再升下一个。千万别贪快并行升多个节点，万一新版有坑，并行升级等于把坑同时挖在所有节点上，回都回不来。
凌晨三四点，业务量最低的时候，最后动核心节点：调度核心、数据库主节点。切换之前再确认一遍回滚包就位、决策人在场。
整个晚上，监控大屏前要有人盯。盯什么？任务堆积数、设备通信状态、异常任务比例。这三个数一不对，立刻停手，先诊断再决定是继续还是回滚。
回滚这条线，升级前就画好
很多人把回滚当成升级失败后的临场发挥，这是错的。回滚是升级方案的一部分，升级前就要写死。
触发条件要量化，写进方案里让所有人签字。比如：新版上线后异常任务比例超过平时基线的数倍、任务堆积超过一个波次的处理能力、关键设备通信中断超过约定的分钟数。达到任何一条，无条件回滚，不开会讨论。回滚决策最怕的就是再观察十分钟，十分钟之后问题更大。
回滚决策人只能有一个。提前指定，一般是运维负责人或者当晚的值班经理。他说回滚就回滚，事后复盘可以吵，当晚必须执行。
回滚之前，至少在测试环境完整演练过一次。演练要计时：从下达回滚指令到业务恢复正常，一共多少分钟。这个时间决定了你的升级窗口要留多长，升级窗口等于升级操作时间加上观察期，再加上回滚时间和缓冲。很多人算窗口只算升级操作，回滚时间不留，真出事就只能硬扛。
还有一个容易漏的：回滚之后的数据对账。新版跑的那段时间产生的任务数据、库存变动，要能完整地导回旧版，或者确认旧版能接着认。WCS 是实时系统，数据断档比系统停机更麻烦。
所以每次客户问我 WCS 升级怎么做，我的回答都是同一套：快照备份先行，备机先升，流量一点点挪，回滚线提前画好。
最后把回滚预案浓缩成几条，升级前逐条打勾：回滚决策人唯一且当晚在场；触发条件量化写进方案；回滚包和升级包一起准备、一起测试；测试环境完整演练过一次并计时；回滚后的数据对账步骤写清楚。这五条都打上勾，升级当晚你才能睡得着。
升级成功没人会记得，但一次漂亮的回滚，全仓库都会记得。
