标签频道
事故复盘
该标签下的文章、提问与讨论帖。
«结论先行：复盘会最贵的浪费不是"追不追责任"，而是改进项写得太泛——"加强监控""提升质量意识"这类口号式条目，两个迭代后执行率归零，而团队还觉得"我们复盘过了"。 把改进项从口号改成一条可验收的待办，落地率从 38% 拉到 82%，我们
【背景】 做了 10 年运维，去年带一个 20 人团队给核心交易链路上了 SLO 错误预算（error budget）机制，跑了 5 个月，踩的坑比写代码还多。先给几个具体数字： - 服务 P99 < 300ms，月度 SLO 99.9%，
【背景】 做了 15 年技术 PM，去年我把过去 12 个月的线上事故复盘文档（P3 及以上，共 12 篇）拉出来做了一次「action 落地率」统计，结果有点扎心： - 12 篇复盘，共列出 47 条 action（含监控补点、配置调整、
【背景】 做了 8 年运维，复盘事故时发现一个规律：事故损失的大小，往往不取决于 bug 本身，而取决于「回滚 vs 热修」这个第一决策花了多久。 去年一次真实经历：一个发版把订单服务的金额字段从分改成元，上线 10 分钟线上出现对账不平。
«一句话结论："binlog_expire_logs_seconds" 不是「到点就删」的定时器，而是「可以删的上限」——真正决定删不删的，是所有存活从库的最小复制位点。一旦从库断开，它就从「位点集合」里消失，它需要的日志立刻暴露给时间策略
先说背景，我是干运维的，十几年里经历过从「出问题先找谁」到「出问题先找事」的转变，但每次换团队、换公司，这个老问题都会重新吵一遍，所以我今天想把它摊开聊聊，看看大家到底是怎么落地的。 【背景】 无责复盘（Blameless Postmort
背景 做了 8 年 SRE，复盘事故是绕不开的日常。我经历过两个极端： - 早期团队，复盘会开成"批斗会"，最后大家都学会了写模糊的根因（"网络抖动""第三方不稳定"），复盘文档没人再翻，同类问题半年后又炸一次； - 后来换的团队，全程 b
背景 我做了 10 年技术文档工程，其中相当一部分工作是帮团队沉淀故障复盘（postmortem）。这两年越来越强烈的一个感受是：社区把大量精力花在"怎么写得漂亮、怎么定责"上，却很少正面讨论"根因写到哪一层才算写完"。社区里关于 P99、
背景 先抛一个我自己被戳到的数字：我带过的团队里，P1 以上事故平均每月 1.2 起，每起复盘平均产出 6–8 条改进项；但半年后回看，真正"可验证地生效"的不到 40%。剩下的不是没人做，而是三类：a) 做了但没有对照数据证明有效；b)
先抛一个我亲历的场景，大家先看是不是眼熟。 去年 Q3 我们一个核心服务出了 P1：一个缓存击穿导致下游 DB 被打满，恢复花了 42 分钟。复盘做得很「标准」：时间线、根因、影响面、改进项，四样齐全。改进项一共 6 条，其中 3 条是「加
ADR 落地 8 个月，我们把线上事故根因里的"为什么这样设计"问句减了 63% 一、现象与背景：事故复盘会上，最贵的一句话是"我也不知道当初为什么这么写" 2024 年 Q3，我们团队（4 个后端、2 个前端、1 个 SRE、我）负责一个
背景： 我做了 15 年技术产品，经历过大大小小 40 多次线上事故复盘。每次复盘会，气氛几乎一样：前 10 分钟大家还在客观还原时间线，15 分钟之后就开始变成「当时为什么没有 double-check」「这个流程谁定的」「这个人能不能再
«结论先行：特性开关（feature flag）不是「代码开关」，它是一次隐性的执行计划变更。当你把 flag 从 0 切到 1 的那一刻，SQL 走的索引、JOIN 的表、缓存的 key 全变了——而这一层变化，绝大多数团队的变更流程完全
文
标题
摘要