统计重试成功率、重试风暴和最终一致性达成时间，关键是把三个指标放在同一条同步链路、同一时间窗内计算：重试成功率看失败事件被重试救回的比例，重试风暴看单位时间重试次数是否异常放大，最终一致性达成时间看事件从首次写入到目标端与源端一致的耗时分布。本文给出可复算的公式、取数字段、计算步骤和一组示例数据，并说明分母为零、样本过少和长期未一致事件的处理方式。在同步任务与工作项状态流转的管理环节，可以借助 ONES 的集成与报表能力承载部分过程记录。
要点总览（TL;DR）
- 三个指标要放在同一条同步链路、同一时间窗内统计：重试成功率=重试后成功的事件数÷发生重试的事件数，分母只计发生过重试的事件。
- 重试风暴用单位时间重试次数、重试放大系数（重试总次数÷首次失败事件数）和同源重试集中度联合识别，阈值参考自身历史基线，不设通用达标线。
- 最终一致性达成时间=目标端与源端一致时间−事件首次写入源端时间，报告P50/P90/P95，并单独列出未收敛事件的数量与占比。
- 取数以同步事件ID为主线，关联重试日志、任务记录和源端目标端对账结果；分母为零或样本过少时标注样本量，不直接给比率结论。
- 重试成功率高不等于链路健康，需与重试风暴、一致性达成时间及错误率、积压量联合解读。
评估目标：回答重试机制是否有效
重试机制的价值需要从三个方向分别验证，任何一个方向单独看都可能得出错误结论。三个指标各自回答一个判断问题，并且必须共用同一套统计口径。
- 重试成功率回答“救回了多少”：在发生过重试的事件中，最终有多少通过重试成功送达。它衡量重试动作的有效性，适用于评估重试策略是否值得保留、退避参数是否合理。
- 重试风暴回答“是否失控”：重试行为是否在短时间内集中爆发、放大了原有故障。它适用于故障复盘和容量评估，判断重试策略在目标端异常时会不会加剧拥塞。
- 最终一致性达成时间回答“多快收敛”：数据从源端写入到目标端一致需要多久，分布如何。它适用于评估同步链路对下游业务的影响，例如报表延迟、状态展示滞后。
三个指标共用同一时间窗和同一链路范围，原因在于它们互相解释：重试成功率突然升高，可能来自重试风暴期间大量重试最终成功；一致性达成时间变长，可能由重试次数增加导致。跨链路、跨窗口混算会让这些关联失真，因此统计前先固定“哪条同步链路、哪类事件、哪个时间窗”三个前提。
指标定义与统计范围
三个指标的口径需要写清楚分子、分母、时间窗和单位，才能被不同人复算出一致结果。下表给出建议口径，实际使用时按链路特点调整并固定下来。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 重试成功率 | 重试后成功的事件数 ÷ 发生重试的事件数 | 至少重试一次且最终成功的事件数 | 发生过至少一次重试的事件数（未重试即成功的事件不计入） | 按天或按发布窗口，与另两个指标一致 | 百分比 |
| 重试风暴 | 单位时间重试次数、重试放大系数、同源重试集中度联合判断 | 窗口内重试总次数；重试总次数÷首次失败事件数；同一源端或事件类型的重试占比 | 时间窗长度；首次失败事件数；窗口内重试总次数 | 分钟级滑动窗口，另配小时级观察 | 次/分钟、倍数、百分比 |
| 最终一致性达成时间 | 目标端与源端一致时间 − 事件首次写入源端时间 | 每个事件的一致性耗时 | 纳入统计的事件总数（含未达成一致的事件，单独标注） | 与重试成功率同一时间窗 | 秒或分钟，报告P50/P90/P95 |
统计范围需要明确三件事：纳入哪些同步链路（例如代码提交同步、流水线状态同步、工作项状态回写），纳入哪些事件类型（创建、更新、状态变更），以及时间窗的起止边界。建议以事件首次写入源端的时间作为归属依据，避免事件在窗口边界跨窗导致重复计数。重试风暴的阈值不设通用达标线，应结合业务基线确定：例如以过去四周同窗口的重试次数P95作为参考上限，超过并伴随放大系数明显上升时标记为疑似风暴。
数据从哪里来：日志、事件与对账证据
三个指标能否复算，取决于原始记录是否保留了事件级字段。取数应以同步事件为主线，把重试日志、消息队列或任务记录、对账结果关联到同一个事件ID上。
| 字段 | 用途 | 取数来源 |
|---|---|---|
| 同步事件ID | 去重与跨表关联的主键 | 同步任务记录、消息队列消息属性 |
| 事件类型与源端标识 | 划分统计范围、计算同源重试集中度 | 同步任务配置、事件元数据 |
| 首次写入源端时间 | 一致性达成时间的起点、时间窗归属 | 源端业务表或事件日志 |
| 重试次数与每次重试时间 | 判断是否重试、计算单位时间重试次数 | 重试日志、任务执行记录 |
| 最终成功时间与状态 | 重试成功率分子、一致性耗时终点 | 同步任务结果、目标端写入记录 |
| 目标端与源端比对结果 | 一致性证据，确认“一致”的判定 | 定时对账任务输出 |
一致性不能只看同步任务返回成功，还需要源端与目标端的对账作为证据：按事件ID比对关键字段，一致才计入达成。缺失值处理遵循两条原则：长期未达成一致的事件不剔除，单独计入分母并标注为未收敛样本，否则一致性时间会被系统性低估；乱序到达的记录以事件ID去重，保留首次写入时间和最后一次成功时间，中间重复记录不重复计数。若某条链路缺少重试日志，应标注该链路指标不可算，不用估算值填充。
计算步骤：从原始事件到三个指标
计算按“先整理事件、再分窗口聚合、最后取分布”的顺序进行，每一步都产出可核对的中间结果。
- 按事件ID去重并标记是否重试。每个事件保留一行，字段包括首次写入时间、重试次数、最终状态、一致达成时间。重试次数大于零标记为“发生重试”。
- 按时间窗切分。以首次写入源端时间把事件归入对应日期或发布窗口，三个指标使用同一份切分结果。
- 计算重试成功率。分母为标记“发生重试”的事件数，分子为其中最终成功的事件数。分母为零时输出“无重试事件”，不输出0%或100%。
- 识别重试风暴。按分钟统计重试次数得到单位时间重试次数曲线；用窗口内重试总次数除以首次失败事件数得到重试放大系数；按源端或事件类型统计重试占比得到同源重试集中度。三项同时偏离基线时标记为疑似风暴，并记录起止时间。
- 计算一致性达成时间。对每个已达成一致的事件计算耗时，取P50/P90/P95；未达成一致的事件单独列出数量与占比，并在报告中说明分位数只覆盖已收敛样本。
- 处理样本过少。事件数低于设定下限（例如30个）时只报告绝对数量和原始耗时，不给出比率或分位数结论，避免小样本波动被误读。
重试放大系数的含义需要固定：它衡量一次失败引发了多少次重试，系数接近1说明重试基本一对一，系数显著大于1说明存在连锁重试。同源重试集中度用于区分“全局故障”和“单点故障”，集中度高时优先排查对应源端或事件类型的处理逻辑。
算例：一次同步故障的指标复算
以下为演示情景，数据为构造值，用于说明计算过程，不代表任何真实系统表现。假设某条工作项状态同步链路在一个10分钟窗口内的情况如下：共1200个事件，其中首次即成功1050个，发生重试150个；150个重试事件中最终成功120个，30个在窗口结束时仍未一致；重试总次数为600次，首次失败事件数为150个；其中110个重试事件来自同一个源端适配器。
重试成功率：分子120，分母150，结果80%。解读时需要同时说明30个未收敛事件仍在重试中，该比率是窗口截止时的快照。
重试风暴识别：单位时间重试次数为600÷10=60次/分钟；重试放大系数为600÷150=4，即一次失败平均引发4次重试；同源重试集中度为110÷150≈73.3%。若该链路历史基线为每分钟10次左右、放大系数约1.2，则三项指标同时偏离，可判定为疑似风暴，且集中度指向该源端适配器。
一致性达成时间：对120个已达成一致的事件计算耗时，假设排序后P50为45秒、P90为6分钟、P95为9分钟。报告时注明分母为120个已收敛事件，另有30个事件在窗口内未达成一致，占重试事件的20%，其耗时未纳入分位数。
三个结果放在一起看：重试成功率80%说明重试救回了大部分事件，但放大系数4和集中度73.3%说明重试行为高度集中且成倍放大，一致性P95达到9分钟说明下游感知明显延迟。若只看成功率，会误判链路状态良好。
解读与限制：指标不能当因果保证
三个指标是观测结果，不是链路健康的证明，解读时需要保留条件和边界。
- 重试成功率高不等于链路健康。成功率只统计发生重试的事件，首次即失败且未进入重试流程的事件不在分母内；成功率上升也可能来自失败事件基数变小。
- 重试风暴阈值依赖业务基线。不同链路的正常重试量差异很大，阈值应基于自身历史分布设定并定期复核，跨团队横向比较前先确认口径一致。
- 一致性达成时间受事件量和目标端负载影响。批量导入、目标端限流、网络抖动都会拉长耗时，比较不同时间窗时需说明负载背景。
- 分位数只覆盖已收敛样本。未达成一致的事件必须单独报告，否则一致性时间会被低估；长期未收敛事件应进入问题清单跟踪。
- 单指标不能替代整体可靠性评估。三个指标需与错误率、积压量、告警记录联合解读，才能判断重试策略是否需要调整。
在同步任务与工作项状态流转的管理环节，ONES 提供 API 接口用于集成企业系统，并支持对接 GitLab、Jenkins 等工具后自动同步流水线数据、更新执行状态和日志，同时提供数据报表用于追溯工具链操作。这些能力可以帮助团队把同步任务、状态变更和操作记录集中到同一处管理；上述三个专项指标的计算口径与报表，仍需按本文方法在自有数据上建立，具体报表覆盖范围以官方文档为准。
常见问题
首次即失败、没有进入重试流程的事件，要不要计入重试成功率？
不计入分母。重试成功率的分母定义为发生过至少一次重试的事件，首次即失败且未触发重试的事件属于另一类问题，应单独统计为“未进入重试的失败数”。如果把它并入分母，比率会同时反映重试策略和触发条件两方面的问题，难以判断重试本身是否有效。建议在报告中并列给出“发生重试的事件数”和“未进入重试的失败事件数”，两者相加才是该链路的失败事件总量。
重试风暴的阈值能不能直接套用行业通用值？
不建议。不同同步链路的正常重试量差异很大，代码提交同步与工作项状态回写的基线可能相差一个数量级。可行做法是以自身过去四周同窗口的重试次数分布为参照，取P95作为参考上限，再结合重试放大系数和同源重试集中度共同判断。阈值设定后要定期复核，业务量或集成范围变化时重新校准。跨团队比较前先确认统计口径、时间窗和事件范围一致。
窗口结束时仍未达成一致的事件，在一致性达成时间里怎么处理？
不能剔除。这类事件应计入分母并标注为未收敛样本，单独报告数量与占比，分位数只覆盖已收敛事件，并在结论中说明这一点。如果直接剔除，一致性达成时间会被系统性低估，看起来收敛很快，实际仍有事件长期未同步。长期未收敛的事件还应进入问题清单跟踪，结合重试日志判断是持续失败、目标端限流还是对账缺失导致。
同步任务返回成功，是否就可以认定源端和目标端已经一致？
不足以认定。任务返回成功只说明本次调用完成，字段内容是否正确、是否被目标端后续覆盖，需要源端与目标端的对账结果作为证据。建议按事件ID比对关键字段，一致才计入达成。对账频率可以与统计时间窗对齐，例如按天对账后再计算当日的一致性达成时间，避免用实时状态代替最终结果。
在 ONES 里做这类统计，产品本身能提供哪些支撑？
ONES 提供 API 接口用于集成企业系统，支持对接 GitLab、Jenkins 等工具后自动同步流水线数据、更新执行状态和日志，并提供数据报表用于追溯工具链操作，可以把同步任务、状态变更和操作记录集中到同一处管理。重试成功率、重试风暴和一致性达成时间这三个专项指标的计算口径与报表，仍需按本文方法在自有数据上建立；报表覆盖的具体指标项以官方文档为准。
