先说结论:WMS对接的监控告警只有一套标准——接口挂了,监控必须比业务先发现。如果客服先接到客户投诉、仓库先发现单子下不来,那这套监控等于没配。我见过太多上线项目,接口文档写得漂漂亮亮,监控页却只有一个绿灯,绿灯的意思是服务器还活着,至于订单有没有真的流过去,没人知道。

2024年11月,华东一个做服装的客户上线新WMS,对接电商平台和快递系统。上线第三天早上,仓库主管打电话问我:为什么系统里一上午没新单?查下来是电商平台的订单接口凌晨2点就断了,中间件一直在重试,重试队列越积越长,到了早上8点积压了600多单。没有一条告警发出来——因为探活接口返回正常,真正传订单的接口早就不通了。客户的原话是:我们花钱上的系统,居然要靠仓库数单子来发现故障。这句话我记到现在。

WMS对接监控的四类告警,每类盯不同的死法

接口的死法有四种,对应四类告警,少一类就留一个盲区。

第一类是探活告警,盯接口通不通。但探活不能只探网关,要探到真正传数据的接口。上面那个服装客户的教训就是探活探错了地方:网关活着,订单接口死了。做法是每个关键接口单独探活,探活频率定在1到3分钟一次,连续两次失败就告警,别等第三次。探活接口本身要轻量,只返回状态,别在探活里查大表。

第二类是队列积压告警,盯数据堵没堵。订单、库存、出库回传各建一个队列水位线,超过阈值就告警。阈值别拍脑袋定:按这家服装仓的数算,平时每小时约400单,积压超过200单、持续15分钟,说明消费端已经跟不上了。这个阈值要在上线前夜用压测数据定下来,写进清单里,而不是上线后凭感觉调。

第三类是失败重试告警,盯数据丢没丢。重试三次还失败的单子必须进死信队列,并且立刻告警到人。最危险的写法是无限重试加静默丢弃——单子在日志里转了几圈,最后谁也不知道它去哪了。死信队列每天要有人清,清单里写清楚谁负责、几点清、清不掉找谁。

第四类是对账告警,盯两边数对不对得上。每天固定时间跑对账:WMS的出库数对平台的发货数、库存数对电商平台的库存数,差异超过约定值就告警。对账是最后一道网,前面三类都漏掉的故障,对账还能在当天兜住。没有对账的对接,上线就是裸奔。

告警类型 盯什么 触发条件示例
探活 接口通不通 关键接口连续两次探活失败
队列积压 数据堵没堵 积压超200单且持续15分钟
失败重试 数据丢没丢 重试三次失败进死信队列
对账 两边数对不对 日对账差异超约定值

三个翻车故事,都是监控没配全

这个坑我见过三次,每次死的姿势都不一样。第一个是上面说的服装客户,探活探错地方,订单接口断了6小时才被仓库发现。修复办法除了把探活改到订单接口,还加了一条业务量告警:每小时新增订单数跌到平时均值的30%以下,直接告警。机器状态正常但业务量断崖,本身就是故障信号。

第二个是2025年3月一个华南的3PL客户,对接了三家快递系统。有一家快递的回传接口间歇性失败,单号回传丢了,客服查不到物流信息,客户投诉量一周涨了三倍。查下来是失败重试没有死信队列,失败的回传在日志里躺着,没人认领。救回来的办法是补死信队列加每日对账,把丢了的回传按单号批量补推。那次之后我给所有项目加了一条铁律:没有死信队列的接口不许上线。

第三个最隐蔽:库存同步延迟。WMS库存变了,电商平台库存两小时后才更新,期间超卖了40多单。接口没断、队列没堵、重试没失败,前面三类告警全是绿的,只有对账能抓到它。库存同步的延迟阈值要单独设:核心SKU同步延迟超过30分钟就告警,别等日对账才发现。超卖的单子要取消、要赔礼、要处理差评,成本远高于一条告警的打扰。

反常识的一点是:告警不是越多越好。告警泛滥的团队最后会把所有告警都当成噪音,真正出事时也没人看。我的做法是分级:探活失败、死信产生、对账差异超标,这三类半夜也要叫醒人;队列积压、同步延迟这类先发工作群,白天处理。分级不清的监控,等于没有监控。

告警发给谁,比告警本身更重要

告警链路的最后一环经常被忽视:告警发出去了,收到的人能不能处理。我见过告警发到项目群,群里二十几个人,没一个人认领,最后还是客户打电话来才有人动。告警必须落到具体的人,写清楚主负责人和备份人,备份人不是摆设,主负责人半小时内没响应,告警自动升级到备份人,再没响应升级到项目经理。升级链路要在系统里配好,不能靠群里喊一嗓子。

告警文案也要说人话:哪条接口、几点几分、影响多少单、第一步该查什么,写在告警正文里。只写"接口异常"四个字的告警,值班的人半夜爬起来还得先翻日志找接口,等于把故障定位的时间白白送掉。好的告警文案长这样:订单接口探活失败,2分钟内两次无响应,当前积压约180单,先查中间件日志,再看平台侧状态页。值班的人照着做,五分钟就能判断是自家问题还是对方问题。

还有一个容易踩的坑:告警通道本身不能依赖被监控的系统。短信通道、邮件通道、企业微信机器人,至少备两条互相独立的路。主通道挂了,告警发不出去,监控再全也是聋子。通道每月测一次,测的就是通道本身通不通,别等到真出事才发现机器人 token 过期了。

上线前夜清单,逐项打勾再签字

上线前夜 checklist 是我每个项目必走的流程,清单上的每一项都要有人签字,不能口头说"差不多了"。

  • 每个关键接口的探活已配好,探活地址是真实业务接口,不是网关首页
  • 订单、库存、回传三条队列的水位阈值已按压测数据定好,写进清单
  • 死信队列已建,重试三次失败自动进死信,死信产生即告警到负责人
  • 日对账任务已排好时间,差异阈值和告警接收人已确认
  • 业务量基线已定:每小时订单量跌破平时均值30%即告警
  • 告警接收人有备份:主负责人休假或关机时,备份人能收到
  • 演练已做过一次:人为断掉一个接口,看告警能不能在5分钟内到人
  • 回滚方案已写好:接口长时间不通时,手工导单的流程和责任人是谁

最后一条演练最容易被跳过,也最重要。没演练过的告警链路,上线当天第一次响,很可能发错人、发错群,或者干脆发不出去。演练花半小时,能省下线当夜的六小时救火。监控告警这件事,标准只有一个:下一次接口挂掉,第一个知道的人应该是值班工程师,而不是仓库主管和客户。

作者:林晓|WMS实施顾问,做过30+上线项目