Trong hầu hết dự án chuyển hệ thống lên cloud, phần tốn thời gian nhất là thiết kế kiến trúc đích và sao chép dữ liệu. Nhưng phần rủi ro nhất lại nằm ở một khoảng thời gian ngắn hơn nhiều: vài giờ cutover, khi lưu lượng thật được chuyển từ hệ thống cũ sang hệ thống mới. Toàn bộ công sức nhiều tháng trước đó được phán xét trong cửa sổ này. Một runbook cutover viết kỹ, tập dượt trước và có ngưỡng rollback rõ ràng là thứ phân biệt một lần chuyển đổi êm thấm với một sự cố phải giải thích với ban lãnh đạo.

Cutover là một sự kiện được thiết kế, không phải một đêm thức trắng

Sai lầm phổ biến nhất là coi cutover như một buổi trực đêm: tập hợp nhiều người giỏi, bắt đầu lúc nửa đêm và xử lý mọi thứ phát sinh. Cách làm này thất bại vì nó dựa vào phán đoán tại chỗ ở đúng thời điểm mà con người mệt mỏi nhất, và vì không ai biết chính xác khi nào thì nên dừng lại.

Cách làm thay thế là xem cutover như một quy trình được viết sẵn từng bước, mỗi bước có người chịu trách nhiệm, thời lượng dự kiến và điều kiện để đi tiếp. Khi đến đêm cutover, đội ngũ chỉ thực thi văn bản đã được duyệt chứ không sáng tạo. Mọi quyết định khó đã được ra trước đó vài tuần, trong trạng thái tỉnh táo.

Tiêu chí đóng băng thay đổi

Trước cutover cần một giai đoạn đóng băng (change freeze) áp dụng cho hệ thống nguồn: không triển khai mã mới, không thay đổi lược đồ cơ sở dữ liệu, không sửa cấu hình hạ tầng, không thêm tích hợp bên thứ ba. Lý do rất thực tế: mọi thay đổi ở nguồn sau khi đã kiểm thử hệ thống đích đều làm mất giá trị của kết quả kiểm thử đó.

Một chính sách đóng băng có ích cần nêu rõ:

Thời điểm bắt đầu và kết thúc đóng băng, tính theo giờ cụ thể chứ không theo ngày.
Phạm vi: những thành phần nào bị đóng băng, những thành phần nào vẫn được phép thay đổi.
Quy trình ngoại lệ: ai có quyền phê duyệt một thay đổi khẩn cấp trong thời gian đóng băng, và thay đổi đó phải được nhân bản sang hệ thống đích như thế nào.
Xử lý dữ liệu nghiệp vụ: đóng băng thường không áp dụng cho dữ liệu người dùng phát sinh, nhưng có thể áp dụng cho các tác vụ hàng loạt, job định kỳ và các quy trình sinh dữ liệu lớn.

Nếu tổ chức không thể đóng băng, đó là tín hiệu cho thấy cần chia dự án thành nhiều đợt cutover nhỏ theo từng nhóm dịch vụ, thay vì một lần chuyển toàn bộ.

Đồng bộ delta lần cuối

Phần lớn dữ liệu nên được sao chép trước, trong nhiều ngày hoặc nhiều tuần, khi hệ thống cũ vẫn đang chạy. Việc còn lại trong đêm cutover chỉ là đồng bộ phần chênh lệch phát sinh kể từ lần sao chép trước. Thời lượng của bước này quyết định phần lớn độ dài cửa sổ gián đoạn, nên nó cần được đo chứ không ước lượng.

Cách đo đơn giản là chạy thử một chu kỳ đồng bộ delta ở môi trường thật vài ngày trước cutover, với đúng khối lượng thay đổi của một ngày làm việc bình thường, rồi ghi lại thời gian thực tế. Với cơ sở dữ liệu, cần phân biệt rõ hai kiểu tiếp cận:

Sao chép logic hoặc replication liên tục: hệ thống đích bám sát nguồn theo thời gian thực, cutover chỉ là dừng ghi ở nguồn, chờ độ trễ replication về 0, rồi chuyển vai trò. Cửa sổ gián đoạn ngắn nhưng đòi hỏi chuẩn bị nhiều hơn.
Sao lưu và khôi phục: đơn giản hơn về mặt kỹ thuật nhưng cửa sổ gián đoạn bằng đúng thời gian dump, truyền và restore, thường dài hơn nhiều với dữ liệu lớn.

Cần kiểm tra tính toàn vẹn sau đồng bộ: đếm bản ghi theo bảng, đối chiếu giá trị chốt của các bảng nghiệp vụ quan trọng, so sánh checksum tệp với kho đối tượng. Việc này phải nằm trong runbook như một bước bắt buộc, không phải một thao tác tùy hứng.

DNS và TTL phải chuẩn bị trước nhiều ngày

DNS là nguyên nhân phổ biến khiến một cutover kỹ thuật thành công vẫn kéo dài gián đoạn cảm nhận được. Bản ghi có TTL dài sẽ tiếp tục được cache ở resolver trung gian và ở phía client sau khi bạn đã đổi trỏ.

Nguyên tắc thực hành:

Hạ TTL của các bản ghi liên quan xuống giá trị thấp ít nhất một khoảng thời gian dài hơn TTL cũ, tính từ trước cutover. Nếu TTL hiện tại là 24 giờ, việc hạ TTL vào chiều hôm cutover không có tác dụng.
Chuẩn bị sẵn nội dung bản ghi mới và kiểm tra cú pháp trước, để đêm cutover chỉ là thao tác dán và lưu.
Giữ hệ thống cũ ở trạng thái chỉ đọc hoặc chuyển hướng thay vì tắt hẳn, để lưu lượng đến trễ không gặp lỗi kết nối.
Đừng dựa hoàn toàn vào DNS nếu có thể chuyển tại tầng cân bằng tải hoặc reverse proxy, vì cách này cho hiệu lực tức thì và rollback nhanh hơn.
Khôi phục TTL về giá trị bình thường sau khi hệ thống đã ổn định.

Checklist kiểm thử sau chuyển đổi

Kiểm thử sau cutover cần được viết sẵn dưới dạng danh sách các bước có kết quả kỳ vọng cụ thể, có thể giao cho người không phải kiến trúc sư hệ thống thực hiện. Danh sách nên bao gồm:

Đăng nhập với vài loại tài khoản khác nhau, bao gồm tài khoản có phân quyền hạn chế.
Một giao dịch nghiệp vụ đầu-cuối thật, kể cả bước ghi dữ liệu, chứ không chỉ mở trang chủ.
Các tích hợp bên ngoài: cổng thanh toán, gửi email, SMS, đối tác API. Đây là nhóm hay hỏng nhất vì phụ thuộc IP nguồn hoặc danh sách cho phép.
Tác vụ nền và job định kỳ: xác nhận chúng chạy đúng một lần, không chạy song song ở cả hai hệ thống.
Chứng chỉ TLS, chuyển hướng HTTP sang HTTPS, tên miền phụ.
Ghi log và giám sát: cảnh báo phải đến đúng kênh, dashboard phải nhận dữ liệu từ hệ thống mới.
Sao lưu: bản sao lưu đầu tiên trên môi trường mới phải chạy và được kiểm chứng khôi phục sớm nhất có thể.
Hiệu năng: so sánh thời gian phản hồi của vài thao tác chính với số liệu nền đã ghi trước đó ở hệ thống cũ.

Ngưỡng rollback và điểm không thể quay lui

Runbook phải định nghĩa trước những điều kiện nào bắt buộc quay lui, viết ra thành ngưỡng khách quan chứ không phải cảm nhận. Ví dụ dạng ngưỡng: đồng bộ delta chưa hoàn tất sau khoảng thời gian X đã định; kiểm tra toàn vẹn dữ liệu không khớp; một tích hợp thanh toán không hoạt động; tỷ lệ lỗi vượt mức Y trong Z phút sau khi mở lưu lượng. Các con số cụ thể do tổ chức tự đặt dựa trên ngưỡng chịu đựng nghiệp vụ của mình.

Quan trọng không kém là điểm không thể quay lui: thời điểm mà hệ thống mới đã nhận dữ liệu ghi từ người dùng thật, khiến việc quay về hệ thống cũ đồng nghĩa với mất dữ liệu hoặc phải đồng bộ ngược phức tạp. Điểm này phải được nêu rõ trong runbook, kèm giờ dự kiến, và phải có một quyết định go/no-go chính thức ngay trước đó, do một người có thẩm quyền đưa ra dựa trên kết quả checklist.

Sau điểm không thể quay lui, phương án dự phòng không còn là rollback mà là khắc phục tại chỗ. Điều đó cần được chuẩn bị bằng nguồn lực khác: người trực, quyền truy cập, kênh liên lạc với nhà cung cấp.

Kế hoạch truyền thông

Trong đêm cutover, thông tin nội bộ quan trọng ngang với thao tác kỹ thuật. Kế hoạch truyền thông nên xác định trước:

Một kênh duy nhất cho đội kỹ thuật, và một người duy nhất chịu trách nhiệm cập nhật trạng thái ra bên ngoài.
Lịch cập nhật cố định theo mốc thời gian, kể cả khi không có gì thay đổi. Im lặng luôn bị hiểu là có sự cố.
Thông báo cho người dùng trước cutover, nêu cửa sổ dự kiến và những chức năng sẽ không khả dụng.
Nội dung soạn sẵn cho ba tình huống: hoàn tất đúng kế hoạch, kéo dài hơn dự kiến, và quay lui.
Danh sách liên hệ của các bên phụ thuộc: đối tác tích hợp, nhà cung cấp dịch vụ, đội hỗ trợ khách hàng.

Hypercare sau cutover

Cutover không kết thúc khi lưu lượng đã chuyển. Giai đoạn hypercare, thường kéo dài từ vài ngày đến vài tuần tùy quy mô, là lúc phát hiện những vấn đề chỉ xuất hiện dưới tải thật hoặc theo chu kỳ nghiệp vụ: job cuối tháng, báo cáo định kỳ, giờ cao điểm.

Trong giai đoạn này nên giữ mức giám sát cao hơn bình thường, giữ hệ thống cũ ở trạng thái đọc được trong một khoảng thời gian đã thỏa thuận trước khi thu hồi tài nguyên, và duy trì một kênh xử lý sự cố riêng có thời gian phản hồi ngắn. Việc thu hồi hệ thống cũ nên là một quyết định có ngày cụ thể trong kế hoạch, không phải điều bị quên lãng rồi phát sinh chi phí kéo dài.

Đánh giá một cam kết downtime có đáng tin không

Khi làm việc với nhà cung cấp, bên mua nên yêu cầu cửa sổ gián đoạn được ước lượng theo cách có thể kiểm chứng, thay vì nhận một con số tròn trịa. Một ước lượng đáng tin thường có các đặc điểm sau:

Được tách thành từng bước có thời lượng riêng: dừng ghi, đồng bộ delta cuối, kiểm tra toàn vẹn, chuyển trỏ, kiểm thử, mở lưu lượng.
Dựa trên số đo từ một lần diễn tập trên dữ liệu thật, có ghi nhận kết quả, chứ không dựa trên kinh nghiệm chung.
Nêu rõ giả định: khối lượng dữ liệu, băng thông khả dụng, mức thay đổi trong ngày, và điều gì xảy ra nếu giả định sai.
Có phần dự phòng thời gian được ghi rõ, thay vì gộp ngầm vào con số cuối.
Kèm ngưỡng rollback và thời điểm ra quyết định, vì một cửa sổ không có ngưỡng dừng thì không phải là cam kết mà chỉ là kỳ vọng.

Công thức khung để bên mua tự kiểm tra tính hợp lý của con số:

Cửa sổ gián đoạn = dừng ghi + đồng bộ delta cuối
                 + kiểm tra toàn vẹn + chuyển trỏ
                 + kiểm thử bắt buộc + dự phòng

Nếu nhà cung cấp không thể điền số vào từng thành phần và nói rõ số đó đến từ đâu, con số tổng không nên được coi là một cam kết. Ngược lại, một ước lượng dài hơn nhưng có cơ sở thường an toàn hơn nhiều cho nghiệp vụ so với một con số ngắn không giải thích được.

HiTechCloud có thể hỗ trợ như thế nào

HiTechCloud là đối tác AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt trong nước. Chúng tôi hỗ trợ khảo sát hệ thống hiện tại, xây dựng runbook cutover với tiêu chí đóng băng và ngưỡng rollback cụ thể, thực hiện diễn tập đồng bộ delta để đo cửa sổ gián đoạn trên dữ liệu thật, và đồng hành trong giai đoạn hypercare sau chuyển đổi. Nếu bạn đang chuẩn bị một dự án di chuyển, hãy liên hệ để trao đổi về phương án phù hợp với ràng buộc nghiệp vụ của bạn.