统计“构建完成到通知到达”的时长，核心是用构建任务写入完成状态的时间戳，减去通知渠道确认送达或首次可被接收的时间戳，差值按秒计。这条指标只衡量构建结果从产出到触达责任人的反馈链路，适合按流水线、分支、通知渠道分组看中位数与P90，并单独标记缺失时间戳和失败通知。ONES 可承载流水线执行状态与项目关联的管理范围，本文围绕这条延迟的口径、取数、计算与解读展开。
要点总览（TL;DR）
- 统计口径：以构建任务写入“完成”状态的时间戳为起点，以通知渠道确认送达或首次可被接收的时间戳为终点，两者之差按秒计。
- 三段口径分开算：提交到构建完成看构建执行效率，构建完成到通知到达看通知触达链路，通知到首次响应看责任人响应节奏，混算会掩盖瓶颈位置。
- 聚合同时给出中位数、P90、均值与样本量 n；分母为成功进入通知环节的构建次数，排除未触发通知、手动取消与重复触发的记录。
- 缺失时间戳、通知失败与重试记录单独标记，不默认计入有效样本；分母为零或样本过少时标注“样本不足”，不输出达标结论。
- 阈值以自身历史分布为基线设定，即时通知渠道与异步渠道分别设阈值；该指标反映链路时效，与问题解决速度是相关关系。
这条延迟要回答什么判断
这条指标回答的是：构建已经产出结果之后，相关责任人多久能收到通知。它评估通知触达环节的及时性，用于识别通知链路中的瓶颈、为响应节奏设定预期，构建执行本身快慢不在它的判断范围内。
具体用途可以落到三个动作上。第一，定位瓶颈：当某条流水线的延迟明显高于同类流水线时，排查方向指向通知配置、渠道拥堵或接收人设置，而非构建脚本。第二，设定响应预期：团队可以据此约定“构建失败后多久内应有人看到”，把模糊的“尽快通知”变成可核对的时间约定。第三，验证通知链路改造效果：更换通知渠道、调整通知规则前后，用同一口径对比分布变化。
需要明确的是，这条指标反映的是通知链路的技术时效，不反映责任人是否及时处理，也不宜单独作为团队或个人绩效依据。通知到达快，不代表问题被快速解决；通知到达慢，也可能源于渠道本身的异步特性。把它当作链路健康度的观察项，比当作考核项更合适。
三个时间口径与指标范围
构建反馈链路上有三个容易混淆的时间段，必须分开统计，不能混算成一个数。三段口径的起止事件、时间戳来源与单位如下表。
| 口径 | 起点事件 | 终点事件 | 时间戳来源 | 单位 | 反映什么 |
|---|---|---|---|---|---|
| 提交到构建完成 | 代码提交或流水线触发 | 构建任务写入完成状态 | 代码托管提交记录、流水线任务状态变更记录 | 秒 | 构建执行效率 |
| 构建完成到通知到达 | 构建任务写入完成状态 | 通知渠道确认送达或首次可被接收 | 流水线任务状态变更记录、通知服务发送/送达回执或渠道日志 | 秒 | 通知触达链路时效 |
| 通知到首次响应 | 通知到达 | 责任人首次查看、确认或处理 | 通知已读回执、工作项状态变更或评论记录 | 秒或分钟 | 责任人响应节奏 |
纳入范围需要事先写清楚，否则不同人算出的数不可比。建议纳入：已配置通知规则的流水线、参与统计的分支（如主干与发布分支）、所有已启用的通知渠道（即时通讯、邮件、工作项内提醒等）。排除项同样要约定：手动取消的构建、同一提交的重复触发记录、测试环境产生的噪声构建，默认不计入有效样本。若团队希望观察测试环境的通知延迟，应单独分组统计，不与生产流水线混在一起。
三段口径分开统计的价值在于定位问题层级。提交到构建完成偏长，问题在构建执行；构建完成到通知到达偏长，问题在通知链路；通知到首次响应偏长，问题在响应机制。三段各自有独立的改进方向，合并计算会掩盖真正的瓶颈位置。
数据从哪里取、口径怎么对齐
这条指标能否复算，取决于两个时间戳是否都能稳定取得、是否在同一时间基准上。取数来源与质量规则建议按下表执行。
| 数据项 | 采集位置 | 质量规则 |
|---|---|---|
| 构建完成时间戳 | 流水线任务状态变更记录中“完成”状态写入的时间 | 以状态变更记录为准，不以日志末行时间替代；同一构建多次状态变更时取首次进入完成状态的时间 |
| 通知到达时间戳 | 通知服务的发送/送达回执，或渠道侧日志中消息可被接收的时间 | 优先取送达回执；无回执时取渠道日志中消息落地时间，并在数据中标注来源类型 |
| 时钟基准 | 各系统服务器时间 | 要求各系统接入统一时间同步；存在跨系统偏差时，先测量偏差量并做校正，校正记录随数据保留 |
| 缺失与异常标记 | 数据清洗环节 | 缺失任一时间戳的记录标记为“数据不完整”；通知发送失败标记为“通知失败”；重试记录标记“重试”并保留首次与最终到达时间 |
时钟一致性是最容易被忽略的环节。构建系统与通知系统若分别部署在不同服务器，几秒到几十秒的偏差足以让短延迟样本失真，甚至出现负值。处理方式有两种：一是统一接入时间同步服务；二是抽样测量两系统时间偏差，在计算前对时间戳做统一校正。无论采用哪种，偏差的处理方式都应写入口径说明，保证后续复算时口径一致。
缺失值与失败记录的处理原则是“标记而不默认计入”。通知发送失败的构建，其“到达时间”实际不存在，若强行计入会拉高或拉低分布；正确做法是单独统计失败率，并在有效样本中排除。重试场景保留首次尝试与最终成功两次时间戳，主指标用最终到达时间，同时记录重试次数，便于判断链路稳定性。
在工具承载层面，ONES 支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步编排的流水线数据并更新执行状态和日志，流水线还可与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等过程。这意味着构建完成状态可以作为可追溯的记录进入统一视图；通知到达时间戳则需结合通知渠道侧的日志或回执取得，两者对齐后再进入计算。
计算步骤与公式
计算分三步：先算单次时长，再做聚合，最后确定分母口径。每一步都有明确的公式与边界。
第一步，单次时长。对每一条有效记录：
单次时长（秒） = 通知到达时间戳 − 构建完成时间戳
结果保留整数秒即可，亚秒精度对这条指标的管理意义有限。若出现负值，说明时间戳异常或时钟偏差未校正，应标记为异常记录并回查，不直接参与聚合。
第二步，聚合统计。对每个分组同时输出以下数值：
- 样本量 n：该分组内有效记录条数；
- 中位数：将时长升序排列后取中间值，偶数条取中间两个值的平均；
- P90：升序排列后第 90 百分位对应的值，常用线性插值法计算；
- 均值：所有时长之和除以 n，仅作参考，需与中位数、P90 并列展示。
同时给出中位数与P90的原因在于分布形态。通知延迟通常是右偏分布，多数构建在数秒内送达，少数因渠道重试或积压拖到数分钟。均值会被长尾拉高，中位数反映典型体验，P90反映多数情况下的上限。三者并列，才能既看常态又看长尾。
第三步，分母口径。分母为成功进入通知环节的构建次数，即构建完成且已触发通知规则的记录数。未触发通知的构建（如通知规则未覆盖该分支）、手动取消的构建、重复触发的构建不计入分母。分母与分子的对应关系必须一致：分子中的每条记录都来自分母所定义的集合。
零分母与样本过少的处理。当某分组分母为零时，输出“无有效样本”，不输出 0 秒，也不输出达标结论。当样本量过少（例如少于 30 条）时，标注“样本不足”，中位数与P90仅供参考，不据此设定或调整阈值。分组维度建议至少覆盖流水线、分支、通知渠道三个方向，任一维度下样本不足时合并到上一级维度展示，并注明合并原因。
一个可复算的例子
以下为演示情景，数据仅用于说明计算过程，不代表任何真实团队。假设某流水线主干分支某日产生 8 条构建记录，其中 1 条通知失败、1 条缺失到达时间戳。
| 记录 | 构建完成时间 | 通知到达时间 | 渠道 | 状态 | 时长（秒） |
|---|---|---|---|---|---|
| 1 | 10:00:00 | 10:00:04 | 即时通讯 | 成功 | 4 |
| 2 | 10:05:00 | 10:05:06 | 即时通讯 | 成功 | 6 |
| 3 | 10:10:00 | 10:10:05 | 即时通讯 | 成功 | 5 |
| 4 | 10:15:00 | 10:15:30 | 邮件 | 成功 | 30 |
| 5 | 10:20:00 | 10:20:08 | 即时通讯 | 成功 | 8 |
| 6 | 10:25:00 | 10:25:12 | 即时通讯 | 成功 | 12 |
| 7 | 10:30:00 | — | 即时通讯 | 通知失败 | 不计入 |
| 8 | 10:35:00 | — | 邮件 | 缺失到达时间 | 不计入 |
有效样本为记录 1 至 6，n = 6。将时长升序排列：4、5、6、8、12、30。中位数为第 3、4 位的平均，即 (6 + 8) ÷ 2 = 7 秒。P90 按线性插值计算：位置为 (6 − 1) × 0.9 + 1 = 5.5，取第 5 位与第 6 位之间插值，12 + (30 − 12) × 0.5 = 21 秒。均值为 (4 + 5 + 6 + 8 + 12 + 30) ÷ 6 ≈ 10.8 秒。
记录 7 与记录 8 不进入分母，但需单独记录：通知失败 1 条，数据不完整 1 条。若按渠道分组，即时通讯渠道有效样本为记录 1、2、3、5、6 共 5 条，中位数为 6 秒；邮件渠道仅记录 4 一条，样本不足，标注后不单独下结论。这个例子也说明均值 10.8 秒高于中位数 7 秒，长尾记录 4 的 30 秒对均值影响明显，只看均值会高估典型延迟。
阈值怎么设、结果怎么读
阈值应基于自身历史分布设定，而非套用外部通用达标线。可行做法是：先积累两到四周的稳定数据，取各分组P90作为基线，再结合业务对反馈速度的要求确定目标值。例如即时通讯渠道历史P90为 15 秒，可将阈值设为 20 秒并观察超阈比例；邮件等异步渠道天然存在投递间隔，阈值应单独设定，通常明显宽于即时渠道。两类渠道混用同一阈值，会让异步渠道长期“不达标”，失去参考意义。
解读结果时注意三点。第一，长尾优先排查：P90 明显高于中位数时，检查是否存在渠道限流、重试堆积、通知规则重复触发或接收人过多导致的发送排队。第二，区分链路问题与配置问题：某条流水线延迟异常，先看其通知规则是否指向了低优先级渠道，再看渠道侧日志。第三，指标与响应时效是相关关系而非因果关系，通知到达快不保证问题被快速处理，评估响应节奏应结合“通知到首次响应”口径单独观察。
在管理动作上，这条指标适合进入构建健康度的例行回顾：按流水线与渠道列出中位数、P90、失败通知数，对超阈值分组逐项确认原因并记录改进措施。ONES 支持多种数据报表，可追溯团队在 DevOps 工具链中的操作，集中度量和分析研发绩效；将流水线执行状态与项目关联后，构建记录与通知状态可以在同一视图下核对，便于把上述分组统计落到固定的回顾节奏中。指标本身只提供观察，改进措施与责任分工仍需团队在回顾中明确。
常见问题
构建完成时间戳和通知到达时间戳分别从哪里取？
构建完成时间戳取自流水线任务状态变更记录中“完成”状态写入的时间，同一构建多次状态变更时取首次进入完成状态的时间，不用日志末行时间替代。通知到达时间戳优先取通知服务的送达回执；没有回执时取渠道日志中消息可被接收的时间，并在数据中标注来源类型。两个时间戳来自不同系统时，需统一时间同步或测量偏差后校正，否则短延迟样本容易失真甚至出现负值。
通知发送失败或时间戳缺失的记录怎么处理？
处理原则是标记而不默认计入。通知发送失败的构建，其到达时间实际不存在，强行计入会扭曲分布，正确做法是单独统计失败率，并在有效样本中排除。缺失任一时间戳的记录标记为“数据不完整”，同样不进入主指标计算。重试场景保留首次尝试与最终成功两次时间戳，主指标用最终到达时间，同时记录重试次数，便于判断链路稳定性。这些标记项应随指标一起例行展示，避免只看到时长而忽略数据质量。
样本量很少的分组能不能直接下结论？
不建议。当某分组分母为零时，输出“无有效样本”，不输出 0 秒，也不输出达标结论。样本量过少（例如少于 30 条）时标注“样本不足”，中位数与 P90 仅供参考，不据此设定或调整阈值。分组维度建议至少覆盖流水线、分支、通知渠道三个方向，任一维度样本不足时合并到上一级维度展示并注明合并原因。这样既保留观察价值，也避免用几条记录得出过度确定的判断。
即时通讯和邮件渠道的阈值要不要分开设？
要分开设。即时通讯渠道通常秒级送达，邮件等异步渠道天然存在投递间隔，两者混用同一阈值会让异步渠道长期“不达标”，失去参考意义。可行做法是先积累两到四周稳定数据，取各分组 P90 作为基线，再结合业务对反馈速度的要求确定目标值。例如即时通讯渠道历史 P90 为 15 秒，可将阈值设为 20 秒并观察超阈比例；邮件渠道单独设定，通常明显宽于即时渠道。
这条延迟指标能否直接用于团队绩效考核？
不宜单独作为绩效依据。该指标反映通知链路的技术时效，通知到达快不代表问题被快速解决，通知到达慢也可能源于渠道本身的异步特性。它与响应时效是相关关系而非因果关系。更合适的用法是作为构建健康度的观察项进入例行回顾：按流水线与渠道列出中位数、P90、失败通知数，对超阈值分组逐项确认原因并记录改进措施。评估响应节奏应结合“通知到首次响应”口径单独观察。
