Ansible Playbook 调试器

你要解决什么问题

Ansible playbook 失败时，报错往往又少又晚：ansible-playbook 只在失败任务处抛一行 FAILED，真正的原因要从 --verbose 输出、stderr 和日志里拼凑。--check 模式下更麻烦：你只看到一堆任务“无变更”，却很难定位是哪个参数、哪种状态或哪个前置条件出了错。一次失败排查的耗时，常常超过写这个 playbook 本身。

技能如何工作

技能组合了三个互补的诊断面：

• 预演优先：用 ansible-playbook --check --diff 先空跑，在真实变更落地前拿到差异范围，避免把修复动作本身变成一次事故。
• 静态 + 动态检查：ansible-lint 负责规则与反模式扫描；Ansible 回调插件 API 挂到任务生命周期钩子上，在任务开始、结束和失败时抓取上下文与结果。
• 解析与归因：解析任务执行结果，对照 ansible.builtin 以及 community collections 中常见模块错误的已知模式，输出建议的修复方向。

典型流程是：跑 --check --diff → 读 ansible-lint 报告 → 回调插件抓取失败任务上下文 → 给出结构化诊断和修复建议。

适用边界与注意点

• 它覆盖的是执行期与规则期的问题；角色结构设计、库存组织、变量优先级这类设计期决策仍要自己判断。
• --check --diff 不是万能：部分模块对 check 模式支持有限，输出可能为空或不完整，必要时需配合真实 dry-run 验证。
• 修复建议基于 ansible.builtin 和常见 community collections；遇到冷门模块、插件或自研模块时，归因能力会明显下降。
• Ansible 面向临时任务执行、网络自动化与多节点编排；如果场景要求严格的声明式状态管理，还要单独审视幂等性约束。
• 模块可以不限 Python 开发，所以排查时不能只盯着 Python 运行时，还要检查模块自身的入口逻辑。