按运维工单的格式写这篇，原汁原味。
| 时间 | 动作 | 结论 |
|---|---|---|
| D0 晚 | 监控告警：某零售商线路 856 已发出 48 小时未收到 997 | 超时阈值触发，进入人工排查 |
| D1 上午 | 查 AS2 传输层：MDN 回执正常，对方服务器已签收 | 报文确实送达，不是通道问题 |
| D1 下午 | 联系对方 EDI 支持，提供报文控制号、时间戳、MDN 证据 | 对方确认：收到了，卡在其内部映射队列，因我方一个可选字段长度触发其新校验规则 |
| D2 | 按对方要求微调字段，重发；同批受影响的 6 张报文一并处理 | 997 全部回到 A（接受），闭环 |
这件事的价值不在处理，在发现
如果没有"997 超时告警"这条规则，会发生什么？856 发出去了，传输层也成功了，所有人都以为没事——直到货到了 DC，收货系统里没有 ASN，扣款单过来，才回头翻三周前的报文。那时候排查难度和沟通成本完全是另一个量级。
所以我们的托管运营里有一条铁律：每一张出向报文都必须有回执闭环。997 没回来的报文不叫"发送成功"，叫"下落不明"。
月度报文对账
除了实时监控，每月还做一次全量对账：我方发出数、对方 997 确认数、异常数，三个数对齐后归档。听起来笨，但"统计数字用两条独立路径交叉核对"这个习惯，帮我们提前发现过不止一次系统性问题。
选服务商的时候可以问一句："你们怎么知道一张报文失败了？"如果答案是"零售商会通知我们"——那通知你的不会是邮件，是扣款单。