依赖为什么要显式
很多变更失败并非动作本身写错，而是执行顺序不对：数据库还在初始化就开始启动应用、配置尚未下发就重启服务、上游未扩容就打开流量。这类顺序关系如果只写在操作手册或依赖人的经验里，自动化执行时很容易丢失。显式声明依赖包含两层：一是顺序，二是完成判据——不是「上一步执行完了」，而是「上一步的结果已经可用」。
基本信息
| 依赖类型 | 顺序依赖、条件依赖、跨系统依赖 |
|---|---|
| 声明方式 | 任务条件判断、编排顺序、等待与轮询 |
| 完成判据 | 可校验的状态，而非执行返回码 |
| 异常处理 | 超时、阻塞与人工升级路径 |
设计要点
- 用判据而非等待：等待固定秒数不靠谱，应轮询实际状态直到满足条件。
- 设置等待上限：轮询要有时限，超时后明确失败而不是无限等待。
- 依赖可见：把依赖关系写在任务名与注释里，便于评审时检查。
- 跨系统依赖留退路：对端不可用时给出阻塞提示与人工入口。
- 避免隐式依赖：不要依赖上一次执行留下的中间产物，除非显式声明。
- 顺序依赖要有失败中止：前置失败时后续任务不得继续执行。
依赖场景与判据
| 场景 | 依赖关系 | 可校验判据 |
|---|---|---|
| 应用启动前 | 数据库可连接 | 连接测试成功或端口可连 |
| 服务重启前 | 配置已下发 | 配置文件内容与模板一致 |
| 开放流量前 | 实例健康检查通过 | 探活接口返回正常 |
| 扩容后 | 新实例已加入集群 | 集群成员列表包含新实例 |
| 备份前 | 应用处于一致性状态 | 相关写入已暂停或完成 |
| 跨系统联动 | 对端任务已完成 | 对端接口或记录中的完成标记 |
把「等待固定秒数」换成「轮询状态直到满足或超时」，是提升任务可靠性最直接的一步：前者在慢环境失败、在快环境浪费，后者随实际状态自适应。
循环依赖会造成任务永久等待：A 等 B、B 等 A 时两侧都不推进，且表面上看不到报错。编排设计评审时要专门检查依赖关系是否存在环。