分批执行设计
分批执行把一个大作业切成多个批次逐步推进，每批完成后观察再决定是否继续，从而把失败影响限制在单批之内。设计要点四项：批次划分维度（按主机数量、百分比、机房或分组、业务单元、ID 区间）、批次大小（先小后大，前几批用于验证假设）、批间观察窗与判定指标（错误率、延迟、日志关键字）、失败处理（只重跑失败批，而不是整批从头再来）。批次边界必须与应用语义匹配，否则拆出来的中间态可能对外不可用。
基本信息
| 批次维度 | 主机数量、百分比、机房或分组、业务单元、ID 区间 |
|---|---|
| 推进方式 | 固定批次（等整批完成再下一批）与滚动窗口（完成一个补一个） |
| 观察窗 | 批间停顿与指标判定，至少覆盖关键指标的一个采集周期 |
| 失败处理 | 只重跑失败集合；批内继续或中止需预先明确 |
典型使用场景
- 上千台主机的配置变更需要控制影响面
- 数据库结构变更需要按业务单元逐步核查
- 发布新版本时先小批验证再逐步放大
- 需要在批次之间等待指标稳定，避免连续冲击叠加
- 必须在时间窗口内完成，因此批次大小要与剩余时间匹配
分批推进示例
分批推进示例
# Ansible：按百分比分批，每批结束后评估
- hosts: web
serial: "10%" # 每批 10%，首批可先手工限制到 1 台
max_fail_percentage: 10 # 失败超过 10% 停止推进
tasks:
- name: deploy
command: /opt/bin/deploy.sh
# 手工批次：批间留观察窗，失败即停止
# for batch in 1 2 3; do
# run_batch "$batch" || { echo "批次 $batch 失败，停止推进"; exit 1; }
# sleep 120 # 观察窗：等待指标回落或暴露问题
# done分批参数建议
| 参数 | 含义 | 取值建议 |
|---|---|---|
| serial | 每批处理的主机数或比例 | 首批取小值，验证后逐步放大 |
| 批间停顿 | 批与批之间的观察时间 | 覆盖关键指标一个采集周期 |
| max_fail_percentage | 允许失败的比例 | 按业务容忍度设定，超阈值整批中止 |
| 批次维度 | 主机分组依据 | 与故障域、业务单元对齐 |
| 失败批重跑 | 只重跑失败集合 | 失败清单必须持久化 |
前几批的主要作用不是推进完成量，而是验证假设。首批应选择有代表性且失败影响最小的目标，并事先写明放大条件与中止条件，避免临场凭感觉判断。
批次划分要与应用语义对齐。把互相依赖的组件拆到不同批次，中间态可能对外不可用，形成比整体停机更长、更难解释的部分可用窗口。