Bối cảnh
Một cửa hàng đang bán hàng thật thì không ai dám thử theme mới ngay trên đó. Sửa hỏng một chỗ là khách thấy ngay, đơn hàng có thể mất. Nên Tân Doanh có hai trang: tandoanh.vn là trang thật, và td.phatdev.net là bản thử, nơi mình dựng và thử mọi thay đổi trước khi chạm vào trang thật.
Bản thử chỉ có ích nếu nó giống trang thật. Giá khác, tồn kho khác, thiếu một đơn hàng thì mọi bài kiểm tra trên đó đều đáng ngờ. Nên việc của mình là giữ cho bản thử luôn khớp với trang thật, theo một chiều duy nhất: trang thật chỉ để đọc, bản thử không bao giờ ghi ngược lại.
Thách thức
Hệ thống đối soát đang theo dõi 5.139 sản phẩm và 213 biến thể (đo ngày 08/11/2026). Giá và tồn kho đổi suốt ngày: nhân viên lưu một sản phẩm, một đơn mới vào, một món hết hàng.
Có ba điều khó. Một là tốc độ: nếu bản thử chậm cả tiếng mới biết giá mới thì nó vô dụng. Hai là độ chính xác: sai một sản phẩm cũng làm lung lay niềm tin vào cả bản thử. Ba là an toàn: bản thử không được gửi thư thật cho khách, không được ghi số vào công cụ thống kê của trang thật, và không được hiện trên Google.
Cách làm
1. Ba lớp, mỗi lớp bù chỗ hở của lớp trước
Mình không tin vào một cơ chế duy nhất, nên xây ba lớp.
Lớp đẩy khi lưu là lớp chính. Khi nhân viên lưu một sản phẩm, giá, tồn kho hay đơn trên trang thật, trang thật gửi một thông báo nhỏ sang bản thử, và bản thử tự kéo đúng mục đó về. Theo sổ vận hành của mình thì mất khoảng 10 giây (mình chưa đo lại từng lần).
Lớp đối soát hằng đêm lúc 03:10 so lại giá và tồn kho của từng mục, và nạp lại những mục lệch.
Lớp chạy tay là một lệnh để kéo cả những thứ ít đổi: ảnh, khách hàng, đơn cũ, đánh giá, trang chủ, nhật ký.
2. Vì sao cần lớp đối soát
Mình phát hiện ra lớp đẩy khi lưu không đủ khi nhìn vào cách trang thật đổi giá. Đổi giá hàng loạt bằng công cụ nhập liệu không làm WordPress ghi lại giờ sửa của sản phẩm, nên các cơ chế dựa vào giờ sửa bỏ sót. Lớp đối soát bù đúng chỗ này. Nó tạo một dấu vân tay ngắn từ giá, giá gốc, giá giảm, tồn kho, trạng thái kho và mã hàng của từng sản phẩm, trên cả hai phía, rồi chỉ nạp lại những mục có hai dấu vân tay khác nhau.
3. Khớp theo ID, không khớp theo mã hàng
Đây là lỗi đắt nhất mình gặp. Ban đầu bản thử tìm sản phẩm tương ứng theo mã hàng (SKU). Nhưng trên trang thật có 135 mã hàng bị trùng (271 sản phẩm), và 1.297 sản phẩm không có mã hàng nào (số ngày 02/08/2026). Khi hai sản phẩm khác nhau cùng một mã, bản thử vớ trúng sản phẩm đầu tiên rồi ghi đè lên nó. Nhật ký vẫn báo thành công. Chuyện này xảy ra hai lần với cùng một cặp ổ cứng.
Cách sửa là đưa ID sản phẩm trên bản thử về bằng đúng ID trên trang thật, rồi khớp theo ID. Sản phẩm tạo riêng trên bản thử dùng dải ID lớn hơn hai triệu, nên không bao giờ đụng ID của trang thật.
4. Bản thử phải vô hại
Bản thử có các chốt chặn riêng. Thư gửi ra bị chặn, kể cả thư qua dịch vụ gửi mail ngoài. Mã theo dõi của công cụ thống kê bị tắt để không làm bẩn số liệu của trang thật. Trang có thẻ báo cho Google đừng lập chỉ mục, và các bot thu thập dữ liệu bị từ chối ở máy chủ web. Với khách hàng, bản thử kéo toàn bộ danh sách từ trang thật, và tự dừng nếu thấy có tài khoản chỉ tồn tại trên bản thử, để không xóa nhầm.
Kết quả
Số đo ở đây lấy từ nhật ký đối soát của chính hệ thống, không phải từ một bài kiểm riêng.
Trước: ghi chú trong mã đối soát cho biết đến ngày 02/08/2026 phép khớp theo mã hàng bỏ sót 1.297 sản phẩm không có mã hàng. Sau: nhật ký đối soát 08/11/2026 cho 5.139 sản phẩm khớp 5.139 và 0 mục lệch; khớp theo ID nên sản phẩm không có mã hàng cũng được so. Hai số đến từ hai thời điểm và hai cách khớp, đọc như cỡ độ lớn.
Đêm 07/11 và đêm 08/11/2026, lớp đối soát chạy lúc 03:10 và so 5.139 sản phẩm cùng 213 biến thể. Cả hai đêm kết quả là 0 mục lệch.
Ngày 03/11/2026, mình xóa dữ liệu của bản thử và dựng lại từ trang thật. Việc đó gồm sản phẩm, đơn hàng, khách, danh mục, và tạo lại ảnh thu nhỏ cho 34.360 ảnh theo đúng kích cỡ của theme mới. Trước khi xóa mình đã sao lưu, và giữ riêng phần của bản thử như các trang, menu và cấu hình theme.
Có một điều mình chưa làm được. Theo rà soát của mình ngày 03/11/2026, lớp đẩy khi lưu chỉ gửi thông báo một lần, không thử lại và không ghi nhật ký. Nếu thông báo rơi mất, mục đó chỉ được vá khi lớp đối soát chạy, mà lớp này chỉ so giá và tồn kho. Sửa mô tả, đổi ảnh hay sửa danh mục thì phải chờ lần chạy tay.
Bài học
Một cơ chế đồng bộ tốt nhất vẫn có chỗ hở. Cái đáng làm là biết chỗ hở nằm đâu và đặt thêm một lớp canh đúng chỗ đó.
Khóa để ghép hai bản ghi phải là thứ không bao giờ trùng. Mã hàng nghe có vẻ là khóa tự nhiên, nhưng dữ liệu thật thì khác lý thuyết.
Nhật ký báo thành công chưa có nghĩa là đúng. Lỗi ghi đè nhầm ở trên kéo dài vì ai cũng tin dòng chữ "ok". Từ đó mình kiểm bằng dữ liệu của hai phía, không kiểm bằng lời báo của chính hệ thống.
Và bản thử phải được xây để vô hại: một lần quên chặn thư là một khách nhận thư thử.
Cần việc tương tự?
Nếu bạn có một trang bán hàng đang chạy và cần chỗ thử an toàn, hoặc dữ liệu giữa hai hệ thống đang lệch nhau mà chưa biết lệch từ đâu, gửi mình vài dòng về hệ thống đó. Mình sẽ xem cách hai bên đang nói chuyện với nhau trước, rồi nói rõ chỗ nào đáng sửa.
