失败了就再试一次，很符合人的直觉。放进自动化系统里，这个办法也有用，只是“再试一次”和“永远再试”，后果差得很远。
设想一个 AI 报告工具，外部服务短暂忙不过来，稍后重试可能成功。可如果用户上传的文件格式本来就错了，等待十次，也不会自动变成正确格式。两种失败都显示红字，需要的处理却不同。
重试适合有机会暂时恢复的问题。错误输入需要修正，权限缺失需要处理权限，把所有失败都交给时间，常常只会增加等待和费用。
服务越忙，立刻重试还可能越添乱。一千个任务同时失败，又同时回来，刚缓过来的服务再次被挤满。于是有了“退避”：失败后隔一段时间再来，必要时逐渐拉长间隔。再加一点随机差异，就能避免大家整齐地踩在同一秒。
AWS 的工程文章用模拟说明，加入这种随机错峰，可以减少集中重试造成的压力。具体效果与场景有关，不是所有系统都能直接套用同一个收益数字。资料：AWS 退避与抖动
但等待总要有尽头。任务到了重试上限，仍然失败，接下来怎么办？系统里常说的“死信队列”，名字有点吓人，其实是把难以自动处理的任务暂时隔离，留给后续排查。Amazon SQS 就提供这类机制。资料：AWS 死信队列
它更像快递站的问题件区。放进去，避免堵住正常包裹；但如果一直没有人查看，它就只是一个更整齐的遗忘角落。谁来接手，客户能看到什么状态，已经等了多久，都仍然影响服务。
重新处理时还有个细节：上一轮可能只完成了一半。报告没生成，额度却已经扣过；邮件没显示成功，实际可能已经发出。如果不先识别已发生的结果，补救可能制造重复扣费或重复发送。
因此，恢复流程既包括继续尝试，也包括停止自动尝试，并让问题进入能够处理它的人或环节。短暂失败有机会被平稳消化，长期卡住的任务也不该无声地躺着。
客户通常不需要知道重试了第几轮。他需要知道自己的事有没有办成；如果还没有，系统是否仍记得它，以及接下来还有没有一条说得清的去向。