时长预算是什么
流水线时长预算是给不同级别的流水线设定明确的时长目标，并把它当成产品体验指标来治理：提交级流水线目标几分钟到十几分钟，合并级目标十几到三十分钟，夜间级全量回归可以放宽到小时级。开发者等待反馈的时间越长，越倾向于攒大批量提交、减少提交次数，「小步快跑」的文化会被时长直接压垮。超预算不是罚则，而是触发专项治理的信号：定位慢在排队、构建、测试还是环境准备，然后针对性优化。
基本信息
| 分档 | 提交级（快）、合并级（中）、夜间级（全） |
|---|---|
| 目标口径 | 按分位（P95）设目标，而不是平均值 |
| 经验区间 | 提交级控制在几分钟到十几分钟，超出会把开发节奏拖成排队 |
| 治理 | 把时长纳入流水线看板，按月复盘持续回归 |
| 关键拆分 | 总等待 = 排队时间 + 执行时间，分开观测 |
典型使用场景
- 新项目起步：在流水线建好时就把三档时长目标写入验收标准，避免逐月膨胀。
- 反馈变慢诊断：开发者抱怨「CI 太慢」时，用分档数据定位是排队还是执行慢。
- 优化立项：缓存、并行、测试分层改造前后对比，用数据证明收益。
- 容量规划：排队时间占比高说明 Runner 不足，执行时间高说明作业本身要优化。
- 合规审计：关键分支的验证必须完整执行，用时长预算证明没有为速度砍掉必要检查。
看板最小集
看板最小集
平均时长 / P95 时长 / 排队时间 / 成功率 / 月度趋势
# 分档参考
提交级: 目标 ≤10 分钟（按团队实际调整）
合并级: 目标 ≤30 分钟
夜间级: 全量回归, 小时级可接受三档读法
| 档位 | 触发时机 | 时长目标思路 | 典型内容 |
|---|---|---|---|
| 提交级 | 每次 push | 分钟到十几分钟 | 构建、单测、静态检查 |
| 合并级 | MR/主干 | 十几到三十分钟 | 集成测试、制品构建 |
| 夜间级 | 定时 | 小时级可接受 | 全量回归、跨平台、性能基线 |
时长预算是产品体验指标：开发者等待越久，小步提交的意愿越低，批量随之变大，交付节奏整体恶化。
缓存命中率高会掩盖冷启动路径：定期测量无缓存（cache miss）的构建时长，否则主干重建时全员受影响。