Bài 3 — Triển khai an toàn: Shadow, Canary và Rollback
Có mô hình mới tốt hơn trên giấy tờ không có nghĩa nên thay ngay 100% traffic. Bài này dạy bạn ba kỹ thuật triển khai an toàn — vũ khí giúp AI Ops PM ship nhanh mà không "đốt nhà".
Ba chiến lược cốt lõi
1. Shadow deployment (chạy song song, không ảnh hưởng người dùng). Mô hình mới nhận cùng traffic thật nhưng kết quả của nó không được dùng — chỉ ghi log để so sánh với mô hình hiện tại. Dùng khi: bạn muốn kiểm tra hành vi trên dữ liệu production thật trước khi dám để nó quyết định. Ưu điểm: rủi ro bằng 0 cho người dùng. Nhược: tốn tài nguyên gấp đôi, và không đo được tác động hành vi người dùng (vì họ không thấy kết quả).
2. Canary deployment (thả từ từ). Cho mô hình mới phục vụ một tỷ lệ nhỏ traffic thật (ví dụ 1% → 5% → 25% → 100%), theo dõi metric ở từng bậc, chỉ tăng khi an toàn. Dùng khi: bạn đã đủ tin để cho nó ảnh hưởng người dùng, nhưng muốn giới hạn thiệt hại nếu sai. Đây là chiến lược phổ biến nhất cho production.
3. Rollback (quay về bản cũ). Khi bản mới gây sự cố, lập tức chuyển traffic về phiên bản ổn định trước đó. Rollback tốt phải nhanh, tự động hóa được, và không mất dữ liệu. Điều kiện tiên quyết: bản cũ vẫn còn deploy được (đừng xóa!) và có trigger rõ ràng để kích hoạt.
Khung quyết định: chọn chiến lược nào?
Hỏi 3 câu:
- Sai thì hậu quả thế nào? Nghiêm trọng (y tế, tài chính) → shadow trước, rồi canary rất chậm. Nhẹ (gợi ý nội dung) → canary trực tiếp.
- Có đo được chất lượng ngay không? Nếu nhãn trễ, canary phải kèm guardrail proxy (latency, tỷ lệ lỗi, tỷ lệ can thiệp thủ công).
- Rollback có rẻ không? Nếu rollback tốn kém/chậm, hãy đầu tư shadow nhiều hơn để giảm xác suất phải rollback.
Ví dụ cụ thể
Một ngân hàng thay mô hình phê duyệt khoản vay nhỏ. Vì rủi ro cao:
- Shadow 2 tuần: so sánh quyết định mô hình mới vs cũ trên đơn thật, phát hiện mô hình mới từ chối nhiều hơn 8% nhóm khách hàng vùng nông thôn → điều tra fairness trước khi ai bị ảnh hưởng.
- Sau khi tinh chỉnh, canary 1% với guardrail: tỷ lệ duyệt, tỷ lệ khiếu nại, phân bố theo nhóm.
- Ở bậc 5%, tỷ lệ khiếu nại tăng bất thường → auto-rollback trong 3 phút nhờ trigger đã định nghĩa sẵn. MTTR thấp vì mọi thứ tự động.
Checklist deploy an toàn
- [ ] Bản cũ (last-known-good) vẫn deploy được, không bị xóa.
- [ ] Có guardrail metrics đo được tại thời điểm canary (không chờ nhãn trễ).
- [ ] Định nghĩa tiêu chí thăng bậc (promote) và tiêu chí rollback trước khi bắt đầu.
- [ ] Rollback tự động hóa và đã được diễn tập (fire drill), không phải quy trình thủ công 20 bước.
- [ ] Có kế hoạch xử lý dữ liệu/side-effect khi rollback (đơn hàng đã tạo, email đã gửi...).
- [ ] Log đầy đủ để so sánh A/B giữa hai phiên bản.
Sai lầm thường gặp
- Nhảy thẳng 100% vì "offline metric đẹp". Offline không phản ánh hành vi người dùng thật.
- Canary nhưng không có tiêu chí thăng bậc rõ ràng, dẫn đến cãi nhau "đủ tốt chưa" mỗi lần.
- Xóa bản cũ ngay sau khi deploy bản mới → mất đường rollback.
- Quên side-effect khi rollback. Model tạo giao dịch/thông báo — rollback code nhưng hậu quả đã xảy ra.
- Shadow nhưng không thực sự so sánh log, biến nó thành nghi thức tốn tiền vô ích.
- Không diễn tập rollback, nên khi cần thì mới phát hiện nó không chạy — MTTR tăng vọt đúng lúc nguy cấp.