灰度期间要盯的不是"有没有报错"
灰度最容易犯的错是只看错误率 ✗：错误率没涨就放量 ✔，结果上线后发现质量下降 ✔、
成本翻倍 ✔、或某类用户被系统性影响 ✔。
灰度指标要分成四组，并事先写好回滚阈值 ✔。
一、四组指标与回滚阈值（建议值，按业务调）
① 可用性（必须盯）
- 错误率、超时率 → 相对旧版 > 2 倍 即回滚 ✔；
- P95 延迟 → > 旧版 × 1.5 回滚 ✔；
- 上游限流/失败率 → 明显上升即回滚 ✔。
② 质量（最容易漏）
- 校验通过率（格式合规 ✔）→ 下降 > 3 个百分点 回滚 ✔；
- 该拒答却作答率（编造倾向 ✔）→ 上升即回滚（这条最该严 ✔）；
- 负反馈率 → 相对上升 > 50% 回滚 ✔。
③ 成本
- 单位成本 → > 预算线 × 1.2 回滚 ✔；
- 缓存命中率骤降（可能是键变了 ✔）→ 查明前不放量 ✔。
④ 影响面（灰度特有）
- 分租户/分场景的成功率：某一组显著更差 → 该组退出灰度 ✔；
- 新出现的失败类型（旧版没有的坏模式 ✔）→ 回滚 ✔。
二、回滚判据要"事先写死"
灰度开始前把上面阈值填进配置/文档 ✔，别在灰度中临场决定 ✗ ——
临场决定会被"再等一会儿看看"拖住 ✗（这是最常见的事故扩大原因 ✔）。
三、灰度的节奏与暂停
- 阶梯放量：1% → 5% → 20% → 50% → 100% ✔；
- 每级停留至少覆盖一个业务高峰 ✔（否则测不出峰值问题 ✔）；
- 每级之间自动检查阈值 ✔（越界自动回滚，不依赖人盯 ✔）；
- 总量上限：灰度期间设成本上限 ✔（见容量与预算那两篇 ✔）。
四、三个常见反模式
- 只灰度"内部用户" ✗ → 内部用法与真实分布差异大，结论不可迁移 ✔；
- 灰度与其它改动并行 ✗ → 指标变化归因不了 ✔；
- 没有回滚演练 ✗ → 真出事时发现切不回去 ✔（见灰度开关那篇 ✔）。
五、上线判据（可直接抄）
✓ 可用性：错误率 ≤ 旧版 × 1.2，P95 ≤ 旧版 × 1.2
✓ 质量：格式合规率不降、该拒答却作答率不升、负反馈率不升 > 50%
✓ 成本：单位成本 ≤ 预算 × 1.2
✓ 影响面：各租户/场景成功率无显著分化，无新增严重失败类型
✓ 观测：以上指标在各阶梯均已覆盖一个业务高峰
任一不达标 → 自动回滚 ✔。