需要明确的回滚标准
别名: 回滚标准 · 灰度回滚 · kill criteria
概念解释
小范围发布若没有事先写明回滚标准（rollback criteria / kill criteria），失败会变成会议室里的口角：多少投诉才算严重、一次数据损坏要不要停、错误率比基线高多少算不可接受。回滚标准是一组可观察、可判定、与范围绑定的停止规则，触发后把用户带回旧体验或关闭新路径。它不是工程上的“能回滚”能力本身——没有标准，能力只是一扇锁着的门。标准必须在看到结果之前冻结，否则团队会在已经受伤之后重新定义“还好”。
机制
发布之后的信息是含混的：新奇效应、支持工单滞后、内部人员帮忙解释。没有阈值时，责任扩散，每个人都能把当前状态说成“再观察一下”。损失会在争论中继续发生。预先标准把判定从偏好改成规则：触及则停，未触及则继续收集。标准还强制团队想象失败形态——崩溃、错误提交、无法完成关键任务、投诉激增——从而补上监控。回滚本身有成本（用户已形成的新习惯、未完成的迁移），所以标准需要区分“立即停”和“本阶段不再扩大”，避免把所有异常都做成拉闸。
怎么研究
把回滚标准当作研究方案的一部分：列出指标、比较基线、时间窗口和决策人。演练一次纸面故障，看现有监控能否在窗口内触发。事后分析应报告是否触发、触发是否过晚、以及标准是否被临时改写。被改写的标准不能再当作预先承诺。质性材料（严重个案）应有升级路径进入回滚，而不是只认聚合指标。与实验中的停止规则（stopping rule）同类：保护参与者优先于保护假设。
边界
有些失败没有干净的回滚：数据已经写进外部系统、用户已经把内容发给别人、监管已经收到申报。此时标准应包含补偿和隔离，而不只是“切回旧版”。指标延迟高的场景（周活跃、NPS）不能当即时回滚依据。标准过窄会把真实伤害当成噪声；过宽会把正常波动当成灾难，损害对方法的信任。多人会签会拖慢触发，一人独断又可能误停——要写明值守职责而不是写明“大家商量”。
怎么落地
- 发布前冻结三条：立即回滚、停止扩大、继续观察；每条配指标、窗口和责任人。
- 用一次故障演练确认监控能在窗口内亮灯，演练失败则不准发布。
- 严重个案设独立升级通道，不要求先凑够统计显著。
- 触发后先执行再解释；禁止在已经达到阈值时开会重新定义阈值。