"Ansible Playbook的任务控制 day5"—— 写这篇的时候，我正在收拾一台刚被跑挂的测试机。这个 day5 不是课程编号，是我自己给自己定的一个系列笔记，专门梳理 Playbook 里那些“任务的执行逻辑”。很多人写 Ansible 停留在写 task、写 handler、跑 playbook 能过就行，但真正到生产环境会发现：任务什么时候执行、失败了怎么办、怎么只做一次、怎么让一组任务按批次滚动，这些才是运维自动化能不能落地、敢不敢落在关键节点上的分水岭。

1. 任务控制的整体思路：搞懂 Playbook 是怎么“跑”起来的

1.1 任务控制到底控制什么

Ansible 的 Playbook 本质上是对“目标主机最终状态”的描述，而任务控制就是决定“达到这个状态要走哪些路径、在什么条件下走、走不动怎么办”。很多新手容易把 Playbook 当成“一堆命令的集合”，这个理解会让后续的排错和维护非常痛苦——因为命令是线性执行的，但 Playbook 的任务是有状态的、有依赖的、有分支的。

举一个最典型的场景：你要在几十台业务机器上部署一套应用，需要先停服务、传文件、解压、改配置、再启服务。如果你只是机械地写 20 个 task 从头跑到尾，一旦中间某一步失败，Ansible 默认就是“立即中止，后续动作全部不执行”。这个默认行为其实很有价值，它避免了你把一套残缺的配置丢到生产环境里。但问题在于：有些失败是可以容忍的，有些失败是需要重试的，有些成功在你眼里其实不算是成功——比如执行 systemctl status 返回了非零状态码，但它恰恰说明服务已经停了，这正是你想要的“成功”。

所以任务控制要解决的就是三个核心问题：

• 什么时候做（when、tags、run_once、serial）
• 怎么做才算成功（changed_when、failed_when、ignore_errors）
• 失败之后怎么办（block/rescue/always、until、最大失败比例）

这套东西梳理清楚了，Playbook 就不再是一串命令脚本，而是一套有弹性的自动化流程。我见过不少同行，写 Playbook 的时候任务之间全靠“但愿能一次跑通”来维系，出问题就靠手工补，这样还不如回到 shell 脚本时代——至少 shell 里你还能写 if 和 trap。Ansible 给了我们更结构化的控制能力，不用就是最大的浪费。

1.2 理解 Playbook 的执行模型

在深入具体关键字之前，得先建立执行模型的整体印象。Playbook 的执行单位有三级：Play（剧本）、Task（任务）、Handler（处理器）。一个 Play 负责确定“在哪批主机上跑”，Task 是真正执行的动作，Handler 是任务的“后续回调”——只有在任务确实对系统造成了改变时，Handler 才会被触发。

这个模型里最容易被忽略的一点是：任务之间并不是“数据库事务”的关系，而是“命令逐条执行”的关系。你可以通过控制关键字把一组任务扭成事务性的，但默认不是。另一个容易忽略的点是：每个 task 都会收集并返回一个结构化结果（变量名为 task 注册的结果，比如 result），这个结果里包含了 stdout、stderr、rc、changed 等字段，后续的判断和重试全都依赖这些字段。所以任务控制其实是一套“基于结果的决策系统”，理解了这一点，再去看 when、until、failed_when，就会发现它们都是围绕结果的语法糖。

我在实际运维中习惯先画一张“执行流程图”，不用画多复杂，但要把每个任务可能的出口标清楚：正常退出、失败退出、被条件跳过、被 when 分支跳转、被 rescue 捕获后继续。画完这张图，Playbook 的骨架基本就出来了。很多人写 Playbook 是写一步想一步，这在 playground 上没毛病，但在生产 Playbook 里，分支和异常路径不提前想清楚，迟早要填坑。

2. 条件判断与状态覆写：让任务只在正确的时候跑

2.1 条件触发：when 的进阶用法

when 是任务控制里最基础、也最容易写烂的一个关键字。初级用法没什么可说的：when: ansible_facts['os_family'] == "RedHat" 这种基于 facts 的判断。但生产里真正有嚼头的是这样几个场景：

第一，基于注册变量。比如你先跑了command: cat /etc/app/version，注册成 result，然后下一个任务在 when: result.stdout != "2.3.1" 时才执行升级。这里要注意的是，result.stdout 是字符串，字符串比较是精确匹配，如果你期望的是版本号比较——2.10 大于 2.9——纯字符串比较是不成立的，得先转成列表再比较，或者用 version 类型的过滤器。这个坑我踩过两次，因为 Ansible 里版本号看起来都是字符串，但升序比较的逻辑不是字典序。

第二，when 和 loop 的组合。loop 里的每个 item 会单独代入 when 判断，也就是 when 可以引用 item 上的字段去做过滤。比如你有一个交换机端口列表，每个端口字典里有 enable 字段，你可以when: item.enable == True，这样循环就只对需要操作的端口生效。这不只是省事，而是让数据驱动配置的玩法真正成立——同一套 Playbook，喂不同的数据，跑出不同的结果。

第三，when 的隐式列表。Ansible 支持在一个 when 下面写列表形式的多条条件，列表内是 AND 关系，比如：

- name: 重启应用 ansible.builtin.service: name: "{{ app_name }}" state: restarted when: - result_health.stdout == "unhealthy" - inventory_hostname in groups['app_node']

注意这里是 AND，不是 OR。如果要 OR，得显式写or。这个微小的差异我见过让人排查了半个小时的案例——列表里写两个条件，想表达“这个或者那个”，结果系统按 AND 处理，任务怎么都不触发。

2.2 状态覆写：changed_when 和 failed_when

刚开始学 Ansible 的人多半不理解：一个任务返回的状态，我还能改？但实际场景里非常需要。比如 shell 脚本执行 curl 探测某个接口返回码：

- name: 检查服务健康 ansible.builtin.shell: "curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/health" register: health_result failed_when: health_result.stdout != "200" changed_when: false

这里的逻辑非常清晰：任务本身是“检查”，不产生状态变化，所以 changed_when 给 false，避免每次跑都触发一堆 handler；而失败标准不再是 rc 是否非零——curl 大多数时候即便拿不到正确响应也会返回 0——而是以业务层面的 http_code 为准。这就是 failed_when 的意义：把“任务的技术状态”转译成“业务的成功标准”。

还有一个常用场景是清理类任务。比如删除旧日志文件，用ansible.builtin.find拿到文件列表后，把列表数量作为判断条件去决定是否要触发日志轮转。如果我们不覆盖 changed_when，find 类型的任务本身不会改变系统状态，不会触发 handler，但你发现它每次跑都显示 ok，而不是 changed——这是对的，但如果结合后续的 restart 任务，就希望“找到文件才改变、没找到就别动”，这时把 changed_when 设置为found_files.matched > 0就有了语义层面的准确表达。

我得给一条实操建议：在你把一台新机器纳入管理前，先把所有检查类任务的状态覆写规则写清楚。否则大量 ok 状态会让你慢慢失去对 Playbook 变化的敏感性——你不再注意哪次是 changed，因为整个界面永远是黄的。我后来养成的习惯是：输出里看到哪个任务异常变成了绿的，先过问一句“它为什么绿了”，状态覆写写清楚了，这个直觉才有意义。

3. 循环与批次控制:一个任务,按清单执行

3.1 循环：loop 实践与 with_* 的取舍

循环是 Ansible 任务控制的另一个核心，围绕它的关键词演进也很有意思。Ansible 早期提供了 with_items、with_fileglob、with_dict 等一大堆循环关键字，每个都有各自的行为和细节差异。到了 Ansible 2.5 之后，官方主推统一的 loop 关键字，并且逐步把 with_items 等标记为“迁移形态”。

我的建议很直接：新写的 Playbook 一律用 loop + 过滤器组合，不要在触及 with_*。理由很实在：loop 的行为是一致的，它只负责“把列表交给任务去执行”，至于这个列表怎么从字典、文件、嵌套结构里生成，交给 lookup 和过滤器来算。举例来说，with_dict 能做的事，用loop: "{{ my_dict | dict2items }}"就能做到，而且得到的是一个标准化的 items 列表，后续在任务里再用 item.key、item.value 访问，可读性比 with_dict 的的 item.key 更直观。

嵌套循环是 loop 的一个经典痛点。场景是：你有一批数据库实例，每个实例下面有一批库，想把它们全部遍历出来执行备份。如果直接嵌套两层 loop，内层的 item 会把外层的 item 覆盖，结果就会出错。解决办法是写个临时变量：

- name: 批量备份数据库 ansible.builtin.shell: "mysqldump -u root {{ item.db_name }} > /backup/{{ item.outer }}_db_{{ item.db_name }}.sql" loop: "{{ db_instances | product(backup_dbs) | list }}" loop_control: loop_var: item

啧，上面这个写法其实还是用了 product，但你会发现 item 变成了一个二元组。我实际更常用的做法是先在内存里把它组装成一个组合列表，再交给 loop，这样每个 item 就是一个干净的字典，里面同时有外层实例名和内层库名，后续的代码就不会被嵌套搞乱。组合列表的做法可以在 vars 段里用 set_fact 或直接在模板里用 Jinja 表达式完成，不过组合过程得先验证一下数据格式，不然 loop 拿到半拉子结构，所有子任务全炸。

循环还有一个细节：loop_control 的 pause。有的场景不希望循环一口气打个几十上百个请求出去，要控制节奏——比如批量创建一堆云主机，API 有频率限制，那就在 loop_control 里加 pause: 2，每个循环之间暂停两秒。这个对保障批量任务的稳定性极其有实用价值，我几乎所有涉及外部 API 的批量任务都会加 pause，免得把生产环境的服务打成限量状态。

3.2 批次与执行位置：serial、run_once 和 delegate_to

如果循环管的是“一个任务跑多轮”，那 serial 管的是“一个 Play 在多个主机上怎么滚动”。默认情况下，Ansible 会同时向 Play 里所有主机执行任务——这在十几台机器的场景下问题不大，但在几十上百台的生产环境里，应用升级同时打到所有机器上，只要新版本有问题，基本就是全线崩溃的“滚动灾难”。serial 就是为这个场景设计的：它把主机列表切成一批批，每批执行完再继续下一批。

- name: 升级业务集群 hosts: app_nodes serial: 10 tasks: - name: 拉取新版本 ...

serial 的值可以是一个数字，也可以是一个列表，比如 [1, 5, 10, 20]——先一台试水，没问题再五台、十台、二十台阶梯放大。这在大型集群上几乎是标准配置了，第一次跑先单台验证，确认没问题再逐步放量，非常契合变更管理的灰度思想，比一把梭稳妥太多了。

run_once 解决的是另外一类需求：有些动作只需要在整批主机中执行一次，而不是每一台都执行一遍。最典型的是集群中的初始化任务，比如生成一个共享的 SSH key，或者批量注册一批节点，这些动作天然不需要每台都做。run_once 直接加在任务上即可，配合 delegate_to 指定在某台具体的机器上执行，效果更好：

- name: 生成共享密钥 ansible.builtin.shell: "ssh-keygen -t ed25519 -f /tmp/cluster_key -N ''" run_once: true delegate_to: localhost

注意 run_once 的一个细节：加了它之后，任务只在第一个主机上执行，但其他主机的执行列表中这个任务也会被标记为“跳过成功”，这会让日志看起来像是“有部分未执行”——别慌，这是设计行为。另外，在 run_once 任务里引用 inventory_hostname 时要格外小心，它指向的是第一个主机，如果你需要的是“当前正在执行的那一台”，得用 ansible_host 或显式指定 delegate_to。

还有一个我常看到误用的点：delegate_to 改变的是“任务的执行地”，但变量解析还是以“目标主机”为基准的。这在运维网络设备、负载均衡这类场景时要特别注意——比如你要在一个代理机上执行 curl 去探测后端服务，但想判断的是某一台具体的后端机器，那你在 hostvars 里的变量引用不能绕开主机维度，得写成hostvars[target_host]['some_var']才可以。任务控制一半靠关键字，一半靠对变量作用域的清晰认知，这两者交叉在一起，才真正体现出 Playbook 的编程感。

4. 失败恢复与执行策略：不是所有失败都需要停

4.1 失败容忍度：ignore_errors 与它的替代方案

ignore_errors: true应该是很多新手最常用的失败容错手段——“我不确定这步一定会成功，但失败了也不影响整体推进，就先忽略掉吧”。这个用法在生产里非常危险，因为它会把真正的错误也一起吞掉，后续任务在残缺状态下继续跑，最后产出一个“看着成功了，实际上全是坑”的结果。

实际上更精细的容错方案几乎都能用 failed_when 替代。比如删除一个可能不存在的日志文件，shell 里 rm 遇到文件不存在会返回非零，但你并不认为这是失败。与其 ignore_errors，不如写成：

- name: 清理过期日志 ansible.builtin.shell: "rm -f /var/log/app/old_*.log" failed_when: false changed_when: false

这样“失败”这个语义没有了，但任务仍然保留执行信息，后续还能注册变量去判断实际行为。又比如命令行工具本身 rc 不可控，你想精确确认“是否达到了目标状态”，完全可以注册变量后，在后面配合一个 assert 或者 debug 任务做二次校验。我自己习惯的做法是：凡是忽略失败的任务，后面一定跟一个检查任务，用 when 判断上一个任务的注册结果是否符合预期，这样“忽略”只发生在前置阶段，最终出口仍然是被校验过的。

还要区分一下 ignore_errors 和 block/rescue 的关系。ignore_errors 是任务级的“不管不顾”，block/rescue 是结构化的“异常处理”。只要是有后续逻辑要处理失败的场景，都应该优先用 block/rescue，而不是 ignore_errors 然后靠手工判断。ignore_errors 只适合“失败完全无影响且不需要做任何后续动作”的场景，这种场景在实际运维里比想象中少得多。

4.2 block、rescue、always：Playbook 里的 try-catch-finally

如果对编程语言熟悉，block/rescue/always 的语法可以说零学习成本。block 里放一组任务，rescue 在 block 里任意一个任务失败时执行，always 无论成功还是失败都会执行，类似 finally。

- name: 部署应用主流程 block: - name: 拉取新包 ansible.builtin.get_url: url: "{{ pkg_url }}" dest: /tmp/app.tar.gz - name: 解压 ansible.builtin.unarchive: src: /tmp/app.tar.gz dest: /opt/app/ rescue: - name: 清理半成品 ansible.builtin.file: path: /opt/app/ state: absent always: - name: 清理临时文件 ansible.builtin.file: path: /tmp/app.tar.gz state: absent

这个结构的价值在于：它把“一组任务的共同失败处理”聚合到了一起，而不是散落在每个任务里各写各的。我在部署类 Playbook 里几乎必用这个结构，尤其是涉及“下载后解压”的操作——网络波动、磁盘满、包损坏，任何一个环节挂了，rescue 里的清理动作都能保证系统不会残留半拉子部署，下一次跑也能有一个相对干净的环境。

要注意的点有两个。第一，rescue 里的任务如果又失败了，Ansible 会“一退到底”，也就是整个 Play 直接失败，不会再去执行 always 以外的任何东西。所以 rescue 里的动作要写得保守，越简单越好，不要埋伏任何复杂的依赖。第二，always 的任务如果失败同样会导致整个 Play 失败。这个设计有时候会让人误解——“always 不是保证会执行的吗？”，它是保证会执行，但没保证执行完一定成功。实际操作中，always 里的清理动作如果可能因为权限、路径等问题失败，我一般会给它加 failed_when: false，以防清理动作本身反而掩盖了真正的问题。

4.3 until + retries + delay：轮询等待的正确姿势

在很多真实场景里，任务的“失败”并不代表业务的最终失败，而是说明“还没准备好”。最典型的是服务启动后的端口探测：systemctl start 返回成功，但端口未必立刻监听。这时候硬性往下跑下一个任务，可能就是一个连接拒绝的错误。until 就是为这类“等待状态收敛”设计的：

- name: 等待服务端口就绪 ansible.builtin.shell: "ss -tlnp | grep -q ':8080'" register: port_result until: port_result.rc == 0 retries: 10 delay: 3

这个任务会每 3 秒试一次，最多试 10 次，只要有一次 rc 为 0 就继续后续任务，10 次内都没成功就失败。这个模式还有一个变体用途：批量启动一批数据库实例，一致性要求是“全部启动完成且主从同步状态为 Yes”，用 until 轮询mysqlsh或者repl.status的输出，就能把“等同步完成”很好地嵌进 Playbook，而不用回到 shell 脚本里写 while 循环。

写 until 时有个注册变量的坑要注意：until 的条件是注册变量的值在轮询过程中会被每次覆盖。你如果希望在轮询结束后还能看到最终一次的结果，直接在任务后引用该注册变量就行，它商会保留最后一次的值；如果想保留每一次的结果用来事后分析，得自己在循环外面用 set_fact 主动收集。这个功能 Ansible 不默认提供，需要的时候自己搭一下，也未必要把每次状态都收下来，调试阶段 debug 打印一下就够了。

5. 任务标签、委派与执行位置：让控制粒度更细

5.1 用 tags 定义任务的可选择性

生产级 Playbook 往往不是“一次跑完所有事”，而是会根据需求选择性地跑部分内容。tags 解决的就是“选择性执行”的问题。给一组任务打上标签，然后在执行时通过--tags参数只跑相关任务，或者--skip-tags跳过某些任务。

- name: 部署应用 hosts: app_nodes tasks: - name: 更新代码 ansible.builtin.git: repo: "{{ repo_url }}" dest: /opt/app tags: code - name: 重启服务 ansible.builtin.service: name: "{{ app_name }}" state: restarted tags: restart

注意 tags 是有继承性的：对 block 打的 tags 会继承到 block 内的所有任务上。还有 always 这个特殊 tag，一旦给任务打了 always，它在任何 tags 过滤下都会执行，除非你用 --skip-tags always 显式跳过。这个机制很适合放那些“不管跑什么任务都必须先做的”内容，比如创建临时目录、生成日志目录、下发基础配置。我一般在 Playbook 开头放一个 always 标签的任务组，上到生产环境后会发现这套设计省下大量反复指定参数的时间。

还有一个容易忽略的细节：tags 对 handler 的影响。如果某个 handler 打了标签，而触发它的任务被跳过，那么即使后续有任务通过 notify 调用了它，也往往不会被真正执行。这是 Ansible 中因为 tags 过滤导致重启服务失败的常见坑。所以给 handler 打标签要格外谨慎，除非你有明确意图，否则建议 handler 不参与 tag 过滤——这一点在文档里没明说，是实践出来的经验。

5.2 delegate_to 与执行位置控制

任务控制的粒度大到主机批次，小到单台任务，中间还有一个维度叫“执行位置”。默认情况下，每个任务在 Play 指定的目标主机上执行。但实际运维中经常需要“在 A 机器上操作 B 机器”或者“在控制机上执行动作影响所有目标机”。delegate_to 就是控制这个位置的。

最经典的应用是负载均衡器场景：你要把一台上线新代码，通常要先从上游 LB 摘流量，操作完成后再挂回去。这个过程涉及两组任务，一组在目标机执行，一组需要在 LB 上执行——lb 把目标机的 IP 从 rs 池里移除。写法：

- name: 从负载均衡摘除节点 ansible.builtin.command: "lbctl remove {{ inventory_hostname }}" delegate_to: lb01

这里 inventory_hostname 在 delegate_to 前后解析语义要看具体版本和用法，但大部分场景下它会正确指向目标主机名。如果疑似有歧义，可以显式用 hostvars[inventory_hostname]['ansible_host'] 来确保取 IP。另外一个常见的组合是 run_once 加上 delegate_to: localhost——所有搜集信息、预处理数据、必要时请求一个接口一次性搞定，在那个环境变量下非常顺手。

要提一个风险点：delegate_to 改了执行地，但传给任务的内容还是按目标机的 facts 和变量解析。如果你的 Playbook 里大量使用{{ ansible_facts['xxx'] }}这种引用，那么在执行位置委派的目标机上它解析的是该目标机的 facts，而不是执行机上的。跨主机引用要用 hostvars 显式访问——这个问题比较容易踩到，尤其是用 delegate_to 去执行本机操作、却潜意识里以为“我是本地执行所以引用当然是本地”的时候。

5.3 与执行策略的配合：更快、更稳的并行策略

任务控制里还有个常被忽略的点是执行策略（strategy）。默认的 linear 策略保证“所有主机的上一个任务都完成后，才开始下一个任务”，这种同步推进的方式简单可控，但在跨多主机的大规模任务里，整体的时间成本会被最慢的那台“拖住”。新版本里的 free 策略允许“各跑各的”——每台主机不等待其他主机，任务尽快推进。这个策略能显著提高批量执行效率，但也意味着日志中的执行顺序不统一，需要你心里有数，不要太依赖日志的时间线排错。

更实用的是把 serial 和 free 策略结合思考：如果你想做“滚动但不扁平地全速跑”，serial 配合默认 linear 比自由策略更容易控制节奏。而如果你只是希望在几十台上快速同步时间（比如 ntp 校准），free 策略是最省时间的。我个人的取舍标准是：有先后依赖、有全局一致性要求的时候用 linear；没有依赖、纯粹想尽快跑完的批量操作才考虑 free。这个思路在控制“翻车半径”上很有价值。

6. 常见问题与排查实战记录

6.1 排查一个 tricky 的 when 不触发问题

说一个我印象特别深的排错案例。当时有一个 Playbook，里面有一段逻辑是“当某个服务的状态文件存在时，执行清理”，when 条件写的是when: status_file_exists.stat.exists。看着没问题，但任务就是不触发。调试了很久，最后发现 status_file_exists 这个变量来自一个stat任务，但那个 stat 任务所在 Play 的执行主机是另一组机器——这不是全局事实，而是每台主机各自注册的变量。我在判断任务里直接引用它，意味着 Ansible 尝试从“当前主机”的变量空间里找这个注册变量，压根找不到，整个 when 就静默失效了。

这告诉我们一个核心规律：注册变量是主机维度的，跨主机引用必须用 hostvars 机制显式取出。Ansible 遇到“找不到变量”时默认把 when 判断视为未满足，不会报错，也不会提示“这个变量不存在”。这种静默失败比直接报错难排查得多。推荐的习惯是在 Playbook 开头用 debug 打一打关键注册变量的值，或者干脆在条件里加一个| default('')确保变量一定是字符串类型，再跟空串对比——这就能显著减少“变量不存在”导致的现场悲喜剧。

6.2 until 轮询误入死循环的教训

另一个我踩过的坑是关于 until 的重试上限。有一回写健康检查的轮询，retries 写的是 30，delay 写的是 2，算下来允许等待 60 秒。结果某次发版确实慢，服务启动超过了 60 秒，轮询直接失败。当时我第一反应是调大 retries，调到 60，延时长了之后轮询倒是没问题了，但整个 Playbook 被搞得死慢。后来才想明白：不应该只靠轮询次数硬等，而应该先判断失败的原因——服务启动慢到底是“加载慢”还是“永远起不来”。如果是后者，你把 retries 调到 100，也只是把失败从 2 分钟延迟到 20 分钟，没有任何意义。

现在的写法是：用 until 等一个保守的时间窗，然后在 rescue 里抓取服务的日志、进程列表、端口状态，把现场信息打印出来，直接进入人工排错。这样自动化脚本的“等待”是有限度的，“失败之后的信息收集”是自动的，整体体验好很多。另外轮询时 delay 不要写太大，否则一次 Playbook 的平均耗时会很难看；如果服务真的需要长时间初始化，更好的做法是把初始化做成异步任务，配合 async + poll 去并行等待，而不是让整个 Playbook 卡在同步轮询上。async 的高级用法这里不展开，但至少要知道“同步轮询不是等待的终点”。

6.3 常见问题速查

我在日常答疑和自测中发现，下面这几个问题出现频率最高，整理成一个表格，方便直接查：

6.4 一些长期有用的调试手段

调试 Playbook 时，我最离不开的是这几个手段：一是ansible-playbook -vvv看清每个任务底层的 SSH 连接日志、模块调用参数和返回结果；二是--step参数，让每个任务执行前停下来询问是否执行——这个在验证新写的控制逻辑时非常好用，可以逐步确认每个任务在什么条件下被触发、跳过、失败。三是ansible-playbook --syntax-check只能帮你查 YAML 语法，查不了变量解析错误，所以跑小样本（--limit）是必要的——先在两台机器上验证，再放大范围。

还有一点关于调试的理念：任务控制写得好不好，光看“正常跑通”是不够的，要看“异常的时候能否留下足够信息”。我习惯在每个关键任务后面（或 rescue 里）放一个 debug 任务，把注册变量和关键数据打印出来，即使任务跑挂了也能立即在输出里看到上下文。这比事后到机器上翻日志高效得多，尤其是当一次跑了几百台机器、光看汇总结果很难定位问题时，逐台 debug 的输出就是最直接的火线情报。

写在最后的一个实操习惯

说一个我自己的小习惯：每写完一个带复杂任务控制的 Playbook，我会在测试机上故意制造一次失败——改坏一个路径、删掉一个依赖文件、把服务端口换掉——然后观察这套控制逻辑的“失败路径”走不走得通。这个做法比任何静态代码审查都有效，因为任务控制本质上是为“异常路径”服务的，正常路径谁都能写，异常路径的代码才是真正决定这套自动化靠不靠谱的东西。多演练几次失败，你会发现不少隐藏的问题：某个 rescue 依赖的资源在失败时也不存在、某个 failed_when 判断的字段在异常输出里可能完全不出现、某个 when 条件的变量在特定主机上确实没注册——这些都是在正常跑通时永远发现不了的。

Ansible 的任务控制看起来是一堆关键字，组合起来其实是一套完整的“决策与恢复系统”。对个人来说，把这部分练扎实了，写出来的 Playbook 才能从“能跑”升级到“敢在关键变更上跑”。这篇笔记算是我 day5 的一个总结，后续实践中还会继续补充更多的案例与坑位。