Spotify 在 AI 高速迭代下的质量治理:四个真实故障与数据复盘

质量与可靠性一直是 Spotify 引以为傲的标签。我们运营着由相互连通的微服务与数据管道组成的庞大生态系统，最终汇聚成一款覆盖超过 2,000 款受支持设备、月活跃用户达 7.77 亿的超级应用。任意时刻，我们的平台服务约 1 亿并发客户端，每秒处理 1,100 万至 1,200 万次后端请求，并运行近 3,000 个生产服务。在如此规模下，质量从来都不是一个已解决的问题。在 AI 进入我们的工作流之前，系统中任何一处弱点都可能迅速波及听众与创作者。然而近来，有四个特定领域同时对我们提出了考验——而或许会让一些人意外的是，AI 灌水内容（AI slop）并不在其中。真正迫使我们做出调整的是 Spotify 内部乃至全球范围的变化速度。

我们的发现与已做出的改变

内容处理

Spotify 每天处理超过 50 万首新歌曲、视频、播客和有声书，且增长迅速。对这些内容的创作者而言，让它们快速、可靠地上线至关重要。

在内容上传洪流到来之前，我们就已存在两个影响该流程及其依赖者的固有弱点。其一，处理失败可能被掩盖。例如，一个我们无法处理的媒体文件有时会静默失败，而对发布的影响数小时都无人察觉，因为失败不会触发任何告警。其二，面对不断增长的视频目录处理需求峰值，管道缺乏足够容量；当转码能力耗尽时，有效的视频剧集可能会在队列中无人告警地等待。

我们的报告描述了 6 月 24 日发生的事件：与上述因素相关的小改动叠加在一起——一个计划中的批处理任务与新剧集争抢资源，近期的一项质量改进提高了每集所需的计算量，而一个调度 bug 使吞吐量下降了约 10%。通常需要几分钟发布的剧集被延迟了数小时。根本原因都是常见的那几类，也是我们的疏忽：失败告警上的细微遗漏、容量规划上的挑战，以及工作负载控制上的小缺口。

此后，我们增加了端到端监控，以便在创作者之前知晓失败，修复了调度器，将批处理任务降为低优先级运行，并增加了容量。我们还重新设计了服务分级与工作负载优先级，在容量受限时让关键服务和新上传优先。来自恶意行为者的剧集被抑制并大幅降低优先级，从而显著减少整体负载，不与高优先级剧集争抢资源。AI 帮助我们更快地交付了这些改进，但与我们开始使用智能体之前一样，这些问题需要工程师独有的判断力、端到端的思维和技能。

集群更新

另一个独立的挑战是管理不断增长的自动化变更规模。多年来，我们自研的 Fleet Management 框架每天都在整个集群上执行大规模变更，绝大多数在通过安全检查后自动合入。一年多来，我们将其扩展到支持更复杂的智能体驱动变更，包括最近一次在三天内完成的跨后端服务 Java 迁移。节奏进一步加快，将工程师从更多琐碎任务中解放出来。

但这种更高的自动化也带来了新的失败模式。今年，一次自动依赖升级通过了我们的检查，仍在生产环境失败，影响了终端用户。我们的应对是强化防护措施、扩展回滚能力，并将自动化变更安排在所有方团队的工作时间内执行。

算力短缺

在整个行业，AI 的使用在 CPU 和 GPU 两端引发了需求的暴涨，而供给并未相应增加，余量容量随之减少。Spotify 长期运作在一个需要时通常能获取到算力的环境中。随着行业需求增长，这种容量变得不那么可预测。当某个区域故障时，我们会将流量切换到另一个区域以承载负载。虽说区域故障转移在某种意义上是一件大事，但我们正是为此而设计，以最小化客户影响。

今年早些时候，当 Spotify 执行区域故障转移时，这种容量短缺放大了此前微不足道、无人察觉的问题。在容量受限的新环境下，我们的终端用户察觉到了。这是 AI 对服务质量的一种影响，但属于间接影响，并非那些常被引用的那种。

因此，我们不得不重新审视网络边缘与分级策略。如今，在进行故障转移时，我们必须接受一个现实：低层级服务可能没有可用容量。我们也在强化生产服务的弹性。在 5 月的一次事故后，我们将预留的边缘容量翻倍。今天，我们可以手动切换一部分内部服务网格流量；将该控制扩展到边缘流量并测试区域溢出仍在推进中。目标是在确保接收区域能够吸收额外负载并保持稳定的同时，循序渐进地转移流量。

移动端体验

十多年来，我们移动端应用的质量一直呈现潮起潮落。我们热衷于快速交付惊艳的新功能，而这可能与体验质量形成权衡。当这些新的负面质量信号累积，我们便将资源与激励转向质量。我们拓宽护栏指标，推动恢复，并以更宽的护栏回到良好状态。久而久之，现有指标与护栏未能覆盖的新问题浮现，循环再次开始。

AI 提高了变化速度，意味着这个循环以更高频率运转，缺口更快暴露。问题不在于 AI 辅助代码本身质量更低；而在于我们衡量与维持质量的系统需要跟上我们现在构建与交付的速度。

我们的发布流程在生产前本就设有审慎的检查点。近期工作凸显的是：单个发布看似健康，而较小的回归会随时间累积、影响特定机型，或落在我们监控的信号之外。如今我们已拓宽这些质量信号，并将长期趋势纳入决策，以便更早识别劣化。

AI 的角色

在如此规模下转向 AI 辅助开发，在公司内外都引出了一个合理的问题：这对质量意味着什么？Google Cloud 2025 年的 DORA 研究发现，AI 采用与更高的交付吞吐量和产品性能相关，但软件交付稳定性更低。但每家公司都不同，因此我们决定用自身数据来回答质量问题。

数据告诉我们什么

首先也是最重要的，我们审视生产事故，因为它们是质量的最终度量。每个月我们都会对所有重大事故做复盘。在 AI 提速期间，我们开始额外追问两个问题：AI 编写的代码是否直接导致了事故？变化的增量是否给审查、测试、发布或可观测性带来了额外压力？

在迄今复盘的所有事故中，我们并未将 AI 编写的代码识别为实质性的直接贡献者。但我们确实观察到了第二类风险：变化增量增长快于我们部分验证控制所能适应的速度。作为回应，我们正在强化整个交付系统，包括审查、测试、发布、可观测性与回滚。

接下来，我们在更上游的管道中寻找质量换速度的证据。我们将每一个合入的 PR 按所含工作分类：功能、代码质量与优化、维护，以及文档。8 月合入的总变更量同比增长超过一倍，从约 8,100 增至 17,000。代码质量与优化工作占该组合的比例从 27% 升至 31%，这意味着工程师今年 8 月在代码质量上投入的绝对工作量达到去年的两倍以上。功能工作也有所增长。维护与配置占比从 31% 降至 25%。代码质量与优化在绝对和相对时间投入上的双增长，是我们相信并未出现简单的「质量换速度」权衡的原因之一。

我们还重建了返工率指标，以将真正的返工与新工作和历史重构区分开。代码流失（code churn）衡量被删除的代码相对于新增代码的比例。返工率则权衡被改动代码的「年龄」，是衡量近期工作是否经得起考验的更好代理。FAROS 2026 报告发现全行业代码流失急剧上升，但我们未见返工率相应上升。这是一个清晰信号：我们并未累积 AI 引发的质量债务。

有两个警示信号我们正在关注：代码复杂度与 PR 规模都在缓慢上升。在 AI 之前，这些都是明确的质量隐患。如今，一个更大的 PR 可能只是意味着人与智能体共同推理并安全地交付了更大单元的工作，而为「单个人脑能装下多少」校准的复杂度阈值或许不再适用。我们对两种假设都缺乏定论，因此刻意不去重写阈值来自我安慰。我们将继续观察这些指标，看它们是否真的是先行指标。

我们的收获

今年早些时候，我们并未在所有期望之处都达到质量标准。因此我们展开调查，并持续补救与改进。原因从平凡到——事后看——在更快节奏下可预见者皆有。或许会让一些人意外的是，数据并未显示出明确的、AI 编写代码直接导致的失败特征。

AI 提高了产生变更的能力。下一个约束变成了我们的验证能力。让交付系统与这种加快的变化节奏保持一致，如今是一项持续的工作：自动化防护、回滚、可观测性、故障转移与质量度量。现在的工作是确保这些控制以与开发相同的节奏运转。