让自动化远离生产故障

在 CI 里跑一次 Ansible playbook 可能要几十分钟，但一条带 become: yes 的 play 在生产节点上执行错了，影响可能是一批服务器的配置漂移。更常见的是，一个拼错的 when 条件、一个在 role 里未声明的依赖、一个在 staging 被忽略的 handler，等到真正 push 到生产环境才暴露问题。

把静态检查放进交付链路

这个技能的思路很简单：在把 playbook 或 role 合入之前，先让 ansible-lint 把仓库里所有相关目标扫一遍。它不执行 playbook，而是做静态分析，把容易触发故障的模式提前拦下来。

常见可以被发现的问题包括：

• tasks/main.yaml 中引用了不存在的 variable 或未声明的 dependency
• playbook 里 handlers 与 tasks 命名冲突，或 handler 永远不会被 notify 到
• YAML 结构可以运行但语义不完整，例如条件表达式缺少关键变量判断
• role 的 meta/main.yml 声明依赖缺失，导致依赖安装顺序不可靠
• 使用了不具备幂等性的 module 写法，例如 command/shell 缺少 creates、removes 或 changed_when

技能如何工作

该技能面向 playbooks、roles 和 collections 三类目标运行 ansible-lint。核心是找到仓库里的 Ansible 代码，按规则集执行检查，并把结果作为 CI 步骤的输出。

它适合放在已有的 CI pipeline 中，作为合并前的一个 gate：

• 在拉取代码后直接扫描本地 Ansible 源文件
• 按默认规则集运行检查，也可以根据项目需要传入自定义配置
• 输出规则 ID、命中文件与片段，方便定位问题
• 只有 lint 通过后，才允许继续执行语法检查、容器化测试或真实部署

适用边界与注意点

ansible-lint 是静态检查，不替代真实运行测试。它可能漏掉只有在特定 inventory 或 target 环境下才出现的行为差异，也可能对业务上合理但形式特殊的 pattern 给出 warning。建议把 lint 结果视为必修项之一，而不是唯一质量门禁。

使用时注意：

• 在 CI 中固定 Python 与 Ansible 的版本，避免规则版本漂移导致结果不稳定
• 对历史仓库先整理 .ansible-lint 配置，逐步引入规则，而不是一次性开启所有规则
• 结合 yamllint 或 CI 中的 YAML 校验，减少格式类问题反复触发
• 不要把 lint 检查放在部署步骤之后，应该在代码合并前完成