ansible批量部署的可靠回滚依赖block-rescue-always结构化设计：block封装强依赖操作链并统一控制条件，rescue在block失败时执行确定性补救（如回滚配置、清理临时文件），always无条件执行收尾任务（如写日志、更新状态标记）。
Ansible 批量部署中真正可靠的错误回滚，不靠“重跑脚本”，而靠结构化设计——用 block 封装操作链、rescue 定义补救动作、always 保障收尾闭环。失败不是终点，而是触发预设恢复路径的明确信号。
用 block 组织强依赖操作
把必须一起成功或一起回退的任务放进一个 block。比如更新服务配置时，“备份原文件→写入新配置→重载服务”三步不可拆分：中间任意一步失败，后续就不能继续，否则系统会处于半配置状态。
- 所有任务共享统一条件（如
when: deploy_enabled），避免每个任务单独判断导致逻辑割裂 - block 内任一任务返回
failed（非 skipped 或 ok），立即中断，不“带病执行” - 适合场景：LVM 卷创建、数据库迁移前检查、中间件热更等有清晰成功边界的变更
用 rescue 做确定性补救
rescue 不是重试，而是你亲手写的“失败说明书”。它只在 block 明确失败时运行，且只执行一次。
- 典型动作包括：copy 回备份配置、清理临时目录、关闭残留连接、记录错误上下文到日志文件
- 可配合
fail模块主动触发 rescue，例如检测到目标路径不存在时提前中止，快速进入补救流程 - 注意：rescue 里的任务失败不会再次触发 rescue，也不会影响 always 执行
用 always 完成强制收尾
always 是真正的“无论如何都走一遍”，无论 block 成功、失败还是被跳过，它都会运行。
- 常见用途：追加时间戳日志到审计文件、更新部署状态标记（如
/var/run/deploy.status=failed）、重启监控探针、释放锁文件 - 其中任务失败默认只报 warning；如需严格保障，可在任务中加
ignore_errors: yes - 和 rescue 分工明确：rescue 解决“出错了怎么办”，always 解决“做完之后必须收什么尾”
结合幂等与续做机制提升容错
网络闪断或临时故障导致中断时，单纯靠 block-rescue 不够，还需配套机制精准续做。
- Ansible 自动生成
playbook.retry文件，记录失败主机；用--limit @playbook.retry只重试这些节点 - 配合
--start-at-task "任务名"跳过已成功步骤，避免重复操作（如重复安装包、重复启服务） - 确保关键模块幂等：用
yum/apt而非shell执行安装；用template替代command写配置；服务控制用systemd模块而非shell systemctl start
