自动化运维脚本错误恢复需分层设防：预判拦截、自愈修复、归档告警；通过set -e/-u/-o pipefail筑基，精准识别临时故障重试，指数退避限次，加timeout/flock/run_id防护，失败后打包归档并人工介入。
在自动化运维脚本中构建完善的错误恢复体系，不是加个 retry 循环就完事，而是要分层设防：能预判的提前拦截，能自愈的就地修复，不能处理的及时归档并告警。核心是让脚本“知错、扛错、止错、留证”。
一、用 set 命令筑起第一道防线
脚本开头必须启用基础防护机制，避免错误静默扩散：
- set -e：任一命令非零退出，立即终止脚本，防止后续操作基于错误状态继续执行（如备份失败后仍覆盖旧备份）
-
set -u：引用未定义变量时报错退出，杜绝因
$BACKUP_DIR拼写成$BACKUP_Dir导致路径为空、命令误删根目录等灾难 -
set -o pipefail：确保管道中任意环节失败（如
grep | awk中 grep 找不到内容），整个管道即视为失败，不被忽略
二、区分错误类型，只对临时故障重试
盲目重试比不重试更危险——语法错误重试100次还是错，而网络超时可能下一秒就好。关键在精准识别：
- 适合重试：timeout、Connection refused、No route to host、503 Service Unavailable
- 禁止重试：Permission denied、No such file or directory、syntax error、invalid option
- 实现方式：捕获
$?+ 读取 stderr 内容匹配关键词：
if [[ $? -ne 0 ]] && grep -q -E "(timeout|refused|unreachable|503)" "$LOG_TMP"; then should_retry=true; fi
三、带退避与限次的重试控制
固定间隔重试易引发雪崩或撞上限流。推荐最多 3 次，每次等待时间指数增长并加入随机抖动：
- 第1次失败后 sleep ≈ 1 秒
- 第2次 sleep ≈ 2 秒
- 第3次 sleep ≈ 4 秒
- 抖动示例：
sleep $(echo "scale=1; $((2**i)) * (0.8 + $RANDOM/32767*0.4)" | bc) - 循环结构建议：
for ((i=1; i
四、加防护层，避免恢复动作本身出问题
重试机制若失控，会成为新故障源。需叠加运行约束：
-
硬性超时：用
timeout 300s ./task.sh防止命令卡死阻塞整条流水线 -
唯一运行标识：生成
run_id=$(date +%s)-$$，用于日志命名、临时目录、锁文件，便于追踪和清理 -
防并发冲突：用
flock加锁，避免 cron 多次触发导致资源争抢：
exec 200>/tmp/mytask.lock; flock -n 200 || { echo "locked"; exit 1; }
五、失败归档与人工介入触发
重试耗尽即代表系统已无法自愈，必须强制转入人工响应流程：
- 将原始命令、完整 stderr、环境快照（
env、df -h、free -h）打包存入/var/log/mytask/failures/${run_id}_attempt3.tar.gz - 仅在最终失败时发通知：调用
mail -s "FAIL: mytask" admin@example.com ，或 <code>curl -X POST https://oapi.dingtalk.com/robot/send?access_token=xxx - 所有 cron 调用统一重定向日志：
0 2 * * * /opt/scripts/backup.sh >> /var/log/backup.log 2>&1
