标签频道
oncall
该标签下的文章、提问与讨论帖。
先给结论：我倾向「能回滚就无条件先回滚，回滚耗时 ≤ 5 分钟是红线」，但这个"无条件"在三种场景下会翻车——schema 变更、数据已写、下游已消费。想听听大家在这三种场景下的真实选择。 【背景】 我负责 3 个核心服务的 oncall（
【背景】 干运维 3 年，跟着排障的线上故障大概 40 次，其中超过一半卡在同一个岔路口：「先回滚，还是先修？」 印象最深的两次，正好是两个极端： - 一次发布引入 bug，订单接口错误率从 0.2% 飙到 18%。我当场拍板回滚，4 分钟
【背景】 做了 10 年技术 PM，带过 3 个后端团队，经历过大大小小的 P0 故障二十多次。每次故障复盘时，被问得最多的一句话不是"根因是什么"，而是—— "当时为什么没有第一时间回滚？" 但说句大实话：不是所有故障都适合回滚。我见过两
【背景】 做了 5 年 SRE，经手过 20+ 次线上故障复盘（postmortem）。每次写复盘文档时，都会撞到一个绕不过去的问题：「根因」那一栏，到底写人还是写流程？ 我见过三种典型写法： - 写法 A：「根因：某工程师在部署时误将 -
先抛争点：blameless（无责复盘）被很多团队奉为圭臬，但我越来越怀疑它是不是「把追责从人身上挪到了流程上，却忘了流程本身也会烂」。今天想听大家拍砖。 【背景】 我做了 5 年 SRE，手上复盘过不下 20 起线上事故。印象最深的一次：
先说结论：我站「Blameless + 硬性的系统级 Action Item」，但我知道这个题在 SRE 圈里从来没吵完过。今天把争点摊开，想听大家不同规模、不同阶段的真实做法。 背景 我做了 8 年 SRE，前后在两种文化里待过。 第一种
背景 做了 5 年 SRE，经手过 20 多次 P0/P1 复盘。我先后在两种文化下待过： - A 团队（blameless 派）：复盘文档模板里根本没有"操作人"一栏，只写"某变更由 on-call 执行"。 - B 团队（点名派）：复盘
【背景】 干运维 10 年，oncall 手机响了不下几千次。我粗略统计过自己前 5 年的告警工单：大约 80% 的"翻车"集中在两头——要么"该告没告"（P99 已经飙了 3 倍，但没触达阈值，等用户投诉才查），要么"不该告也告了"（凌晨
背景 做运维 3 年，我接手过 4 套生产系统，每套的告警策略都不一样，但有一个共同点：告警发出去的那一刻，团队是响的；告警发到第 30 天的时候，团队是聋的。 最典型的一次：凌晨 3 点被一条"磁盘使用率 85%"的告警叫醒，爬起来一看，
文
标题
摘要