How Reliability and Product Teams Collaborate at Booking.com

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

Bối cảnh

• 2019: hơn 1,5 triệu đêm phòng/ngày, 50.000+ server vật lý ở 4 data center và 6 PoP. Quy mô đủ để có team reliability riêng cho từng nền tảng lớn.
• Vấn đề sở hữu: một team reliability lo một hệ mà nhiều (có khi hàng chục) team sản phẩm cùng đẩy code. Mỗi team sản phẩm hiểu "reliability" khác nhau; phần lớn kỳ vọng team reliability làm hết (toil, monitoring, sự cố), điều không thực tế.

Thay đổi chính

• Reliability Collaboration Model (RCM): liệt kê đầy đủ mọi việc giữ một hệ ổn định, chia bốn nhóm (vận hành cơ bản, disaster recovery, observability, vận hành nâng cao: capacity planning, quản lý dependency, nâng cấp server…), và ba mức hỗ trợ chia việc khác nhau:
  • Mức 3, Product Autonomy (mặc định): team sản phẩm lo mọi thứ, giữ pager; team reliability hỗ trợ khi có thể. Hợp với hệ ít quan trọng (hỏng một, hai ngày cũng được). Team reliability làm tài liệu, công cụ tự động, đào tạo cho từng mục để team sản phẩm tự làm được.
  • Mức 2, Partial: team reliability nhận khoảng một nửa việc; team sản phẩm vẫn lo alert và pager.
  • Mức 1, Full: team reliability nhận hết, trừ pager vẫn chia chung: theo Booking, bắt buộc phải có developer sản phẩm trong lịch trực để họ thấy trọn vòng từ deploy code xấu tới bị gọi dậy.
  • Mức 1, 2 không "tốt hơn": kèm chuẩn bắt buộc và họp định kỳ, làm chậm tốc độ phát triển.
• Độ quan trọng do lãnh đạo sản phẩm quyết, không phải team reliability: "bạn có N engineer reliability, tự chọn đặt hệ nào ở mức nào". Hệ mới luôn bắt đầu ở mức 3 (giống mô hình engagement SRE của Google).
• Nâng mức phải chứng minh độ quan trọng hoặc lưu lượng; nếu team reliability không đủ người thì phía sản phẩm gửi người sang hoặc hạ mức hệ khác. Hạ mức khi hệ liên tục vi phạm SLO, alert giả do thay đổi của team sản phẩm, vi phạm chuẩn bảo mật/kỹ thuật, hoặc để đổi chỗ. Hạ mức nghĩa là team sản phẩm nhận lại pager.
• Ownership Map: bảng hệ thống của một team reliability theo trục mức hỗ trợ × độ quan trọng; lý tưởng là nằm trên đường chéo. Đặt bản hiện tại cạnh bản mục tiêu để thấy hệ nào được hỗ trợ thừa (ví dụ logging ít quan trọng mà ở mức 1) và hệ nào chưa đạt chuẩn của mức mình (đánh dấu sao).
• Kèm theo: team reliability 5–8 người có cả product manager, 50% thời gian cho project (tooling, automation), báo cáo SLO và postmortem định kỳ, checklist cho việc hạ mức.

Vì sao

• Theo Booking: không nói rõ ai làm gì thì giữa team reliability và team sản phẩm dễ nảy sinh nghi ngờ; liệt kê đầy đủ việc tạo ra thứ để bàn.
• Mức hỗ trợ phải tỉ lệ với độ quan trọng kinh doanh, và người hiểu kinh doanh nhất là lãnh đạo sản phẩm.

Bài học cho SWE

• Liệt kê tường minh việc vận hành và chia theo mức giúp tránh "SRE làm hết" (Xử lý sự cố và on-call).
• Developer nên ở trong lịch trực ngay cả khi có team reliability.
• Mặc định tự chủ + công cụ, tài liệu, đào tạo từ nhóm nền tảng (Nền tảng nội bộ cho service (đường ray chung)).

Liên quan

• Mô hình tổ chức SRE
• Booking.com 2017 (hai năm trước: quy trình sự cố) · Booking.com 2014
• Netflix 2020 · Mercari 2022 · Monzo 2022
• Xử lý sự cố và on-call · Nền tảng nội bộ cho service (đường ray chung)