ignore_errors: yes 仅对模块执行完成但返回 "failed": true 的情况有效，如安装不存在的包、访问不存在的文件或重启未部署的服务；对连接失败、变量未定义、语法错误、模块名错误等解析或运行时异常完全无效。
ignore_errors: yes 能让任务失败后继续执行，但只对模块正常运行但返回 "failed": true 的情况有效；它对连接失败、变量未定义、语法错误、主机不可达等完全无效。
哪些失败能被 ignore_errors 拦住
这个参数只在任务“跑完了但结果是 failed”时起作用。典型场景包括：
-
yum或apt安装一个已卸载或不存在的包（如name: old-monitor-agent state: present） -
shell执行ls /etc/myapp/config.yaml，部分节点路径不存在 -
service重启一个仅在部分节点部署的服务（如name: fluentd state: restarted）
这些任务会输出 "failed": true，加 ignore_errors: yes 后 Ansible 继续执行，该主机最终统计为 ok，且不会触发 handlers（除非同时设 force_handlers: yes）。
哪些失败它根本拦不住
ignore_errors 对以下情形完全无效，Playbook 会直接中断：
- 主机
UNREACHABLE（网络不通、SSH 失败、目标关机）→ 必须用ignore_unreachable: yes - 变量未定义（
Undefined variable: 'foo'）→ 需提前用default或is defined判断 - YAML 语法错误（冒号后少空格、缩进混用）→ 运行前用
ansible-playbook --syntax-check检查 - 模块名写错（如把
copy写成cp）→ 报MODULE_NOT_FOUND，属于解析阶段失败
真正可靠的容错要分层做
别指望单靠 ignore_errors 实现“柔性部署”。正确做法是组合控制：
- 把非核心节点（如监控、日志、备份节点）单独归入
[monitoring]或[logging]主机组 - 为该组写独立
play，不与[web]、[db]混写 - 在该 play 中，对具体任务加
ignore_errors: yes+failed_when精准过滤（例如failed_when: result.rc not in [0, 1]） - 若节点偶发离线，在对应 task 上加
ignore_unreachable: yes（注意：不能写在 play 级别）
最常被忽略的一点：ignore_errors 不影响 changed 状态判断，也不自动抑制 handlers 触发——如果任务失败但被忽略，又恰好满足 notify 条件，handler 仍不会运行，除非显式启用 force_handlers: yes。
