SRE 周刊第 528 期

Mon, 03 Aug 2026 01:56:15 +0000

译者按

这期周报其实就一个共识：可靠性拼的不是谁能把事故消灭到零，而是出事后有没有一套能快速拼出全貌、高效应对的机制和角色分工。
Spotify 和 Honeycomb 那套大厂玩法直接落到国内中小厂肯定水土不服，没专职 SRE 也没独立技术负责人的预算，先把值班和复盘两个基本盘做扎实比什么都强。
国内团队搞复盘最容易变成追责大会，“无指责文化”这张皮好披、骨子里难改，建议先从“流程缺陷清单”这种中性模板切入，让复盘只聊事实和可执行改进。
K3s 这类轻量环境里加读副本前先盯住主从延迟和连接池配置，备份恢复演练没做到位就别急着扩读，不然副本没帮上忙先把故障面搞大了。

SRE Weekly 运维周报精选

赞助商速递 | PlanetScale

大多数数据库事故的起点是一条高开销查询，而非数据库宕机本身。PlanetScale 为 SRE 团队提供高可用 Postgres 与 MySQL，支持自动化故障转移、查询洞察和数据库流量控制，在异常查询触发告警前即可拦截。

本期内容

1. Spotify 播客发布事故分析

Spotify 团队分享了近期播客发布故障中最严重一起的完整复盘报告。

作者： Jim Whitehead, Ulrik Mikaelsson, John Lagomarsino, Saunak Jai Chakraborty — Spotify

2. 用户视角下的 Spotify 可靠性危机

The Pulse 从用户角度审视 Spotify 的可靠性问题，并对其官方发布的故障时间线进行了事实核查。

作者： Gergely Orosz — The Pragmatic Engineer

3. 新角色解锁：事故技术负责人（Incident Tech Lead）

现代软件架构意味着没有谁能掌握全貌。在紧急情况下要快速拼出完整图景，你需要一个事故技术负责人。这篇文章对技术负责人与事故指挥官（Incident Commander）之间的协作关系描述得尤为精彩。

作者： Brent Chapman

4. 反直觉观点：事故越少，系统越不可靠

一个值得深思的观点：如果你一味追求减少事故数量，系统反而会变得更脆弱。正确的目标应该是"敢于面对更多事故，但每次都处理得当"。

SRE周刊第527期

Mon, 27 Jul 2026 01:15:44 +0000

译者按

一句话核心结论：AI 写代码真正的坑不在生成，而在凌晨 3 点 on-call 时你对着陌生代码无从下手——可维护性才是最后的账单。
对中小厂/K3s 环境，MongoDB 轮询替代 RabbitMQ 这套思路直接能用，消息量没过万 QPS 就别上重中间件；但 Honeycomb 那套 Kafka 迁移复盘属于大厂基建玩法，小团队照搬容易把自己绕晕。
私有云环境最水土不服的是「负二分钟」预警：很多人连基础告警都没配齐，先别追求预判故障，把现有告警的延迟和误报率降下来更实际。
落地提醒：如果团队开始用 AI 生成代码，把「可观测性埋点和 runbook」写进 AI 任务的验收标准，否则你只是把写代码的时间省下来，加倍花在排查问题上。

SRE Weekly 精选：本周值得读的运维文章

来源：sreweekly.com

赞助商消息 · PlanetScale

大多数数据库故障的起点，是一条昂贵的查询，而不是数据库宕机本身。PlanetScale 为 SRE 团队提供高可用 Postgres 与 MySQL，具备自动故障转移（automated failover）、查询洞察（query insights）以及数据库流量控制能力，能在失控查询触发告警前将其拦截。

→ 了解 PlanetScale

负二分钟（Minus Two Minutes）

一个值得深思的概念：负向检测时间——在故障影响真正发生之前，就已经预判到事故即将来临。但遗憾的是，多数监控与告警系统并未设计来追踪这种信号，部分事故处理流程甚至会忽略甚至「惩罚」这类提前预警行为。

— Tim Irving

AI 生成代码的 on-call 成本

核心问题：当 AI 写的代码在凌晨 3 点搞挂生产环境时，值班工程师能多快定位并修复它？

— Brent Chapman

Honeycomb 如何重构 Kafka 运维

文章深入拆解了 Honeycomb 如何构建并验证一套极其复杂的 Kafka 迁移方案。值得借鉴的是，他们充分复盘了去年的事故，并将其经验直接转化为迁移计划中的关键决策。

运维周刊 on ZbitOps｜智能运维