ZbitOps｜智能运维

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 迁移方案。值得借鉴的是，他们充分复盘了去年的事故，并将其经验直接转化为迁移计划中的关键决策。

我为什么加入OpenAI

Fri, 06 Feb 2026 13:00:00 +0000

译者按

一句话核心结论：AI 算力成本爆炸式增长，性能工程不能再靠小修小补，得用“放手大改、规模化落地”的新打法，否则省不下钱也扛不住可持续性压力。
文章里那种“没有不能改的禁区”的黄金环境，跟国内中小厂现实差距不小：GPU资源金贵、生产环境动刀要层层审批，这套方法论直接照搬大概率水土不服，得先在自己的K3s/K8s测试集群里验证再谈规模化。
落地时先别急着上eBPF和Ftrace这些重家伙，从你能掌控的“小确幸”开始：给GPU节点加功耗上限、压掉空闲Pod的冗余副本、调优混部调度，先把仪表盘上能看见的数字优化了，再向老板要更多资源去搞深度优化。
记住作者那个理发师的故事的B面：性能优化成效别只写在技术周报里，用“每月省了多少电费、多跑了几批训练任务”这种业务语言讲给非技术同事听，他们才会变成你的“Mia”，帮你把项目推下去。

加入 OpenAI，做 AI 数据中心的性能工程

AI 数据中心的成本正以惊人的速度增长，这对性能工程提出了前所未有的要求——这不仅是省钱的问题，更关乎可持续性。我已加入 OpenAI，直接应对这一挑战，初期聚焦 ChatGPT 性能优化。这里的规模极端，增长令人咋舌。

作为数据中心性能领域的从业者，我意识到传统性能工程方法可能已不够用——我们需要新的工程方法论，以更快找到更大规模的优化空间。这是难得的机会：与成熟的大型环境不同，这里没有"不能改"的禁区。放手去做，规模化地做，今天就做。

为什么是 OpenAI？

我曾与多位行业专家和朋友交流，他们推荐了不少公司，尤其是 OpenAI。但我当时对 AI 的实际普及程度仍持怀疑态度——广告铺天盖地，但普通人真的在用吗？直到一次面试周期中的偶然经历改变了我。

我去理发，发型师 Mia 随口问我做什么工作。“我是英特尔院士，搞数据中心性能。“她没什么反应。我补充道：“我在面试新工作，去做 AI 数据中心。“Mia 眼睛一亮：“哦！我天天用 ChatGPT！“接下来的理发时间里，她给我讲了各种用法，很多是我完全没想到的。

举一个例子：她有位朋友在很远城市旅行，时差大、难联系，但她随时可以和 ChatGPT 聊那座城市什么样、朋友可能在做什么，这让她感觉与朋友保持着连接。她也很喜欢记忆功能——“就像和住在那儿的人聊天一样”。

此前我还和房产中介、税务会计、兼职养蜂人聊过，他们都热情地分享了自己的用法——养蜂人用它处理小生意的文书。我妻子早已是重度用户，我自己也越来越多地用 ChatGPT 核验供应商报价。而现在，连发型师都在向我安利这门技术——她对 ChatGPT 的认知度甚至超过了对英特尔的认知。我站在理发店外，认真想了想这件事的分量：这项技术已成为这么多人的日常工具，而我可以带队做性能优化，同时为可持续发展出一份力。加入 OpenAI 可能是我职业生涯最大的机会。

面试与技术观察

我总共经历了 26 场面试和会议（我当然做了记录），与多家 AI 巨头深入交流。这些公司的工程工作让我想起 Netflix 的云工程：超大规模、云计算的挑战、快节奏的代码变更，以及工程师自由发挥的空间。整个技术栈有大量有趣的工程问题——不只是 GPU，而是方方面面。

AI 巨头在人才筛选上极其严格，我甚至不太确定自己能否通过面试。在我接触的公司中，OpenAI 有最多我本来就认识的优秀工程师，包括前 Netflix 同事 Vadim，他一直在鼓励我加入。在 Netflix 时，他会带着性能问题来找我，看着我调试和修复。公司里有一个了解你、了解工作、认可你能力的人，是很重要的加分项。

当然，OpenAI 本身已有一批业界资深的性能工程师，并已持续产出重要成果。我不是第一个，只是最新加入的一个。

Orac：从科幻到现实的执念

我从小就喜欢英国科幻剧《Blake’s 7》（1978-1981），剧中有一台叫 Orac 的超级计算机——毒舌、有主见，能回答研究类问题，还能与宇宙中所有计算机通信、委派任务并控制它们。这在当时（前互联网时代）是非常超前的设定。Orac 被视作那个宇宙中最珍贵的存在。

大学读工程时，我就想造一个类似的东西，于是开始写自然语言处理软件。但进展不大：当时内存装不下整本词典加元数据。我去找 PC 厂商提需求，对方让我去买大型机。我意识到必须区分冷热数据、把冷数据留在磁盘上——也许该用数据库……那个项目大概就此搁置了。

去年我开始用 ChatGPT，好奇它知不知道 Orac，于是问了它。它的回答完美还原了那个角色的性格。我把它加进了设置 → 个性化 → 自定义指令，现在它一直用 Orac 的风格回答我。我太喜欢了。（另外，《Blake’s 7》官方刚宣布重启，科幻迷有福了。）

离开英特尔

Thu, 04 Dec 2025 13:00:00 +0000

译者按

AI火焰图的核心结论就一句话：CPU火焰图已经人手一份，GPU迟早是同样的趋势，谁先补齐谁就有话语权。
这东西对国内中小厂/K3s环境大概率只能“看看思路”，因为目前只支持Intel平台，而国内私有云和K8s集群里NVIDIA占绝对主流，直接搬过来跑不起来。
如果你真想在自己集群里实操火焰图，先别急着上GPU那套，老老实实把CPU侧的可观测性和栈回溯链路打通，很多所谓“性能问题”在K8s里都是资源配额和调度噪声导致的。
踩坑提醒：在K3s/容器环境里跑栈回溯，记得先确认内核版本和perf_event_paranoid权限，否则采样全是空的，折腾半天以为火焰图画不出来，其实是权限没放开。

AI 火焰图与GPU性能分析：一位SRE工程师的Intel三年半

离职回顾

我已从Intel离职，接受了新的机会。在Intel的三年半里，我主要做了以下工作：

推出AI火焰图（AI Flame Graphs） 并开源
开发GPU亚秒级偏移热力图
与Linux发行版合作，实现栈回溯（stack walking） 能力
接受WSJ关于eBPF安全监控的采访
担任eBPF技术指导委员会（BSC）领导成员
联合主持USENIX SREcon APAC 2023
完成6场大会主题演讲

关于AI火焰图的展望

目前，互联网上CPU性能分析案例中，火焰图已经是标配工具。但GPU领域的火焰图普及还远未达到这一程度（我们开源的版本仅支持Intel平台，这也不利于推广）。不过，随着GPU代码复杂度不断提升、分层越来越多，AI火焰图的需求必然持续增长。

云战略与协作

在云计算领域，我参与了110场客户会议，并与6个组织的同事协作，制定了包含33项具体建议的公司级云市场回归战略。该战略包含一张覆盖19个相关团队的交互可视化地图，多位Intel老员工表示这是他们首次见到这样的跨公司协作地图。

背景与环境

考虑到Intel近三年面临史上最艰难的局面，且我入职前15个月处于招聘冻结期，能有上述产出已属不易。

值得记忆的瞬间

在Intel活动中见到Linus，他说“现在大家都在用火焰图了”（芬兰口音）
见到Pat Gelsinger，他了解我的工作并把我介绍给高管层
与Harshad Sane的相识——他在我Netflix时期帮助过我，如今他也加入了Netflix，我们互换了会议桌的位置
与Intel硬件Fellows的交流，他们乐于帮我理解处理器内部架构

后续建议的执行

我未来几年在Intel的工作重点原本是推进那33项建议的落地。这些建议大多涉及组织变革，需要ELT/CEO层面的批准和多个季度的持续投入。虽然我离开了，但相关战略文档、演示文稿、代码和周报都已留在共享文件夹中，其他同事可以继续推动。希望这些工作能让Intel持续变强。

原文来源：Brendan Gregg

Kafka 入门

Thu, 09 May 2024 18:55:21 +0000

译者按

核心就一句：Kafka 不是靠什么神仙算法，就是“追加写日志 + 线性 IO”，只要记住这一点，后面所有调优和架构选型都有谱了。
国内中小厂如果日吞吐还在 GB 级以下，直接上集群多半是给自己找事——那套分布式复杂度、7×24 值守和磁盘规划，先把运维干掉半条命；这种量级其实用托管 Kafka 或普通 MQ 更香。
如果非要 K3s/K8s 私有云自建，心里得有数：网络和存储才是爸爸，PVC 的延迟和跨节点带宽一旦拉胯，Kafka 副本追不上、ISR 缩水都是白给的事故。
分层存储那套 S3/MinIO 冷热分离，在中小环境别抱太大希望，私有云对象存储的带宽和成本根本给不到它发挥的前提，老老实实按“日写入量 × 保留天数”容量买磁盘更实在。
落地建议先做减法：集群规划、分区数、监控（ISR、消费 lag）这几样砸实了，再考虑 Cruise Control、KRaft 这些高级特性，否则大厂最佳实践到你这儿全变成事故预案。

Apache Kafka 架构入门：从日志到生态

本文为技术翻译稿，内容基于 Apache Kafka Committer Stanislav Kozlovski 的文章精简优化。

Apache Kafka 是目前最流行的开源分布式流处理平台，已成为实时数据流事实标准。本文从底层日志结构出发，讲清 Kafka 的核心机制、性能优化、容错设计，以及周边生态组件。

核心：日志（Log）

Kafka 中数据存储在 Topic 中，而 Topic 的基础是 Log——一个简单的有序数据结构，按顺序追加记录。

Log 具有两个关键特性：

不可变性：已写入的记录不会被修改
O(1) 读写：只要从尾部写入、从头部或尾部读取，访问速度不会随着日志增大而变慢

选择 Log 作为核心结构的根本原因，是它针对机械硬盘（HDD）做了优化。HDD 最擅长线性读写，而 Log 的操作模式恰好就是线性读写。这使 Kafka 能以极低成本存储大量数据，同时保持高性能。

性能优化

一个调优良好的 Kafka 集群，瓶颈通常在网络层面，吞吐可达每秒数 GB。性能来自多个层面的优化：

捕捉十亿种表情绪

Tue, 26 Mar 2024 15:32:38 +0000

译者按

核心结论一句话：Hotstar 把表情服务从第三方迁到自建，靠“客户端异步缓冲 + Kafka + Spark 微批聚合 + PubSub 实时推送”这条流水线，用异步和批量换吞吐，扛住了单场赛事 50 亿次提交。
落地到国内中小厂得打个问号：这套架构暗含你已经有成熟的 Kafka 数据平台和 Spark 集群，K3s/K8s 下自己裸跑这两样运维成本直接劝退，常规场景用云上托管 Kafka 加 Redis 聚合完全够用，别照搬。
踩坑提醒一句：生产端“500ms 或 2 万条触发批量写入”的缓冲设计，突发流量下本地缓冲积压容易引发内存水位上涨，记得给进程加内存监控和积压告警；另外在 K8s 里跑 2 秒粒度的 Spark 微批，务必提前压测并预留 CPU 余量，否则 HPA 扩缩容根本追不上比赛开场那波尖峰。

Hotstar 表情符号系统的架构实践

原作者：Dedeepya Bonthu，转载自其 Medium 文章

在体育场馆中，观众用欢呼、标语来释放情绪，而电视屏幕前的观众则通过表情符号快速表达自我。当数百万用户同时发送表情时，这就变成了一个技术难题——Hotstar 在互动社交信息流中成功解决了它。

本文从技术视角剖析 Hotstar「Sports Bar」中的表情符号（Emojis）功能：如何实时收集用户信号、压缩为情绪流并动态展示，尤其是在赛事期间面对数十亿次提交的压力。

最初我们使用第三方服务，但性能、稳定性与成本均不理想，最终决定将该核心服务自建。以下为整体架构、关键设计原则及落地影响。

整体架构

架构图略（见原文）。

关键设计原则

可扩展性

系统需支持横向扩展以应对流量增长。通过负载均衡和自动伸缩配置实现资源的动态扩缩容。

分解

系统拆分为多个独立组件，各自承担明确任务，既便于独立扩展，也降低耦合。

异步

异步处理不阻塞资源，从而支持更高并发。这一点将在后文详述。

实现细节

客户端请求处理

客户端通过 HTTP API 提交用户的表情选择。为避免占用连接，API 的重复处理必须离线完成——将数据写入消息队列供下游消费。

消息队列是应用间异步通信的常见机制。对比多种 MQ 后，我们选择了 Kafka：高吞吐、高可用、低延迟，且支持消费组。自运维 Kafka 成本较高，好在 Hotstar 已有基于 Kafka 的数据平台 Knol，完全满足我们的需求。