Kiểm thử phục hồi & chuyển đổi dự phòng (Recovery & Failover Testing) cho hệ ngân hàng lõi

1. Tóm tắt nhanh & màn hình giao dịch bạn sẽ test

Nếu bạn đã quen thiết kế ca kiểm thử cho luồng nghiệp vụ đúng, chương này đưa bạn sang một lớp rủi ro khác: điều gì xảy ra khi HẠ TẦNG — không phải nghiệp vụ — gặp sự cố đúng giữa lúc tiền đang di chuyển. Với một sàn thương mại điện tử, một lần failover lỗi có thể chỉ gây gián đoạn vài phút; với hệ ngân hàng lõi, cùng một lỗi có thể khiến tiền của khách 'biến mất' tạm thời hoặc bị trừ hai lần — hai kịch bản có thể kéo theo khiếu nại, kiểm toán và mất niềm tin khách hàng. Chúng ta sẽ học qua hệ thống chuyển khoản của CoreBank: từ khái niệm RTO/RPO, sơ đồ trạng thái failover, tới các bộ ca kiểm thử cụ thể cho mất mạng, ngắt DB và toàn vẹn dữ liệu.

2. RTO, RPO & vì sao ngân hàng lõi cần kiểm thử phục hồi

Hai chỉ số nền tảng của mọi kế hoạch phục hồi thảm hoạ (Disaster Recovery) là RTO và RPO. RTO (Recovery Time Objective) là THỜI GIAN tối đa hệ thống được phép ngừng hoạt động, tính từ lúc sự cố xảy ra tới lúc phục hồi xong và sẵn sàng phục vụ trở lại. RPO (Recovery Point Objective) là lượng DỮ LIỆU tối đa được phép mất, tính theo khoảng thời gian trước sự cố — RPO = 5 giây nghĩa là dữ liệu ghi trong 5 giây cuối trước sự cố có thể bị mất, còn dữ liệu cũ hơn phải được bảo toàn. Với giao dịch tài chính, RPO thường phải gần bằng 0: mất dù một giao dịch cũng có thể là tiền thật của khách hàng biến mất.

Vì sao core banking đặc biệt cần kiểm thử phục hồi có hệ thống, không chỉ dựa vào tài liệu kiến trúc? Vì RTO/RPO trong tài liệu là con số MỤC TIÊU do đội kiến trúc/kiến trúc hạ tầng thiết kế, còn RTO/RPO THỰC TẾ chỉ lộ ra khi bạn thật sự gây sự cố và đo lại. Nhiều hệ thống có replication đồng bộ trên giấy nhưng khi đo thật lại có độ trễ vài giây; nhiều runbook failover chạy mượt trên môi trường test nhưng vượt SLA nhiều lần khi chạy ở production do dữ liệu lớn hơn, kết nối phức tạp hơn. Vai trò của tester ở đây không phải thiết kế hạ tầng, mà là ĐO và XÁC MINH những con số mà business đã cam kết với khách hàng và cơ quan quản lý.

3. Kiến trúc failover Primary→Standby & checklist lỗi kinh nghiệm

Trước khi thiết kế ca kiểm thử, tester cần hiểu rõ vòng đời một lần failover đi qua những trạng thái nào — không chỉ 'Primary hỏng, Standby lên thay' đơn giản. Sơ đồ dưới mô tả 6 trạng thái: Primary ACTIVE (bình thường) → Primary DOWN (sự cố xảy ra) → Standby PROMOTED (chuyển đổi, đo RTO tại đây) → Đối soát dữ liệu (kiểm tra giao dịch dở dang, đo khoảng dữ liệu mất so với RPO) → Primary phục hồi & resync (đồng bộ ngược dữ liệu ghi trong lúc Standby hoạt động) → Primary ACTIVE trở lại (failback hoàn tất). Mỗi mũi tên trong sơ đồ là một điểm cần có ca kiểm thử riêng, đặc biệt là cạnh nét đứt 'Dữ liệu ngoài RPO' — nơi dữ liệu có thể bị mất nếu sự cố xảy ra đúng lúc.

Từ sơ đồ này, ta xây một Defect Taxonomy — checklist lỗi kinh nghiệm dành riêng cho phục hồi/failover, tổng hợp từ các diễn tập DR (Disaster Recovery drill) và sự cố production đã ghi nhận. Khác với checklist chức năng thông thường, mỗi dòng trong bảng dưới trả lời câu hỏi 'lỗi này lộ ra ở TRẠNG THÁI nào trong vòng đời failover' — giúp tester biết chính xác nên gây sự cố vào lúc nào để tái hiện đúng loại lỗi cần tìm.

4. Quy trình thiết kế ca kiểm thử phục hồi có hệ thống

Kiểm thử phục hồi chuyên nghiệp không phải 'rút dây mạng rồi xem điều gì xảy ra' một cách ngẫu hứng. Nó cần một quy trình lặp lại được, có thể đo lường, và bàn giao lại cho đồng đội — đặc biệt quan trọng vì kiểm thử phục hồi thường đụng tới môi trường gần giống production, cần phối hợp chặt với đội vận hành (Ops/SRE).

▶ Bước 1: Xác định phạm vi & môi trường diễn tập: dùng môi trường staging/DR riêng có cấu hình Primary-Standby giống production, KHÔNG diễn tập trực tiếp trên production khi chưa có quy trình an toàn.