译者按

• 这期周报其实就一个共识：可靠性拼的不是谁能把事故消灭到零，而是出事后有没有一套能快速拼出全貌、高效应对的机制和角色分工。

• 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. 反直觉观点：事故越少，系统越不可靠

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

作者： Tim Irving

5. 每天 30 到 70 个 PR：我们如何做到不搞垮系统

Honeycomb 团队分享了高频率部署实践中的残酷真相，尤其是对事故率和应急响应的真实影响，坦诚得令人耳目一新。

作者： Liz Fong-Jones — Honeycomb

6. 事故刚发生完，接下来该做什么？

当系统发生故障后，团队内部究竟会发生什么？团队通常如何复盘？如何在保持"无指责文化"（Blameless Culture）的前提下落实问责制？这篇文章给出了实践中的答案。

作者： Karan Nagarajowda — Uptime Labs

7. SRE 视角下的 Datadog《2026 AI 工程现状报告》

Agent 无序扩张（Agent Sprawl）已成为生产可靠性危机，而 SRE 领域目前还缺乏相应的治理框架。

作者： Ajay Devineni — DZone

8. 加只读副本之前，先读这篇文章

核心观点：只读副本（Read Replica）能扩展读负载，但会引入额外的复杂性。作者详细梳理了实践过程中踩过的坑及对应的解决方案。

作者： Johanna Larsson — incident.io

原文来源：SRE Weekly