Di cư AWS sang GCP: 5 điều tôi sẽ làm khác nếu được làm lại

Chuyển một sản phẩm đang chạy thật từ AWS sang GCP không giống như đọc tài liệu rồi bấm nút “migrate”. Nó giống việc thay động cơ của một chiếc xe đang lăn bánh trên cao tốc: khách vẫn phải mua được hàng, đơn vẫn phải chạy, mà mọi thứ bên dưới đang được tháo ra lắp lại từng ngày.

Bài viết gốc trên blog madhav.dev kể lại đúng trải nghiệm đó. Và điều đáng giá nhất không nằm ở danh sách dịch vụ AWS nào đổi sang dịch vụ GCP nào, mà ở câu hỏi: nếu được làm lại, tôi sẽ làm gì khác? Dưới đây là những gì tôi đúc kết được, viết theo hướng thực hành để bạn có thể mang về bàn với đội của mình ngay tuần này.

Di cư cloud hiếm khi là bài toán kỹ thuật thuần túy

Phần lớn kỹ sư hình dung migration là chuyện API, CLI, Terraform provider, vài buổi đọc docs rồi xong. Nhưng khi vào việc thật, phần lớn thời gian lại trôi vào những câu hỏi không hề có trong tài liệu: ai chịu trách nhiệm khi hạn mức mới bị chạm? dịch vụ nội bộ nào đang gọi ngầm vào endpoint cũ? kế toán có hiểu cách nhà cung cấp mới tính tiền không?

Vì vậy, trước khi mở trình soạn thảo, hãy viết ra giấy lý do di cư và viết thật cụ thể. Nếu lý do chỉ là “cho hiện đại”, bạn sẽ hối hận ở tháng thứ hai. Nếu lý do là chi phí, hãy kiểm tra xem chi phí đó đến từ đâu. Nếu lý do là năng lực của đội, hãy hỏi xem đội có thật sự muốn học lại bộ công cụ mới hay không.

Một cuộc di cư tốt không phải cuộc di cư nhanh nhất, mà là cuộc di cư mà bạn vẫn giải thích được với chính mình sau sáu tháng.

Đừng bê nguyên kiến trúc cũ sang nhà mới

Cách nhanh nhất để “xong việc” là lift and shift: dựng lại từng máy ảo, từng bucket, từng queue y như bên cũ. Nó chạy được, nhưng bạn vừa mang theo toàn bộ nợ kỹ thuật sang một nơi mà cách tính tiền và cách vận hành đều khác. Bạn sẽ trả giá bằng đúng những thứ mình tưởng đã để lại phía sau.

Hãy dành thời gian rà lại những điểm dưới đây trước khi copy cấu hình:

• Ranh giới dịch vụ: chỗ nào nên là managed service, chỗ nào nên giữ tự vận hành để kiểm soát chi phí và độ trễ.
• Giả định về autoscaling: hành vi mở rộng và thời gian khởi động của hai nền tảng không giống nhau, đừng giả định là giống.
• Luồng dữ liệu giữa các vùng: thiết kế cũ có thể vô tình tạo ra lưu lượng liên vùng liên tục mà bạn không nhìn thấy.
• Những đoạn code “chỉ chạy được ở nhà cung cấp cũ”: SDK, metadata service, định dạng log, cơ chế xác thực. Đây là chỗ tốn thời gian nhất.

Một mẹo nhỏ nhưng hiệu quả: vẽ lại kiến trúc trên giấy trắng, không nhìn bản vẽ cũ. Nếu bạn không giải thích được vì sao thành phần đó tồn tại, rất có thể nó không cần tồn tại nữa.

Hiểu cách tính tiền trước khi viết dòng code đầu tiên

Chi phí cloud là thứ dễ gây bất ngờ nhất trong một cuộc di cư. Cùng một khối lượng công việc, hai nhà cung cấp có thể cho ra hai hoá đơn rất khác nhau, vì đơn vị tính tiền khác nhau: lưu lượng ra ngoài, lưu lượng giữa các vùng, số lượng request, tầng lưu trữ, thời gian sống của dữ liệu tạm.

Đừng chờ đến cuối tháng mới nhìn hoá đơn. Hãy làm ba việc này ngay từ đầu:

1. Ước tính chi phí cho lưu lượng mạng riêng một mục, vì đây là khoản hay bị bỏ sót nhất.
2. Bật nhãn (label) cho mọi tài nguyên ngay khi tạo, theo dịch vụ và theo môi trường, để sau này còn biết tiền chảy đi đâu.
3. Đặt cảnh báo ngân sách ở mức thấp hơn dự kiến, để học sớm thay vì học đắt.

Một khi đã nhìn thấy tiền chảy theo từng dịch vụ, bạn sẽ có thêm lý do để dọn dẹp những thành phần thừa — và đó thường là khoản tiết kiệm lớn nhất của cả dự án.

Danh tính, quyền truy cập và mạng phải làm trước, không phải làm sau

Đây là bài học đau nhất. Cấu trúc tài khoản, phân quyền, và cách tổ chức dự án ở nhà cung cấp mới thường không ánh xạ một-một với cái cũ. Nếu bạn dựng ứng dụng trước rồi mới nghĩ đến phân quyền, bạn sẽ phải sửa lại gần như mọi thứ: biến môi trường, đường dẫn bí mật, chính sách truy cập, cách dịch vụ này gọi dịch vụ kia.

Thứ tự hợp lý hơn là ngược lại: thiết kế phân cấp tổ chức, tách môi trường, đặt quy tắc mạng và luồng xác thực trước, rồi mới đặt ứng dụng lên trên. Nghe chậm, nhưng nó tiết kiệm cho bạn nhiều tuần sửa lỗi quyền truy cập lúc nửa đêm.

• Tách biệt rõ môi trường phát triển, staging và production ngay từ khung đầu tiên.
• Không dùng tài khoản cá nhân cho bất kỳ luồng tự động nào.
• Ghi lại mọi thay đổi hạ tầng bằng code, để có thể dựng lại từ đầu khi cần.

Dữ liệu, downtime và đường lui

Phần khó nhất của mọi cuộc di cư không phải là dựng hạ tầng mới, mà là chuyển dữ liệu mà không làm sai lệch con số. Người dùng không quan tâm bạn dùng dịch vụ nào; họ chỉ quan tâm đơn hàng của họ có còn đúng không.

Vì vậy hãy thiết kế đường lui trước khi cắt cầu. Chạy song song hai hệ thống trong một khoảng thời gian, ghi dữ liệu ở cả hai nơi nếu cần, và quan trọng nhất là có cách đối chiếu để biết dữ liệu mới có khớp với dữ liệu cũ hay không. Một bảng kiểm tra đối chiếu đơn giản, chạy hằng ngày, sẽ cứu bạn rất nhiều cuộc họp căng thẳng.

Và hãy nói trước với những người liên quan về khả năng có gián đoạn ngắn. Im lặng rồi để hệ thống chậm vài phút còn tệ hơn nhiều so với một thông báo trước.

Con người học công cụ mới chậm hơn bạn nghĩ

Kỹ thuật có thể xong trong vài tuần, nhưng phản xạ của đội thì cần vài tháng. Khi có sự cố lúc 2 giờ sáng, người trực sẽ làm theo bản năng cũ: tìm dashboard cũ, gõ lệnh cũ, mở runbook cũ. Nếu những thứ đó không còn đúng, thời gian xử lý sự cố sẽ dài hơn bình thường rất nhiều.

Hãy đầu tư vào những việc tưởng như phụ: viết lại runbook, đặt tên tài nguyên thật rõ ràng, ghim dashboard quan trọng vào một chỗ, và có một buổi diễn tập nhỏ để cả đội cùng thao tác trên hệ thống mới. Đừng biến cuộc di cư thành dự án của riêng một người giỏi nhất — hãy biến nó thành kiến thức chung.

Nếu được làm lại, tôi sẽ đi theo thứ tự này

1. Viết rõ lý do di cư và tiêu chí thành công, bằng những câu không thể ngụy biện.
2. Thiết kế lại kiến trúc trên giấy trắng, chỉ giữ những gì thật sự cần.
3. Dựng khung phân quyền, mạng và môi trường trước khi có ứng dụng.
4. Chuyển một dịch vụ nhỏ, ít rủi ro nhất, để học cách vận hành thật.
5. Thiết lập đo lường chi phí và đối chiếu dữ liệu ngay từ ngày đầu.
6. Chỉ cắt cầu khi đã có đường lui và đã diễn tập ít nhất một lần.

Điều thú vị là sau tất cả, nhiều đội nhận ra cuộc di cư không giúp họ thông minh hơn về cloud, mà giúp họ hiểu rõ hệ thống của chính mình hơn. Bạn buộc phải trả lời những câu hỏi mà trước đây có thể né: thành phần này để làm gì, ai gọi nó, nếu nó chết thì sao. Đó là phần thưởng ít được nói đến, và cũng là phần bền vững nhất.

Còn bạn, nếu đang đứng trước một cuộc di cư, hãy thử một phép thử nhỏ: viết ra giấy ba thứ bạn sẽ làm khác so với lần trước. Nếu chưa viết được ba, có lẽ bạn chưa cần di cư — mà cần dọn dẹp trước.

Bạn nghĩ sao: với một hệ thống đang chạy ổn, có nên di cư cloud chỉ vì hoá đơn chưa tối ưu, hay nên tối ưu trước rồi mới tính chuyện chuyển nhà? Để lại bình luận góc nhìn của bạn nhé — tôi rất muốn nghe phía ngược lại. Và nếu bài viết này giúp bạn nhìn cuộc di cư nhẹ nhàng hơn một chút, hãy lưu lại và gửi cho người đồng nghiệp đang chuẩn bị bước vào dự án tương tự.