给自动化脚本加了个「失败就重试3次」的逻辑，结果日志里全是假成功

前阵子写了个定时任务，每天凌晨自动跑数据同步。怕网络抖动，加了个「失败重试3次」的兜底逻辑，心里觉得稳了。

跑了三天，翻日志发现次次都是成功，看着挺舒服。但第四天我手动去核对目标目录，发现有三天的增量文件根本没落盘。

问题出在重试的判定上：我用的是命令的退出码，但那个同步工具就算网络断了也返回0，只是把错误写进了自己的日志里。我的脚本拿到0就当成功，重试逻辑压根没触发过。

踩坑细节记录一下：

1. 退出码不可信：有些工具（尤其带 GUI 的同步软件）不管成没成，进程退出码都是0。得去解析它的输出文件或者日志关键字，不能只看 $?。
2. 重试要带退避：我第一版是立即重试，三次挤在2秒内，网络一抖全撞墙上。改成指数退避（5s、15s、45s）后，失败率明显降了。
3. 重试上限撞满要报警：之前重试3次全失败也静默结束，第二天根本不知道。现在撞满就写一条醒目的 ERROR 到独立告警文件，顺手发个邮件。
4. 日志要能对账：每次重试单独记行，带上时间戳、退出码、本次耗时。别只记最终结果，否则出问题根本回不到现场。

改完之后我又拿两台机子跑了一周，故意拔网线、掐进程，确认重试真的触发了、告警真的收到了，才算完。

这种「假成功」最坑人，因为日志看着一片绿，人就不查了。

问一句：你们写定时任务的失败判定，是看退出码，还是去解析输出内容？有没有遇到过工具永远返回0的？