Diễn tập khôi phục một luồng nghiệp vụ: RPO, RTO và bẫy database đã về

Hội đồng quản trị hỏi: nếu datacenter có chuyện, bao lâu chạy lại? Câu trả lời thường nằm trên giấy: có DC2, có runbook, chưa ai bấm thử. Diễn tập cả hệ thống gần như không bao giờ được lên lịch, vì không ai ký cửa sổ dừng cho mọi bộ phận. Bài này thu hẹp xuống một luồng nghiệp vụ: vẽ phụ thuộc, kiểm tra Ceph RBD mirroring, diễn tập, đo RPO và RTO thật, rồi ghi bằng chứng kèm giới hạn để trình lên. Mùa cao điểm còn 4–5 tháng, đủ cho hai vòng.

RPO và RTO, nói cho đúng

Theo tài liệu Disaster Recovery of Workloads on AWS, RTO là “khoảng trễ tối đa chấp nhận được giữa lúc dịch vụ bị gián đoạn và lúc dịch vụ được khôi phục”; RPO là “khoảng thời gian tối đa chấp nhận được kể từ điểm khôi phục dữ liệu gần nhất”. Cả hai do tổ chức tự định ra.

RTO không kết thúc khi VM lên mà khi khách làm được việc: database đã về mà cổng thanh toán từ chối IP mới thì đồng hồ vẫn chạy. RPO là khoảng dữ liệu mà nghiệp vụ chấp nhận mất: 5 phút đơn hàng và 5 phút log có giá trị khác nhau.

Không phải luồng nào cũng cần dưới 15 phút; bảng dưới là ví dụ về cách đặt mục tiêu, không phải khuyến nghị:

Luồng	RPO mục tiêu	RTO mục tiêu
Đặt hàng và thanh toán	Vài phút	Dưới một giờ
Báo cáo nội bộ	Một ngày	Một ngày làm việc
Media tĩnh	Một ngày	Vài giờ

Chọn một luồng, không phải cả hệ thống

Tài liệu AWS có một câu đáng dán lên tường: “cách khôi phục duy nhất hoạt động là con đường bạn kiểm thử thường xuyên”. Chọn luồng có doanh thu trực tiếp, ít phụ thuộc bên ngoài, và có người nghiệp vụ sẵn sàng đặt đơn thử rồi ký biên bản; thiếu người này, kết quả chỉ là “VM đã lên”. Phạm vi hẹp cho phép lặp: thất bại ở vòng một là một kết quả tốt, vì nó lộ ra lỗ hổng trước khi sự cố thật xảy ra.

Vẽ phụ thuộc của luồng

Đây là bước lộ ra cái bẫy. Liệt kê mọi thứ luồng chạm vào, từ DNS đến cron:

Thành phần	Nằm ở đâu	Sang DC2 bằng gì	Ai xác nhận
Database đơn hàng	Volume Ceph RBD, DC1	RBD mirroring	Vận hành hạ tầng
Ứng dụng và API	VM OpenStack, DC1	Triển khai lại từ image	Đội ứng dụng
Hàng đợi	VM, DC1	Thường không mirror; dựng lại	Đội ứng dụng
Secret, khóa API	Vault hoặc file .env	Chưa rõ, phải kiểm tra	Bảo mật
DNS, chứng chỉ TLS	Nhà cung cấp DNS, TTL hiện tại	Đổi bản ghi, chờ hết TTL	Vận hành hạ tầng
IP whitelist cổng thanh toán	Phía đối tác	Đăng ký IP của DC2 từ trước	Nghiệp vụ, đối tác
Cron, cấu hình sửa tay	Một VM ở DC1	Chỉ tồn tại một nơi, dễ quên	Đội ứng dụng

Mỗi dòng cần một người ký, không phải một đội. Bốn dòng cuối là nơi RTO thật khác RTO trên giấy: database về, ứng dụng lên, nhưng cổng thanh toán từ chối IP lạ, hoặc khách còn trỏ về DC1 đến hết TTL.

Nhân bản dữ liệu bằng Ceph RBD mirroring

Trên Ceph, đĩa VM là RBD image; theo tài liệu Ceph, RBD mirroring có hai chế độ:

• Journal-based: mỗi lần ghi được đưa vào journal trước khi sửa image, cụm nhận replay journal đó. Bản sao nhất quán theo thời điểm (crash-consistent), nhưng độ trễ ghi “gần như tăng gấp đôi”.
• Snapshot-based: mirror-snapshot tạo theo lịch, cụm nhận sao chép phần khác biệt giữa hai snapshot. Lịch đặt bằng rbd mirror snapshot schedule add, tính bằng phút, giờ hoặc ngày.

Tài liệu không dùng từ RPO, nhưng hệ quả rõ: với snapshot-based, DC2 chỉ có dữ liệu đến mirror-snapshot gần nhất đã đồng bộ xong, “phần nào mới áp dụng một nửa sẽ bị rollback tại thời điểm failover”. Lịch 5 phút không đồng nghĩa RPO 5 phút nếu băng thông giữa hai datacenter không kịp chép hết phần khác biệt trong 5 phút.

Failover có trật tự theo tài liệu: dừng truy cập ở DC1, rbd mirror image demote ở DC1, rbd mirror image promote ở DC2, mở lại truy cập; RBD “chỉ cung cấp công cụ cần thiết”, ai dừng ứng dụng, ai đổi DNS là việc của runbook. Khi DC1 mất hẳn phải promote --force; tài liệu cảnh báo cách này tạo ra split-brain: hai bên không còn đồng bộ cho đến khi demote image cũ và chạy rbd mirror image resync. Failback vì thế là một lần đồng bộ theo chiều ngược.

Lưu ý Nhân bản block không thay backup. Xóa nhầm, bảng hỏng hay dữ liệu bị mã hóa ở DC1 đều được nhân bản sang DC2 như dữ liệu bình thường. Tài liệu AWS nói nhân bản liên tục “có thể không bảo vệ trước hỏng dữ liệu hay tấn công có chủ đích tốt bằng backup theo thời điểm”. Cần cả hai.

Kịch bản diễn tập: trước, trong, sau

Có hai kiểu diễn tập. Tabletop: ngồi đi qua runbook từng bước, tìm được lỗ hổng nhưng không đo được RTO. Chuyển thật một luồng sang DC2 trong giờ thấp điểm: chỉ cách này mới đo được RTO và RPO.

Trước: báo nghiệp vụ và đối tác thanh toán; chốt cửa sổ; chốt tiêu chí dừng, ví dụ “T+30 phút chưa đặt được đơn thử thì quay về DC1”; chốt ai quyết định failover; chốt cách mô phỏng: tắt dịch vụ ở DC1 (an toàn, không thử được promote --force) hay cắt hẳn kết nối DC1 (gần thật hơn, rủi ro hơn).

Trong: một incident commander, một người ghi biên bản, một người nghiệp vụ. Biên bản ghi T0, rồi T+x cho từng bước: promote xong, VM lên, DNS đổi, đơn thử thành công; mỗi bước ghi ai làm, tay hay tự động.

Sau: failback và resync, phần hay bị bỏ vì mọi người đã mệt. Chưa quay về DC1 thì mới chứng minh được một nửa.

Đo gì và ghi bằng chứng kèm giới hạn

Thứ trình hội đồng quản trị không phải “đã diễn tập thành công” mà là ba cột: điều đã chứng minh, bằng chứng, giới hạn của bằng chứng. Số đo tối thiểu: RTO từ T0 đến lúc đơn thử hoàn tất, có chữ ký nghiệp vụ; RPO là khoảng cách giữa bản ghi cuối ở DC1 trước T0 và bản ghi cuối có ở DC2; số bước làm tay; bước thất bại; và điều chưa được chứng minh.

Giới hạn của ví dụ Đây là ví dụ giả định về cấu trúc biên bản, không phải số đo thật, nên cố tình không ghi phút. Đã chứng minh: luồng đặt hàng hoàn tất ở DC2 sau khi tắt dịch vụ ở DC1; RTO và RPO đo được dưới mục tiêu. Giới hạn: tải thấp; chưa thử mất hẳn DC1 nên chưa thử promote --force; chưa thử failback; IP của DC2 mới thử với sandbox cổng thanh toán. Việc tiếp theo: vòng hai thử failback trước ngày khuyến mãi.

Thị trường đã trả giá để hỏi câu này

Sáng 24/3/2024, hệ thống của Chứng khoán VNDIRECT bị tấn công mạng; theo lãnh đạo công ty, dữ liệu bị mã hóa. Ngày 25/3, HNX và HoSE ngắt kết nối giao dịch với công ty. Việc mở lại đi theo giai đoạn: tra cứu trạng thái và thông tin tài khoản trước, giao dịch tiền và chứng khoán sau. Thư chủ tịch gửi nhà đầu tư, báo chí đăng ngày 29/3, cho biết việc kết nối trở lại được các cơ quan chức năng kiểm soát chặt chẽ. Sáng 1/4/2024, hai sở thông báo kết nối lại, trên cơ sở báo cáo đã khắc phục xong và hệ thống đã qua các bước kiểm tra.

Bài không bàn nguyên nhân hay cách xử lý của VNDIRECT, chỉ ghi hình dạng của quá trình khôi phục: tính bằng ngày, theo từng luồng, bước cuối do bên thứ ba kiểm tra.

Ví dụ: Funtap

Funtap chạy tải nền trên Private Cloud OpenStack ở hai datacenter tại Việt Nam, 46 node gồm 6 controller, 28 compute, 12 node Ceph. DC1 là primary; DC2 là cụm OpenStack đầy đủ ở chế độ dự phòng nóng, nhận bản sao dữ liệu Ceph từ DC1. Theo số liệu Funtap cung cấp, mục tiêu kiến trúc đã đạt là RPO dưới 5 phút, RTO dưới 15 phút, uptime 99,95%.

Giới hạn của ví dụ Đây là mục tiêu kiến trúc đã đạt theo số liệu khách hàng cung cấp; bài không công bố chi tiết từng lần diễn tập của Funtap. Luồng chính của game ít phụ thuộc bên ngoài hơn luồng thanh toán qua nhiều cổng, nên con số này không chuyển thẳng sang bạn.

Việc cần làm trong 4 tuần tới

1. Tuần 1: chọn luồng. Doanh thu trực tiếp, có người nghiệp vụ tham gia, RPO và RTO mục tiêu do nghiệp vụ đặt.
2. Tuần 1–2: vẽ phụ thuộc. Bảng như trên, mỗi dòng một người ký; đăng ký IP của DC2 với cổng thanh toán ngay.
3. Tuần 2: kiểm tra mirroring. rbd mirror image status cho các image của luồng, rbd mirror snapshot schedule ls --recursive để xem lịch, và daemon rbd-mirror ở DC2 đang chạy.
4. Tuần 3: runbook một trang và tabletop. Mỗi bước ghi ai làm, lệnh gì, biết xong bằng gì; chốt tiêu chí dừng.
5. Tuần 4: diễn tập thật một luồng trong giờ thấp điểm, ghi biên bản kèm giới hạn; đặt lịch vòng hai thử failback trước mùa cao điểm.

Kiến trúc hai datacenter với dữ liệu nhân bản là bài toán Hybrid & DR trong trang giải pháp; diễn tập khôi phục là một dòng trong bảng phân công của cả ba mô hình vận hành.