Spotify 8 月合併變更量同比翻倍至 17,000 個，並因 AI 輔助開發調整品質管控

據 InfoQ 中文站報導，Spotify 擴大 AI 輔助開發應用後，8 月合併變更量同比增長一倍以上，從約 8,100 個增至 17,000 個。Spotify 運營近 3,000 個生產服務，支撐 7.77 億月活用戶，每秒處理 1,100 萬至 1,200 萬次後端請求。復盤中發現內容處理、集群變更、計算容量與移動端品質等問題，公司隨之優化監控、測試、發布防護、回滚、容量規劃與品質度量。 其中一起事故發生在內容處理流水線（每天處理超過 50 萬首新增歌曲、影片、播客與有聲書）。6 月 24 日，一項計畫內的定時批次任務與新節目內容搶占資源，一項品質優化提高了資源需求，加上調度錯誤使吞吐量下降約 10%，原本幾分鐘可上線的節目延遲數小時。後續措施包括新增端到端監控、修復調度器、調低批次任務優先級、重構優先級策略並擴容。 在集群自動化方面，Spotify 的集群管理系統已合併超過 250 萬個自動維護拉取請求，多數在安全檢查後自動合併。公司引入 Honk，這是在 Kubernetes Pod 中以 Agent SDK 運行 Claude 的後台編碼智能體；Fleetshift 負責目標選擇、調度與進度追蹤，Honk 完成程式修改並可在 CI 中執行建置。Spotify 稱，近期一次後端服務的 Java 遷移耗時三天。不過，一次自動化依賴升級雖通過既有校驗，仍在生產環境出現故障，公司因此強化防護、擴大回滚能力，並將自動化變更安排在負責團隊的工作時段執行。 品質與優化工作占合併變更的比例由 27% 升至 31%，維護與配置工作則由 31% 降至 25%。Spotify 表示返工量並未隨之增加，但拉取請求規模與程式複雜度持續上升；事件審查認為 AI 編寫的程式碼未造成實質直接影響，但變更數量已超過部分驗證機制的負荷。外部工程師也指出，寫程式變容易後，確保上線前品質成為難點。此發現與 Google 2025 年 DORA 研究相呼應：AI 提升交付吞吐量，卻與交付穩定性呈負相關，自動化測試、版本控制與快速回饋被視為關鍵實踐。