ansible 健壮执行的关键是区分真错误与业务信号，而非简单忽略错误；应使用 failed_when 结合 register 捕获输出语义判断失败，配合 block-rescue 实现原子操作与补偿，用 when 实现条件分支，并通过 any_errors_fatal、serial 等控制错误传播范围。
Ansible 默认将非零返回码视为任务失败并中断执行，但真实运维场景中，很多命令的“异常码”其实是预期行为（比如 grep 未匹配时返回 1）。要构建健壮的执行链，关键不是屏蔽错误，而是**区分哪些是真错误、哪些是业务信号**——再据此决定继续、回滚还是告警。
用 failed_when 精准捕获业务级失败
比 ignore_errors 更安全的方式，是让 Ansible “读懂”命令输出的语义。例如检查服务端口是否监听，nc -z localhost 8080 成功返回 0，失败返回 1 —— 但这个 1 只代表“没连上”，不等于“配置出错”。这时应结合输出内容做判断：
- 只在真正异常时失败：比如检测到进程崩溃日志才标记为失败
-
把退出码转为变量再判断：用
register捕获结果，再用failed_when写条件表达式 -
避免硬编码数字：用字符串匹配（如
'timeout' in result.stderr）比result.rc != 0更贴近实际意图
用 block-rescue 封装有状态变更的操作链
当一组操作必须原子性完成（比如停服务→改配置→启服务），中间任何一步失败都可能导致系统半瘫痪。block 不是容错开关，而是定义“成功边界”：
- block 内任务共享同一个成败判定逻辑：任意一个失败，立刻跳出，不执行后续步骤
- rescue 不是重试，而是补偿：比如配置写错了，就从备份还原；端口被占用了，就 kill 掉冲突进程
- always 做收尾确认：无论成败，都记录时间戳、清理临时文件、发通知——确保可观测、可追溯
用 register + when 实现条件跳过与分支处理
有些任务失败后，后续流程要走不同路径。比如证书检查失败，就该触发申请新证书流程，而不是直接报错退出：
-
先注册结果：用
register: cert_check把命令输出存下来 -
用 when 分支控制：后续任务加
when: cert_check.rc == 0或when: "'EXPIRED' in cert_check.stdout" - 避免嵌套 rescue：复杂分支逻辑更适合用条件任务，而不是层层 block 套娃
全局策略：控制错误传播范围
单台机器出问题，是否要让整个滚动更新停下来？这取决于部署目标：
- any_errors_fatal: true：适合核心数据库集群，要求所有节点状态严格一致
- serial: 1：配合错误处理，实现“逐台验证+即时回滚”，降低爆炸半径
- ignore_errors: yes 要慎用：仅用于明确知道失败无害的场景（如检查某个可选工具是否存在）
