配置编排的并行安全边界是什么
并行能压缩变更时长，但并非所有步骤都能并发。判断安全边界看三条：步骤之间是否存在共享资源竞争（同一文件、同一服务、同一配额）；是否存在不可交换的中间态（A 必须看到 B 的最终结果而非中间结果）；失败是否需要整体停止（部分失败能否只回滚局部）。满足「无共享、可交换、可独立回滚」的步骤可以并行，否则串行或以小组为单位并行。第二个约束来自目标侧：并发过高会触发限流、连接上限与性能抖动。
基本信息
| 可并行条件 | 无共享资源竞争、中间态可交换、可独立回滚 |
|---|---|
| 必须串行 | 有共享资源、依赖对方最终结果、失败需整体停止 |
| 目标侧约束 | 会话上限、请求限流、性能余量 |
| 控制手段 | 并发上限、分组、失败退避重试 |
| 验证方式 | 注入部分失败，观察影响是否局限在对应分支 |
典型使用场景
- 对互不相关的主机并行执行同类任务
- 同一主机上的多个步骤保持串行
- 对共享配置中心的写入串行或加锁
- 对网络设备限制并发以避免会话耗尽
- 把独立子系统分成并行组以缩短变更窗口
并行安全判断三问
并行安全判断三问
# 1) 是否访问同一共享资源（文件、服务、配额）？ 是 → 串行或加锁
# 2) 是否依赖对方的最终结果？ 是 → 串行
# 3) 失败时能否只回滚其中一部分？ 否 → 串行或整组处理
# 目标侧：设并发上限、按目标类型分组、失败退避重试
# 验证：注入部分失败，观察影响是否只落在对应分支场景与并行判断
| 场景 | 能否并行 | 原因 |
|---|---|---|
| 不同主机的同类任务 | 可以 | 无共享资源竞争 |
| 同一主机的多步操作 | 不可以 | 可能访问同一文件与服务 |
| 共享配置写入 | 不可以 | 存在写竞争 |
| 独立子系统之间 | 可以 | 失败可独立回滚 |
并行的收益常被目标侧瓶颈吃掉：并发提高到一定程度后，目标限流与重试使总时长反而增加，同时引入更多超时失败。并发上限应通过实测确定，而不是取「越大越快」。
不要用加大并发来解决总时长问题。变更窗口不足时，正确做法是缩小单次范围、增加批次或调整窗口，而不是把风险压到目标侧。