Spotify 8月代码合并量翻倍至17000个，AI辅助开发提速

Spotify 把 AI 辅助开发的摊子铺得更大了。8 月份，其合并变更量同比涨了一倍多，从大约 8100 个攀到 17000 个。生产系统里的软件变更数量猛增，公司也在同步调整质量与可靠性控制体系。

眼下 Spotify 跑着近 3000 个生产服务，背后是 7.77 亿月活用户、约 1 亿并发客户端，每秒要扛住 1100 万至 1200 万次后端请求。复盘时，问题出在内容处理、集群变更、计算容量和移动端应用质量几块。针对这些，Spotify 对监控、测试、发布防护、回滚能力、容量规划和质量度量做了优化。

有一回事故跟内容处理流水线有关。这条流水线每天要处理超 50 万首新增歌曲、视频、播客及有声书。6 月 24 日，一个计划内的定时批处理任务和新节目内容抢起了资源，一项质量优化又把处理资源需求抬高了，再加上一个调度错误，吞吐量掉了约 10%。结果，本来几分钟就能上线的节目，拖了好几个小时。之后 Spotify 补上了端到端监控，修好调度器，调低批处理任务优先级，重构任务优先级策略，还做了扩容。

集群自动化那边是另一番麻烦。Spotify 的集群管理系统已经合并了超过 250 万个自动化维护拉取请求，其中大部分在安全检查后自动合并。后来公司引入了 Honk——一个在 Kubernetes Pod 里用 Agent SDK 跑 Claude 的后台编码智能体。Fleetshift 管目标选择、调度和进度跟踪，Honk 负责改代码，还能在 CI 里执行构建。Spotify 报告称，最近其后端服务的一次 Java 迁移只花了三天。

但 Spotify 也说了，有一次自动化依赖升级通过了现有校验，到了生产环境照样出事。公司正在加强防护手段、扩大回滚能力，并把自动化变更安排到负责团队的工作时段执行。

JumpCloud 软件工程师 Amit Jha 在 LinkedIn 发帖讨论 Spotify 的复盘时提到：

更多的变更意味着测试、评审和可观测性面临更大压力。

Alex Beck 在 LinkedIn 帖子中同样聚焦验证难题：

编写代码变得更容易了。现在的难点是确保代码上线前质量达标。

谷歌 2025 年 DORA 研究正好呼应了上述发现：报告显示，AI 的引入能提高软件交付的吞吐量和产品性能，可另一方面，交付稳定性会随之走低。报告认为，引入 AI 的过程中，要把软件交付管好，自动化测试、版本控制加上快速反馈闭环是几项关键做法。

分工上，Spotify 把标准化维护交给集群管理系统，Honk 处理复杂的代码变更，Fleetshift 负责编排，CI 承担验证。质量和优化工作占合并变更的比例从 27% 升至 31%，维护和配置工作则从 31% 降到 25%。Spotify 报告称返工量没有跟着涨，但拉取请求体量和代码复杂度在往上走。事件审查发现，AI 编写的代码没有造成实质性的直接影响，可变更数量已经超出了一些验证机制的处理能力。

查看英文原文：

https://www.infoq.com/news/2026/10/spotify-ai-quality-controls/