【背景】
上周一个兄弟团队半夜 2 点告警，灰度发布后核心接口 P99 从 80ms 飙到 2.3s。值班同学做了两件事：
- A 同学（10 年经验）：直接点回滚，3 分钟恢复，第二天慢慢查。
- B 同学（3 年经验）：先 kubectl logs 看了 5 分钟，发现是下游超时配置被改，定位后改了配置而不是回滚。
结果两人都对——A 避免了更大面积的雪崩，B 省了一次回滚 + 重新发布的 15 分钟窗口。
但问题是：如果 B 看日志的 5 分钟里，流量已经打爆了下游，怎么办？
【两种流派，我见过两种极端】
流派一：「回滚是肌肉记忆，定位是事后复盘」
- 逻辑：线上状态不可信，回滚后环境回到已知稳定态，排查空间最大。
- 适用：发布引发的、影响面未知的、下游依赖多的场景。
- 代价：回滚本身有成本（连接池重建、缓存失效、数据状态不一致），而且「回滚了」不等于「理解了」，同一个坑下次还会踩。
流派二：「先看 5 分钟日志再动手，别把回滚当万能药」
- 逻辑：很多时候根因是一行配置 / 一个参数，回滚是「治标」，改配置才是「治本」。
- 适用：影响面可控（单服务、无跨服务级联）、日志清晰、改动可逆的场景。
- 代价：那 5 分钟里故障在扩散，如果你判断错了，代价是回滚 + 额外 15 分钟恢复窗口。
【我的倾向：两个变量决定第一动作】
做了 10 年运维，我的判断框架其实很简单，就两个变量：
- 爆炸半径是否可控？ —— 如果故障只影响一个服务、下游没有级联风险，我有信心看 3 分钟日志。如果可能级联（消息队列堆积、连接池耗尽、数据库锁等待），我秒回滚，不犹豫。
- 回滚本身是否安全？ —— 如果这次发布涉及数据迁移、schema 变更、不可逆的格式转换，回滚可能比不回滚更危险。这种情况我反而不敢轻易回滚，而是先止血（限流 / 降级 / 切流）再定位。
但说实话，这套框架是我自己脑子里的，不是团队共识。我们团队没有明确的「回滚 vs 定位」决策树，全靠值班同学当天的状态和直觉。状态好就快，状态差就慢，这本身就是风险。
【想听大家聊的，四个问题】
- 你团队有没有「线上事故第一动作」的明确 SOP？还是全靠值班同学临场判断？如果有，能贴一下决策树吗？
- 有没有遇到过「回滚反而让事情更糟」的情况（比如数据迁移到一半、不可逆操作）？当时怎么处理的，事后怎么补的？
- 你觉得「15 秒内做决定」和「5 分钟看日志」之间，有没有一个可量化的边界？比如 QPS 超过多少就必须回滚、低于多少可以定位？还是说这根本没法量化，只能靠经验？
- 最后一个扎心的问题：如果回滚后你花了 2 小时定位根因，发现根因是「发布流程本身有 bug」（比如 CI 脚本把超时配置写错了），你下次还敢直接回滚吗？还是说你会先查清楚再动？
我个人觉得这个问题没有标准答案，但我觉得团队应该有共识，哪怕只是「先止血、后定位、再复盘」这九个字。没有共识的时候，每个值班同学都在用自己的直觉替整个团队做决策，这才是最大的风险。
0赞
0收藏
0楼层