Argo Rollouts at scale: Bringing Automated Rollbacks to 2,100+ services at Monzo

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

Bối cảnh

Monzo (ngân hàng số ở Anh) theo đuổi microservices: hơn 2.100 service, hơn 100 lượt deploy/ngày, hơn 27.000 lượt deploy trong năm 2021.
Deploy bằng một lệnh CLI. Đã có nhiều lớp bắt lỗi, nhưng vẫn dựa vào alert gửi tới kỹ sư để phản ứng với deploy xấu. Hạn chế:
- con người hay bỏ sót, "kỷ luật không thay được tự động hoá";
- phải trông deploy tốn thời gian và sức chú ý;
- deploy kiểu "tất cả hoặc không": pod khởi động được là bản xấu có thể lên toàn bộ trước khi có alert.
Mục tiêu dài hạn là GitOps (deploy theo merge vào main). Theo Monzo, rollback tự động là điều kiện tiên quyết, vì deploy sẽ bất đồng bộ hơn.

Yêu cầu: trong suốt với kỹ sư (giữ công cụ CLI và Slack hiện có); luật rollback dựa trên metric Prometheus đã quen; mở rộng được sang progressive rollout sau này.
Chọn Argo Rollouts (controller Kubernetes). Chiến lược ban đầu: canary cơ bản, lên hết pod nhanh rồi phân tích metric và rollback tự động nếu cần.
Luật toàn cục dùng chung ngưỡng với alert chung: tổng tỷ lệ lỗi RPC trên 20%; có panic/crash; lỗi DB tăng vọt. Gắn nhãn pod mới/cũ để phân biệt trong query.
Deploy chuyển sang bất đồng bộ (phân tích có thể mất hơn 5 phút), kết quả báo qua Slack.
Migration 2.000+ service:
- migrator service chạy theo lô mỗi ngày (staging trước, production chậm hơn), từ service ít quan trọng nhất (theo "tier");
- có hàng đợi để retry và để dùng lại cùng pipeline khi cần revert;
- dùng tính năng của Argo cho phép thêm Rollout trỏ vào Deployment có sẵn thay vì thay thế, nên migration không phá huỷ gì và revert được. Không downtime.

Migration và tích hợp với công cụ sẵn có chiếm hơn 90% công sức; proof of concept thì nhanh.
Tự động hoá migration ở mức cao và làm nhanh. Script không đủ cho hơn 1.000 lần lặp. Tránh giao cho từng chủ service tự migrate: các lần thử trước đều "bị treo vô thời hạn".
Tách thay đổi trải nghiệm khỏi việc đưa hệ thống mới vào: lẽ ra nên đưa Argo vào mà giữ nguyên hành vi deploy, rồi bật rollback ở một dự án sau.
Dùng hệ thống bên thứ ba chưa trưởng thành ("alpha") nghĩa là tự gánh thêm, gặp bug và phải đóng góp ngược.

Đã chặn được một số deploy xấu lên production; phản hồi nội bộ tốt. Bước tiếp: progressive rollout, cho phép team tự cấu hình luật rollback.

Rollback tự động dựa trên metric là tầng bảo vệ tiếp theo sau canary. Cloudflare 2025 nói rằng nếu đã có nó thì đợt sập thứ hai đã không xảy ra (Cloudflare 2025).
Dùng lại ngưỡng alert chung cho mọi service thì có độ phủ lớn với ít công.
Migration hàng loạt cần một "nhà máy" (migrator + hàng đợi + revert), không phải script, và không phải phân tán cho từng team. Cùng tinh thần với Nền tảng nội bộ cho service (đường ray chung).