粒度的判断标准
判断一条任务是否拆得合适，可以看三件事：失败时能否一眼看出中断在哪个动作；能否只重跑这一个动作而不牵连其他；执行报告里的变更提示是否对应单一结果。若一条任务里既有创建目录、又有下发文件、还有重启服务，那么失败时只能整体重跑，报告里的变更也无法区分来源。反过来，把每行配置拆成一条任务则会让输出失去可读性。
基本信息
| 合适粒度 | 一个任务对应一个可独立验证的结果 |
|---|---|
| 拆分依据 | 失败可定位、可单独重跑、变更含义单一 |
| 分组工具 | 用块组织相关任务并统一条件 |
| 标签 | 按动作类型打标签，支持选择性执行 |
划分方法
- 按结果拆分：安装、写配置、启服务分别成为独立任务。
- 用块组织：把有共同条件或错误处理的任务放进一个块，兼顾可读与统一控制。
- 按标签分类：为校验类、变更类、清理类任务打标签，便于单独执行某类操作。
- 任务命名说清结果：任务名描述达成的状态，而不是描述调用的模块。
- 避免循环生成大量任务：批量文件用循环处理，但保留整体结果提示。
- 把长命令拆成准备、执行、校验三段，而不是一条长脚本。
- 把复杂条件提取为变量：减少任务内的条件嵌套，让意图更直观。
拆分前后的对比
拆分前后的对比
# 拆分前：一条任务做三件事，失败无法定位
- name: 部署应用
ansible.builtin.shell: |
mkdir -p /opt/app && cp -r ./dist/* /opt/app/ && systemctl restart app
# 拆分后：三步各自可验证、可单独重跑
- name: 确保应用目录存在
ansible.builtin.file:
path: /opt/app
state: directory
- name: 同步应用文件
ansible.builtin.copy:
src: ./dist/
dest: /opt/app/
- name: 重启应用服务
ansible.builtin.service:
name: app
state: restarted粒度对照
| 粒度 | 优点 | 代价 |
|---|---|---|
| 过粗 | 任务条数少 | 失败无法定位，无法单独重跑 |
| 合适 | 可定位、可重跑、报告清晰 | 条数适中，需要起好任务名 |
| 过细 | 每步都可控 | 输出冗长，看不出整体意图 |
| 循环处理 | 文件多时简洁 | 单文件失败需从循环输出中辨认 |
| 块组织 | 统一条件与错误处理 | 块内任务仍各自独立 |
| 长命令 | 贴近手工操作 | 无法判断变更来源 |
任务名是最便宜的可读性投入：把「执行脚本」改成「下发站点配置并触发重载」，评审者无需读实现即可判断这条任务是否符合预期。
循环要权衡：文件列表不长时逐个任务更利于定位，列表很长或来源动态时用循环并在结果中保留失败项信息更实用。