发布回滚阈值要能直接支撑“回不回”的决策，需要把错误率、延迟、业务成功率三类指标成组量化：每个指标写清分子分母、统计范围、观察窗口、基线来源和对应动作。阈值由发布前基线推导，并与绝对上限并用；样本不足或分母过小时转人工判断。本文给出可复算的定义、判定步骤和验证方法，数值示例仅作演示。
要点总览（TL;DR）
- 三类阈值要成组量化：错误率=失败请求数÷有效请求数，延迟用P95/P99分位值对比发布前基线，业务成功率=关键动作成功数÷发起数，每个指标都要写清统计范围与排除项。
- 观察窗口按流量覆盖速度分段设置，如发布后5分钟、30分钟、2小时，并设最小样本量；样本不足或分母过小时标记为数据不足，转人工判断而非自动回滚。
- 阈值由基线相对增幅与绝对上限并用推导，硬指标任一越线即触发回滚，软指标需连续多个窗口越线，判定结果对应回滚、继续观察、暂停放量三种动作。
- 阈值有效性通过发布演练、历史发布回放和灰度对照验证，记录每次触发与未触发的实际影响并定期校准；指标达标不等于无风险，单指标不能代表整体发布质量。
回滚阈值要回答的评估目标
回滚阈值的评估目标只有一个：在本次发布造成不可接受影响之前，给出一个可执行、可追责的回滚判断。它评估的对象是本次发布变更引入的异常，而不是一般服务事件。线上故障可能来自依赖、基础设施或流量突增，这些情况走事件处置流程；回滚阈值只回答“这次发布是否应当撤回”。
围绕这个目标，阈值说明至少要绑定三件事：判定依据（哪几个指标、什么口径）、触发方式（自动触发还是人工确认）、责任角色（谁在什么时限内执行回滚）。自动触发适合错误率、延迟这类能实时取数、口径稳定的硬指标；业务成功率涉及订单、支付等关键动作，通常需要业务方确认数据完整性后再决定，适合人工确认触发。两类方式可以并存，但要在发布前写清楚各自覆盖哪些指标。
一份可用的评估目标说明可以包含以下字段：发布批次与变更范围、受影响的接口和业务链路清单、三类指标的阈值与窗口、自动触发与人工确认的分工、回滚执行人和决策人、回滚后的验证方式。这份说明在发布评审时确认，发布期间按同一版本执行，避免中途改口径。
三类指标的定义、范围与分母口径
三类指标都要写成可复算的公式，并固定分子、分母、统计范围和排除项。口径一旦确定，发布前后必须一致，否则对比失去意义。
| 指标 | 公式 | 分子 | 分母 | 单位 | 统计范围与排除项 |
|---|---|---|---|---|---|
| 错误率 | 失败请求数 ÷ 有效请求数 | 计入失败的状态码或异常请求数 | 同窗口内有效请求数 | 百分比 | 按服务或接口统计；剔除健康检查、压测流量、爬虫流量 |
| 延迟 | P95 或 P99 响应时间 | — | 同窗口内成功请求的响应时间样本 | 毫秒 | 按接口或链路统计；说明采样方式与是否含超时请求 |
| 业务成功率 | 关键动作成功数 ÷ 发起数 | 成功完成的关键业务动作数 | 同窗口内发起的关键动作数 | 百分比 | 按关键动作清单统计；剔除测试账号与内部流量 |
错误率的关键在“哪些算失败”。5xx 通常计入；4xx 要区分：参数错误、鉴权失败属于客户端问题，一般不计入发布引入的失败，但发布后 4xx 突增也可能说明接口契约变更，需要单独观察。超时、连接重置、下游返回异常也应明确是否计入。这些规则写在指标定义表里，发布期间不改。
延迟用分位值而不是平均值。平均值会被少量极慢请求拉高，也会被大量快请求稀释，难以反映尾部体验。P95 表示 95% 的请求快于该值，适合观察大多数用户的体验；P99 更敏感，适合核心链路。要说明统计的是哪些接口、是否包含超时请求、采样是全量还是抽样。不同接口的延迟不可直接比较，阈值按接口分别设定。
业务成功率依赖发布前确定的关键动作清单，例如下单、支付、登录、提交表单。清单在发布评审时固定，避免发布后挑选有利指标。分母是发起数而非访问数，分子是成功完成数，部分成功、重复提交、幂等重试的处理规则也要写明。
观察窗口、最小样本量与基线怎么定
观察窗口按流量覆盖速度和业务周期确定。发布后流量逐步切到新版本，窗口太短可能只覆盖少量实例，太长则延误回滚。常见做法是分段设置：发布后 5 分钟看即时异常，30 分钟看稳定表现，2 小时覆盖一个较完整的业务周期。核心交易类业务还应覆盖至少一个业务高峰或日切时点。每个窗口独立计算指标，独立判定。
最小样本量解决“数字好看但不可信”的问题。窗口内有效请求数或关键动作发起数低于设定下限时，指标波动主要来自随机性，不能据此自动回滚。处理方式是标记为数据不足，延长窗口继续观察，或转人工判断。最小样本量按业务量设定，例如核心接口每个窗口至少数百次有效请求，低频接口则直接采用人工确认。具体数值应结合历史流量分布确定，没有通用标准。
基线取发布前同时间段、同流量水平的历史数据。同时间段能抵消业务周期的自然波动，同流量水平能避免高峰与低谷混比。如果发布前流量结构发生明显变化，例如大促、渠道调整，历史基线可能失效，此时应改用灰度对照组：同一时间新旧版本各承接一部分流量，直接比较两组指标。分母为零或极小时，标记为数据不足，不参与自动判定，避免因流量过低产生误报。
阈值计算与回滚判定步骤
阈值由基线推导，并与绝对上限结合。只用相对增幅，低基线时轻微波动就会越线；只用绝对上限，高基线业务可能长期贴着上限运行。两者并用：相对增幅捕捉“比平时明显变差”，绝对上限兜住“已经不可接受”的情况。
- 取发布前基线与发布后各窗口的同口径数据，分别计算错误率、P95 延迟、业务成功率。
- 为每个指标设定相对阈值，例如错误率较基线上升若干个百分点、P95 延迟较基线上升一定比例、业务成功率较基线下降若干个百分点。具体数值按业务容忍度确定。
- 同时设定绝对上限，例如错误率超过某一水平、P95 延迟超过某一毫秒数、业务成功率低于某一水平。绝对上限来自业务可接受的最低体验，而不是行业通用值。
- 组合判定：硬指标（如核心链路错误率、支付成功率）任一越线即触发回滚；软指标（如非核心接口延迟）需连续多个窗口越线才触发，减少偶发波动造成的误回滚。
- 判定结果映射到三种动作：触发回滚、继续观察、暂停放量。暂停放量适合指标接近阈值但尚未越线的情况，先停止扩大新版本流量，等待下一个窗口确认。
判定过程要留痕：每个窗口的指标值、对比基线、判定结论、执行人和时间。发布评审时把这些记录与变更单关联，回滚决策有据可查。在 ONES 中，可以把发布单、阈值说明和每个窗口的判定记录放在同一个工作项下，用文档承载指标定义与基线，用状态流转记录“观察中—暂停放量—回滚”的决策过程，让开发、测试和业务方看到同一份依据。
一个可复算的量化示例
以下为演示数据，仅用于说明计算过程，数值不可直接照搬。
| 指标 | 基线（发布前同时段） | 发布后 30 分钟窗口 | 阈值设定 |
|---|---|---|---|
| 有效请求数 | 100,000 | 48,000 | — |
| 失败请求数 | 500 | 720 | — |
| 错误率 | 0.50% | 1.50% | 较基线上升 0.5 个百分点，或绝对超过 2% |
| P95 延迟 | 180 ms | 260 ms | 较基线上升 30%，或绝对超过 400 ms |
| 关键动作发起数 | 20,000 | 9,000 | — |
| 关键动作成功数 | 19,600 | 8,550 | — |
| 业务成功率 | 98.0% | 95.0% | 较基线下降 2 个百分点，或绝对低于 95% |
逐步计算：错误率 720 ÷ 48,000 = 1.50%，较基线 0.50% 上升 1.0 个百分点，超过 0.5 个百分点的相对阈值，未超过 2% 的绝对上限，判定为越线。P95 延迟 260 ms 较基线 180 ms 上升约 44%，超过 30% 的相对阈值，未超过 400 ms 绝对上限，判定为越线。业务成功率 8,550 ÷ 9,000 = 95.0%，较基线下降 3.0 个百分点，超过 2 个百分点的相对阈值，且正好触及 95% 的绝对下限，判定为越线。
按组合规则，错误率和业务成功率属于硬指标，任一越线即触发回滚。本例三项均越线，结论是立即回滚，并记录该窗口数据用于后续校准。示例假设基线来自同时间段、同流量水平，且失败请求已按定义剔除健康检查和压测流量；实际使用时若流量结构不同，基线需重新选取，阈值也应随业务调整。
阈值是否有效的验证方法与解读限制
阈值设定后要通过发布演练、历史发布回放和灰度对照验证。发布演练在预发或小流量环境模拟异常，检查阈值能否在预期窗口内触发、误报是否可接受。历史发布回放用过去已知有问题的发布数据代入当前阈值，看是否能提前识别；再用正常发布数据检查误报率。灰度对照让新旧版本同时承接流量，比较两组指标差异，验证阈值对真实劣化的灵敏度。
每次发布后记录触发与未触发的情况：指标值、判定结论、实际影响、是否回滚、回滚后指标恢复情况。定期汇总这些记录，校准阈值。误报多说明阈值过紧，漏报多说明过松。校准要基于数据，而不是凭感觉调整。
解读阈值时有几项限制需要说明。指标达标不等于无风险，功能缺陷、数据错误、权限问题可能不体现在这三类指标上，单指标更不能代表整体发布质量。跨服务的指标不可直接比较，不同接口的延迟基线差异很大。流量结构变化，例如渠道切换、大促、爬虫比例上升，可能导致基线失效，此时应改用灰度对照或重新取基线。阈值是决策辅助，最终回滚判断仍需结合变更内容、影响范围和业务方意见。
常见问题
发布后流量很小，指标波动大，这时还能按阈值自动回滚吗？
不建议。窗口内有效请求数或关键动作发起数低于设定的最小样本量时，指标波动主要来自随机性，自动判定容易误报。此时应把该窗口标记为数据不足，延长观察窗口继续取数，或转人工判断。低频接口可以直接采用人工确认触发，不必强行套用自动阈值。
错误率里的4xx要不要算作发布引入的失败？
需要分类处理。参数错误、鉴权失败这类4xx通常属于客户端问题，一般不计入发布引入的失败；但发布后4xx突增可能说明接口契约变更或调用方适配问题，应单独观察。5xx、超时、连接重置、下游返回异常是否计入，要在指标定义表里事先写明，发布期间不改口径。
历史基线在大促或渠道调整期间失效了怎么办？
改用灰度对照组：同一时间让新旧版本各承接一部分流量，直接比较两组指标差异，用组间差异代替历史基线。如果无法做灰度，则重新选取与当前流量结构接近的时段作为基线，并在发布记录中注明基线变更原因，避免与旧阈值混用。
阈值触发回滚后，怎么判断这次触发是必要的还是误报？
回滚后对比指标恢复情况与实际业务影响：回滚后指标明显回落且用户侧有可感知异常，说明触发必要；回滚后指标无明显变化，可能是偶发波动或基线失效。把每次触发与未触发的指标值、判定结论、实际影响记录下来，定期汇总，误报多说明阈值过紧，漏报多说明过松，据此校准。
三类指标都达标，是否就可以认为这次发布安全？
不能。功能缺陷、数据错误、权限问题可能不体现在错误率、延迟和业务成功率上。这三类指标是回滚决策的辅助依据，最终判断还需结合变更内容、影响范围和业务方意见。跨服务的指标也不可直接比较，不同接口的延迟基线差异很大，阈值应按接口或链路分别设定。
