How we deploy to production over 100 times a day

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

Bối cảnh

• Theo Monzo, công ty lớn lên thường chậm lại: chi phí của lỗi tăng nên thêm quy trình phê duyệt, nhiều người đụng vào cùng hệ, nhiều người mới phải hiểu hệ. Hậu quả là engineer gom thay đổi thành bản phát hành lớn, vừa chậm vừa rủi ro hơn.
• Monzo là ngân hàng nhưng chọn hướng ngược lại: tối ưu đường đi tới production để thay đổi nhỏ, và chính thay đổi nhỏ làm giảm rủi ro.
• Số liệu (năm trước bài, 2021–2022): số engineer tăng 148 → 232 (+60%); số deploy mỗi engineer tăng, số sự cố giảm rõ, tỉ lệ rollback mỗi deploy gần như không đổi. Hơn 100 deploy/ngày, hơn 2.000 service.

Thay đổi chính

• Quy trình thay đổi ít điểm chạm người: tối thiểu một review từ engineer của team sở hữu là được merge và deploy.
• Bù lại bằng guardrail, monitoring và audit dựng sẵn:
  • pipeline chặn thao tác sai (ví dụ deploy lên production phiên bản chưa lên staging);
  • pipeline ghi lại sự kiện để tra lại khi có lỗi;
  • middleware request phát sẵn metric, dashboard Grafana và alert chung cho mọi service;
  • CLI cảnh báo migration database chưa chạy hoặc commit chưa deploy ở nhánh khác;
  • đang làm rollback tự động dựa trên chính các metric của alert chung.
• Minh bạch về khẩu vị rủi ro: công bố mức chịu sự cố của công ty và theo dõi theo mục tiêu; gắn tier cho từng service, bot GitHub bình luận cảnh báo khi PR sửa service nằm trên "hot path".
• Không đổ lỗi cho người ("be hard on problems, not on people"); tìm lỗ hổng ở guardrail.
• Công cụ: CLI có chủ kiến, một lệnh để deploy lên staging và production; engineer hiếm khi đụng thẳng Kubernetes. Công nghệ đồng nhất (Go, cùng thư viện, cùng database, cùng công cụ deploy) để guardrail và tài liệu dùng lại được.
• Giảm tranh chấp bằng kiến trúc: microservice nhỏ, deploy độc lập; xác suất hai người cùng sửa một service thấp nên ít chặn nhau.
• Tác dụng phụ ghi nhận: deploy dễ quá nên staging bị dùng để thử quá nhiều; đang cải thiện môi trường dev local.

Vì sao

• Mọi ma sát (cần hai người duyệt, bốn môi trường pre-prod, chờ người khác test xong) đều đẩy engineer gom thay đổi. Theo Monzo, bỏ ma sát chính là cách giảm rủi ro.
• Monzo cảnh báo không nên đặt mục tiêu cho số deploy hay số rollback, vì đây chỉ là chỉ số đại diện (định luật Goodhart).

Bài học cho SWE

• Kiểm soát thay đổi có thể dời từ người phê duyệt sang guardrail tự động gắn trong pipeline và công cụ (Deploy và release an toàn).
• Một lý do ít được nói của microservices: giảm tranh chấp deploy khi số engineer tăng (Monolith và microservices — đi và quay lại).
• Đồng nhất công nghệ là điều kiện để nền tảng dựng guardrail một lần dùng cho 2.000 service (Nền tảng nội bộ cho service (đường ray chung)).

Liên quan

• Monzo 2022 (rollout từng bước cho cùng nền tảng)
• Monzo 2022 · Monzo 2024
• Deploy và release an toàn · Monolith và microservices — đi và quay lại · Nền tảng nội bộ cho service (đường ray chung)