范围判断出错是最贵的错误
批量执行的事故里，目标范围判断错误造成的影响最大：命令本身没错，脚本也测试过，只是它作用的机器不是你以为的那批。范围出错的原因往往很朴素——主机名相似导致模式匹配到更多主机、分组继承把不该包含的机器带了进来、动态清单在两次执行之间发生了变化。二次确认的意义是让「我以为」变成「我核对过」，用一次廉价的检查换取执行结果的确定。
基本信息
| 适用对象 | 批量执行工具的主机选择与清单管理 |
|---|---|
| 选择方式 | 分组名、模式匹配、显式清单、标签 |
| 常见出错点 | 相似主机名、分组继承、动态清单变化 |
| 确认方式 | 执行前打印主机清单与数量，并核对关键主机是否在内 |
| 配套要求 | 执行结果需能对应到具体主机，便于事后核对 |
范围出错的具体形态
- 名称相似：按前缀匹配时把序号更大的主机一并选中，范围远超预期
- 分组继承：子分组继承了父分组的成员，实际包含的机器比看到的多
- 环境混排：同一分组里混有非生产机器，或同名的分组存在于两个环境
- 动态清单变化：清单来自自动发现时，两次执行之间成员可能已经改变
- 名称解析歧义：别名、多个解析记录会让同一名字对应多台主机
- 显式排除缺失：只写了包含条件却没排除临时机器、备用节点
执行前的范围核对
执行前的范围核对
ansible -i inventory --list-hosts 'prod:&web' # 只列出目标，不执行
ansible -i inventory --list-hosts 'prod:&web' | wc -l # 数量是否符合预期
ansible -i inventory --list-hosts 'prod:&web' | grep -x 'prod-web01' # 关键主机必须在内
ansible -i inventory --list-hosts '!prod' # 反向确认排除项生效
ansible-playbook -i inventory site.yml --limit 'prod-web01' # 先单机执行
ansible-playbook -i inventory site.yml 2>&1 | tee run.log # 留档，事后核对实际命中核对项与判据
| 核对项 | 判据 | 异常处理 |
|---|---|---|
| 目标数量 | 与预期数量一致 | 不一致立即中止排查 |
| 关键成员 | 核心主机在清单内 | 缺失说明匹配写错 |
| 排除项 | 临时与备用节点不在内 | 补排除条件 |
| 环境归属 | 全部属于当前环境 | 拆分清单或修正分组 |
| 清单来源 | 静态或已确认的动态结果 | 动态清单需先冻结再执行 |
数量核对只能发现明显异常，核对清单内容才能发现「数量正确但对象错误」。两者都需要做，且关键主机必须在清单里逐一确认存在，而不是假定它在。
对动态清单执行破坏性操作前应先冻结清单：自动发现机制在两次执行之间增删成员，会让「检查时安全」与「执行时安全」成为两件事，中间的时间差正好是风险的窗口。