Ansible 的 changed=0 给了我什么把握

“部署成功”如果只看命令退出码，还少问了一件事：同一套配置再执行一次，会不会继续改动服务器？在这台个人服务器上用 Ansible 维护配置后，我把重复执行的结果也纳入验证。如果每次都显示变更，就很难区分正常重复执行和配置漂移。

把可重复执行当成要求

现在仓库里的 Playbook 管基础软件、Caddy 配置、站点目录和静态内容。修改前先跑 check/diff，看它准备动哪些文件；正式执行后再跑一遍，期望结果是 changed=0。它表示这套配置对当前主机而言已经收敛，重复执行不会继续覆盖文件。网站文案几次变更后，我也用这个结果确认模板部署没有留下反复改写的任务。

这不只是一个好看的统计数字。比如一个任务每次都复制同样内容却仍报 changed，我会怀疑权限、模板内容或任务条件。反过来，如果我在服务器上手工改了受管文件，下一次执行出现 diff，也能及时发现仓库和实际状态不一致。对个人项目来说，这种反馈降低了“只有当时的我知道改过什么”的风险。

部署静态页面时，我也尽量让页面、标题和路径都有一个明确来源。文章正文在站点源文件，目录和摘要在同一个清单里，页脚的公开备案号由站点配置注入。否则即使 Playbook 每次运行都没有变化，也可能只是它一直在重复部署一套内容分散、难以审查的配置。幂等性要和清晰的配置归属一起看。

它不能证明网站可用

changed=0 只说明 Ansible 在自己管理的范围里没看到需要改动的地方。它不会证明 DNS 指向正确服务器，也不会证明公网证书被普通客户端信任，更不会自动确认文章链接和备案页脚。我的验证因此分成几层：先检查 Playbook 的预期 diff；部署后检查 Caddy 配置与服务状态；再从公网按两个域名请求页面，检查 TLS、HTTP 状态、跳转、内容和链接；最后重复执行 Playbook。

曾经清理公开站点的旧备份文件时，这个区别尤其明显。Playbook 可以显示文件处理任务已收敛，但是否还能通过旧 URL 取到文件，必须用公网请求去验证。被管理的文件状态与用户能看到的实际结果，要分别取证。

类似地，更新文章时不能只看目标文件有没有变化。我会从外部打开首页、记录列表和文章详情，确认新文章不是一个没人能点到的孤立页面；也要检查两个域名是否显示一致。页面越多，这类“可到达性”检查越有价值。Playbook 负责把文件放到对的位置，外部请求负责确认读者真的能走到那里。

把数字放回变更过程

我更愿意把 changed=0 看作“可重复部署”的一个证据，而不是运维质量总分。每次变更要留下检查、实际部署、服务验证和记录。若检查模式或正式执行出现意外 diff，就先解释原因，再决定是否继续；若公网验证失败，即使最终显示 changed=0，也仍是未完成的变更。

目前这套做法适合我的单机基础配置。以后加入数据库或其他有状态应用时，幂等性仍重要，但数据迁移和恢复需要自己的验证，不能被一个 Playbook 结果概括。

对我而言，真正安心的不是某一次绿色输出，而是隔一段时间再回来看，仍然知道配置从哪里来、服务器上应该是什么样、怎样证明网页正常。changed=0 是这条链上的一个清楚信号；它之所以有用，正因为旁边还有 diff、日志和公网访问结果可以互相校验。