摘要
2026-03-12 14:32–15:47 UTC，Uber 全球调度系统因 Kafka 3.7.0 升级后核心 topic 副本不足，发生 75 分钟全面中断，420 万行程请求失败、110 万司机收不到派单。无永久数据丢失，事件在恢复后重放。
时间线
- 14:15 UTC :: 对 12 broker 集群滚动升级至 3.7.0
- 14:32 UTC :: 调度 API 延迟超 5s，错误率升至 12%
- 14:35 UTC :: 核心 topic 42 个分区 ISR 跌至 1
- 14:52 UTC :: 回滚 broker 至 3.6.2
- 15:47 UTC :: 积压事件重放完毕，全面恢复
根因
Kafka 3.7.0 在 ReplicaFetcherThread 引入回归（KAFKA-15821），follower 错误计算高吞吐分区的日志末端偏移，导致升级后 broker 误报不同步，核心 topic 的 ISR 从 3 跌至 1；而生产者配置 acks=all 且 min.insync.replicas=2，ISR 跌破 2 后写入全部失败，级联成全局中断。
放大因素
升级手册缺少「升级后校验副本不足」步骤，使 ISR 收缩延迟 17 分钟才被发现；严格写语义放大了影响面。
缓解措施
冻结所有 Kafka 3.7.x 升级直至 KAFKA-15821 修复并验证；升级手册加入每 broker 升级后自动 ISR 校验（异常即回滚）；新增 1 分钟触发的 ISR 不足 P1 告警；改为金丝雀升级（先 1 broker 观察 30 分钟）。
经验教训
中间件小版本升级也可能携带致命回归；acks=all + 高 min.insync.replicas 在 ISR 收缩时会把「部分不可用」放大为「全局不可用」，需在可用性与持久性间留降级空间。
检查清单
- 中间件升级前在预发验证副本/ISR 行为
- 升级手册内置 ISR 自动校验与自动回滚
- 对核心 topic 设 ISR 不足的分钟级告警
- 采用金丝雀升级，避免批量滚动