Runbook xử lý sai lệch khi hệ thống đối soát đang tự động

Hệ thống đang tự chạy nhưng cuối ngày có khoản tiền chưa gắn đơn, hai phiếu thu cho một giao dịch hoặc đơn đã giao vẫn chờ thanh toán. Lúc đó, chạy lại toàn bộ webhook có thể làm tình hình khó hơn: dữ liệu thiếu được bổ sung, còn nghiệp vụ đã làm lại bị kích hoạt thêm lần nữa.

Xử lý sai lệch giao dịch khi đối soát ngân hàng tự động cần một runbook giữ được bằng chứng và giới hạn tác động phục hồi. Bài viết trên hoadontudong.com.vn dành cho người trực vận hành cùng đội kỹ thuật: xác định phạm vi, lần theo trạng thái, chạy bù đúng bước và kiểm tra trước khi mở lại tác vụ.

Khoanh vùng bằng tài khoản, thời gian và tác động

Bắt đầu bằng các khoản cụ thể, không chỉ một tổng chênh. Ghi tài khoản, nguồn dữ liệu, khoảng thời gian, số giao dịch và giá trị ảnh hưởng. Đánh dấu những đơn đã giao, công nợ đã cập nhật hoặc khoản hoàn đang thực hiện để ưu tiên đúng.

Xác định sự cố đang tiếp diễn hay chỉ còn dữ liệu lịch sử. Nếu rule đang ghép sai, cần giới hạn tác động của rule đó; nếu nguồn chỉ thiếu một khoảng cũ, có thể tiếp tục luồng mới trong phạm vi được kiểm soát. Tắt toàn bộ nhận dữ liệu khi không cần có thể làm phần thiếu lớn hơn.

Chỉ định một đầu mối điều phối và người có quyền duyệt thao tác nghiệp vụ. Đội kỹ thuật giữ trạng thái kết nối, người phụ trách đối soát xác nhận khoản tiền và bộ phận bán hàng giữ thông tin hàng hóa. Một quyết định chạy bù cần biết nó có thể ảnh hưởng tới bước nào.

Giữ bằng chứng trước khi sửa hoặc gửi lại

Lưu bản ghi nguồn, payload hoặc báo cáo phù hợp, log tiếp nhận, quyết định matching và trạng thái đơn. Giữ phiên bản cấu hình tại thời điểm phát sinh. Nếu sửa mapping rồi chỉ lưu kết quả mới, đội điều tra sẽ mất căn cứ giải thích vì sao lần trước đi sai.

Che khóa, token và thông tin cá nhân không phục vụ điều tra khi chia sẻ log. Các định danh liên kết nên đủ để lần từ giao dịch nguồn tới đơn và tác vụ. Không cần đưa toàn bộ số dư hoặc lịch sử khách vào một ticket chỉ vì dễ sao chép.

Với lớp kết nối Pay2S, có thể rà calls, log và lỗi API. Cần giữ cả lỗi nghiệp vụ của ứng dụng nhận, vì request đã tới không chứng minh dữ liệu đã lưu hoặc đơn đã cập nhật.

Lần theo chuỗi trạng thái để tìm bước đứt

Đi từ nguồn xác nhận giao dịch tới lớp nhận, staging, phân bổ, đơn và tác vụ sau thanh toán. Mỗi bước cần bằng chứng đã hoàn tất. Không suy kết quả của bước sau chỉ từ response thành công ở bước trước.

Webhook ngân hàng và IPN đơn có hợp đồng khác nhau. Bài luồng biến động số dư giúp xác định nguồn khoản thu; khi điều tra Collection Link, cần xem riêng IPN và dữ liệu đơn đã lưu.

Phân biệt dữ liệu gửi lại với tiền nhận hai lần

Hai thông báo cùng định danh nguồn có thể là retry hoặc replay. Chúng nên nối về một giao dịch. Hai giao dịch thật khác định danh cho cùng đơn lại có thể là khách trả hai lần và cần giữ cả hai để xử lý thu thừa.

Không xóa record chỉ vì cùng số tiền, thời gian gần hoặc nội dung giống nhau. Kiểm tra phạm vi định danh theo nguồn và tài khoản. Nếu dữ liệu đến từ API, webhook và file, cần quan hệ đối chiếu được xác minh giữa các nguồn, không hợp nhất bằng cảm giác.

Khi đã có nghiệp vụ trùng, giữ bản gốc và tạo điều chỉnh theo quyền được duyệt. Xóa dấu vết có thể làm tổng tạm khớp nhưng khiến khoản tiền không còn giải thích được. Cách sửa chứng từ đã ghi nhận phụ thuộc hệ thống và quy trình doanh nghiệp.

Chọn thao tác phục hồi nhỏ nhất đủ để giải quyết

Nếu chỉ thiếu bản ghi nguồn, bổ sung dữ liệu qua cơ chế được hỗ trợ rồi cho đi qua cùng validation. Nếu giao dịch đã lưu nhưng matching lỗi, chạy lại phần matching sau khi sửa căn cứ. Nếu chỉ email hoặc tác vụ giao vận lỗi, phục hồi đúng tác vụ đó thay vì xử lý thanh toán từ đầu.

Tài liệu webhook Pay2S có lịch sử gửi và chức năng gửi lại. Trước khi dùng, xác nhận endpoint nhận đã sẵn sàng và biết những tác động nào sẽ được kích hoạt. Tài liệu IPN cùng SDK cũng yêu cầu merchant kiểm tra dữ liệu và chống xử lý lại bằng database.

Với Collection Link, hướng dẫn tiếp nhận IPN giúp rà điều kiện. Replay không được thay số tiền kỳ vọng bằng chính payload hoặc bỏ kiểm tra trạng thái chỉ để request lần này đi qua.

Chạy bù theo lô có checkpoint và kiểm tra kết quả chưa rõ

Chọn phạm vi nhỏ, lưu danh sách đầu vào và checkpoint. Sau mỗi lô, kiểm tra giao dịch được bổ sung, khoản đã phân bổ và tác vụ phát sinh. Nếu có lỗi, biết lô nào còn chờ thay vì phải gửi lại toàn bộ khoảng thời gian.

Giữ timestamp nguồn khi nhập bù. Thời gian nhận lại hôm nay không làm giao dịch trở thành khoản phát sinh hôm nay. Khoảng lọc và phân trang phải đủ; chuyển checkpoint chỉ sau khi dữ liệu tương ứng được lưu bền vững.

Timeout khi gọi hệ thống khác là kết quả chưa rõ. Nghiệp vụ có thể đã được tạo; giữ định danh gốc và truy trạng thái theo cơ chế hỗ trợ trước khi gửi lại. Tạo request mới với mã mới có thể biến phục hồi thành một lần tạo trùng.

Các kiểm soát trong vận hành chống xử lý trùng cần áp ở cả dữ liệu nhận và tác vụ phía sau. Một khóa nguồn duy nhất chưa đủ nếu worker vẫn tạo chứng từ mới mỗi lần chạy.

Đừng khôi phục toàn bộ database để sửa một khoản lệch

Trong lúc điều tra, giao dịch mới có thể vẫn đến và nhân viên vẫn thực hiện đơn. Đưa toàn bộ dữ liệu về một bản cũ có thể làm mất những sự kiện hợp lệ sau đó. Cần đánh giá phạm vi và chọn điều chỉnh theo đối tượng, theo kế hoạch được duyệt.

Nếu phải dùng bản sao dữ liệu để so sánh, giữ nó ở môi trường phù hợp và bảo vệ thông tin. Kết quả điều tra cần chỉ ra bản ghi nào được thay đổi, tác động nào đã xảy ra và cách khôi phục tương ứng. Không tự xóa log hoặc đổi ngày giao dịch để làm báo cáo giống trước sự cố.

Khi chứng từ đã khóa hoặc hàng đã giao, phối hợp người có quyền nghiệp vụ. Công việc kỹ thuật là giữ và thực hiện quyết định có kiểm soát, không tự chọn cách đảo mọi tác động chỉ từ trạng thái ngân hàng.

Xác nhận phục hồi ở cả dữ liệu và công việc

So nguồn với dữ liệu nhận theo định danh và phạm vi tài khoản. So phân bổ với đơn/công nợ, rồi so các tác vụ phải thực hiện với kết quả thực. Tổng tiền khớp vẫn chưa đủ nếu một khoản gán nhầm hoặc một phiếu giao hàng được tạo hai lần.

Kiểm tra những ngoại lệ chưa giải quyết có người nhận việc và lý do. Một incident không nên bị đánh dấu xong chỉ vì queue rỗng; worker có thể đã đưa lỗi sang nơi khác hoặc bỏ qua record. Người phụ trách cần nhìn cả giá trị ảnh hưởng còn lại.

Lấy vài trường hợp đã lỗi để kiểm tra xuyên suốt cùng đội vận hành. Nếu khách cần cập nhật kết quả, thông tin phải dựa trên trạng thái đã xác minh. Đừng gửi hàng loạt thông báo thành công chỉ vì job phục hồi kết thúc.

Mở lại theo phạm vi đã được kiểm tra

Nếu đã dừng một rule hoặc tác vụ, mở lại ở nhóm nhỏ và quan sát các khoản mới. Đảm bảo cấu hình đang áp là phiên bản đã thử, không phải bản tạm trong lúc điều tra. Giữ khả năng dừng phần tác động mà vẫn lưu dữ liệu nguồn.

Theo dõi thêm backlog cũ và giao dịch mới để tránh hai nhóm cùng tranh xử lý một khoản. Những trường hợp cần duyệt tay vẫn giữ ở ngoại lệ, không bật một điều kiện rộng hơn chỉ để kết thúc incident nhanh.

Ghi mốc mở lại, phạm vi và đầu mối nhận cảnh báo. Người trực ca sau cần biết điều gì đã sửa, điều gì còn đang quan sát và khi nào chuyển trách nhiệm. Một bàn giao rõ sẽ giảm nguy cơ cùng vấn đề bị điều tra lại từ đầu.

Biến nguyên nhân thành một kiểm soát cụ thể

Phân biệt tác nhân kích hoạt với nguyên nhân gốc. Deploy có thể làm endpoint ngừng, nhưng thiếu cơ chế lưu/đối soát mới khiến dữ liệu mất. Khách ghi sai nội dung có thể tạo ngoại lệ, nhưng rule ghép theo tiền mới là nguyên nhân khoản đó được xác nhận sai.

Sau sự cố, bổ sung test hồi quy, cảnh báo và người sở hữu kiểm soát tương ứng. Test cần tái hiện tác động sai từng xảy ra, không chỉ kiểm tra endpoint trả 200. Theo dõi lại sau một khoảng vận hành để biết biện pháp đã giảm nguy cơ tái diễn hay chưa.

Một runbook tốt giúp nhóm xử lý trả lời được ba điều: khoản tiền nào bị ảnh hưởng, bước nào đã hoàn tất và bước nào còn cần làm. Khi giữ được những câu trả lời đó trong dữ liệu, phục hồi sẽ bớt phụ thuộc vào trí nhớ của người trực sự cố.