前端发布后验证：灰度观察窗口、核心指标与"谁拍板全量"到底该谁定？

背景

上个月我们团队一个 B 端 SaaS 前端发版出了点事：灰度 10% 放量后第 4 分钟，一个路由守卫的竞态 bug 导致部分用户进不去"订单中心"页面。但当时没有任何人盯着灰度大盘——QA 回归在发版前已经跑完了，开发同学发完就切到别的需求了，运维同学说"前端的事你们自己盯"。等第一个用户反馈"白屏"时，已经过了 11 分钟。

事后复盘我们加了一条"灰度放量后开发必须盯 10 分钟"的口头约定，但执行了两周就形同虚设了。这让我开始想：前端"发布后验证"这个环节，到底该怎么做、做到什么程度，似乎从来没有被认真讨论过。

社区里已经聊过很多相关话题——#431 讨论了稳定性投入的最低水位，#61 聊了前端该不该背 on-call，#513 讨论过性能预算该不该做，#28 讲了错误监控的落地路径。但有一个更具体、更日常的环节我还没看到被专门拿出来聊：代码已经发出去了、灰度正在放量、从"发完"到"确认没问题"这中间那 5~15 分钟，到底该看什么、看多久、谁负责看？

常见分歧 / 几种做法

我观察了身边几个团队和社区的讨论，大致有四种流派：

1. QA 回归兜底派：发版前 QA 跑完全量回归，发版后"没有 bug report 就是没 bug"。最省心，但前提是 bug 在 QA 环境能复现——灰度特有的问题（比如和后端新版本的时序竞态、CDN 缓存策略变化）根本覆盖不到。
2. 灰度阶梯派：1% → 5% → 20% → 50% → 100%，每档至少观察 10 分钟，看"大盘没报警"就继续放量。看起来最规范，但"大盘没报警"对前端来说是个很模糊的标准——后端的 5xx 率、RT 对前端不适用，前端看什么？JS error rate？白屏率？LCP？这些指标你的监控里真的都有、且能区分"本版本引入"和"历史存量"吗？
3. 佛系派：前端回滚就是切一个 CDN 版本号，成本极低，所以"有问题再回滚就行"。逻辑上没错，但"有问题"的前提是有人发现。那 11 分钟里，如果用户量小（B 端场景 10% 灰度可能只有 30 个用户），30 个人里出 2 个白屏，你根本收不到投诉。
4. 照搬后端 SLO 派：把后端的 error rate < 0.1%、P99 < 200ms 直接套到前端。问题是前端的"error"定义完全不同——一个 console.error 不算、一个未捕获的 Promise rejection 算、一个 React ErrorBoundary 兜住的组件渲染失败算不算？分母是 PV 还是 UV？采样率 10% 的 error rate 和 100% 的能一样吗？

我的倾向与理由

做了 8 年前端，我的核心判断是：前端发布后验证不需要很重，但需要"有标准 + 有人看 + 有时间上限"三件套，缺一个就退化成"凭感觉"。

具体来说，我倾向于一个"最小可执行"的组合：

• 核心指标就盯 3 个（别贪多）：

  1. JS uncaught error rate（相对上一版本，不升高 >5%）——注意是 uncaught，ErrorBoundary 兜住的不算；分母用采样后的 PV，和上一版本同口径对比。
  2. 核心链路成功率（比如"登录 → 首页渲染完成"这条链路，成功率不低于上一版本）——这个比 LCP 更硬，因为 LCP 受网络/CDN 影响太大，而"链路成功率"直接反映"用户能不能用"。
  3. 白屏率（首屏 3s 内无有效 DOM 的比例）——如果你们有前端监控的话，这应该是最该看的。

• 灰度窗口：1% 观察 5 分钟，够了。 理由：前端回滚成本极低（CDN 切版本，30 秒生效），所以不需要像后端那样等 10 分钟做"统计显著性"。5 分钟够 1% 流量打出足够样本（日活 10 万的 B 端 = 1000 UV × 5min = 5000 PV），error rate 的置信区间已经够窄了。

• "谁拍板全量"：发布人自己，不需要额外审批。 理由：前端回滚的代价是 30 秒 + 用户刷新，远低于"找运维确认 → 运维找开发确认 → 开发从会议里切回来"的流程成本。把决策权给离代码最近的人，反而比多一层审批更安全。

• 落地成本：上面 3 个指标，如果你们已经有 Sentry / 自研前端监控，大概率已经有原始数据，缺的只是"版本维度的对比看板"。做一个简单的 Grafana panel 或飞书机器人推送，半天能搞定。别为了"发布后验证"上一套新系统。

想听大家在什么场景下怎么选

1. 你们的团队"发布后验证"实际是怎么做的？是有人盯着，还是"没投诉 = 没问题"？
2. C 端（日活百万级）和 B 端（日活几千级）的灰度策略，你们觉得应该一样吗？我直觉是不一样——B 端 1% 可能就是 20 个用户，统计上根本不够。
3. 有没有遇到过"灰度 10% 没问题、全量 100% 后出问题"的情况？你们怎么解释这个 gap？（我怀疑是"量级效应"——1% 时不会触发的竞态、缓存穿透、第三方限流，100% 时全暴露了。）
4. 前端"发布后验证"和"日常线上监控"的边界在哪？如果日常监控已经 7×24 开着，发布后验证是不是就是"把告警阈值临时收紧 + 指定一个人 5 分钟内响应"？

欢迎拍砖，尤其欢迎"我们就是这么做的"或"我们试过但失败了"的真实案例。