构建完成到通知到达的时间怎么统计

统计“构建完成到通知到达”的延迟，核心做法是用同一条流水线记录的两个时间戳相减：构建完成时刻（构建任务结束、状态落定为成功或失败的时间点）与通知到达时刻（通知渠道回执或接收方系统确认送达的时间点），差值即延迟，单位取秒，展示时换算为分钟。要让结果可复算，还需固定分母口径、分组维度，并单独统计缺失时间戳与发送失败的比例，避免把发送失败算成零延迟。

要点总览（TL;DR）

• 用同一条流水线的两个时间戳相减：构建完成时刻（任务结束、状态落定为成功或失败）与通知到达时刻（渠道回执或接收系统确认送达），差值单位为秒，展示时换算为分钟。
• 分母建议以构建完成事件为分母，同时单独统计发送失败率与时间戳缺失率，避免把发送失败算成零延迟；只统计成功送达的通知会掩盖漏发问题。
• 聚合以中位数和P90为主、均值仅作参考，按流水线、分支、通知渠道、时段分组；样本少于20条的分组不宜直接下结论。
• 阈值基于自身两到四周的历史分布设定，以P90为基线逐步收紧，即时通讯与邮件渠道分开设阈值，不套用外部通用达标线。
• 该指标只反映通知链路时效，需与提交到构建完成、通知到首次响应两段联合解读，才能定位瓶颈在流水线、通知链路还是人的响应。

这条延迟到底在量什么

“集成反馈延迟”描述的是从代码提交到有人对结果作出反应之间的总时长。它由三段组成，每段回答不同的问题，需要分别计量。本文的主口径是中间一段：构建完成到通知到达。这一段衡量通知链路的时效，构建本身快慢由前一段反映，人看到通知后的处理速度由后一段反映。

段名	起点	终点	回答的问题
提交到构建完成	代码提交进入流水线触发队列	构建任务结束、状态落定	流水线跑得快不快、排队久不久
构建完成到通知到达（主口径）	构建任务结束、状态落定	通知渠道回执或接收方系统确认送达	结果出来后，消息多久送到人手里
通知到首次响应	通知到达时刻	接收方首次查看、认领或处理	人看到消息后多久开始处理

把三段分开看，才能定位问题出在流水线、通知链路还是人的响应。如果只看总时长，构建慢和通知慢会混在一起，改进方向难以判断。本文后续的公式、取数和计算都围绕中间一段展开，另外两段仅在解读时作为对照。

指标定义、范围与分母

指标名称定为“构建完成到通知到达延迟”。公式为：通知到达时刻 − 构建完成时刻。两个时间戳都精确到秒，差值单位统一为秒，报表展示时除以60换算为分钟，保留一位小数即可。

统计范围需要事先写清，包括时间窗、流水线、分支和环境。例如“近30天内，主干与发布分支在预发、生产环境上的全部构建”。时间窗过短会让样本量不足，建议至少覆盖两周的完整工作日节奏；如果团队构建频率低，可延长到30天或按季度观察。

分母口径是复算时最容易出现分歧的地方，常见两种选择：

• 以构建完成事件为分母：时间窗内每一条状态落定的构建都计入分母。发送失败、缺失时间戳的样本仍留在分母中，但单独标记，不参与延迟计算。这种口径能同时反映“通知是否发出”和“发出后多快到达”，适合评估通知链路的整体可靠性。
• 以成功发出的通知为分母：只统计实际送达的通知，延迟数值更干净，但会掩盖发送失败的问题。适合单独分析“送达之后的速度”，不适合作为唯一口径。

建议主口径采用第一种，并在同一张报表中并列展示“发送失败率”和“时间戳缺失率”。这样延迟中位数与失败率一起看，才能判断通知链路是快而稳，还是快但经常漏发。纳入范围应排除人工手动触发的补发通知、测试流水线以及被明确静默的构建，排除规则需在口径文档中固定，不能每次统计临时调整。

时间戳从哪里取、怎么保证可比

两个时间戳的来源不同，取数时必须明确优先级，否则不同人算出的结果无法比较。

构建完成时刻取流水线系统的任务结束时间，即状态从运行中变为成功或失败的那个时间点。日志最后一行的时间不能替代它：日志可能因缓冲延迟写入，也可能在构建结束后仍有清理步骤输出，两者会相差数秒到数十秒。如果流水线系统只提供开始时间和总耗时，可用开始时间加耗时推算，但需在口径中标注为推算值。

通知到达时刻优先取通知渠道的回执或接收方系统的入库时间，这是口径等级最高的一类。部分渠道只返回“已发送”而不返回“已送达”，此时退而取发送成功日志的时间，并在字段表中标注为次级口径。两类口径混用时，应在报表中分开统计或至少注明占比，避免把发送时刻当作到达时刻直接比较。

字段名	来源系统	口径等级	缺失处理
构建完成时刻	流水线系统任务结束记录	一级（状态落定时间）	缺失则整条样本剔除并计数
通知到达时刻	通知渠道回执或接收系统入库时间	一级（送达确认）	缺失则降级取发送日志时间
通知发送时刻	通知服务发送日志	二级（发送成功）	缺失则标记为无法计算
发送状态	通知服务	—	失败样本单独计数，不参与延迟计算
静默标记	通知配置或人工操作记录	—	标记后从分母中排除并说明原因

跨机器时间戳需要统一时区，通常统一为UTC或团队所在时区，并在取数时完成转换，不在展示层临时换算。参与记录的服务器应启用时钟同步服务，抽取样本时可比对同一构建在流水线系统与通知系统中的相邻事件时间，若出现系统性偏移，先校正再计算。重试与多渠道路径也要在口径中固定：一条构建触发多次通知重试时，取首次成功送达的时间；同时发往即时通讯和邮件两个渠道时，按渠道分别记录，不合并成一条。

计算步骤与分组方式

计算流程可以固化为五步，每一步都产出可核对的中间结果：

1. 抽取构建完成事件：按时间窗和范围条件，从流水线系统取出每条构建的标识、流水线名、分支、环境、完成时刻和最终状态。
2. 关联通知记录：以构建标识为键，关联通知服务中的发送记录与渠道回执，得到每条构建对应的通知到达时刻、渠道和发送状态。
3. 计算差值：通知到达时刻减构建完成时刻，得到秒数。发送失败或时间戳缺失的样本标记为无效，不参与差值统计。
4. 剔除无效样本：差值为负说明时钟回拨或记录错位，差值异常大（例如超过数小时）需排查是否为补发通知或积压重试，确认原因后决定剔除或单列。
5. 分组聚合：按流水线、分支、通知渠道、时段分组，计算样本数、中位数、P90和最大值。

聚合时以中位数和P90为主，均值仅作参考。通知延迟通常呈右偏分布，少数积压或重试样本会把均值拉高，中位数反映典型体验，P90反映较差情况下的等待时间。分组维度建议至少保留流水线与通知渠道两个，因为不同渠道的链路长度差异明显，混在一起算出的中位数缺乏指导意义。时段分组可按工作日与夜间、工作时段与非工作时段划分，用于观察通知服务在低峰期是否存在积压。

时间窗内没有构建或没有通知时，分母为零，此时不输出延迟数值，报表显示“无样本”，并注明原因，不能用0填充。若某分组样本数少于20条，中位数和P90的波动较大，应与相邻周期合并观察或标注样本不足。

当构建记录与通知记录分散在流水线工具和通知服务中时，需要有一个地方把两者按构建标识关联并留存。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，同时可将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建与发布过程。团队可以据此把构建完成事件与项目上下文对应起来，再结合通知记录完成关联取数；具体同步字段是否包含所需时间戳，需按实际集成配置核验。

一个可复算的例子

以下为演示情景，数据为虚构，仅用于说明计算过程。假设某流水线在一天内完成8次构建，通知发往即时通讯渠道，原始记录如下。

构建编号	构建完成时刻	通知到达时刻	状态	差值（秒）
B1	09:00:00	09:00:08	送达	8
B2	09:20:00	09:20:15	送达	15
B3	09:45:00	09:45:12	送达	12
B4	10:10:00	—	发送失败	无效
B5	10:35:00	10:35:40	送达	40
B6	11:00:00	11:00:09	送达	9
B7	11:25:00	—	时间戳缺失	无效
B8	11:50:00	11:52:30	送达（重试后）	150

有效样本为B1、B2、B3、B5、B6、B8共6条，差值排序为8、9、12、15、40、150秒。中位数取第3与第4个值的平均，即(12+15)/2=13.5秒。P90按6个样本计算，位置为0.9×(6−1)+1=5.5，即第5与第6个值之间插值，40+(150−40)×0.5=95秒。若把B8的重试延迟视为异常并单列，剩余5条样本的中位数为12秒，P90约为40秒。

分母对比：以构建完成事件为分母，共8条，其中2条无效，有效样本占比75%，发送失败率12.5%，时间戳缺失率12.5%。若以成功送达的通知为分母，则只报6条样本的延迟，失败与缺失被隐藏。两种口径下中位数相同，但前者同时暴露了通知链路的可靠性问题，这正是建议采用第一种口径的原因。

阈值怎么设、结果怎么读

这条延迟没有通用的达标线，阈值应基于团队自身的历史分布设定。做法是先积累两到四周的数据，取P90作为初始基线，再按改进目标逐步收紧，例如每季度将P90目标下调10%至20%，每次调整后观察一个完整周期再决定是否继续。阈值按渠道分层：即时通讯类渠道链路短，阈值可设在数十秒量级；邮件渠道受投递队列影响，阈值应放宽，两类渠道合并设一个阈值会让结果失去参考价值。时段上，工作时段与非工作时段也可分开设阈值，用于发现低峰期的积压。

解读结果时需注意三点限制。第一，该指标只反映通知链路的时效，不能单独证明协作改善；通知变快不等于问题被更快解决，还需结合“通知到首次响应”一段判断。第二，样本量小时中位数和P90波动大，少于20条样本的分组不宜直接下结论，建议观察两到三个周期。第三，应与另外两段联合解读：如果提交到构建完成很长而通知段很短，瓶颈在流水线；如果通知段突然拉长而构建段稳定，应排查通知服务、渠道限流或重试策略。

把三段放在同一张趋势图上，按周观察，比单看一个数字更能说明问题出在哪一环。延迟下降时，也应确认失败率和缺失率没有同步上升，避免用漏发换来的“快”。

常见问题

构建完成时刻取日志最后一行的时间可以吗？

不建议。日志最后一行的时间可能因缓冲延迟写入，也可能在构建结束后仍有清理步骤输出，与任务真正结束的时间相差数秒到数十秒。应取流水线系统的任务结束时间，即状态从运行中变为成功或失败的那个时间点。如果流水线系统只提供开始时间和总耗时，可用开始时间加耗时推算，但要在口径中标注为推算值，与直接取状态落定时间的样本分开统计。

通知渠道只返回“已发送”而没有“已送达”回执，该怎么算？

此时退而取发送成功日志的时间作为通知到达时刻，并在字段表中标注为次级口径。两类口径混用时，应在报表中分开统计或至少注明各自占比，避免把发送时刻当作到达时刻直接比较。如果同一批数据中一级口径与次级口径并存，建议分别给出中位数和P90，再合并看整体趋势，而不是把两种口径的样本混在一起算一个数。

一条构建触发多次通知重试，或者同时发往多个渠道，取哪个时间？

重试场景取首次成功送达的时间，重试造成的额外延迟单独记录，便于发现渠道限流或积压。多渠道路径按渠道分别记录，不合并成一条：即时通讯和邮件的链路长度差异明显，合并后算出的中位数缺乏指导意义。这些规则需要在口径文档中固定下来，每次统计沿用同一规则，否则不同周期的数据无法比较。

时间窗内某条流水线没有构建，或者有构建但通知全部失败，报表怎么显示？

分母为零时不输出延迟数值，报表显示“无样本”并注明原因，不能用0填充，否则会把“没有数据”误读为“延迟为零”。有构建但通知全部失败时，延迟同样无有效样本，但失败率应为100%，这一条要单独呈现。失败率与延迟中位数并列展示，才能判断通知链路是快而稳，还是快但经常漏发。

用ONES做这类统计，构建和通知记录能直接关联吗？

ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，也可将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建与发布过程。团队可据此把构建完成事件与项目上下文对应起来，再结合通知记录完成关联取数。同步字段是否包含所需的构建完成时间戳与通知送达时间戳，需按实际集成配置核验；现有资料未提供“构建完成到通知到达”这一现成指标，通常需要自行计算。