Ansible虽无原生断点续传，但可通过全局超时配置、任务级重试逻辑、rsync同步及.retry文件实现高鲁棒性：设connect_timeout、timeout、SSH复用；uri/command模块显式重试；synchronize模块启用--partial续传；.retry文件辅助定位失败任务。
Ansible 本身不提供“断点续传”式重试，但可以通过组合配置、模块特性和任务级控制，在网络不稳定或远程响应延迟时显著提升任务鲁棒性。核心思路是：**让失败可恢复、传输可续传、连接不中断、重试有节制**。
全局连接与超时加固
在 ansible.cfg 中统一设置基础韧性参数，避免逐个任务重复配置：
-
缩短连接建立耗时：设置
connect_timeout = 20（单位秒），防止 SSH 握手卡死 -
延长单任务执行窗口：设置
timeout = 120，尤其对编译、大包解压等长耗时操作更友好 -
启用 SSH 长连接复用：添加
ssh_args = -C -o ControlMaster=auto -o ControlPersist=600，减少反复建连开销 -
适度提高并发数：设
forks = 15（根据控制机资源调整），加快整体推进节奏，间接降低单任务排队等待时间
任务级重试逻辑（带条件判断）
对易受网络抖动影响的操作（如下载、API 调用），不用 rely on default retry，而是显式定义重试行为：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 用 uri 模块下载文件时，注册结果并循环检查状态码：
retries: 4+delay: 15+until: download_result.status == 200 - 用 command 或 shell 模块调用外部工具（如 curl、aria2c）时，直接利用其原生重试能力：
command: aria2c -c -x 5 -s 5 -k 1M https://example.com/app.tar.gz - 关键任务若允许临时失败，加
ignore_errors: yes，再用failed_when精确控制什么算真失败（例如仅当返回码为 127 才终止）
文件同步环节真正支持断点
copy 模块全量覆盖、无续传；synchronize 模块（基于 rsync）才是传输大文件的首选：
- 默认已启用
--partial和--inplace，中断后保留已传部分，重跑自动续传 - 显式指定
rsync_opts提升容错：- "--partial-dir=.rsync-partial"（暂存未完成块）- "--timeout=90"（rsync 自身超时，区别于 Ansible 层）- "--compress"（对文本类压缩传输） - 若需校验一致性，加
checksum: yes，但会增加首次比对时间
利用 .retry 文件做运维级恢复
.retry 文件不是技术层断点，而是快速定位失败入口的运维捷径：
- Playbook 执行失败后，Ansible 自动生成
playbook.retry - 重试只需：
ansible-playbook site.yml --limit @site.retry - 配合
--start-at-task "Deploy app"可跳过前置已成功步骤，聚焦故障点 - 注意：.retry 不记录任务内部状态（如某 rsync 传到 80% 失败），它只记录“该任务未成功”，所以仍依赖模块自身的幂等/续传能力
