发布回滚阈值要能用于现场决策，前提是三类指标都能按同一口径复算：错误率按“失败请求数÷有效请求总数”，延迟按P95或P99分位与发布前基线的偏离幅度，业务成功率按“成功业务事件数÷应完成业务事件数”。阈值由基线、可接受劣化幅度和最小样本量共同推导，再放进灰度观察窗口验证，避免把单个指标当作回滚的唯一依据。
要点总览（TL;DR）
- 三类阈值都要先固定可复算口径：错误率＝失败请求数÷有效请求总数，延迟看P95或P99与发布前基线的偏离幅度，业务成功率＝成功业务事件数÷应完成业务事件数。
- 阈值由发布前同口径基线、可接受劣化幅度和最小样本量共同推导，绝对兜底阈值与相对偏离阈值组合使用，避免拍固定数字。
- 阈值要绑定灰度放量节奏：每个观察窗口结束时判定继续、延长观察或回滚，样本不足时优先延长观察而不是放量。
- 阈值有效性靠历史发布回放验证，统计误触发率与漏触发率，并把判定结果和故障确认写入发布复盘，定期校准。
- 阈值是风险信号而非故障因果证明，低流量时段和聚合指标容易失真，判定时按核心链路拆分指标并结合人工确认。
回滚阈值要回答的三个判断问题
阈值服务于发布过程中的三个动作：继续放量、暂停观察、立即回滚。设计阈值时先明确每个指标对应哪个动作，再讨论具体数字，否则容易出现“指标报警了但没人知道该不该停”的情况。
三类指标承担不同职责。错误率反映请求处理的正确性，是最直接的故障信号；延迟反映用户体验的劣化程度，往往在错误率上升之前先出现；业务成功率反映业务结果是否达成，能捕捉到接口正常但业务链路失败的情形，例如下单请求返回成功但支付回调未完成。
阈值必须与观察窗口、样本量和放量节奏绑定。同一个错误率数值，在100个请求的窗口和10万个请求的窗口里，可信程度完全不同。阈值表里应同时写明判定所需的样本下限和窗口长度，让判定动作有可执行的前提。
| 决策动作 | 主要参考指标 | 触发条件示例 |
|---|---|---|
| 继续放量 | 三类指标均在阈值内且样本量达标 | 错误率、延迟偏离、业务成功率均未越过阈值，窗口样本达到下限 |
| 暂停观察 | 单指标接近阈值，或样本量不足 | 错误率达到阈值的80%，或窗口内有效请求数低于最小样本量 |
| 立即回滚 | 任一硬性指标越过阈值且样本量达标 | 错误率超过绝对阈值，或业务成功率跌破下限，或延迟P95偏离超过设定幅度 |
三类指标的量化口径与分母定义
口径先行是阈值可复算的基础。每个指标都要写清分子、分母、统计时间窗、单位和缺失值处理方式，并固定下来，发布期间不改口径。
错误率
错误率＝失败请求数÷有效请求总数×100%。失败请求通常包括服务端5xx、网关超时、连接失败，以及业务层明确返回失败的错误码；4xx中属于客户端参数错误的请求一般不计入失败，也不计入分母。健康检查、探针请求、压测流量和内部调用是否计入，需要在口径中写明，通常排除以免稀释真实用户请求的错误率。统计时间窗建议与观察窗口一致，例如5分钟滚动窗口。
延迟
延迟使用P95或P99分位，单位毫秒，统计时间窗与错误率保持一致。核心链路建议看P99，面向大量用户的页面或接口可看P95。判定时比较的是与发布前同口径基线的偏离幅度，例如P95从180ms上升到260ms，偏离约44%。只报绝对值容易受流量结构影响，偏离幅度更能反映发布带来的变化。分位统计需要足够样本，样本过少时分位值不稳定。
业务成功率
业务成功率＝成功业务事件数÷应完成业务事件数×100%。业务事件要给出明确定义，例如“支付成功回调”“订单创建完成”，并规定去重规则，同一订单重复回调只计一次。分母来自业务侧应完成的事件数，例如进入支付流程的订单数，而不是接口请求数。事件定义和分母来源需要与业务方共同确认，避免发布期间临时调整。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 | 缺失值处理 |
|---|---|---|---|---|---|---|
| 错误率 | 失败请求数÷有效请求总数 | 5xx、超时、连接失败、业务失败码 | 排除探针、压测、内部调用后的用户请求 | 5分钟滚动 | 百分比 | 分母为0时判定为样本不足，不计算 |
| 延迟P95/P99 | 窗口内请求耗时的分位值 | — | 有效请求的耗时样本 | 5分钟滚动 | 毫秒 | 样本低于下限时标记不可比 |
| 业务成功率 | 成功业务事件数÷应完成业务事件数 | 去重后的成功事件 | 进入业务流程的应完成事件 | 与观察窗口一致 | 百分比 | 分母为0时判定为无业务流量，不触发回滚 |
分母为零、样本量不足、流量结构变化是三类常见异常。分母为零时不做比率判定，转为检查流量是否正常；样本量低于下限时延长观察窗口或暂停放量，不用小样本比率下结论；流量结构明显变化时，例如大促流量涌入或某渠道中断，应暂停判定并人工确认，因为此时基线不再可比。
阈值怎么从基线推导出来
阈值来自基线、可接受劣化幅度和统计置信度的组合，固定数字只能作为兜底。推导分四步。
- 采集发布前同口径基线。取近7天同时段数据，按与发布期相同的公式、时间窗和过滤规则计算错误率、延迟分位和业务成功率，记录均值和波动范围。同时段很重要，工作日早高峰与周末凌晨的流量结构差异会直接影响分位值。
- 设定可接受劣化幅度。依据包括业务影响程度、SLO目标和历史波动。核心交易链路的可接受劣化幅度应小于非核心页面；历史波动大的指标，阈值要留出波动空间，避免正常抖动触发回滚。
- 确定最小样本量与观察窗口。根据基线流量估算在给定窗口内能积累多少有效请求，确保分位统计和比率判定有足够样本。低流量服务需要更长窗口或更低放量起点。
- 组合绝对阈值与相对偏离。绝对阈值用于兜底，例如错误率超过5%立即回滚；相对偏离用于捕捉发布带来的变化，例如延迟P95较基线上升超过30%触发暂停。两者同时写入阈值表，判定时任一满足即进入对应动作。
| 指标 | 基线值（近7天同时段） | 可接受劣化幅度 | 相对阈值 | 绝对兜底阈值 | 最小样本量 |
|---|---|---|---|---|---|
| 错误率 | 0.4% | +0.6个百分点 | 1.0% | 5% | 2000请求/窗口 |
| 延迟P95 | 180ms | +30% | 234ms | 500ms | 2000请求/窗口 |
| 业务成功率 | 99.2% | -0.5个百分点 | 98.7% | 97% | 300业务事件/窗口 |
上表是可填写的结构示例，数值需按各自业务的基线和SLO替换，不作为通用达标线。
观察窗口与放量节奏如何配合阈值
阈值只有放进灰度时间轴才有判定意义。按放量比例分阶段设置观察窗口，每个窗口结束时做一次判定：通过则进入下一阶段，接近阈值或样本不足则延长观察，越过硬性阈值则回滚。
| 阶段 | 放量比例 | 观察窗口 | 样本要求 | 判定节点 |
|---|---|---|---|---|
| 灰度1 | 1% | 30分钟 | 有效请求≥2000 | 窗口结束判定，样本不足则延长至满足或回滚 |
| 灰度2 | 10% | 30分钟 | 有效请求≥5000 | 同上，重点看业务成功率 |
| 灰度3 | 50% | 20分钟 | 有效请求≥10000 | 三类指标同时判定 |
| 全量 | 100% | 60分钟 | 按实际流量 | 发布后观察，异常则回滚 |
窗口内样本不足时，优先延长观察而不是直接放量，因为小样本下的比率和分位都不可靠。多指标同时触发时，按严重程度排序：业务成功率跌破绝对下限或错误率越过绝对阈值，直接回滚；延迟偏离和单指标接近阈值，先暂停观察。单指标触发只说明存在风险信号，是否回滚结合其他指标和人工确认决定。
算一个例子：一次灰度发布的阈值判定
以下为演示情景，数字用于说明计算过程，不代表真实发布数据或通用标准。
某服务灰度10%流量，观察窗口30分钟，窗口内有效请求12000个，失败请求156个；延迟P95为250ms，发布前基线为180ms；业务事件应完成400笔，成功392笔。阈值采用上一节的设定：错误率相对阈值1.0%、绝对阈值5%；延迟P95相对阈值234ms；业务成功率相对阈值98.7%、绝对下限97%。
- 错误率＝156÷12000＝1.3%，超过相对阈值1.0%，未到绝对阈值5%，判定为暂停观察。
- 延迟偏离＝(250-180)÷180≈38.9%，超过30%的可接受幅度，P95超过234ms，同样指向暂停。
- 业务成功率＝392÷400＝98.0%，低于98.7%的相对阈值，高于97%的绝对下限，判定为暂停观察并排查业务链路。
三项指标同时越过相对阈值，虽然都未触及绝对兜底线，结论应是暂停放量、排查原因，而不是继续放量。若窗口内有效请求只有800个，低于2000的最小样本量，则比率和分位都不可比，应延长观察窗口；若业务事件分母为0，说明该窗口没有业务流量，业务成功率不参与判定，转而检查流量是否正常。
怎么验证阈值在实际发布中有效
阈值设定后需要用历史数据检验，否则无法判断它是灵敏还是迟钝。验证分三步。
- 回放历史发布。取过去若干次发布（包括正常发布和发生过故障的发布）的指标数据，按当前阈值重新判定，统计误触发率（阈值触发但实际无故障）和漏触发率（实际发生故障但阈值未触发）。误触发率高说明阈值过紧，漏触发率高说明阈值过松。
- 对照故障确认。阈值触发后，用故障工单、告警记录和用户反馈确认是否真的发生了可感知故障，建立触发与故障的对照关系，避免把指标波动当成故障。
- 定期校准。建议每季度或在重大架构变更、流量结构变化后重新采集基线并校准阈值；连续多次误触发或漏触发时提前校准。
验证结果应写入发布复盘记录，包括本次发布的指标实际值、阈值判定结果、是否回滚、事后确认的故障情况，以及阈值是否需要调整。这些记录可以在ONES中通过发布工作项和复盘文档承载：把每次发布的阈值判定结果作为工作项字段或文档内容留存，复盘时按发布批次汇总误触发和漏触发情况，形成可追溯的校准依据。这样阈值调整有历史数据支撑，而不是凭印象修改。
| 记录项 | 内容 |
|---|---|
| 发布批次 | 版本号、发布时间、放量阶段 |
| 指标实际值 | 错误率、延迟P95/P99、业务成功率及样本量 |
| 判定结果 | 继续、暂停或回滚，触发的是哪个指标 |
| 故障确认 | 是否发生可感知故障，影响范围 |
| 阈值调整 | 是否调整、调整依据、新阈值 |
解读阈值时的限制与常见误用
阈值是风险信号，不能证明故障原因。错误率上升可能来自依赖服务异常、流量突增或发布本身，阈值只告诉你“需要停下来看”，不告诉你“问题出在哪”。把阈值触发直接等同于发布缺陷，会误导排查方向。
不同业务和流量结构下的阈值不能直接照搬。交易类服务与内容浏览服务的基线、波动和业务事件定义差异很大，同一组数字在一个场景有效，在另一个场景可能频繁误触发或完全失灵。跨团队复用阈值时，至少重新采集基线和样本量。
低流量时段的统计不可比。凌晨低峰期的请求量可能不足以支撑分位计算，此时延迟P99波动剧烈，错误率的一个失败请求就能让比率跳变。低流量窗口应延长观察或降低判定权重，不用小样本结论驱动回滚。
指标被稀释或掩盖的情形也需要警惕。全站错误率可能因为大量健康检查请求或缓存命中而保持平稳，掩盖了某个核心接口的持续失败；平均延迟正常但P99已经恶化，说明部分用户体验严重下降。判定时应按核心链路拆分指标，而不是只看聚合值。阈值是发布风险管理的工具之一，需要与人工确认、日志排查和业务反馈配合使用。
常见问题
发布期间流量很小，错误率和延迟分位都波动很大，阈值还怎么用？
低流量时比率和分位都不稳定，一个失败请求就能让错误率跳变，P99延迟也会剧烈波动。处理方式是先看样本量：窗口内有效请求低于最小样本量时，判定为样本不足，延长观察窗口或降低放量起点，不用小样本比率下结论。如果服务整体流量长期偏低，可以把观察窗口拉长到能积累足够样本，或者把判定重心放在业务成功率这类事件计数指标上，同时保留人工确认环节。分母为零时不做比率判定，先检查流量是否正常。
多个指标同时越过阈值，但都没到绝对兜底线，应该直接回滚吗？
这种情况通常先暂停放量、排查原因，而不是立即回滚。绝对兜底阈值用于处理明确的严重故障，例如错误率超过5%或业务成功率跌破绝对下限；相对阈值捕捉的是发布带来的劣化信号，多项同时越过说明风险在累积，但还需要结合日志、依赖服务状态和业务反馈确认。如果排查中发现根因指向本次发布且短期无法修复，再执行回滚。判定顺序建议是：绝对阈值触发直接回滚，相对阈值触发先暂停观察，单指标接近阈值只做预警。
业务成功率的事件定义由谁确认，发布期间可以调整吗？
业务事件定义和分母来源需要与业务方在发布前共同确认，例如“支付成功回调”“订单创建完成”具体指哪个环节、如何去重、分母取进入流程的订单数还是其他口径。确认后应写入阈值表并固定，发布期间不调整，否则前后窗口的数据不可比，判定结论也失去意义。如果发布过程中发现事件定义有遗漏，正确做法是记录问题、暂停相关判定，等发布结束后再修订口径，而不是临时改公式继续判定。
阈值校准多久做一次，什么情况下要提前校准？
常规做法是每季度校准一次，重新采集近7天同时段基线并核对阈值。出现以下情况时提前校准：连续多次误触发（阈值触发但事后确认无故障）或漏触发（发生故障但阈值未触发）；重大架构变更或依赖服务调整；流量结构明显变化，例如大促、渠道上线或下线。校准依据来自发布复盘记录中的指标实际值、判定结果和故障确认情况，用历史数据支撑调整，而不是凭印象改数字。
全站聚合指标看起来正常，是否就可以判定发布通过？
聚合指标正常不足以判定通过。全站错误率可能被大量健康检查请求或缓存命中稀释，掩盖某个核心接口的持续失败；平均延迟正常但P99已经恶化，说明部分用户体验严重下降。判定时应按核心链路拆分指标，分别看关键接口的错误率、延迟分位和业务成功率，再结合聚合值做整体判断。阈值表里也建议为核心链路单独设定阈值，避免单点问题被大盘数据掩盖。
