Bạn lãnh đạo một migration lớn một cách an toàn như thế nào?

Question

Accepted Answer

Các migration lớn, cơ sở dữ liệu mới, framework mới, platform mới, có rủi ro cao vì chúng chạm vào mọi thứ và không mang lại giá trị nào hiển thị với người dùng cho đến khi hoàn thành. Cách tiếp cận an toàn là **tăng dần và có thể đảo ngược**, không bao giờ là một cú cutover big-bang. Bạn migrate theo các lát mà bạn có thể kiểm chứng và roll back.

## Một playbook migration an toàn

```text
1. Biết TẠI SAO — một migration không có lợi ích rõ ràng thì không đáng rủi ro.
2. Migrate TĂNG DẦN — không bao giờ lật mọi thứ cùng một lúc.
3. Chạy CŨ và MỚI song song — mẫu strangler-fig.
4. Dùng feature flag / GHI KÉP (DUAL WRITES) để dịch chuyển traffic dần dần.
5. KIỂM CHỨNG liên tục — so sánh output cũ vs. mới (shadow traffic).
6. Giữ một đường ROLLBACK ở mỗi bước.
7. Dọn dẹp hệ thống cũ CHỈ SAU KHI hệ thống mới đã được chứng minh.
```

## Mẫu strangler-fig

Bọc hệ thống cũ lại và định tuyến các lát chức năng sang hệ thống mới từng mảnh một, cho đến khi hệ thống cũ bị "siết nghẹt" hoàn toàn và có thể gỡ bỏ. Tại mọi thời điểm bạn đều có một hệ thống hoạt động và một con đường quay lại. Đây là kỹ thuật migration quan trọng nhất.

## Một ví dụ cụ thể

Migrate cơ sở dữ liệu: ghi kép vào cả hai, backfill dữ liệu lịch sử, đọc từ DB mới cho một % nhỏ traffic, so sánh kết quả, tăng dần, và chỉ ngừng hoạt động DB cũ khi DB mới đã phục vụ 100% sạch sẽ trong một thời gian.

## Một cái bẫy

Cú "big rewrite" chạy hàng tháng trong một branch và cutover tất cả cùng một lúc. Đó là một thảm họa kinh điển, bạn phát hiện ra mọi vấn đề ở thời điểm tệ nhất, không có đường quay lại.

## Tại sao điều này quan trọng

Migration là nơi các nhóm gánh lấy rủi ro ẩn khổng lồ để đổi lấy phần thưởng vô hình, và các cú cutover big-bang thất bại thảm khốc.

Migration tăng dần, có thể đảo ngược biến một canh bạc đặt cược cả công ty thành một chuỗi các bước nhỏ, an toàn, có thể kiểm chứng.