Cách chuyển đổi dữ liệu hệ thống khi triển khai công nghệ

Một quy trình an toàn thường đi theo chuỗi: kiểm kê dữ liệu → ánh xạ nguồn–đích → làm sạch và biến đổi → chạy thử → đối soát → cutover → kiểm tra sau chuyển đổi. Với dữ liệu quan trọng, tiêu chí hoàn tất phải dựa trên mức độ đúng, đủ và nhất quán của dữ liệu chứ không chỉ dựa vào việc công cụ migration đã báo chạy thành công.

Chốt phạm vi và lập bản đồ dữ liệu nguồn–đích

Bước đầu tiên là xác định chính xác dữ liệu nào phải chuyển, dữ liệu nào cần lưu trữ nhưng không đưa sang hệ thống mới và dữ liệu nào có thể loại bỏ. Việc chuyển toàn bộ dữ liệu lịch sử theo mặc định thường làm tăng khối lượng xử lý mà không tạo thêm giá trị vận hành.

Doanh nghiệp nên kiểm kê ít nhất các thành phần sau:

·         Bảng, tệp, tài liệu hoặc đối tượng dữ liệu thuộc phạm vi chuyển đổi

·         Khóa chính, khóa ngoại và quan hệ giữa các đối tượng

·         Trường dữ liệu bắt buộc và trường có thể để trống

·         Kiểu dữ liệu, độ dài, định dạng ngày giờ, mã hóa ký tự và đơn vị đo

·         Dữ liệu chủ như khách hàng, sản phẩm, nhân sự, nhà cung cấp

·         Dữ liệu giao dịch và dữ liệu lịch sử cần duy trì

·         Hệ thống hoặc dịch vụ đang đọc và ghi vào nguồn dữ liệu

Sau kiểm kê là data mapping. Mỗi trường ở nguồn phải được xác định sẽ đi đâu trong mô hình đích và chịu quy tắc gì.

Ví dụ, hệ thống cũ có HoTen, trong khi hệ thống mới tách thành FirstName và LastName. Đây không còn là thao tác sao chép một-một mà cần quy tắc phân tách. Nếu hệ thống cũ lưu trạng thái khách hàng bằng 0/1 còn hệ thống mới sử dụng Inactive/Active, mapping phải mô tả rõ phép chuyển đổi này.

Bản mapping nên xác định ít nhất: trường nguồn, trường đích, kiểu dữ liệu, quy tắc biến đổi, giá trị mặc định, điều kiện ngoại lệ và cách xử lý khi dữ liệu không hợp lệ. Nếu một trường không có đích tương ứng, quyết định bỏ hay lưu trường đó cũng phải được ghi nhận thay vì để công cụ migration tự xử lý.

Làm sạch, chuẩn hóa và xây quy tắc biến đổi

Dữ liệu nguồn có thể đang hoạt động được trong hệ thống cũ nhưng chưa chắc đáp ứng cấu trúc hoặc quy tắc của hệ thống mới. Vì vậy, làm sạch phải diễn ra trước hoặc ngay trong pipeline chuyển đổi.

Các lỗi thường gặp gồm dữ liệu trùng, trường bắt buộc bị thiếu, ngày tháng không đồng nhất, mã định danh sai cấu trúc, khoảng trắng thừa, dữ liệu số nằm trong trường văn bản hoặc nhiều cách viết khác nhau cho cùng một giá trị.

Một bộ quy tắc chuyển đổi thường bao gồm:

·         Chuẩn hóa định dạng ngày, giờ, số điện thoại và địa chỉ

·         Chuẩn hóa mã quốc gia, mã đơn vị, trạng thái và danh mục

·         Loại hoặc gộp bản ghi trùng theo quy tắc nghiệp vụ

·         Chuyển kiểu dữ liệu giữa nguồn và đích

·         Tách hoặc ghép trường

·         Tính lại trường dẫn xuất

·         Gán giá trị mặc định khi trường mới không tồn tại ở hệ thống cũ

·         Xử lý ký tự đặc biệt, bảng mã và dữ liệu đa ngôn ngữ

Không nên “làm sạch” bằng cách tự động sửa mọi dữ liệu bất thường. Một giá trị khác số đông có thể là lỗi, nhưng cũng có thể là ngoại lệ nghiệp vụ hợp lệ. Quy tắc làm sạch cần phân biệt ba tình huống: có thể sửa tự động, cần người nghiệp vụ xác nhận hoặc phải giữ nguyên.

ISO/IEC 25012:2008 cung cấp mô hình chất lượng cho dữ liệu có cấu trúc và có thể được dùng để xác định yêu cầu cũng như đánh giá chất lượng dữ liệu. Tiêu chuẩn này vẫn được ISO xác nhận là hiện hành sau lần rà soát năm 2025. Trong thực tế chuyển đổi, các thuộc tính như tính chính xác, đầy đủ và nhất quán nên được chuyển thành tiêu chí kiểm tra cụ thể thay vì chỉ nhận xét dữ liệu “tốt” hoặc “sạch”.

Chạy thử chuyển đổi trước khi chuyển dữ liệu thật

Không nên thực hiện lần đầu tiên trên toàn bộ dữ liệu production. Pipeline cần được chạy thử với tập dữ liệu có đủ trường hợp bình thường và ngoại lệ để phát hiện lỗi mapping, lỗi kiểu dữ liệu hoặc vấn đề hiệu năng trước cutover.

Một lần chạy thử nên ghi nhận:

·         Số bản ghi đọc từ nguồn

·         Số bản ghi được chuyển thành công

·         Số bản ghi bị loại theo quy tắc đã duyệt

·         Số bản ghi lỗi

·         Nguyên nhân lỗi theo từng nhóm

·         Thời gian xử lý

·         Các bảng hoặc đối tượng chưa hoàn thành

·         Các giá trị bị cắt, làm tròn hoặc chuyển kiểu ngoài dự kiến

Không nên chỉ chọn dữ liệu “đẹp” để thử. Tập kiểm thử cần có bản ghi thiếu trường, ký tự Unicode, dữ liệu gần giới hạn độ dài, quan hệ cha–con, dữ liệu trùng và các trường hợp nghiệp vụ đặc biệt.

Sau mỗi lần thử, lỗi phải được phân loại. Lỗi do mapping cần sửa mapping; lỗi do dữ liệu nguồn cần đi qua quy tắc làm sạch; lỗi do dữ liệu hợp lệ nhưng hệ thống đích chưa hỗ trợ cần được xử lý ở thiết kế đích. Việc sửa thủ công một vài bản ghi để lần chạy thử tiếp theo thành công sẽ che giấu lỗi có thể lặp lại khi chuyển toàn bộ dữ liệu.

Đối soát dữ liệu trước khi cutover

Một migration chạy hết các bước kỹ thuật chưa chứng minh rằng dữ liệu đích đã đúng. Trước khi chuyển người dùng sang hệ thống mới, cần đối soát nguồn và đích trên nhiều cấp độ.

Kiểm tra số lượng và tính đầy đủ

Đối chiếu tổng số bản ghi theo bảng hoặc nhóm nghiệp vụ là lớp kiểm tra cơ bản. Tuy nhiên, cùng số lượng bản ghi vẫn có thể chứa dữ liệu sai, vì vậy không nên dùng row count làm tiêu chí duy nhất.

Nên bổ sung các phép kiểm tra như:

·         Số bản ghi theo trạng thái nghiệp vụ

·         Tổng tiền, số lượng hoặc chỉ tiêu tổng hợp

·         Số bản ghi có trường bắt buộc bị rỗng

·         Số khóa chính trùng

·         Số quan hệ bị mất khóa tham chiếu

·         Giá trị nhỏ nhất, lớn nhất hoặc phạm vi ngày

Kiểm tra nội dung giữa nguồn và đích

Với dữ liệu quan trọng, cần so sánh trực tiếp giá trị tương ứng hoặc sử dụng checksum/hash khi phù hợp. AWS Database Migration Service là một ví dụ về cơ chế kỹ thuật có thể xác thực dữ liệu bằng cách so sánh từng hàng ở nguồn với hàng tương ứng ở đích và ghi nhận các bản ghi không khớp.

Cách kiểm tra này cũng cho thấy một trade-off quan trọng: validation càng chi tiết càng tiêu tốn thêm thời gian, tài nguyên cơ sở dữ liệu và băng thông. Vì vậy, dự án cần xác định trước mức kiểm tra cho từng nhóm dữ liệu thay vì đợi đến cuối migration mới quyết định.

Đối với dữ liệu chủ hoặc giao dịch trọng yếu, một acceptance gate thực tế là không còn bản ghi sai lệch chưa được giải thích hoặc phê duyệt trước cutover. Dữ liệu ít quan trọng hơn có thể áp dụng mức dung sai nếu doanh nghiệp xác định rõ nguyên nhân, phạm vi ảnh hưởng và kế hoạch xử lý sau đó.

Thực hiện cutover, đồng bộ phần chênh và chuẩn bị rollback

Khi dữ liệu đã vượt qua các vòng kiểm thử và đối soát, dự án mới chuyển sang cutover. Đây là thời điểm nguồn dữ liệu cũ ngừng hoặc hạn chế nhận thay đổi và hệ thống mới bắt đầu trở thành nguồn vận hành chính.

Một trình tự cutover phổ biến gồm:

1.    Chốt trạng thái và thời điểm bắt đầu cutover

2.    Dừng hoặc kiểm soát ghi dữ liệu vào hệ thống cũ

3.    Tạo bản sao lưu cuối cùng

4.    Chuyển phần dữ liệu còn chênh kể từ lần migration gần nhất

5.    Chạy validation cuối

6.    Chuyển kết nối ứng dụng hoặc người dùng sang hệ thống mới

7.    Kiểm tra các luồng nghiệp vụ trọng yếu

8.    Xác nhận go-live hoặc kích hoạt rollback

Hướng dẫn migration của AWS cũng sử dụng logic tương tự với các bước đóng băng dữ liệu đầu vào, backup, đồng bộ cuối, chuyển routing và kiểm thử trước khi coi migration hoàn tất.

Không phải hệ thống nào cũng cần dừng hoàn toàn. Nếu yêu cầu downtime thấp, có thể tải dữ liệu ban đầu trong khi hệ thống cũ vẫn hoạt động rồi sử dụng Change Data Capture hoặc cơ chế đồng bộ tương đương để chuyển các thay đổi phát sinh. Cách này giảm thời gian ngừng dịch vụ nhưng tăng độ phức tạp vì phải đảm bảo nguồn và đích thực sự đồng bộ tại thời điểm chuyển quyền vận hành.

Rollback cũng phải được thiết kế trước cutover. Kế hoạch cần xác định điều kiện quay lại hệ thống cũ, thời hạn cho phép rollback, cách xử lý giao dịch đã phát sinh ở hệ thống mới và người có quyền ra quyết định. Backup chỉ là một thành phần của rollback; nếu không biết cách khôi phục trạng thái nghiệp vụ nhất quán thì có bản sao lưu vẫn chưa đủ.

Kiểm tra sau chuyển đổi trước khi đóng migration

Sau khi hệ thống mới go-live, dữ liệu cần tiếp tục được kiểm tra trong một khoảng thời gian ổn định vận hành. Một số lỗi chỉ xuất hiện khi người dùng và các hệ thống tích hợp bắt đầu đọc, cập nhật hoặc tạo giao dịch mới trên dữ liệu đã chuyển.

Kiểm tra sau chuyển đổi nên bao phủ ba lớp.

Lớp dữ liệu: tiếp tục theo dõi bản ghi thiếu, sai quan hệ, sai tổng hợp, lỗi đồng bộ hoặc các mismatch còn phát sinh.

Lớp nghiệp vụ: thử các quy trình quan trọng như tạo đơn hàng, cập nhật hồ sơ, lập báo cáo hoặc tra cứu lịch sử để xác nhận dữ liệu chuyển đổi được ứng dụng mới diễn giải đúng.

Lớp vận hành: theo dõi log, lỗi ứng dụng, thời gian phản hồi, hàng đợi tích hợp và các chỉ số dịch vụ có liên quan. AWS cũng khuyến nghị thiết lập giám sát sau cutover dựa trên các thông số và chỉ số vận hành cần thiết.

Dữ liệu chỉ nên được coi là chuyển đổi hoàn tất khi các lỗi nghiêm trọng đã được xử lý, số liệu đối soát đạt acceptance criteria, người phụ trách nghiệp vụ xác nhận kết quả và không còn phụ thuộc chưa kiểm soát vào hệ thống cũ.

Hệ thống cũ cũng không nên bị xóa ngay sau go-live. Việc đưa hệ thống nguồn sang trạng thái chỉ đọc hoặc lưu trữ trong thời hạn quy định giúp hỗ trợ truy vết và phục hồi nếu phát hiện sai lệch muộn. Thời gian giữ lại cần phù hợp với yêu cầu nghiệp vụ, bảo mật và chính sách lưu trữ dữ liệu của tổ chức.

Chuyển đổi dữ liệu hệ thống hiệu quả là quá trình kiểm soát tính toàn vẹn của dữ liệu xuyên suốt từ nguồn đến đích. Ánh xạ xác định dữ liệu phải đi đâu, làm sạch và transformation xác định dữ liệu phải thay đổi thế nào, còn chạy thử và đối soát chứng minh kết quả có thể sử dụng được.

Trước khi go-live, cần có một điểm kiểm soát rõ ràng: dữ liệu trọng yếu đã được chuyển đủ, các sai lệch đã được giải thích hoặc xử lý, đồng bộ cuối đã hoàn tất và rollback có thể thực hiện nếu cutover thất bại. Sau go-live, validation vẫn phải tiếp tục cho đến khi cả dữ liệu, quy trình nghiệp vụ và vận hành hệ thống mới đều ổn định.