持续集成运行一段时间后，效果复盘要回答三个问题：构建是否稳定、问题发现是否够快、失败是否被处理。对应的核心指标是构建成功率、反馈时长和失败闭环率。三项指标只有在时间窗、分母、统计对象一致的前提下才能横向比较，也才能支撑改进判断。
要点总览（TL;DR）
- 效果复盘围绕三个问题取数：构建是否稳定（构建成功率）、问题发现是否够快（反馈时长）、失败是否被处理（失败闭环率与修复时长）。
- 构建成功率=成功构建次数÷有效构建总次数，需事先约定取消、跳过、超时和基础设施故障是否计入分母，并保留清洗日志。
- 反馈时长以代码提交到首个构建结果为起止点，明确排队时间是否计入，同时看中位数与第90百分位，避免长尾被平均值掩盖。
- 失败闭环率依赖记录完整性，判定闭环要有缺陷或工作项关联、处理记录和事先约定的关闭标准，记录缺失时先补记录再计算。
- 指标用于定位改进方向，需结合趋势、分布和流水线拆分解读，样本量过小或流水线变更时应标注前提，不把单一指标当作绩效结论。
效果复盘要回答的三个问题
复盘的目标是判断持续集成是否在稳定运行、是否及时给出反馈、失败是否被有效处置。这三个判断分别对应稳定性、及时性和处置质量，任何一项缺失都会让结论失真。例如只看构建成功率，可能忽略失败长期无人处理；只看反馈时长，可能忽略构建本身频繁失败。
三类指标之间存在依赖关系。构建成功率反映整体运行状态，是反馈时长和失败闭环率的前提；反馈时长决定开发者多快知道结果，影响修复起点；失败闭环率与修复时长反映失败被发现之后是否真正被消化。复盘时应先看稳定性，再看及时性，最后看处置质量，形成从“有没有问题”到“问题处理得怎么样”的判断链条。
| 评估问题 | 核心指标 | 辅助指标 | 判断方向 |
|---|---|---|---|
| 构建是否稳定 | 构建成功率 | 构建时长、失败重跑率 | 成功率趋势是否平稳，失败是否集中在少数流水线 |
| 问题发现是否够快 | 反馈时长（提交到首个构建结果） | 排队时长、构建执行时长 | 中位数是否可接受，长尾是否过长 |
| 失败是否被处理 | 失败闭环率、失败修复时长 | 关联缺陷或工作项比例 | 失败是否有处理记录，关闭是否有依据 |
评估周期建议与迭代节奏对齐，按周或按迭代聚合，并保留按天的明细用于定位异常。对比基线可选三类：上一周期的环比、团队设定的目标值、历史稳定区间。目标值应由团队根据自身流水线特点设定，没有通用达标线；历史区间适合判断“当前是否偏离常态”，环比适合观察改进是否生效。
指标清单与统计范围
指标清单要覆盖稳定性、及时性、处置质量三类，并为每条指标明确统计对象、时间窗和粒度。指标名称相同但统计范围不同，结果不可比，因此统计范围需要在复盘开始前固定下来。
| 指标 | 定义 | 单位 | 建议粒度 |
|---|---|---|---|
| 构建成功率 | 成功构建次数÷有效构建总次数 | 百分比 | 按天/周，按流水线、团队拆分 |
| 构建时长 | 单次构建从开始执行到结束的耗时 | 分钟 | 按流水线，取中位数与分位数 |
| 反馈时长 | 代码提交到首个构建结果返回的耗时 | 分钟 | 按流水线，取中位数与长尾 |
| 失败闭环率 | 已闭环失败次数÷失败总次数 | 百分比 | 按周，按流水线或团队 |
| 失败修复时长 | 失败发生到闭环记录的耗时 | 小时或天 | 按周，取中位数 |
| 失败重跑率 | 重跑次数÷失败次数 | 百分比 | 按流水线 |
统计范围要明确三件事。第一，纳入哪些分支和流水线，主干分支与发布分支通常分开统计，避免发布前集中构建拉低整体成功率。第二，纳入哪些触发方式，定时构建和手动构建是否计入需要事先约定；定时构建失败可能反映环境或依赖问题，与提交触发的构建性质不同，建议单独统计或明确标注。第三，时间窗与粒度，按天聚合用于发现异常日，按周聚合用于趋势判断，按流水线或团队拆分用于定位责任范围。
数据口径与取数证据
口径决定结果能否复算。构建成功率的分子是成功构建次数，分母是有效构建总次数。取消、跳过、超时和基础设施故障是否计入分母，需要在复盘前写明。常见做法是将因基础设施故障导致的失败单独标记并从成功率分母中剔除，同时单独统计基础设施故障次数；取消和跳过一般不计入有效构建。无论采用哪种规则，都要在报告中注明，保证不同周期可比。
反馈时长的起点是代码提交时间，终点是首个构建结果返回时间，单位为分钟。排队时间是否计入需要明确：若关注开发者等待体验，应计入排队时间；若关注构建执行效率，可单独统计排队时长和执行时长。两种口径不能混用，报告中应同时给出总反馈时长和其中排队、执行两段的拆分。
失败闭环的判定需要证据。可核验的闭环证据包括：失败是否关联了缺陷或工作项、是否有明确的处理记录、关闭标准是否事先约定。仅凭“失败后没有再出现”不能算闭环，因为可能是流水线被停用或分支被合并。闭环率依赖记录完整性，记录缺失时应先补记录再计算，否则闭环率会系统性偏低。
数据来源与清洗规则同样要固定。构建记录从流水线平台导出，缺陷或工作项记录从项目管理工具导出，两边按构建编号或提交标识关联。重复触发、重跑记录要去重或单独标记，缺失字段要说明处理方式，例如反馈时长缺失的构建不计入时长统计但计入成功率统计。这样每项指标都能按同一规则复算。
计算与评估步骤
复盘可以按以下步骤执行，形成可复用的流程。
- 确定评估周期与对比基线。选定时间窗，明确环比对象、目标值或历史区间，并记录选择理由。
- 按口径导出构建记录。从流水线平台导出时间窗内的构建明细，包含触发方式、分支、流水线、开始与结束时间、结果状态、重跑标记。
- 清洗异常数据。剔除或单独标记取消、跳过、基础设施故障记录，处理重复触发和缺失字段，保留清洗日志。
- 计算三类指标。按流水线和团队拆分计算构建成功率、反馈时长中位数与分位数、失败闭环率与修复时长中位数。
- 结合趋势与分布定位问题。对比基线与本期趋势，查看失败是否集中在少数流水线，反馈时长长尾是否集中在特定时段或特定流水线。
- 形成改进项。针对定位到的问题提出具体动作，例如优化某条流水线的依赖缓存、为高频失败补充自动通知、明确失败关闭标准。
在失败闭环环节，构建失败与缺陷或工作项的关联记录是闭环证据的主要来源。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，同时将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程。对于需要留存失败处理记录的团队，这种关联可以把构建失败与项目内的工作项、缺陷记录放在同一上下文中追踪，便于复盘时核对闭环证据。具体报表类型与指标口径以实际产品配置为准。
一个复盘示例
以下为演示情景，数值仅用于说明计算方法，不代表真实团队水平。假设某团队统计一周内主干分支上由提交触发的构建，共 200 次有效构建，其中成功 170 次，失败 30 次。
构建成功率 = 170 ÷ 200 = 85%。若上一周为 88%，则环比下降 3 个百分点，需要进一步查看失败分布。假设 30 次失败中有 18 次集中在两条流水线，说明问题局部化，优先排查这两条流水线的依赖或环境配置。
反馈时长方面，假设 200 次构建的反馈时长中位数为 12 分钟，第 90 百分位为 45 分钟。中位数可接受，但长尾明显，进一步查看发现 45 分钟以上的构建集中在晚间时段，排队时间占比较高。改进方向是增加构建资源或调整定时任务时段，而不是单纯优化构建脚本。
失败闭环方面，30 次失败中 24 次关联了缺陷或工作项并有处理记录，失败闭环率 = 24 ÷ 30 = 80%。已闭环的 24 次失败修复时长中位数为 6 小时。剩余 6 次失败没有处理记录，需要确认是遗漏记录还是确实未处理；若是记录遗漏，应先补记录再评估闭环率，避免把记录问题误判为处置问题。
| 指标 | 示例数值 | 计算或说明 | 解读方向 |
|---|---|---|---|
| 构建成功率 | 85% | 170 ÷ 200 | 环比下降，失败集中在两条流水线 |
| 反馈时长中位数 | 12 分钟 | 200 次构建的中位数 | 整体可接受 |
| 反馈时长第 90 百分位 | 45 分钟 | 长尾集中在晚间 | 排队时间占比高，需调整资源或时段 |
| 失败闭环率 | 80% | 24 ÷ 30 | 6 次失败缺少处理记录，需核实 |
| 失败修复时长中位数 | 6 小时 | 已闭环失败的中位数 | 结合闭环率一起看，避免只看速度 |
结果解读与常见限制
指标解读要处理几类常见限制。分母为零时，例如某条流水线一周内没有构建，成功率无定义，应标注为“无数据”而不是 0%。样本量过小时，例如某团队一周只有 5 次构建，成功率波动大，不宜直接与大体量团队比较，可拉长时间窗或只做趋势观察。构建量骤变时，例如发布前集中构建，成功率可能被短期拉低，应结合触发方式和分支拆分判断。
成功率与反馈时长的可比性有前提。流水线变更、构建环境调整、依赖升级都会改变指标基线，跨期比较时应标注这些变更，必要时分段统计。反馈时长的口径若中途调整，例如开始计入排队时间，前后数据不可直接比较。
失败闭环率依赖记录完整性，不能直接等同于质量水平。闭环率高可能来自记录规范，也可能来自关闭标准宽松；闭环率低可能是记录遗漏，也可能是失败确实积压。解读时应同时查看修复时长和失败分布，并结合抽样核对处理记录。
指标的作用是定位改进方向，适合作为团队复盘和流程优化的输入。将单一指标直接作为个人绩效结论，容易导致规避行为，例如减少构建次数或放宽关闭标准。更稳妥的做法是三类指标一起看，结合趋势、分布和具体流水线问题，形成可执行的改进项。
常见问题
构建成功率的分母要不要把取消、跳过和基础设施故障的构建算进去？
这取决于复盘想回答的问题，关键是事先写清楚并在各周期保持一致。常见做法是：取消和跳过的构建不计入有效构建；因基础设施故障导致的失败单独标记，从成功率分母中剔除，同时单独统计基础设施故障次数，避免环境问题掩盖代码问题。无论采用哪种规则，都应在报告中注明，保证不同周期、不同流水线之间可比。中途更换口径会让前后数据失去可比性，需要分段统计。
反馈时长应该从提交算到构建结束，还是算到构建开始？
建议以代码提交时间为起点、首个构建结果返回时间为终点，单位为分钟，这样衡量的是开发者实际等待时间。排队时间是否计入要明确：关注开发者等待体验时计入，关注构建执行效率时可把排队时长和执行时长单独拆分统计。两种口径不能混用，报告中同时给出总反馈时长和排队、执行两段拆分，便于判断长尾是资源不足还是构建脚本慢。
失败闭环率偏低，是处置不及时还是记录不规范？
两种情况都会拉低闭环率，需要先区分再下结论。可以抽样核对未闭环的失败记录：如果失败后代码已修复但缺少关联的工作项或处理记录，属于记录遗漏，应先补记录再重新计算；如果失败长期无人处理，属于处置积压，应结合修复时长和失败分布定位是人力不足还是责任不清。闭环率依赖记录完整性，在记录规范之前，它更适合作为改进线索，不宜直接当作质量水平结论。
团队构建量很小，指标波动大，还能做效果复盘吗？
可以，但要调整解读方式。样本量过小时，例如一周只有几次构建，成功率会因单次失败大幅波动，不适合与大体量团队横向比较。可行做法是拉长时间窗按月度聚合，或只观察趋势方向而不追求精确数值；同时把失败明细逐条查看，用具体问题代替比率结论。分母为零的流水线应标注为“无数据”，不要记为 0%。
复盘时如何留存构建失败的处理证据？
闭环证据主要来自构建记录与缺陷或工作项记录的关联。ONES DevOps 解决方案支持集成 Jenkins、GitLab CI 等第三方流水线工具，集成后自动同步流水线数据并更新执行状态和日志，同时将流水线与项目关联，在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程。团队可以把构建失败与项目内的工作项、缺陷记录放在同一上下文中追踪，复盘时按构建编号或提交标识核对处理记录。具体报表类型与指标口径以实际产品配置为准。
