标签频道
高可用
该标签下的文章、提问与讨论帖。
一、现象或背景：一条毒消息引发 4 个 Queue 0 QPS 的灾难 在 RocketMQ 5.1.4 的压测中，我们遭遇了典型的「毒消息阻塞」场景： - 压测参数：4 个 Queue，消费端 8 线程，QPS 5200 - 异常表现：3
资金三方对账：差错池五分类、自动补单 fencing 与「差异清零 3 天」收敛判定的落地方案 «结论先行：金额 diff = 0 是最弱的一致性承诺，真正的对账必须同时校验金额、状态、方向、时间窗四维度，且每一类差异都要有独立的处置 SL
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
【背景】 我在一家中型公司做网络与稳定性，管着一套 60+ 微服务（Java/Go 混合，K8s 1.28，自研 Ingress）。去年经历过一次「健康检查雪崩」： MySQL 主从切换耗时 8 秒，期间所有服务的 /ready 探针（查
【背景】 SRE 干了 3 年，复盘会里见过最刺眼的一类事故不是"没发现"，而是"发现得太快、动手得也太快"：凌晨 2 点告警风暴，值班同学 30 秒内重启了 4 个副本，MTTR 很漂亮，第二天复盘才发现——重启把现场（堆内存、连接状态、
【背景】 做 K8s 容器化运维 5 年，探针配置是每个集群都绕不开、但几乎没人认真讨论过的配置项。我复盘过两次线上事故，恰好踩在两个极端： 事故一（重启风暴）：一个 Java 订单服务，livenessProbe 配的是 "httpGet
先抛一个我自己纠结过很久的判断：Rebalance 风暴的根因，到底是「协议太激进」还是「配置太保守」？这两个答案会导出完全相反的治理动作，我见过两种团队各打各的，谁也没说服谁。想在这里把牌摊开，听听大家的真实选择。 【背景】 我维护过一个
背景 - Kafka 3.4（KRaft，3 broker），topic "order-status-change" 32 分区，消费组 8 实例（每实例 4 分区），峰值 QPS 3w - 一条消息（订单状态变更）需要扇出写 3 个下游：
【背景】 做安全加固这几年，见过最典型的线上事故不是「漏洞被打了」，而是「安全组件挂了，默认动作选错了」： - 一个电商网关，鉴权 token 校验服务（独立微服务）挂了 40 分钟。因为网关里写的是 "try { validate(tok
【背景】 干运维 3 年，跟着排障的线上故障大概 40 次，其中超过一半卡在同一个岔路口：「先回滚，还是先修？」 印象最深的两次，正好是两个极端： - 一次发布引入 bug，订单接口错误率从 0.2% 飙到 18%。我当场拍板回滚，4 分钟
【背景】 做了 10 年技术 PM，带过 3 个后端团队，经历过大大小小的 P0 故障二十多次。每次故障复盘时，被问得最多的一句话不是"根因是什么"，而是—— "当时为什么没有第一时间回滚？" 但说句大实话：不是所有故障都适合回滚。我见过两
资金三方对账：差错池五分类、自动补单 fencing 与「差异清零 3 天」收敛判定的落地方案 «结论先行：「金额对得上」不等于「对账通过」。真正的对账闭环 = 差错分类 + 差错池 + 自动补单 + 人工兜底 + 收敛判定，五环缺一不可。
先给结论：健康检查探针不是"越探越稳"，探得太深反而可能成为故障放大器。我踩过一次真实的坑，今天想把这个争点摊开聊。 【背景】 我维护一批 K8s 1.27（12 节点、containerd 1.7）的核心服务。去年一次 Redis 抖动约
先抛争点：blameless（无责复盘）被很多团队奉为圭臬，但我越来越怀疑它是不是「把追责从人身上挪到了流程上，却忘了流程本身也会烂」。今天想听大家拍砖。 【背景】 我做了 5 年 SRE，手上复盘过不下 20 起线上事故。印象最深的一次：
【背景】 10 年 SRE，过去三年在两家不同公司都推过混沌工程（Chaos Engineering）。一次在金融客户环境做网络延迟注入（模拟跨机房 RTT 从 2ms 升到 50ms），一次在电商大促前做 pod 驱逐演练。两次都差点没批
【背景】 最近热榜上有两篇帖子我反复看了几遍：一篇讲超时重试配错把流量放大成雪崩，一篇讲 Kafka offset TTL 导致的静默丢消息。两件事表面上不相关，但我把它们放在一起看，发现背后是同一个问题——当你的某个依赖（下游服务、DB、
【背景】 我负责一个订单履约链路（Java 17 + Spring Boot 3 + Kafka 3.4 + MySQL 8.0），核心路径：支付回调 → 扣库存 → 调物流 API → 确认发货。用的是标准 Saga 编排：每步成功写本地
【背景】 做了 15 年运维，从 IDC 裸机到 K8s 集群，经历过上千次线上故障。有一个现象我观察了至少 5 年：同一个团队、同一个 P1，值班的 A 先翻 application.log 找异常堆栈，B 直接 kubectl top
【背景】 做了 8 年运维，复盘事故时发现一个规律：事故损失的大小，往往不取决于 bug 本身，而取决于「回滚 vs 热修」这个第一决策花了多久。 去年一次真实经历：一个发版把订单服务的金额字段从分改成元，上线 10 分钟线上出现对账不平。
【背景】 一个很日常、但每次聊起来都会吵起来的场景：服务 A 依赖下游风控 / 鉴权 / 计费，下游抖了或超时了，A 是「放行 + 事后补录」（fail-open），还是「拦截 + 事后人工放行」（fail-close）？ 我踩过的两个坑，
已经到底了
文
标题
摘要