线上变更灰度：比例、观察时长、回滚阈值，你们到底卡在哪几个数上？

背景

做了 10 年运维，从 3 人小团队到 200 人 SRE 组织都待过，主持过上百次发布。有一个话题每次发布评审都要吵，而且每次吵完都"各打五十大板"——灰度到底灰多少、观察多久、什么信号触发自动回滚？

我见过三种典型做法：

• 激进派：10% 灰度，观察 5 分钟，错误率没翻倍就上全量。理由是小团队人力少，"灰度 3 小时等于发布 3 小时，业务等不起"。
• 中间派：1% → 5% → 20% → 100% 四档，每档观察 15–30 分钟，看 P99、错误率、关键业务指标（下单成功率、支付成功率）。
• 保守派：先 0.1% 金丝雀，观察 1 小时甚至跨一个业务高峰，配合自动化断言（核心接口 200 率、关键 SQL 无慢查询、下游无 5xx 突增），任一红线触发就自动回滚。

我的倾向与理由

我站中间偏保守。理由很具体：

1. 1% 灰度在日活千万的系统上其实只有几十 QPS，统计上根本看不出异常——错误率从 0.1% 涨到 0.8% 你都可能觉得"正常波动"。所以灰度比例要和流量基数挂钩，不能拍脑袋写 1%。
2. 观察时长要和"业务周期"挂钩，不能只看时间。比如电商，灰度窗口必须覆盖一个完整的小高峰（比如整点下单峰），否则你观察的 30 分钟可能全是低谷，等于没观察。
3. 回滚阈值要量化到数字，不能写"错误率明显上升就回滚"。我会写成：核心接口 P99 超过基线 2 倍且持续 3 分钟，或错误率绝对值超过 0.5%（不是相对值），任一命中自动回滚 + 通知。

想听大家怎么选

• 你们团队灰度分几档？每档多少比例、观察多久？
• 回滚是人工拍板还是自动触发？触发条件具体写的是什么数字？
• 有没有遇到过"灰度通过了，全量才炸"的情况？根因是什么？
• 你们怎么定义"灰度通过"的标准？是时间到了就过，还是必须满足一组指标？

欢迎带上你的具体数字和场景，咱们把"灰度"从玄学聊成工程。