工作流监控与告警设计：超时、失败重试与补偿

结论先行：工作流监控的目标是把"用户投诉才发现故障"变成"系统比人先知道"。设计分四层：节点级运行日志、关键指标埋点、分级失败重试、补偿事务兜底。做到这四层，90% 的故障能在 5 分钟内被发现，其中大部分还能自动恢复，剩下的人工兜底也有完整线索。

工作流搭完上线只是开始。真正考验团队的是凌晨两点支付回调失败、库存同步卡了一半、审批流卡在某个节点三天没人动——这些时刻监控体系在不在、好不好用，直接决定自动化是省心还是添乱。

一、运行日志与指标埋点

运行日志记录到节点级：每次流程运行生成一条主记录（触发时间、触发来源、最终状态），每个节点生成一条明细（开始时间、耗时、输入输出快照、错误信息）。排查问题时，先看主记录定位哪一次运行，再看节点明细定位哪一步出错，输入输出快照让你不用复现就能看清现场。

指标埋点盯三个数：成功率（目标 99% 以上）、平均耗时（环比突增 50% 即异常）、卡住数（运行中超过预设时长未流转的实例数）。指标每天出日报，突刺型异常靠实时告警，缓慢劣化靠日报趋势发现。

不是所有失败都该重试，按错误类型分级：

最后一行是重点：超时重试最大的坑是"对方其实成功了，你以为失败了又来一次"。任何超时后的重试，都要先查证（对账或状态查询）再决定是否重发。

一条流程跨三个系统：创建订单成功、扣库存成功、调支付失败。这时前两步已经发生，不能当作没发生过。补偿事务（Compensating Transaction）的思想来自 Saga（萨加）模式：每一步正向操作都预先定义一个反向操作，中途失败就按逆序执行补偿——取消订单、回滚库存。

用生活类比：网购下单后申请退货，商家不是"假装没卖过"，而是走一套退货退款流程把状态恢复。工作流的补偿同理，它不追求强一致，追求"最终状态说得清、回得去"。

告警必须分级，否则要么骚扰要么失灵：P1 级（资金、核心链路中断）电话加短信；P2 级（非核心任务失败）群消息通知；P3 级（重试后自愈）记入日报复盘。每个告警要带上下文：哪条流程、哪个节点、什么错误、运行链接，让值班的人 30 秒内进入排查状态。

以猫拽低代码（CatPull）为例：工作流引擎里每个节点可配置失败分支，重试逻辑用条件分支与循环节点组合实现，补偿动作用云函数代码节点编写，最终告警统一走 HTTP 请求节点推送企业微信与短信。可视化编排让补偿分支和正常分支一样清晰可见，接手维护的人不需要读源码就能理解整个恢复路径。

最后补一条经验：每月做一次"告警复盘"，统计误报率和平均恢复时长，删掉从不被处理的告警项——告警的有效性比数量重要得多。

A：瞬时错误 3 次、限流错误 5 次以内，并设置总时限（如 10 分钟）。重试次数过多会把对方故障放大成自己的雪崩；超过时限仍失败就进入人工或补偿流程，不要无限重试。

A：补偿本身也要重试与告警，连续失败升级为 P1 人工介入。更根本的做法是把补偿动作设计成幂等操作，并保留失败现场快照，让人工接手时能准确判断系统当前状态，而不是靠猜。

A：节点级明细建议保留 90 天在线可查，满足绝大多数排查需求；涉及资金与合规的流程日志按行业要求归档（通常 1~3 年）。归档日志要能按运行 ID 检索，否则等于没留。