批量下发解决什么问题
批量下发指一次定义检查项与目标范围后，由调度端把同一份任务实例化并分发到成百上千台被检对象上执行，再把结果汇总回中心。它要解决的不是单条命令怎么跑，而是在可控时间窗口内让同一套检查覆盖全部目标，并且事后能说清哪些没跑到、为什么。核心矛盾是规模与可控性的平衡：并发过高会打满被检端与网络，过低则一个巡检周期跑不完。
基本信息
| 适用对象 | 主机、网络设备、数据库、中间件等被检集合 |
|---|---|
| 下发方式 | 巡检平台调度、配置管理工具、CI 定时任务 |
| 分发粒度 | 以目标清单（inventory）为单位实例化任务 |
| 关键参数 | 并发度、单次超时、重试次数、执行窗口 |
| 结果标识 | task_id 加目标标识，二者共同唯一定位一次采集 |
典型使用场景
- 夜间全量巡检：在业务低谷统一执行检查，避开高峰对被检端 I/O 与连接数的挤占
- 变更后定向复核：只对刚变更过的一批目标下发检查，验证改动是否引入偏差
- 合规基线巡检：把内控与等保要求固化为检查项，按周期全员覆盖并留存证据
- 发布前健康摸底：先对灰度组下发，确认检查项本身无误再推向全量组
- 慢变量巡检：证书、域名、许可、磁盘水位这类变化缓慢的指标按月巡检
目标范围与下发方式
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 小规模且需人工判断 | 逐台或小批交互执行 | 便于即时看回显并止损 |
| 大批量同构目标 | 清单分组加并行调度 | 吞吐高、结果结构统一 |
| 含网络设备等异构目标 | 按协议分通道下发 | 采集通道与回显格式不同 |
| 高风险检查项 | 先小样本试点再全量 | 避免全量误判被放大 |
分批并行的最小写法
分批并行的最小写法
- hosts: all
serial: 10 # 每批 10 台推进，控制单批冲击面
throttle: 5 # 单个任务并发不超 5，保护被检端
gather_facts: false # 巡检不需要的事实采集可跳过，减少开销
tasks:
- name: 采集磁盘水位
shell: df -hP | awk 'NR>1 {gsub(/%/,"",$5); if ($5+0 >= 85) print}'
register: disk_out
failed_when: false # 检查项非零退出不应中断整批任务
changed_when: false # 只读巡检不得产生 changed 标记下发不是终点。任务实例要有唯一 task_id，并把当次目标清单落成快照，否则无法回答今天哪些目标没被巡检到。只统计执行成功数，会把从未纳入清单的目标隐藏成覆盖率假象。
巡检项默认必须是只读动作。一旦脚本里混入修复命令，批量下发会把单机误判放大成全量故障；确需自动修复的项应独立成任务，单独审批并单独限流。