Fleet Management at Spotify (Part 1): Spotify's Shift to a Fleet-First Mindset

Spotify · 2023 · 3. Quy mô lớn · Độ khó: Dễ — bài gốc

Series ba phần: phần 1 (bài này, vì sao) · phần 2 Spotify 2023 (hạ tầng khai báo) · phần 3 Spotify 2023 (refactor toàn fleet). Số liệu theo Spotify (2023).

Bối cảnh

• Spotify chia phần mềm thành rất nhiều component nhỏ do từng squad tự thiết kế, build, vận hành (microservice cho mọi loại: service, pipeline dữ liệu, web...). Số component tăng nhanh hơn số kỹ sư.
• Bảo trì hàng nghìn component, kể cả thay đổi nhỏ, rất tốn công; migration lớn (Python 2 → 3, thêm region cloud) cần hàng trăm team trong nhiều tháng; bản vá khẩn thành chiến dịch phối hợp. Ví dụ trước Fleet Management: nâng runtime Java mất 8 tháng và khoảng 2.000 PR bán tự động.

Thay đổi chính

• Fleet-first: thay vì 10 lần nâng cấp lớn mỗi năm, làm 10.000 lần nhỏ trên toàn codebase bằng tự động hoá. Đi kèm thay đổi văn hoá: chủ sở hữu component sẽ nhận thay đổi do người khác (hoặc máy) tạo.
• Bốn câu hỏi phải trả lời (khoảng 60 triệu dòng code production trong hơn 1 tỉ dòng ở source control):
  1. Đổi code ở đâu? Code search, và mọi code/cấu hình cùng dữ liệu hạ tầng production được nạp vào BigQuery để truy vấn (dependency, deploy, container, lỗ hổng).
  2. Mọi thứ đã nằm trong version control chưa? Code thì rồi, nhưng nhiều resource cloud (bucket, service account, DB) chưa: dẫn tới hạ tầng khai báo (phần 2).
  3. Áp thay đổi thế nào? Tìm chỗ, refactor tự động, kiểm bằng CI, điều phối merge/deploy và theo dõi (phần 3). Theo bài, định luật Hyrum đúng ở quy mô này.
  4. Tin thay đổi không ai review thế nào? Thêm test (container-based integration test), canary tự động khi deploy, và rebuild + redeploy mọi component ít nhất mỗi tuần để luôn deploy được từ nhánh chính.

Kết quả (theo Spotify)

• Hơn 80% component production được quản lý bởi Fleet Management; hơn 100 migration tự động trong ba năm; hơn 300.000 thay đổi tự động đã merge, khoảng 7.500 mỗi tuần, 75% tự merge.
• Bản vá Log4j tới 80% backend production trong 9 giờ (phần chưa được quản lý mất thêm vài ngày).
• Phiên bản mới của service framework nội bộ tới 70% backend: từ khoảng 200 ngày còn dưới 7 ngày.
• Hơn 75% môi trường production được "repave" (build và deploy lại từ source) hằng tuần. Khảo sát: hơn 95% kỹ sư cho rằng chất lượng phần mềm tốt hơn.
• Còn lại: đuôi dài component không theo chuẩn công nghệ; muốn chuẩn hoá framework hơn nữa vì component càng giống nhau thì thay đổi hàng loạt càng dễ.

Vì sao

• Khi số component tăng nhanh hơn số người, chi phí bảo trì theo từng component vượt quá sức; phải chuyển đơn vị thay đổi từ repo sang cả fleet (Quản lý fleet và migrate code hàng loạt, Nền tảng nội bộ cho service (đường ray chung)).

Bài học cho SWE

• Muốn thay đổi tự động không cần người review thì phải có test, canary, và khả năng deploy từ main bất kỳ lúc nào.
• Dữ liệu về code và hạ tầng ở dạng truy vấn được (BigQuery) là điều kiện để biết đổi ở đâu.
• Đo thời gian để một thay đổi phủ X% fleet; đó là chỉ số của tốc độ nền tảng.

Liên quan

• Spotify 2023 · Spotify 2023 · Spotify 2026 · Allegro 2024
• Quản lý fleet và migrate code hàng loạt · Nền tảng nội bộ cho service (đường ray chung)