自动回滚到底该多激进？聊聊误伤与漏报的取舍

背景

先交代一下我的坐标：SRE 5 年，管过 12 个微服务的发布链路。过去两年我把团队发布流水线从「人点发布 → 人盯 30 分钟 → 人决定回滚」逐步改成「金丝雀 5% → 自动观测 10 分钟 → 异常自动回滚」，中间踩了不少坑，也收获了不少。今天想把一个没想清楚的问题抛出来，听大家怎么权衡。

常见分歧

社区里我大致看到四种流派，我自己也在这几种之间摇摆过：

流派 A：激进派 —— 错误率超过基线 2 倍、P99 超过 SLO 阈值，直接回滚，不管是不是「发布引起」的。理由是：SRE 的第一原则是「先止血再排查」，误伤一次发布的成本 < 漏报一次 P0 的成本。

流派 B：保守派 —— 只告警、不自动回滚，人确认后再动。理由是：自动回滚的误伤成本其实很高——一次误回滚，用户会看到 5xx、网关会抖、下游会重试风暴、值班会被电话叫醒排查「为什么回滚了」，最后发现是流量毛刺不是发布问题，一来一回 40 分钟。

流派 C：分级派 —— 按服务等级分：核心交易链路激进（阈值松、回滚快），非核心链路保守（阈值紧、允许人确认）。听起来最合理，但落地时「核心/非核心」怎么划、谁说了算、怎么维护，是另一场战争。

流派 D：SLO 驱动派 —— 不看瞬时错误率，看 SLO 烧尽率（burn rate）：多窗口多阈值（1h 快烧 + 6h 慢烧），只有两者同时触发才回滚。Google SRE 那套，理论最干净，工程上最重。

我踩过的坑

去年一次大促前，我把核心支付链路的自动回滚阈值调得比较激进（错误率 > 基线 1.5× 持续 3 分钟就回滚）。结果某次发布后 12 分钟，上游一个批量任务把 QPS 拉高了 3 倍，瞬时错误率 2.1×，自动回滚触发了。回滚本身没问题，但：

1. 网关短暂抖动 8 秒，上游 200 个请求失败重试
2. 值班同学被叫醒，花了 25 分钟排查「是不是发布有问题」
3. 最后发现是上游流量问题，不是发布问题
4. 更麻烦的是：这次发布本身是好的，回滚后又要重新走一遍金丝雀流程，白白多花了 40 分钟

从那以后我对「多激进」这件事开始纠结。

我的倾向（欢迎打脸）

我现在倾向于一个混合策略，但还没完全落地：

1. 快烧窗口（1h）：错误率 > 基线 3× 持续 2 分钟 → 自动回滚（这个阈值足够高，基本只有真正的发布问题会触发）
2. 慢烧窗口（6h）：错误率 > 基线 1.3× 持续 30 分钟 → 只告警 + 冻结后续批次（不自动回滚，但阻止 10% → 50% → 100% 的推进）
3. SLO 烧尽率作为辅助信号，不单独触发回滚，只用于「是否放行下一批」的决策

核心逻辑：回滚是不可逆操作（至少对当次发布而言），所以阈值要松；冻结是可逆操作，所以阈值可以紧。 把「回滚」和「暂停推进」拆成两个独立决策，各自用不同的阈值，比「一个阈值管所有事」合理得多。

想听大家聊的

1. 你们的自动回滚阈值是怎么定的？有没有一套可复现的方法论，还是「拍脑袋 + 事故驱动调参」？
2. 误伤一次自动回滚，你们的实际成本大概是多少（人时 + 用户影响）？这个数字怎么量化？
3. 核心/非核心链路的分级，你们怎么划的？谁拍板？怎么防止「所有服务都号称核心」？
4. 有没有人真正落地过 Google 那套多窗口 SLO 烧尽率？工程上最重的环节是哪一步？
5. 一个更开放的问题：你们团队里，自动回滚触发后，值班同学的第一反应是「系统真聪明」还是「又要排查为什么回滚了」？ 这个感受本身可能比任何指标都重要。

欢迎带案例来聊，越具体越好。