灰度发布期间，判断继续放量、暂停还是回滚，需要同时看三层指标：技术健康度（错误率、延迟分位、资源饱和度、依赖调用失败率）、业务健康度（核心转化、下单与支付成功率、关键接口成功率）、用户体验与反馈（崩溃率、客诉与工单量、前端性能）。这些指标只有在发布前设定好阈值、分母、时间窗和最小样本量之后，才能支撑决策。本文给出指标清单、口径写法、判定步骤和一个可复算的算例，灰度观察记录与发布评审的承载方式也会一并说明，ONES可作为记录与流转的载体之一。
要点总览（TL;DR）
- 灰度判断看三层指标：技术健康度（错误率、延迟分位、资源饱和度、依赖失败率）、业务健康度（核心转化、下单与支付成功率、关键接口成功率）、用户体验与反馈（崩溃率、客诉工单量、前端性能）。
- 继续放量的条件是所有关键指标在观察窗口内落在预设阈值内，且样本量达到最小值；指标越界但未达严重级别、或样本不足时暂停并延长观察；严重越界、错误扩散或数据不可信时回滚。
- 每个指标发布前写清口径：分子分母、时间窗、单位与缺失值处理。错误率需说明请求级还是事务级，延迟用P95/P99并注明采样方式，分母为零时标记无数据而非记为0%。
- 阈值基于发布前基线设定，分正常、越界、严重越界三档并写明对应动作；多指标冲突时以影响核心业务链路的指标优先、严重级别高的优先。
- 单指标达标不代表整体健康，灰度组与基线组流量结构差异可能导致不可比，阈值调整需留痕复盘，指标结论只说明当前观察范围未发现劣化。
灰度判断要回答的三个问题
灰度期间的所有指标，最终都服务于三个动作：继续放量、暂停观察、回滚。三者对应不同的证据强度，发布前就应把判定条件写清楚，避免在压力下临时拍板。
| 决策 | 需要的证据 | 典型触发情形 |
|---|---|---|
| 继续放量 | 所有关键指标在观察窗口内落在预设阈值内，且样本量达到最小值 | 错误率、延迟分位、业务成功率与基线组差异在允许范围内，无新增客诉集中出现 |
| 暂停观察 | 指标越界但未达严重级别，或样本量不足导致结论不可信 | 某项指标轻微超出阈值、灰度流量过小、埋点数据缺失，需要延长窗口再判断 |
| 回滚 | 严重越界、错误扩散到更大流量，或数据本身不可信无法评估 | 错误率显著高于基线且持续上升、支付成功率骤降、崩溃率明显抬升、监控数据失真 |
三类决策的共同前提是健康度与样本量同时满足。指标好看但样本只有几十个请求，结论不成立；样本充足但关键指标越界，也不能放量。决策权和观察窗口同样要在发布前确定：谁有权宣布放量、谁批准回滚、每个观察窗口多长，都写进发布计划，避免灰度期间反复确认。
灰度观察的指标分层与范围
指标按三层组织，每层回答不同问题：技术层回答“系统是否稳定”，业务层回答“用户是否还能完成关键动作”，体验层回答“用户是否感知到问题”。三层都看，才能避免技术指标正常但业务已经受损的情况。
技术健康度
- 错误率：接口失败请求占比，区分请求级与事务级。
- 延迟分位：P95、P99 响应时间，关注尾部而非平均值。
- 资源饱和度：CPU、内存、连接池、队列积压的使用比例。
- 依赖调用失败率：下游服务、数据库、缓存的调用失败占比。
业务健康度
- 核心转化：注册、下单、支付等关键路径的完成率。
- 下单与支付成功率：按事务统计，而非按页面点击统计。
- 关键接口成功率：承载核心业务的接口单独设阈值。
用户体验与反馈
- 崩溃率：客户端崩溃次数占启动或会话的比例。
- 客诉与工单量：与发布前同期对比，关注集中出现的同类问题。
- 前端性能：首屏时间、关键资源加载失败率。
每个指标都要有对比对象：灰度组与基线组对比，或当前版本与上一稳定版本对比。两组流量结构不同时，直接比较绝对值容易失真，必要时按渠道、机型、地域做分层对比。
数据口径：分母、时间窗与缺失值
指标能不能用于决策，取决于口径是否可复算。发布前应为每个指标写一张口径卡，包含公式、分子分母、时间窗、单位和缺失值处理方式。
| 指标 | 公式 | 时间窗与单位 | 缺失值处理 |
|---|---|---|---|
| 错误率 | 失败请求数 ÷ 总请求数 | 按 5 或 15 分钟滚动窗口，百分比 | 分母为零时标记“无数据”，不记为 0% |
| 延迟 P95/P99 | 窗口内响应时间排序后的 95/99 分位值 | 与错误率同窗口，毫秒 | 采样率过低时标注采样方式与样本数 |
| 支付成功率 | 支付成功事务数 ÷ 发起支付事务数 | 按小时统计，百分比 | 埋点缺失时以服务端日志为准并注明来源 |
| 崩溃率 | 崩溃会话数 ÷ 总会话数 | 按天统计，百分比 | 版本未覆盖的机型单独标注 |
最小样本量与观察窗口要一起设定。常见做法是要求每个观察窗口内关键接口请求数达到一定量级，例如数百次以上，再结合业务量确定窗口长度；样本不足时延长窗口，而不是降低标准。分母为零、埋点缺失、灰度流量过小时，结论应标记为“不可判定”，按暂停处理，待数据补齐后重新评估。
从指标到决策的计算与判定步骤
判定流程可以固定为五步，每次灰度按同一顺序执行，减少临场判断的随意性。
- 发布前采集基线：用上一稳定版本或基线组在相同时间窗内的数据，记录各指标均值与波动范围。
- 设定阈值：在基线基础上留出合理波动空间，明确“正常”“越界”“严重越界”三档，并写明每档对应的动作。
- 逐层比对：先看技术健康度，再看业务健康度，最后看体验与反馈。技术层严重越界时直接进入回滚评估，不必等业务指标。
- 处理冲突：多个指标结论不一致时，以影响核心业务链路的指标优先，以严重级别高的指标优先。
- 给出结论并留痕：继续放量、暂停延长观察或回滚，记录判定依据、样本量和决策人。
暂停之后的升级路径也要提前写明：延长一个观察窗口后指标回到阈值内，可继续放量；指标持续越界或出现新的严重越界，升级为回滚。回滚动作的触发人和执行顺序在发布计划中固定，避免灰度期间临时协调。
一个放量判断的算例
以下为演示情景，数字仅用于说明判定过程，不代表通用达标线。
某服务灰度 10% 流量，观察窗口 30 分钟，关键接口请求数 12,000 次，基线组同期请求数 108,000 次。预设阈值：错误率不超过 1%，P99 不超过 800 毫秒，支付成功率不低于基线 0.5 个百分点，崩溃率不超过 0.3%。
情形一：继续放量
- 灰度组错误率 0.6%（72 ÷ 12,000），基线组 0.5%。
- 灰度组 P99 为 720 毫秒，基线组 700 毫秒。
- 支付成功率 98.9%，基线 98.7%，差异在允许范围内。
- 崩溃率 0.2%，无集中客诉。
所有关键指标在窗口内落在阈值内，样本量达到要求，判定继续放量。
情形二：暂停观察
同一窗口内，灰度组错误率为 1.4%（168 ÷ 12,000），超过 1% 阈值但未达严重级别，P99 为 760 毫秒仍在范围内。此时判定暂停，延长一个观察窗口；若下一窗口错误率回落到 1% 以内，可继续放量，若继续上升则升级为回滚。
情形三：样本不足
若灰度流量过小，窗口内关键接口请求仅 300 次，即使错误率为 0.3%，样本量不足以支撑结论，同样判定暂停，延长窗口或扩大灰度比例后重新评估。
结果解读与常见误判
指标结论有明确边界，误读会导致错误放量或过度回滚。以下情形需要在判定时主动排除。
- 单指标达标不等于整体健康：错误率正常但支付成功率下降，说明问题出在业务链路而非接口层。
- 流量结构差异导致不可比：灰度组若集中在新机型或特定渠道，指标差异可能来自用户结构而非版本本身。
- 短期波动与真实劣化：单窗口的轻微越界可能只是波动，需结合多个窗口和样本量判断趋势。
- 阈值调整需留痕：灰度期间临时放宽阈值必须记录原因和批准人，事后复盘，避免阈值变成事后解释工具。
阈值是判断工具，不是绩效保证。指标全部达标只说明当前观察范围内未发现劣化，不能推断版本在更大流量下一定安全，放量过程仍需保持观察。
把灰度观察记录进发布流程
灰度判断的价值在于可追溯。每次观察应形成一条记录，包含指标口径、阈值、观察窗口、样本量、各层指标数值、判定结论、决策人和决策时间。记录与发布单关联，回滚时可直接引用当时的判定依据。
在发布评审环节，灰度记录作为放量或回滚的输入材料：评审人查看指标是否达标、样本是否充足、结论是否与阈值一致。回滚动作执行后，将回滚原因、影响范围和后续修复计划补充到同一条记录中，形成从观察到决策再到处置的完整链路。ONES 可以承载这类发布评审与观察记录的管理动作，把指标结论、决策留痕和回滚交接放在同一工作项下，便于后续复盘时按版本追溯。
常见问题
灰度期间技术指标全部正常，业务指标却出现下滑，应该怎么判定？
这种情况按业务指标优先处理。技术层正常只说明接口和资源层面未发现异常，业务指标下滑意味着用户完成关键动作的链路可能受损，例如支付成功率下降、下单转化走低。判定时应先确认业务指标的分母和统计口径是否一致，排除埋点或统计窗口差异；确认下滑真实存在后，即使未达严重级别，也应按暂停处理，延长观察窗口并排查业务链路，避免在原因不明时继续放量。
灰度流量很小，指标看起来都正常，可以直接放量吗？
不建议直接放量。样本量不足时，指标数值的波动范围很大，少量请求下的正常结果不足以支撑结论。常见做法是要求每个观察窗口内关键接口请求数达到一定量级，再结合业务量确定窗口长度；样本不足时延长窗口或适当扩大灰度比例后重新评估。若因流量客观限制无法在合理时间内积累样本，应把结论标记为不可判定，按暂停处理，并说明后续补数据的计划。
灰度期间临时放宽阈值可以吗？需要留下什么记录？
可以调整，但必须留痕。放宽阈值前应记录原阈值、调整原因、调整后的数值、批准人和生效时间，并与当次观察记录关联。调整后继续按新阈值判定，复盘时核对放宽是否合理、是否掩盖了真实劣化。若放宽阈值后指标仍然越界，应按原定升级路径进入回滚评估，避免阈值被反复下调变成事后解释工具。
暂停观察之后，什么情况下继续放量、什么情况下升级为回滚？
暂停后延长一个观察窗口，若越界指标回落到阈值内且样本量达标，可继续放量；若指标持续越界、出现新的严重越界，或错误开始扩散到更大流量，则升级为回滚。升级路径和触发人应在发布计划中提前固定，暂停期间同步排查原因，把排查结论写入观察记录，便于回滚时直接引用判定依据。
灰度组和基线组指标差异明显，怎么判断是版本问题还是用户结构差异？
先检查两组流量结构是否可比。灰度组若集中在新机型、特定渠道或特定地域，指标差异可能来自用户构成而非版本本身。处理方式是按渠道、机型、地域等维度做分层对比，看差异是否在每一层内依然存在；同时核对两组的统计窗口、分母口径和采样方式是否一致。分层后差异消失，说明更可能是结构差异；分层后差异仍在，才按版本劣化处理。
