Cần kiểm tra gì trước khi di chuyển dữ liệu?
- Xác định chính xác phạm vi dữ liệu cần di chuyển
- Đánh giá chất lượng và tính toàn vẹn của dữ liệu nguồn
- Kiểm tra khả năng tương thích giữa hệ thống cũ và hệ thống mới
- Kiểm tra bảo mật, quyền truy cập và yêu cầu tuân thủ
- Chuẩn bị sao lưu, kế hoạch chuyển đổi và phương án quay lui
- Thực hiện di chuyển thử và kiểm tra khả năng vận hành
- Xây dựng tiêu chí đối soát và phê duyệt trước khi vận hành
Trước khi thực hiện, doanh nghiệp cần trả lời được sáu câu hỏi trọng tâm:
· Dữ liệu nào thực sự cần chuyển
· Dữ liệu nguồn có đủ sạch và đáng tin cậy không
· Cấu trúc dữ liệu giữa hai hệ thống có tương thích không
· Dữ liệu nhạy cảm sẽ được bảo vệ như thế nào
· Kết quả di chuyển sẽ được kiểm chứng bằng tiêu chí nào
· Có thể khôi phục hệ thống cũ nếu quá trình chuyển đổi thất bại hay không
Một kế hoạch chỉ được xem là sẵn sàng khi các câu hỏi trên được chuyển thành danh mục kiểm tra, người chịu trách nhiệm, tiêu chí chấp nhận và bằng chứng xác nhận cụ thể.
Xác định chính xác phạm vi dữ liệu cần di chuyển
Việc đầu tiên là lập danh mục dữ liệu đang tồn tại trong hệ thống nguồn. Danh mục này phải phản ánh không chỉ các bảng hoặc tệp dữ liệu mà còn cả quan hệ, nguồn phát sinh, chủ sở hữu, mức độ quan trọng và mục đích sử dụng.
Doanh nghiệp nên phân loại tối thiểu các nhóm sau:
· Dữ liệu chủ như khách hàng, nhà cung cấp, sản phẩm và nhân sự
· Dữ liệu giao dịch như đơn hàng, hóa đơn, thanh toán và tồn kho
· Dữ liệu cấu hình như mã thuế, tiền tệ, trạng thái và tham số nghiệp vụ
· Dữ liệu lịch sử phục vụ tra cứu, báo cáo hoặc kiểm toán
· Tệp đính kèm, tài liệu, hình ảnh và nội dung phi cấu trúc
· Nhật ký hệ thống, lịch sử thay đổi và dữ liệu phục vụ truy vết
Không phải mọi dữ liệu trong hệ thống cũ đều cần được đưa sang hệ thống mới. Dữ liệu trùng lặp, hết thời hạn lưu giữ, không còn giá trị nghiệp vụ hoặc không xác định được nguồn gốc có thể làm tăng thời gian xử lý và rủi ro sai lệch.
Mỗi tập dữ liệu nên được gắn với một quyết định rõ ràng:
· Di chuyển toàn bộ
· Di chuyển có chọn lọc
· Chuyển vào kho lưu trữ
· Giữ lại trong hệ thống cũ để tra cứu
· Loại bỏ theo chính sách được phê duyệt
Phạm vi cũng phải bao gồm các phụ thuộc. Một bảng đơn hàng có thể không sử dụng được nếu thiếu dữ liệu khách hàng, sản phẩm, địa chỉ, thuế hoặc trạng thái liên quan. Vì vậy, doanh nghiệp cần kiểm tra quan hệ khóa, thứ tự tải dữ liệu và các quy tắc tham chiếu trước khi lập lịch di chuyển.

Đánh giá chất lượng và tính toàn vẹn của dữ liệu nguồn
Dữ liệu không đạt chất lượng sẽ không tự trở nên chính xác sau khi được chuyển sang hệ thống mới. Ngược lại, quá trình chuyển đổi có thể làm lỗi cũ khó phát hiện hơn do dữ liệu đã đi qua các bước ánh xạ, biến đổi và hợp nhất.
Các vấn đề cần kiểm tra gồm:
· Bản ghi trùng lặp
· Trường bắt buộc bị bỏ trống
· Giá trị sai định dạng
· Mã hoặc trạng thái không còn hợp lệ
· Dữ liệu mâu thuẫn giữa các hệ thống
· Bản ghi con không có bản ghi cha tương ứng
· Ngày tháng, đơn vị đo hoặc tiền tệ không thống nhất
· Dữ liệu bị cắt ngắn hoặc chứa ký tự không được hỗ trợ
· Thông tin không xác định được nguồn gốc hoặc người chịu trách nhiệm
Doanh nghiệp cần xây dựng hồ sơ chất lượng cho từng tập dữ liệu quan trọng. Hồ sơ có thể bao gồm tổng số bản ghi, tỷ lệ trường trống, số lượng bản ghi trùng, số lỗi quan hệ và số giá trị nằm ngoài quy tắc nghiệp vụ.
Không nên đặt mục tiêu chung chung như “dữ liệu phải sạch”. Mỗi nhóm dữ liệu cần có tiêu chí chấp nhận riêng. Chẳng hạn, dữ liệu khách hàng đang hoạt động có thể yêu cầu đầy đủ mã khách hàng và thông tin liên hệ, trong khi dữ liệu lịch sử chỉ cần bảo toàn khả năng tra cứu và đối chiếu.
Các lỗi phải được xử lý tại nơi phù hợp:
· Sửa trong hệ thống nguồn khi lỗi ảnh hưởng đến hoạt động hiện tại
· Làm sạch trong quy trình chuyển đổi khi cần chuẩn hóa hàng loạt
· Gắn cờ để xử lý thủ công khi không thể xác định quy tắc tự động
· Loại khỏi phạm vi khi dữ liệu không còn giá trị và được phê duyệt
Việc kiểm tra tính toàn vẹn phải dựa trên cả số lượng và ý nghĩa nghiệp vụ. Hai hệ thống có thể có cùng số bản ghi nhưng vẫn sai nếu quan hệ, số dư, trạng thái hoặc giá trị tổng hợp không khớp.
Kiểm tra khả năng tương thích giữa hệ thống cũ và hệ thống mới
Khác biệt về cấu trúc là nguyên nhân phổ biến khiến dữ liệu được chuyển thành công về mặt kỹ thuật nhưng không thể sử dụng đúng trong nghiệp vụ.
Doanh nghiệp cần lập tài liệu ánh xạ giữa nguồn và đích, trong đó xác định:
· Bảng hoặc đối tượng nguồn
· Trường dữ liệu nguồn
· Đối tượng và trường dữ liệu đích
· Kiểu dữ liệu
· Độ dài trường
· Giá trị mặc định
· Quy tắc chuyển đổi
· Quy tắc làm tròn
· Cách xử lý giá trị rỗng
· Quan hệ và thứ tự tải
· Điều kiện loại trừ
· Người phê duyệt quy tắc
Kiểm tra kiểu và định dạng dữ liệu
Một trường văn bản trong hệ thống cũ có thể được định nghĩa thành trường số, ngày tháng, danh mục hoặc khóa tham chiếu trong hệ thống mới. Nếu không xử lý đúng, dữ liệu có thể bị từ chối, cắt ngắn hoặc chuyển thành giá trị không hợp lệ.
Các yếu tố cần chú ý gồm:
· Bộ ký tự và mã hóa
· Định dạng ngày tháng
· Múi giờ
· Dấu phân cách thập phân
· Độ chính xác của số
· Đơn vị đo
· Tiền tệ
· Giá trị Boolean
· Quy tắc viết hoa và chuẩn hóa ký tự
Kiểm tra quy tắc nghiệp vụ
Một mã trạng thái trong hệ thống cũ không nhất thiết có giá trị tương đương trực tiếp trong hệ thống mới. Nhiều giá trị nguồn có thể phải hợp nhất thành một giá trị đích, hoặc một bản ghi nguồn có thể phải tách thành nhiều đối tượng.
Mọi quy tắc chuyển đổi phải được xác nhận bởi chủ sở hữu nghiệp vụ, không chỉ bởi đội kỹ thuật. Nhân sự kỹ thuật có thể xác nhận dữ liệu được nạp đúng cấu trúc, nhưng bộ phận nghiệp vụ mới có thể xác nhận ý nghĩa của dữ liệu sau chuyển đổi vẫn chính xác.
Kiểm tra phụ thuộc ứng dụng
Dữ liệu còn được sử dụng bởi báo cáo, tích hợp, quy trình phê duyệt, tác vụ tự động và ứng dụng bên ngoài. Thay đổi mã định danh hoặc cấu trúc trường có thể làm các thành phần này ngừng hoạt động dù cơ sở dữ liệu đích không báo lỗi.
Doanh nghiệp cần lập danh sách các phụ thuộc và kiểm tra từng thành phần trong môi trường thử nghiệm trước khi chuyển đổi chính thức.
Kiểm tra bảo mật, quyền truy cập và yêu cầu tuân thủ
Trong quá trình di chuyển, dữ liệu thường tồn tại đồng thời ở hệ thống nguồn, vùng trung gian, tệp xuất, bản sao lưu và hệ thống đích. Số lượng vị trí lưu trữ tăng lên đồng nghĩa với việc bề mặt rủi ro cũng tăng.
ISO/IEC 27001:2022 xác định các yêu cầu đối với hệ thống quản lý an toàn thông tin, trong đó việc kiểm soát rủi ro, quyền truy cập và bảo vệ tài sản thông tin phải được quản lý theo hệ thống thay vì xử lý riêng lẻ.
Trước khi di chuyển, doanh nghiệp cần xác định:
· Dữ liệu nào thuộc nhóm nhạy cảm hoặc hạn chế truy cập
· Ai được phép đọc, xuất, biến đổi và phê duyệt dữ liệu
· Dữ liệu có được mã hóa khi truyền và khi lưu trữ hay không
· Tệp tạm và bản sao trung gian được lưu ở đâu
· Nhật ký truy cập và thay đổi có được ghi nhận hay không
· Tài khoản kỹ thuật có được giới hạn quyền theo nhiệm vụ hay không
· Dữ liệu tạm sẽ được xóa an toàn vào thời điểm nào
· Chính sách lưu giữ và tiêu hủy nào phải được áp dụng
· Có hạn chế nào về vị trí địa lý lưu trữ dữ liệu hay không
Quyền truy cập không nên được sao chép nguyên trạng từ hệ thống cũ. Hệ thống cũ có thể tồn tại quyền cấp dư thừa hoặc tài khoản không còn sử dụng. Quá trình di chuyển là thời điểm thích hợp để đối chiếu vai trò, loại bỏ quyền không cần thiết và áp dụng nguyên tắc quyền tối thiểu.
Doanh nghiệp cũng cần xác định dữ liệu nào phải được che, ẩn danh hoặc thay thế trong môi trường thử nghiệm. Sử dụng nguyên bản dữ liệu khách hàng, nhân sự hoặc tài chính trong môi trường có mức kiểm soát thấp hơn có thể tạo ra rủi ro ngoài phạm vi của chính hoạt động di chuyển.
Chuẩn bị sao lưu, kế hoạch chuyển đổi và phương án quay lui
Không nên thực hiện di chuyển dữ liệu sản xuất nếu chưa có bản sao lưu đã được kiểm tra khả năng phục hồi. Việc “có tệp sao lưu” không đồng nghĩa với việc có thể khôi phục hệ thống trong điều kiện thực tế.
NIST nhấn mạnh khả năng phát hiện dữ liệu bị hỏng và phục hồi hệ thống, cơ sở dữ liệu, tệp, ứng dụng cùng cấu hình sau các sự kiện phá hoại dữ liệu.
Trước thời điểm chuyển đổi, doanh nghiệp cần hoàn thành:
· Sao lưu đầy đủ dữ liệu và cấu hình hệ thống nguồn
· Kiểm tra tính toàn vẹn của bản sao lưu
· Thử phục hồi trên một môi trường tách biệt
· Ghi nhận thời gian sao lưu và thời gian phục hồi
· Xác định điểm phục hồi được chấp nhận
· Xác định thời gian gián đoạn tối đa
· Chốt thời điểm ngừng cập nhật dữ liệu nguồn
· Xây dựng cách xử lý giao dịch phát sinh trong thời gian chuyển đổi
Kế hoạch chuyển đổi phải mô tả trình tự thực hiện từ lúc đóng băng dữ liệu đến lúc mở hệ thống mới cho người dùng. Mỗi bước cần có người thực hiện, thời điểm bắt đầu, điều kiện hoàn thành và bằng chứng xác nhận.
Phương án quay lui phải trả lời rõ:
· Điều kiện nào kích hoạt quay lui
· Ai có quyền ra quyết định
· Dữ liệu phát sinh trên hệ thống mới sẽ được xử lý thế nào
· Mất bao lâu để khôi phục hệ thống cũ
· Làm thế nào để tránh ghi dữ liệu đồng thời vào hai hệ thống
· Người dùng và các bên liên quan sẽ được thông báo ra sao
Kế hoạch quay lui không nên chỉ dựa trên cảm nhận của nhóm dự án. Doanh nghiệp cần xác định ngưỡng cụ thể, chẳng hạn xuất hiện sai lệch ở dữ liệu tài chính trọng yếu, không thể đăng nhập, giao dịch cốt lõi thất bại hoặc thời gian chuyển đổi vượt quá cửa sổ đã phê duyệt.
Thực hiện di chuyển thử và kiểm tra khả năng vận hành
Một lần chạy thử trên dữ liệu đại diện giúp phát hiện vấn đề về hiệu năng, ánh xạ, chất lượng và quy trình trước khi dữ liệu sản xuất bị tác động. Microsoft khuyến nghị xây dựng truy vấn kiểm tra trên cả cơ sở dữ liệu nguồn và đích, đồng thời thiết lập môi trường thử nghiệm tách biệt để kiểm tra quá trình di chuyển.
Dữ liệu thử phải phản ánh đủ các trường hợp quan trọng:
· Bản ghi thông thường
· Bản ghi có dung lượng lớn
· Dữ liệu có ký tự đặc biệt
· Quan hệ nhiều cấp
· Trường rỗng
· Giá trị biên
· Giao dịch đang mở
· Dữ liệu lịch sử
· Trường hợp từng phát sinh lỗi
Sau mỗi lần chạy thử, nhóm dự án cần ghi nhận:
· Thời gian trích xuất
· Thời gian biến đổi
· Thời gian tải
· Tốc độ xử lý
· Số bản ghi thành công
· Số bản ghi lỗi
· Loại lỗi
· Khả năng chạy lại
· Mức sử dụng tài nguyên
· Thời gian đối soát
Kết quả thử nghiệm phải được so sánh giữa các lần chạy. Nếu thời gian hoặc tỷ lệ lỗi biến động lớn mà chưa xác định được nguyên nhân, kế hoạch chưa đủ ổn định để áp dụng cho môi trường sản xuất.
Ngoài dữ liệu, doanh nghiệp phải kiểm tra quy trình nghiệp vụ sau khi nạp. Người dùng đại diện cần thực hiện các tác vụ thực tế như tìm kiếm khách hàng, mở đơn hàng, đối chiếu số dư, tạo báo cáo hoặc xử lý giao dịch. Điều này giúp phát hiện những lỗi không thể nhìn thấy bằng việc đếm bản ghi.
Xây dựng tiêu chí đối soát và phê duyệt trước khi vận hành
Doanh nghiệp phải xác định cách chứng minh kết quả di chuyển là đúng trước khi bắt đầu. Không nên chờ đến sau khi chuyển đổi mới quyết định cần kiểm tra những gì.
AWS Database Migration Service sử dụng cơ chế xác thực bằng cách so sánh dữ liệu nguồn và dữ liệu đích sau khi tải, cho thấy đối chiếu trực tiếp là thành phần trọng yếu của quá trình xác nhận kết quả.
Tiêu chí đối soát nên bao gồm nhiều lớp:
Đối soát cấu trúc
· Đủ bảng, trường và quan hệ cần thiết
· Kiểu dữ liệu đúng với thiết kế
· Khóa chính và khóa ngoại hợp lệ
· Chỉ mục và ràng buộc được tạo đúng
Đối soát số lượng
· Tổng số bản ghi nguồn và đích
· Số bản ghi theo từng nhóm nghiệp vụ
· Số bản ghi bị loại
· Số bản ghi lỗi
· Số bản ghi được hợp nhất hoặc tách
Đếm bản ghi chỉ là bước đầu. Một quy trình có thể tạo đúng số lượng nhưng đưa sai giá trị vào từng bản ghi.
Đối soát nội dung
· So sánh trường trọng yếu
· So sánh mẫu ngẫu nhiên
· So sánh dữ liệu theo từng khoảng thời gian
· Kiểm tra hàm băm hoặc tổng kiểm tra khi phù hợp
· Kiểm tra quan hệ giữa các bản ghi
Đối soát nghiệp vụ
· Tổng doanh thu
· Số dư công nợ
· Giá trị tồn kho
· Số lượng giao dịch đang mở
· Tổng tiền theo kỳ
· Trạng thái hồ sơ
· Kết quả báo cáo quản trị
Tiêu chí chấp nhận cần được phê duyệt bởi cả đội kỹ thuật và chủ sở hữu nghiệp vụ. Đội kỹ thuật xác nhận cấu trúc, tính toàn vẹn và khả năng vận hành; bộ phận nghiệp vụ xác nhận dữ liệu phản ánh đúng thực tế kinh doanh.
Quyết định đưa hệ thống mới vào vận hành chỉ nên được thực hiện khi:
· Các kiểm tra bắt buộc đã hoàn tất
· Sai lệch trọng yếu bằng không
· Sai lệch không trọng yếu đã được ghi nhận và chấp thuận
· Người dùng đã hoàn thành kiểm thử chấp nhận
· Kế hoạch hỗ trợ sau chuyển đổi đã sẵn sàng
· Người có thẩm quyền đã ký xác nhận
Trước khi di chuyển dữ liệu doanh nghiệp, trọng tâm không nằm ở việc công cụ có thể sao chép dữ liệu nhanh đến đâu mà ở khả năng chứng minh dữ liệu sau chuyển đổi vẫn đầy đủ, chính xác, bảo mật và sử dụng được.
Một quy trình chuẩn bị đáng tin cậy phải bao phủ toàn bộ chuỗi: xác định phạm vi, đánh giá chất lượng, ánh xạ cấu trúc, kiểm soát bảo mật, chuẩn bị sao lưu, chạy thử, đối soát và phê duyệt. Nếu chưa có tiêu chí chấp nhận hoặc chưa thử phương án quay lui, doanh nghiệp chưa nên thực hiện chuyển đổi trên dữ liệu sản xuất.
Hỏi đáp về di chuyển dữ liệu doanh nghiệp
Có cần làm sạch toàn bộ dữ liệu trước khi di chuyển không?
Không nhất thiết phải sửa mọi dữ liệu lịch sử. Doanh nghiệp nên ưu tiên dữ liệu đang hoạt động, dữ liệu ảnh hưởng đến giao dịch, báo cáo, tuân thủ và quyết định quản trị. Dữ liệu không còn giá trị có thể được lưu trữ hoặc loại bỏ theo chính sách đã phê duyệt.
Chỉ so sánh số lượng bản ghi có đủ không?
Không. Số lượng bằng nhau không chứng minh giá trị, quan hệ và ý nghĩa nghiệp vụ đều chính xác. Cần kết hợp đối chiếu số lượng, nội dung trường, quan hệ dữ liệu và các tổng kiểm soát nghiệp vụ.
Khi nào cần dừng quá trình di chuyển?
Quá trình nên dừng khi xuất hiện sai lệch ở dữ liệu trọng yếu, lỗi không thể khắc phục trong cửa sổ chuyển đổi, hệ thống đích không đáp ứng nghiệp vụ cốt lõi hoặc thời gian gián đoạn vượt ngưỡng đã phê duyệt.
Ai chịu trách nhiệm xác nhận dữ liệu sau di chuyển?
Trách nhiệm cần được chia sẻ. Đội kỹ thuật xác nhận cấu trúc và tính toàn vẹn kỹ thuật; chủ sở hữu dữ liệu và người dùng nghiệp vụ xác nhận ý nghĩa, số liệu và khả năng sử dụng; người có thẩm quyền phê duyệt quyết định vận hành chính thức.
Có thể bỏ qua lần di chuyển thử khi dữ liệu ít không?
Không nên. Dù dung lượng nhỏ, dữ liệu vẫn có thể gặp lỗi ánh xạ, mã hóa, quan hệ hoặc quy tắc nghiệp vụ. Lần chạy thử giúp xác minh cả công cụ, quy trình, trách nhiệm và phương án xử lý lỗi trước khi tác động đến hệ thống sản xuất.
