译者按
- 一句话核心结论：AI 写代码真正的坑不在生成，而在凌晨 3 点 on-call 时你对着陌生代码无从下手——可维护性才是最后的账单。
- 对中小厂/K3s 环境，MongoDB 轮询替代 RabbitMQ 这套思路直接能用，消息量没过万 QPS 就别上重中间件；但 Honeycomb 那套 Kafka 迁移复盘属于大厂基建玩法，小团队照搬容易把自己绕晕。
- 私有云环境最水土不服的是「负二分钟」预警：很多人连基础告警都没配齐，先别追求预判故障，把现有告警的延迟和误报率降下来更实际。
- 落地提醒：如果团队开始用 AI 生成代码，把「可观测性埋点和 runbook」写进 AI 任务的验收标准，否则你只是把写代码的时间省下来，加倍花在排查问题上。
SRE Weekly 精选：本周值得读的运维文章
赞助商消息 · 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 迁移方案。值得借鉴的是，他们充分复盘了去年的事故，并将其经验直接转化为迁移计划中的关键决策。
— Josh Parsons / Honeycomb
让 768 台服务器看起来像 1 台
一篇深度的 PostgreSQL 分片（sharding）入门指南。即便你自认为已吃透分片原理，这篇文章仍有一些值得细读的细节。
— Ben Dicken / PlanetScale
说明：本文由本期刊赞助商发布，但赞助关系不影响其入选本期精选。
说「是」的成本已经变了
初读此文时我本想吐槽，读完却改变了想法——里面确实有不少值得思考的东西。文章探讨的是：AI 编程代理（coding agents）如何重塑我们在承接项目时说 yes / no 的成本判断。
写得便宜 ≠ 维护得便宜
AI 代码的真正成本不在生成，而在长期运维与所有权（ownership）。
— Dalia Abuadas / GitHub
系统拒绝拉杆？！汉莎航空 1829 号班机事件始末
一次商用客机险情中，本为提升可靠性而设计的系统（α 地板保护，alpha floor protection）反而成为事故的直接原因——飞机发生非指令性俯冲。这是一个关于自动化系统双刃剑效应的绝佳案例。
核心问题：我们是否清楚系统何时正常工作、如何工作、如何最大化其价值，以及当它「失控反水」时如何绕过它？
— Mentour Pilot
消息 Broker 成为瓶颈：用 MongoDB 轮询替代 RabbitMQ 扩展推送与短信
常规经验告诉我们：「数据库不适合当队列用」，应该选择专业消息中间件。但这帮人反其道而行——拆掉 RabbitMQ，改用 MongoDB 轮询方案。文章的亮点在于，作者在结尾完整列出了为了让轮询方案跑通，他们不得不自建的所有组件。
— Pavel Zavialov / DevOps.com
Runbooks + RAG：给 AI SRE Agent 补齐缺失的上下文
文章详细介绍了他们的实现方案与测试方法，也坦诚列出了仍在迭代优化的薄弱环节。
— Akhilesh Rao Meesala / HackerNoon
译者注：本期内容覆盖了数据库可靠性、AI 代码运维成本、Kafka 迁移、分片架构、自动化系统失效等多个方向。其中最值得国内中小厂团队关注的是两篇：一篇关于 AI 生成代码的 on-call 调试成本——代码生成只是起点，可维护性才是真正的账单；另一篇用 MongoDB 轮询替代 RabbitMQ 的「反常识」实践——在消息量可控的场景下，简化架构、减少中间件依赖，往往比引入重型组件更划算。
原文来源：SRE Weekly