30.5 脚本与自动化最佳实践：可观测、可回滚、错误兜底

运维自动化脚本一旦上线，往往会直接操作生产环境，修改文件系统、防火墙规则、数据库记录，甚至启停服务。因此，一个合格的自动化脚本必须具备三个底层修养：让你清楚知道它在做什么（可观测）、出了问题能撤回变更（可回滚）、异常时不会让系统变得更糟（错误兜底）。这三点并非空洞的理论，都可以通过具体的技术手段来实现。

一、可观测：让脚本对自己“开口说话”

脚本在后台静默执行是最危险的状态——你只知道它结束了，却不知道中间发生了什么。良好的脚本应该像一个经验丰富的老手，会在关键时刻主动汇报进度和决策。

1. 输出带时间戳的结构化日志
不要只依赖 echo 的随意输出。尽量让脚本的每一条关键操作都带上时间、级别和消息，便于事后搜索和分析：

log() {
    echo "$(date '+%Y-%m-%d %H:%M:%S') [$1] $2"
}
log INFO "开始清理 /tmp 下的过期缓存..."

这样，即便脚本运行了几个小时，你也可以从日志中快速定位到某个步骤的开始和结束时间。

2. 重要操作前后显式确认
修改防火墙规则、重启服务、或删除用户前，脚本应清晰地告诉运维人员“我将要做什么”。对于破坏性操作，可以加上交互式确认（仅在手动执行时）：

read -p "即将删除用户 $USER，是否继续？(y/n) " -n 1 -r
echo
[[ ! $REPLY =~ ^[Yy]$ ]] && exit 1

对于无人值守的自动化任务，至少应在日志中用 WARN 级别注明高风险操作。

3. 通过返回值与状态文件暴露结果
不要仅靠“脚本最后没报错”来判断成功。可以约定在脚本结尾创建一个状态文件，包含成功/失败标志、处理数量等元数据，供监控系统读取：

echo "status=success" > /var/run/cleanup.status
echo "files_removed=$count" >> /var/run/cleanup.status

二、可回滚：让每一步都有退路

任何修改都不应该是一次性的豪赌。可回滚的设计意味着你拥有撤回操作的能力，它比失败后手动救火要体面得多。

1. 先备份，再修改
这是最朴素也最有效的保障。修改配置文件前，自动创建一个带时间戳的备份：

config_file="/etc/nginx/nginx.conf"
backup="${config_file}.bak.$(date +%Y%m%d_%H%M%S)"
cp "$config_file" "$backup"
sed -i 's/worker_connections 1024/worker_connections 2048/' "$config_file"

如果事后发现异常，一条命令即可恢复。更进一步，可以将备份文件路径输出到日志中，让回滚有明确依据。

2. 追求操作幂等性
理想的自动化脚本可以多次重复执行，而不会产生累积副作用。例如，创建用户前先检查是否已存在：

if ! id "$username" &>/dev/null; then
    useradd "$username"
else
    log INFO "用户 $username 已存在，跳过创建。"
fi

幂等性让运维人员可以放心重复执行脚本，将系统收敛到期望状态，而不必担心“执行一次是帮忙，执行两次是灾难”。

3. 事务式处理
对于涉及多步骤、文件或系统状态变更的操作，尽量模仿数据库事务：要么全部完成，要么全部撤销。一个简单的实现思路是记录修改清单，在脚本异常退出时让 trap 自动恢复备份。比如，脚本中维护一个备份文件路径列表，错误时遍历并恢复：

bak_list=()
cp /etc/hosts /etc/hosts.bak && bak_list+=("/etc/hosts")
cp /etc/resolv.conf /etc/resolv.conf.bak && bak_list+=("/etc/resolv.conf")

rollback() {
    log ERROR "发生异常，正在回滚..."
    for f in "${bak_list[@]}"; do
        original="${f%.bak}"
        mv "$f" "$original"
    done
}
trap rollback ERR

trap ... ERR 会在任何命令返回非零退出码时触发回滚函数，将已经改动的文件恢复原样。

三、错误兜底：意外发生时不雪崩

脚本在执行中会遇到各种意外：依赖的命令不存在、磁盘写满、网络超时、权限不足……如果对这些视而不见，一条命令的失败可能会破坏后续逻辑，甚至导致不可逆的数据损坏。

1. 启用严格模式
在 Bash 脚本开头加上：

set -euo pipefail

set -e：任何命令返回非零状态码时立即退出，避免带着错误继续执行。
set -u：使用未定义变量时退出，防止因拼写错误导致空变量被误用。
set -o pipefail：管道中任意一个命令失败，整个管道命令被视为失败。

这三项组合能让脚本在异常第一时间就停止，把损失降到最低。

2. 关键步骤显式检查
对于不能依赖 set -e 的复杂命令（例如 grep 在没有匹配行时返回非零，这可能不是错误），要手动检查返回值并给出清晰报错：

if ! docker pull "${image}:${tag}"; then
    log ERROR "镜像拉取失败，请检查仓库网络和标签是否存在。"
    exit 1
fi

3. 添加超时保护
操作远程服务或等待子进程时，应避免脚本无限期挂起。使用 timeout 命令为可能堵死的操作设置上限：

timeout 30s curl -fsSL "$url" -o /tmp/file || {
    log ERROR "下载超时或失败，URL: $url"
    exit 1
}

4. 防御性清理
使用 trap 确保脚本即使中途崩溃，也能清理临时文件或锁，避免留下垃圾：

tmpfile=$(mktemp)
trap "rm -f $tmpfile" EXIT

EXIT 信号会覆盖正常退出和因 set -e 导致的异常退出，保证临时文件总是被删掉。

5. 退避重试机制
对于网络抖动等瞬态故障，简单的退避重试比彻底放弃实用得多：

retry() {
    local n=1
    local max=5
    until timeout 5s "$@"; do
        ((n++))
        log WARN "第 $n 次重试..."
        sleep $((n * 2))
        if [[ $n -ge $max ]]; then
            log ERROR "重试已达上限，放弃执行：$*"
            return 1
        fi
    done
}
retry curl -fsSL "$url"

这种方式既给临时故障恢复的机会，又能避免长时间死等。

总结

在 Linux 自动化的世界里，一个脚本的价值不在于它能跑一遍成功，而在于它能否在环境变化、资源异常、使用者疏忽等复杂现实下，始终保持可预测的行为。可观测让你第一时间知道发生了什么，可回滚让你有底气大胆变更，错误兜底则是最后的安全网。当这些最佳实践内化成你的编码习惯时，脚本就会从“一次性用的危险品”变成同事口中“信得过的好工具”。