幂等、重试、审批与人工兜底设计
自动化最大的风险不是"不能用"，而是"出错了还在跑"。发货通知发了 5 遍、库存扣减了两次、退款重复执行——这些都是自动化缺乏错误处理机制的后果。这一节讲的不是炫技，而是让自动化安全运行的基本原则。
幂等性：为什么自动化会重复执行
Webhook 在网络不稳定时可能重复投递同一个事件。如果你的自动化没有幂等性保护，同一个事件可能触发两次动作：
sequenceDiagram
participant P as 平台
participant W as Webhook 接收端
participant A as 自动化动作
P->>W: 事件 A（第一次）
W->>A: 执行动作
P->>W: 事件 A（网络重试，重复投递）
W->>A: 再次执行动作 ← 问题所在
幂等性的实现方式： - 在执行前检查"这个事件/订单 ID 我是否已经处理过" - 如果已处理，跳过，不重复执行 - 使用平台提供的事件 ID 作为去重 key
幂等检查示例（伪代码）:
if (event_id in processed_events):
return # 跳过，已处理
else:
process(event)
processed_events.add(event_id)
重试机制的正确设计
自动化失败（网络超时、第三方 API 报错）时，要有重试，但不能无限重试：
| 重试策略 | 说明 | 适用场景 |
|---|---|---|
| 固定间隔重试 | 每 5 分钟重试一次，最多 3 次 | 通知类动作 |
| 指数退避 | 1 分钟、2 分钟、4 分钟… | API 调用类动作 |
| 不重试 | 直接失败，记录日志 | 幂等敏感操作（如扣款） |
重试后仍然失败怎么办： 进入失败队列，通知人工处理，而不是静默丢弃。
哪些动作需要人工审批
并不是所有自动化都应该全程无人干预。以下类型的动作建议加入人工审批节点：
flowchart TD
A[自动化触发] --> B{动作类型}
B --> C[金融类: 退款 > $100]
B --> D[高风险: 批量删除/修改]
B --> E[对外沟通: 批量邮件发送]
C & D & E --> F[暂停, 等待人工审批]
F --> G{审批结果}
G -->|通过| H[执行]
G -->|拒绝| I[中止并记录]
常见需要审批的场景： - 批量价格变更 - 超过阈值的退款 - 向客户批量发送邮件 - 删除/归档订单数据
人工兜底设计
任何自动化都需要一个"如果自动化失败，人工怎么接"的方案：
人工兜底设计模板:
自动化任务: 发货后自动发送物流通知邮件
失败场景:
- 邮件服务商 API 超时
- 用户邮箱格式异常
- 物流单号格式不匹配
兜底动作:
- 失败记录进入待处理列表
- 每日汇总报告发给运营
- 运营手动发送（有邮件模板可用）
监控:
- 每日检查失败队列数量
- 超过 10 条失败告警即时通知
自动化审计日志
每个自动化执行都应该留下日志，记录： - 触发事件（事件类型 + ID） - 执行时间 - 执行结果（成功/失败） - 如果失败，失败原因
这不是为了好看，而是在出问题时能快速排查："昨晚 2 点订单通知没发，是为什么？"
常见误区
- 自动化上线后从不检查日志：无声无息失败了好几周才发现
- 所有自动化都允许无限重试：某个 API 故障时，重试把第三方 API 打崩
- 没有人工兜底方案：自动化一旦失败，整个流程就断了
- 幂等性只靠"运气"（觉得重复投递概率很低）：低概率事件在高并发下是必然发生的
本节执行清单
- [ ] 检查现有自动化是否有幂等性保护（尤其是退款、发货类动作）
- [ ] 确认每个自动化的失败处理策略（重试策略 + 失败通知）
- [ ] 为高风险自动化动作加入人工审批节点
- [ ] 确认自动化执行日志的保存位置和保存时长
下一章：权限、审计与协作治理——自动化稳定之后，系统权限和团队协作治理是维持长期健康运营的基础。