标签频道
故障复盘
该标签下的文章、提问与讨论帖。
«作者：温若衡-259｜分布式系统 / 安全加固｜8 年 栈：Spring Boot 3.2.4（内嵌 Tomcat 10.1.19）、MyBatis-Plus 3.5.5、MySQL 8.0.36（InnoDB）、Nginx 1.25.4
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
先给结论：我倾向「能回滚就无条件先回滚，回滚耗时 ≤ 5 分钟是红线」，但这个"无条件"在三种场景下会翻车——schema 变更、数据已写、下游已消费。想听听大家在这三种场景下的真实选择。 【背景】 我负责 3 个核心服务的 oncall（
【背景】 SRE 干了 3 年，复盘会里见过最刺眼的一类事故不是"没发现"，而是"发现得太快、动手得也太快"：凌晨 2 点告警风暴，值班同学 30 秒内重启了 4 个副本，MTTR 很漂亮，第二天复盘才发现——重启把现场（堆内存、连接状态、
【背景】 做了 3 年 SRE，复盘过不下 20 次线上故障，我有个越来越强的体感：复盘报告写得再漂亮，如果没变成代码 / 配置 / 告警，下次同类故障大概率还会来。 举两个我亲历的例子： - 一次 Redis 大 key 把带宽打满，复盘
«结论先行：上游超时是上游的本地行为，服务端根本不知道。"Future.get(300ms)" 超时只是上游不再等待，下游任务还在线程池里继续跑、继续占连接、继续烧 CPU。这就是"超时=释放资源"这个常见误解的真实代价。本文用一次真实 P
【背景】 先给结论：liveness 探针是 K8s 里最容易被低估的故障源，它不是部署模板里的勾选项，而是一条隐式的「自动重启回路」。 去年大促前一周，我们一个 8G 堆的 Java 服务（JDK 17，K8s 1.28，containe
【背景】 做了 5 年 SRE，经手过 20+ 次线上故障复盘（postmortem）。每次写复盘文档时，都会撞到一个绕不过去的问题：「根因」那一栏，到底写人还是写流程？ 我见过三种典型写法： - 写法 A：「根因：某工程师在部署时误将 -
先抛争点：blameless（无责复盘）被很多团队奉为圭臬，但我越来越怀疑它是不是「把追责从人身上挪到了流程上，却忘了流程本身也会烂」。今天想听大家拍砖。 【背景】 我做了 5 年 SRE，手上复盘过不下 20 起线上事故。印象最深的一次：
背景 我们一台 RHEL 9 节点的支付网关日志（RHEL 9.2，logrotate 3.21.0，应用 Java 直写文件，非 systemd-journald），logrotate 配置是这样的： /var/log/paygw/pay
【背景】 做了 15 年 SRE，我见过太多这样的场景：线上 P99 从 80ms 抖到 400ms，告警一响，值班同学的肌肉记忆就是——「加个缓存吧」。Redis 一上，TTL 给 10 秒，P99 曲线确实好看了一周。 直到某个大促前夜
【背景】 我做了 3 年 SRE，手上管着 40 来个服务的告警。去年 Q4 我们团队把「每周 3am 被叫醒次数」立成了硬指标：从平均 6 次压到 0，庆功会上老板说这就是「稳定性的胜利」。 但今年 Q1 复盘一起 P2 事故时我发现一个
背景 我做了 3 年测试开发，维护一条 B 端 SaaS 的接口自动化：pytest + httpx，约 1800 条用例，跑在 4 人共享的 staging（MySQL 8 + Redis 7）。近 12 个月这条链路出了 3 起 P2/
【背景：一次让我当场下不来台的复盘会】 先说个真事。去年双 11 前一周，我们一个结算服务挂了 11 分钟。事后拉复盘会，气氛一开始很"政治正确"：大家齐刷刷说"是流程问题、是架构问题、是监控没覆盖"，没人提谁。可改进项写完，一周后我去查—
«结论先行：Go 服务里有一类事故长得很像「资源泄漏」，其实一个 goroutine 都没漏——它们都好好地阻塞在某个「永远不会醒」的等待里，因为发起等待的那个 context 在上游被吞掉了。"pprof" 看 goroutine 数量只
背景 做了 3 年 SRE，经历过十几次 P1 级故障复盘，也见过另外两家团队的做法，慢慢发现"blameless postmortem"这个词，每家落地姿势差异极大。有人把它当成"甩锅防火墙"，有人把它当成"真·无责复盘"，还有人把它当
文
标题
摘要