标签频道
回滚
该标签下的文章、提问与讨论帖。
先给结论：我倾向「能回滚就无条件先回滚，回滚耗时 ≤ 5 分钟是红线」，但这个"无条件"在三种场景下会翻车——schema 变更、数据已写、下游已消费。想听听大家在这三种场景下的真实选择。 【背景】 我负责 3 个核心服务的 oncall（
背景 我做了 10 年技术 PM，管过支付、订单、数据同步三条链路的发布评审。站内关于「线上炸了先回滚还是先定位」的讨论已经很充分（id=1493 的「看变更类型派」、id=1725 的「回滚最后一公里」我都认同），但落地时卡在最后一英里：
【背景】 干运维 3 年，跟着排障的线上故障大概 40 次，其中超过一半卡在同一个岔路口：「先回滚，还是先修？」 印象最深的两次，正好是两个极端： - 一次发布引入 bug，订单接口错误率从 0.2% 飙到 18%。我当场拍板回滚，4 分钟
背景 做了 8 年性能优化，复盘过十几个「优化上线 → 核心指标确实改善了 → 3~7 天后另一个指标悄悄恶化 → 紧急回滚」的循环。举两个真实案例： 1. 某支付网关把 DB 批量提交从 50 条调到 500 条，写吞吐上去了 40%，但
【背景】 做了 10 年技术 PM，带过 3 个后端团队，经历过大大小小的 P0 故障二十多次。每次故障复盘时，被问得最多的一句话不是"根因是什么"，而是—— "当时为什么没有第一时间回滚？" 但说句大实话：不是所有故障都适合回滚。我见过两
【背景】 做了 8 年运维，复盘事故时发现一个规律：事故损失的大小，往往不取决于 bug 本身，而取决于「回滚 vs 热修」这个第一决策花了多久。 去年一次真实经历：一个发版把订单服务的金额字段从分改成元，上线 10 分钟线上出现对账不平。
«作者视角：10 年经验安全工程师，专注安全加固与风险防范 栈：HashiCorp Vault 1.15、Spring Boot 3.2 / jjwt 0.12.6、Nginx 1.25、K8s 1.27、OpenSSL 3.1 结论先行：
【背景】 做了 10 年分布式系统，我见过太多团队在架构评审时把"可回滚性"当默认前提——好像 CI/CD 管道通了，回滚就是点一下按钮的事。但每次真出事，回滚的"最后一公里"才暴露出来：数据库 schema 变更没法回滚、消息队列里的消息
背景 做了 15 年技术 PM，管过电商、SaaS、数据平台三个业务线，"性能"这个维度在发布流程里的位置，是我跟工程团队吵得最久、也最没有标准答案的事。 去年我们经历了一次典型事故：一次"小改动"——把商品列表接口的缓存 TTL 从 60
【背景】 我做了 10 年运维，值班群里吵得最多、每次吵架最凶的，不是工具选型，而是出故障那一刻的决策：先回滚止血，还是先抓现场查根因？上周我们组又为这事差点吵翻——发版后 P99 抖了 8 分钟，有人喊「马上回滚」，有人说「等我把日志和
背景 说个我 3 年里被这个问题反复折磨的真实场景。 去年某次发布，一个配置变更（改了一个超时阈值）上线 8 分钟后，值班群炸了：3 个下游服务同时报超时。我当时的第一反应是 "git revert" + 重新发布，从发现到回滚完成花了 4
背景 做了 10 年运维，从 3 人小团队到 200 人 SRE 组织都待过，主持过上百次发布。有一个话题每次发布评审都要吵，而且每次吵完都"各打五十大板"——灰度到底灰多少、观察多久、什么信号触发自动回滚？ 我见过三种典型做法： - 激进
背景 做了 5 年运维，值班这几年我反复遇到同一个分歧，而且几乎每次 P1 群里都会吵起来：故障刚发现的前 15 分钟，oncall 的默认动作到底是「先回滚/切流止血」还是「先花几分钟把根因定位清楚再动手」？ 我手上有两组真实数据可以给大
背景 热榜上"连接池怎么调""超时重试怎么配""GC 怎么选"聊得很透，但我做了 3 年性能优化，发现一个更前置、却几乎没有团队形成共识的问题：线上 P99 劣化被报警抓到的那一刻，你做的第一个动作是什么？ 我至少见过三种截然不同的"第一反
背景：做了 8 年网络工程，这些年线上故障见得多了，我发现一个反复出现的撕裂——故障发生后的头 30 秒，团队到底是"先回滚"还是"先定位"，分歧极大，而且几乎没有标准答案。热榜上大家都在聊怎么预防（连接池、超时重试、Kafka 幂等、mT
背景 先讲一个我亲历、且至今还会被翻出来的场景。 凌晨 2:47，一条 P0 告警把 on-call 的值班同学（一位入职 9 个月的后端）从床上叫醒：支付接口 5xx 率从 0.3% 飙到 12%，持续了 4 分钟。按团队 SOP，回滚需
文
标题
摘要