变更前置时间是什么
变更前置时间（Lead Time for Changes）统计从代码提交到在生产运行所经历的时间，衡量需求从写完到可用的流动速度，是 DORA 指标中与部署频率并列的速度指标。口径要点：起点一般定在提交合入主干（也有团队用 PR 创建时间，关键是固定一种）；终点是变更在生产可用；中间拆成编码、评审等待、流水线运行、发布窗口四段后，瓶颈通常一眼可见。实现上把版本控制时间戳与部署事件关联计算，按周看中位数与 p90：尾部时间比平均值更能反映流程卡点。
基本信息
| 起点 | 提交合入主干（或 PR 创建，口径固定） |
|---|---|
| 终点 | 变更在生产可用 |
| 分段 | 编码、评审等待、流水线、发布窗口 |
| 工具 | issue/PR 时间戳与部署事件关联计算 |
| 观察口径 | 中位数加 p90，别只看平均值 |
典型使用场景
- 建立基线：先测出现状，再设定改进目标与节奏。
- 定位瓶颈：分段数据找出大头在评审、流水线还是窗口。
- 发布窗口治理：固定窗口造成批量等待时，缩短窗口可直接见效。
- 联动分析：频率低且前置时间长，典型是批量发布模式。
- 小批次改造：拆小需求与提交，缩短每段等待时间。
- 对外汇报：用中位数与 p90 的季度趋势说明交付能力变化。
按周统计中位数
按周统计中位数
SELECT date_trunc('week', deployed_at) AS wk,
percentile_cont(0.5) WITHIN GROUP (ORDER BY deployed_at - merged_at) AS p50
FROM deploys
GROUP BY 1 ORDER BY 1; -- 同法可算 p90 看尾部分段与卡点
| 分段 | 计量区间 | 常见卡点 |
|---|---|---|
| 评审等待 | PR 创建到批准 | 评审人排队、大改动 |
| 流水线 | 批准到制品就绪 | 测试慢、队列拥塞 |
| 发布窗口 | 制品就绪到上线 | 固定窗口、批次合并 |
| 返工 | 失败到重新合并 | 用例不稳、修复往返 |
中位数与 p90 一起看：平均值被极端值拉偏，尾部时间反映最难受的那批变更。
口径必须固定：merge 口径与 PR 创建口径能差出数倍，改口径要同时在趋势图上标注。
等待往往比执行费时：优化评审容量与流水线排队，通常比压榨单个环节更有效。