统计从构建完成到通知到达的时间，核心公式是：通知到达时间减去构建完成时间，单次结果以秒或分钟计。要得到可用于判断反馈链路及时性的数据，还需把提交到构建完成、构建完成到通知到达、通知到首次响应三个口径分开统计，按流水线、分支、通知渠道和时间窗汇总中位数与P90，并单独报告缺失时间戳的比例。
要点总览（TL;DR）
- 单次延迟 = 通知到达时间 − 构建完成时间，以秒为单位；超过60秒可同时给出分钟值。
- 三个口径要分开统计：提交到构建完成衡量排队与执行，构建完成到通知到达衡量通知链路，通知到首次响应衡量人的处理启动。
- 汇总按流水线、分支、通知渠道分组，输出样本量、中位数、P90和最大值；均值仅作参考，样本不足时不发布分位数。
- 缺失通知时间戳的记录计入分母并单独报告缺失比例，重复通知取首次到达时间，多渠道分别统计。
- 阈值以团队4至8周历史基线和业务可接受等待时间为依据，按工作日与夜间、不同渠道分别设定，不套用通用达标线。
这条延迟到底在量什么
这条指标回答一个具体问题：构建结果已经产生，接收方过多久才收到通知。它衡量的是信息传递环节的耗时，起点是流水线判定构建完成的那一刻，终点是通知实际到达接收端的那一刻。数值越小，说明构建结果越快进入可被处理的状态。
它容易与另外两个口径混淆，需要明确边界。提交到构建完成衡量的是排队与执行耗时，反映构建资源与任务调度效率；构建完成到通知到达衡量的是通知链路的传递耗时；通知到首次响应衡量的是人收到信息后开始处理的时间。三者首尾相接，但分别对应不同环节的问题，混在一起统计会掩盖真正的瓶颈位置。
这条指标服务于反馈及时性判断。它描述通知链路快慢，构建本身是否稳定、测试是否充分、代码质量高低，需要由构建成功率、测试通过率等指标回答。把延迟低直接等同于工程质量好，会得出错误结论。
三个时间口径与统计范围
三个口径需要各自约定起点、终点、单位和纳入范围，并在报表中并列呈现。下表给出可直接执行的对照关系。
| 口径 | 起点事件 | 终点事件 | 单位 | 纳入范围 |
|---|---|---|---|---|
| 提交到构建完成 | 代码提交或合并请求更新被流水线接收 | 流水线判定构建完成（成功或失败） | 秒 | 推送触发、合并请求触发的自动构建 |
| 构建完成到通知到达 | 流水线判定构建完成 | 通知在接收端可读（消息平台回执或客户端接收记录） | 秒，较长时折算为分钟 | 已配置通知的自动构建，按渠道分别统计 |
| 通知到首次响应 | 通知到达接收端 | 接收人首次查看、评论或触发修复动作 | 分钟或小时 | 有明确响应记录的构建事件 |
纳入范围要事先写清。按触发方式区分推送触发、合并请求触发和定时触发，三类任务的构建时长与通知行为不同，合并统计会互相干扰。手动重跑通常由当事人主动发起，通知到达时间受人为因素影响大，建议单列或排除。配置了跳过通知的构建没有终点事件，应排除在延迟统计之外，但要在数据质量报告中记录数量。
时间窗按统计目的选择。日常观察用按天或按周滚动窗口，能及时发现链路劣化；版本复盘用发布周期窗口，与发布节奏对齐。窗口一旦确定，前后对比要保持一致，否则趋势变化可能来自窗口调整而非链路本身。
数据从哪里取、口径怎么对齐
可复算的前提是每条记录都能追溯到两个明确的时间戳。构建完成时间戳一般来自流水线运行记录，包含构建ID、提交SHA、分支、触发方式和完成状态。通知到达时间戳来自通知服务的发送日志或消息平台的回执记录，包含消息ID、目标渠道、发送时间与送达时间。两者通过构建ID或提交SHA关联，关联键必须在两侧都存在且唯一。
时区与时钟需要统一。所有时间戳在入库时转换为同一时区（通常为UTC或团队统一时区），并在字段说明中标注原始时区。流水线执行机与通知服务所在主机应保持时钟同步，否则几秒级的偏差会直接进入指标。对跨主机采集的数据，可先用同一事件在两侧的记录时间做抽样比对，确认偏差在可接受范围内再正式统计。
几类特殊情况要有固定规则：缺失通知到达时间戳的记录计入总样本分母，同时单独报告缺失比例，不用均值填补；同一构建因重试或多次推送产生重复通知时，取首次到达时间作为终点，其余记录去重；配置多个接收渠道时按渠道分别统计，不把多渠道时间混在一个分布里。规则写进指标说明文档，保证不同人复算得到相同结果。
在ONES中，流水线运行记录与工作项、提交记录可以建立关联，构建结果与通知动作围绕同一工作项留痕，便于按工作项追溯构建ID与提交SHA，再与通知渠道的送达记录对齐。这一衔接解决的是关联键从哪里取、记录能否回溯的问题，具体统计仍按上述字段规则执行。
计算步骤与汇总方式
单次延迟的计算为：延迟 = 通知到达时间 − 构建完成时间，结果以秒为单位，超过60秒可同时给出分钟值。计算前先剔除终点早于起点或时间戳明显异常的记录，异常记录数量单独报告。
汇总按流水线、分支、通知渠道三个维度分组，每组输出样本量、中位数、P90和最大值。中位数反映典型体验，P90反映较慢部分的水平，最大值用于发现极端情况。均值对长尾敏感，单次通知服务排队就可能把均值拉高，因此以中位数和P90作为主要判断依据，均值仅作参考并注明受异常值影响。
样本不足时不下结论。可设定每组样本量下限，例如一周内少于30条记录不发布分位数，只报告样本量和原始记录，避免少量样本产生的分位数波动被误读为链路变化。分母为零的分组（如某分支本周没有触发构建）在报表中标注为空，不参与趋势对比。
输出节奏按周或按发布周期固定。每期报表保留口径说明、样本量、缺失比例和三个口径的并列结果，使相邻两期可以直接比较。趋势图上同时标注通知配置变更、渠道调整等事件，便于解释曲线变化。
一个可复算的例子
假设某流水线一周内产生6条有效构建记录，通知渠道为即时消息，时间戳已统一为同一时区。原始数据与单次延迟如下（示例数据，仅用于演示计算过程）：
| 构建ID | 构建完成时间 | 通知到达时间 | 延迟（秒） |
|---|---|---|---|
| B-101 | 10:00:00 | 10:00:08 | 8 |
| B-102 | 10:15:00 | 10:15:12 | 12 |
| B-103 | 11:02:00 | 11:02:05 | 5 |
| B-104 | 14:30:00 | 14:30:45 | 45 |
| B-105 | 16:10:00 | 16:10:09 | 9 |
| B-106 | 17:20:00 | 17:21:30 | 90 |
将6个延迟值排序：5、8、9、12、45、90。中位数为第3与第4个值的平均，即(9+12)/2=10.5秒。P90按最近秩法计算，位置为0.9×6=5.4，向上取整为第6个值，即90秒；若采用线性插值，结果为45+(90−45)×0.4=63秒，两种算法需在口径说明中固定一种。最大值为90秒。
假设同一周还有2条构建因通知服务未返回回执而缺失到达时间戳。总样本分母为8，有效样本6，缺失比例25%。报表中应同时呈现：有效样本的中位数10.5秒、P90（按所选算法）、最大值90秒，以及缺失2条、缺失比例25%。缺失比例偏高时，先排查通知服务日志是否完整，再判断延迟指标本身是否可信。
阈值怎么设、结果怎么读
阈值来自团队自身的历史基线与业务可接受等待时间，没有通用达标线。做法是先积累4至8周数据，取中位数与P90的稳定区间作为基线，再结合业务对反馈速度的要求设定观察线与告警线。例如基线中位数为10秒左右、P90在60秒以内，可把P90超过120秒设为需要排查的信号；若团队要求构建失败后5分钟内必须有人介入，则通知环节的预算应据此倒推。
阈值按场景区分。工作日白天与夜间、不同通知渠道的传递特性不同，即时消息与邮件到达时间差异明显，应分别设定。合并请求触发的构建通常对反馈速度要求更高，可设更紧的观察线；定时构建的延迟容忍度相对宽松。阈值调整要记录时间和原因，避免频繁变动导致趋势不可比。
结果解读保持克制。该指标描述通知链路的耗时，不能单独作为个人或团队绩效依据，也不能证明延迟与交付效率之间存在因果关系。出现P90明显上升时，排查方向包括通知服务是否排队积压、渠道是否触发限流、接收端是否离线或客户端未同步，以及构建完成时间戳是否因流水线状态更新延迟而偏早。把这条指标与提交到构建完成、通知到首次响应并列观察，才能定位问题发生在链路的哪一段，并据此决定是优化构建调度、调整通知配置，还是改进入口响应机制。
常见问题
通知到达时间戳拿不到，只有发送时间，这条延迟还能统计吗？
可以统计，但需要把口径写清楚。用通知服务的发送时间作为终点，得到的是“构建完成到通知发出”的耗时，它不包含消息平台排队和客户端接收的时间，通常比真实到达时间偏小。建议在报表中把这类记录单独标注为发送口径，与有回执的到达口径分开汇总，不混入同一个分布。若发送口径记录占比很高，先排查通知服务是否开启了回执记录，再决定是否继续用该指标判断链路及时性。
同一构建因为重试推送了多次通知，延迟按哪一次算？
取首次到达接收端的时间作为终点，其余通知记录去重，这样得到的是接收方第一次能获知构建结果的时间，与反馈及时性的评估目标一致。如果重试是因为首次通知发送失败，建议在数据质量报告中记录失败次数和原因，因为这类失败会直接拉长首次到达时间，是排查通知链路问题的重要线索。去重规则要写进指标说明，保证不同人复算结果一致。
样本量少的分组能不能直接看均值？
样本量少时，均值和分位数都不稳定，单条异常记录就能明显改变结果。建议设定每组样本量下限，例如一周内少于30条记录只报告样本量和原始记录，不发布中位数与P90，也不参与趋势对比。分母为零的分组在报表中标注为空。等积累到足够样本再纳入正式统计，避免把少量样本的波动误读为链路变化。
P90明显上升但中位数没变，应该先查什么？
中位数稳定而P90上升，说明典型情况正常、较慢部分变差，排查重点放在长尾环节：通知服务是否出现排队积压、消息渠道是否触发限流、部分接收端是否离线或客户端未同步，以及构建完成时间戳是否因流水线状态更新延迟而偏早。同时核对这一期是否新增了通知渠道或调整了通知配置，配置变更常是长尾变差的直接原因。把这条指标与提交到构建完成、通知到首次响应并列观察，可以判断问题出在链路的哪一段。
这条指标能不能用来考核团队或个人的响应速度？
不建议单独用于考核。它描述的是通知链路的传递耗时，受通知服务、渠道限流、接收端状态等外部因素影响，与个人工作表现没有稳定对应关系。更合适的用法是作为链路健康度的观察指标，出现异常时推动排查通知配置和基础设施问题。若要评估响应情况，应结合通知到首次响应这一口径，并明确响应动作的定义，避免把查看通知等同于开始处理。
