前端灰度回滚怎么把「业务转化路径」变成可自动触发的判据：埋点 → 流式聚合 → 统计阈值这条链，窗口、样本量、显著性到底卡在哪几个数上？

背景

我们是一个 B 端 SaaS（React 18 + Vite，约 300 路由），发布走灰度：5% → 20% → 50% → 100%，每档观察 30 分钟。目前的自动回滚条件只有两条：

1. 灰度组 JS 错误率（按 UV 去重）> 对照组 3 倍且绝对值 > 0.5%；
2. 白屏率（DOMContentLoaded 后 2s 内无可见内容）> 1%。

这两条兜住了「跑崩」，但兜不住「跑对了但体验坏了」——典型如：路由守卫竞态导致订单中心进不去、表单提交链路多了一次无必要的二次确认、列表页首屏接口被改成了串行。这类问题在灰度组里错误率是平的，用户只是「少走了几步」，要到全量后工单才爆发。

热榜上 #1620 那篇讲得很透：灰度放量失败 80% 是「看的指标没暴露新代码的错」，该盯「灰度组 vs 对照组同口径差分」。#569 也提到了路由守卫竞态这种「进不去页面」的场景。但两篇都停留在「该看哪些差分指标」，没落到「这些指标怎么变成一条机器可执行的回滚规则」——而恰恰是这一步卡了我们团队半年。

现象（一次真实事故）

3 周前一次发版：订单列表页把「导出」按钮的点击链路从「直接调接口」改成了「先弹确认框再调接口」。功能没坏，灰度组 JS 错误率平、白屏率平、P99 平。全量后 2 小时收到 11 条工单「导出变慢了/多了一步」。事后算：灰度组「点击导出 → 导出成功」的转化率从 96.2% 掉到 71.4%，掉了 25pp，但因为分母小（灰度组该路径日均约 400 次转化），按 30 分钟窗口算，样本只有 ~60 次，卡方检验根本到不了 p<0.05——就算我把转化率做成了告警指标，按常规显著性阈值它也触发不了。

已尝试的排查与结果

1. 埋点侧：已把关键业务路径（登录、下单、导出、支付）拆成「入口点击 → 中间步骤 → 结果态」的漏斗埋点，事件走 Kafka → Flink 窗口聚合（30s tumbling），按 release_tag 分灰度组 / 对照组。数据管道没问题，延迟 P99 < 2s。
2. 阈值侧：
   • 试过「转化率绝对跌幅 > 5pp 且样本 ≥ 200」→ 灰度 5% 档下 30 分钟窗口凑不齐 200 样本，规则形同虚设；
   • 试过「跌幅 > 5pp 且样本 ≥ 50」→ 一周误报 4 次（全是自然波动），值班同学直接关了；
   • 试过贝叶斯方法（Beta 先验 + 后验概率 P(转化率下降) > 0.95）→ 理论上更稳，但 Flink 里实现成本高，且先验怎么定（用近 7 天同路径转化率？用大盘均值？）没有共识，团队没人敢拍板。
3. 窗口侧：30 分钟窗口太短（样本不够）；拉到 4 小时窗口，回滚响应时间从「分钟级」变成「小时级」，对真故障不可接受。
4. 降级方案（当前在用，但不满意）：灰度 20% 以上后，人工每 30 分钟拉一次漏斗对比报表，肉眼判断是否回滚。本质上是把「自动回滚」退化成了「值班盯盘」。

期望得到的答案形态

我不是要一篇「灰度发布最佳实践」综述，而是想请教几个具体到数字的问题：

1. 你们的「业务路径转化率」回滚规则，样本量下限到底设多少？是「转化率 × 窗口内 UV」这种估算，还是直接卡「该路径窗口内点击次数 ≥ N」？N 是多少？
2. 显著性/置信度怎么定：卡方 p<0.05？贝叶斯后验概率？还是干脆不用统计检验、只卡「跌幅 > X pp 且样本 ≥ Y」的朴素规则？你们被误报折磨过几次？
3. 窗口和响应时间的矛盾怎么解：是「短窗口高灵敏度 + 长窗口确认」两段式？还是「5% 档不自动回滚只告警、20% 档起才启用自动回滚」按放量档位分级？
4. 先验/基准线怎么定：用近 7 天同路径转化率做 baseline？还是用「对照组实时值」做动态 baseline（对照组本身也在自然波动）？
5. 如果只能抄一套配置直接上线，你们的「灰度组转化率回滚规则」的完整参数（指标定义、窗口、样本下限、阈值、确认逻辑、回滚动作）是什么？

引用依据：

• #1620《2% 灰度看 48 小时「一切正常」，全量后 30 分钟被工单打穿》——「该盯灰度组 vs 对照组同口径差分」，但没落到具体阈值；
• #569《前端发布后验证：灰度观察窗口、核心指标与"谁拍板全量"》——路由守卫竞态场景，「没人盯灰度大盘」的痛；
• #1357《Service Worker 把 GET 接口数据缓存成 7 天陈旧数据》——虽然不是灰度话题，但「监控里接口 200、耗时正常、错误率为零，用户却拿到旧数据」和我要解决的「指标平、体验坏了」是同一类问题。