DataOps nâng cao 30 — DR & Business Continuity cho nền tảng dữ liệu

Vì sao DR & BCP là bắt buộc với nền tảng dữ liệu ngân hàng

Ta đã bàn về độ tin cậy vận hành: observability (DataOps nâng cao 6), SLA và data downtime (DataOps nâng cao 22). Nhưng những bài đó xử lý sự cố thường ngày — một pipeline trễ, một bảng lệch số. Bài này xử lý sự cố thảm hoạ: mất cả một data center, ransomware mã hoá toàn bộ warehouse, một câu DELETE xoá nhầm bảng lõi lúc 2 giờ sáng.

Với ngân hàng, đây không phải lựa chọn kỹ thuật mà là nghĩa vụ tuân thủ. Ngành có yêu cầu về liên tục hoạt động (business continuity) và khôi phục sau thảm hoạ; NHNN kỳ vọng tổ chức có kế hoạch, có diễn tập, có bằng chứng đối soát sau khôi phục. Nền tảng dữ liệu — nơi sinh báo cáo tuân thủ, số dư, giao dịch — nằm trong phạm vi đó. Câu hỏi không phải "có cần DR không" mà là "RTO/RPO của từng data product là bao nhiêu, và ta đã chứng minh khôi phục được chưa".

Ba khái niệm hay bị nhập nhằng: Backup vs DR vs BCP

Rất nhiều đội nói "chúng tôi có backup rồi" và tưởng thế là đủ. Ba thứ này khác nhau về phạm vi:

Cách nhớ: backup là artifact, DR là khả năng kỹ thuật dùng backup + hạ tầng để đứng dậy, BCP là khả năng tổ chức để nghiệp vụ không đứt trong lúc DR đang chạy. Một đội có backup đầy đủ nhưng chưa bao giờ test restore, không có runbook, không phân vai — về bản chất không có DR, chỉ có ảo giác an toàn.

Những rủi ro cần phòng — không chỉ "cháy data center"

Mọi người hình dung thảm hoạ là động đất, hoả hoạn. Thực tế phần lớn sự cố mất dữ liệu đến từ trong nhà:

• Mất vùng / data center: hỏng phần cứng, mất điện diện rộng, mất kết nối cả một region cloud.
• Corruption (hỏng dữ liệu): lỗi phần cứng, bug engine, bản ghi hỏng lan theo bản backup nếu backup lấy cả phần hỏng.
• Xoá nhầm (human error): DROP TABLE/DELETE không WHERE, chạy nhầm script prod trên staging tưởng, terraform destroy nhầm workspace. Đây là nguyên nhân số một trong thực tế.
• Ransomware: mã hoá cả storage lẫn backup nếu backup nằm cùng account/credential. Ransomware hiện đại săn tìm và xoá backup trước.
• Lỗi pipeline làm hỏng bảng: một model dbt sai logic ghi đè bảng fact bằng dữ liệu rác, một backfill sai khoảng ngày. Bảng "vẫn còn" nhưng nội dung sai — khó phát hiện hơn mất bảng.
• Mất metadata / mã: mất định nghĩa dbt project, DAG Airflow, catalog/metastore. Dữ liệu còn nguyên nhưng không ai biết bảng nghĩa là gì, pipeline dựng lại thế nào.

Điểm mấu chốt: DR cho dữ liệu phải phòng cả sáu, không chỉ mất vùng. Đặc biệt corruption/xoá nhầm cần backup có lịch sử điểm thời gian (point-in-time), vì backup mới nhất có thể đã chứa dữ liệu hỏng.

RTO & RPO: hai con số quyết định mọi thứ

Trước khi chọn công nghệ, phải đặt hai mục tiêu:

• RTO — Recovery Time Objective: thời gian tối đa chấp nhận được để khôi phục dịch vụ. "Sau sự cố, bao lâu báo cáo chạy lại?"
• RPO — Recovery Point Objective: lượng dữ liệu tối đa chấp nhận mất, tính theo thời gian. "Được phép mất bao nhiêu giờ dữ liệu mới nhất?" RPO 1 giờ nghĩa là backup/replication phải cách nhau tối đa 1 giờ.

RTO/RPO không đặt đồng loạt cho cả nền tảng — chi phí sẽ khủng khiếp. Đặt theo mức quan trọng của từng data product (tiering):

Con số ở bảng là minh hoạ — mỗi tổ chức tự thoả thuận với nghiệp vụ và ghi vào chính sách. Nguyên tắc: RTO/RPO càng khắt khe thì chi phí càng cao, nên đừng gán Tier 0 cho mọi thứ.

Bốn chiến lược DR: đánh đổi chi phí và tốc độ

Đây là phổ chuẩn của DR, xếp theo chi phí tăng dần và RTO/RPO giảm dần. Việc chọn chiến lược là bài toán chi phí vs độ tin cậy — xem thêm Cloud 7 — Chi phí & độ tin cậy:

Với nền tảng dữ liệu (analytics), active-active hiếm khi cần vì đây không phải hệ giao dịch online. Warm-standby cho Tier 0 và backup-restore/pilot-light cho phần còn lại thường là điểm cân bằng hợp lý về chi phí.

Backup thực chiến: dữ liệu là chưa đủ

Sai lầm kinh điển: chỉ backup dữ liệu, quên metadata và mã. Khi thảm hoạ tới, bạn có 10TB dữ liệu nhưng không biết nó là gì và pipeline dựng lại ra sao. Cần backup ba lớp:

1. Dữ liệu (warehouse / lakehouse)

Sao lưu bảng vật lý. Với lakehouse (Delta/Iceberg/Hudi trên object storage), dữ liệu là file Parquet + transaction log; bật cross-region replication của object storage là có RPO thấp gần như miễn phí về công sức. Với warehouse truyền thống, dùng snapshot/export theo lịch + giữ nhiều điểm thời gian.

2. Metadata & catalog

• Metastore / catalog (Hive metastore, Glue, Unity Catalog): backup định kỳ. Mất metastore = mọi bảng biến thành đống file vô nghĩa.
• Định nghĩa nghiệp vụ: mô tả bảng, lineage, chủ sở hữu, phân loại PII.

3. Mã — và đây là insight quan trọng nhất

Mã đã version trong Git = một phần của DR. dbt project, DAG Airflow, Terraform/IaC, config, dbt tests, semantic layer — nếu tất cả ở Git thì bạn có thể dựng lại toàn bộ pipeline ở vùng mới bằng cách clone repo và chạy. Đây là lý do reproducibility (khả năng tái tạo) chính là DR: mã tái tạo được dữ liệu dẫn xuất, nên bạn chỉ cần backup dữ liệu nguồn (raw), còn các lớp staging/mart có thể build lại từ mã.

Nguyên tắc vàng: Backup không được test = không tồn tại. Rất nhiều đội có backup chạy đều đặn nhưng chưa từng restore thử — đến khi cần thì phát hiện file backup hỏng, thiếu quyền, hoặc quy trình khôi phục sai. Phải kiểm thử khôi phục định kỳ (ví dụ hằng quý restore vào môi trường sandbox và đối soát).

Lakehouse giúp DR như thế nào

Kiến trúc lakehouse cho vài "siêu năng lực" DR gần như miễn phí, đặc biệt để chống corruption và xoá nhầm:

• Time Travel / versioning: mỗi lần ghi tạo một version. Bảng bị pipeline lỗi ghi đè rác? Chỉ cần RESTORE về version trước sự cố — khôi phục trong giây, không cần restore từ backup. Đây là lá chắn trực tiếp cho rủi ro "pipeline làm hỏng bảng".
• Replication ở tầng object storage: cross-region replication cho RPO thấp mà không cần công cụ backup riêng.
• Snapshot rẻ: giữ nhiều điểm thời gian với chi phí thấp nhờ chỉ lưu delta.

Time Travel liên hệ chặt với mẫu Write-Audit-Publish (DataOps nâng cao 11): WAP chặn dữ liệu xấu trước khi publish, còn Time Travel giúp lùi lại nếu dữ liệu xấu đã lỡ publish. Hai lớp bổ sung nhau.

Lưu ý: Time Travel có giới hạn thời gian lưu (retention) và không thay thế backup cross-region — nó không cứu được khi mất cả vùng hay bị ransomware xoá cả log.

Immutable / WORM & phòng ransomware

Ransomware nhắm vào backup. Phòng thủ:

• Immutable / WORM (Write Once Read Many): backup ghi xong thì không thể sửa/xoá trong khoảng retention, kể cả bằng credential admin. Object lock của object storage cho phép điều này.
• Cô lập credential: backup nằm ở account riêng, key riêng, kẻ tấn công chiếm được production không với tới được backup ("air-gap logic").
• Giữ nhiều điểm thời gian: nếu backup gần nhất đã dính mã hoá, còn điểm cũ sạch để lùi về.
• Quy tắc 3-2-1: 3 bản sao, 2 loại phương tiện, 1 bản off-site/cô lập.

Khôi phục pipeline: reproducibility chính là DR

Khôi phục dữ liệu mới là một nửa. Nửa còn lại là dựng lại pipeline để tiếp tục sản xuất. Vì mã ở Git:

1. Clone repo (dbt project, DAG, IaC) ở vùng/hạ tầng mới.
2. Chạy IaC dựng lại infrastructure (Terraform apply).
3. Restore dữ liệu nguồn (raw) từ backup.
4. Chạy lại pipeline build lại các lớp staging/mart từ raw.
5. Đối soát control-total để chứng minh dữ liệu khôi phục đúng.

Điều này chỉ chạy được nếu pipeline idempotent (chạy lại cho cùng kết quả, không nhân đôi) và hỗ trợ backfill (chạy lại theo khoảng ngày). Xem DataOps nâng cao 8 — case study ngân hàng về cách thiết kế mô hình chạy lại được. Idempotent + backfill là điều kiện để bước 4 an toàn: bạn có thể chạy lại toàn bộ lịch sử mà không sợ dữ liệu bị nhân đôi hay lệch.

Đối soát sau khôi phục: control-total

Sau restore, câu hỏi kiểm toán đầu tiên: "Làm sao chứng minh dữ liệu khôi phục khớp dữ liệu trước sự cố?" Cách chuẩn là so control-total — một tổng bất biến (số dòng, tổng số dư theo currency) chụp trước sự cố và tính lại sau restore. Nếu khớp từng nhóm, dữ liệu toàn vẹn.

Ví dụ minh hoạ trên sandbox — tính control-total tổng số dư và số tài khoản theo loại tiền, để so số này trước/sau khi restore:

-- ▶ Chạy được
SELECT
  currency,
  COUNT(*)                              AS so_tai_khoan,
  ROUND(SUM(balance)::numeric, 2)       AS tong_so_du,
  ROUND(AVG(balance)::numeric, 2)       AS so_du_tb
FROM accounts
GROUP BY currency
ORDER BY tong_so_du DESC;

Chụp kết quả này thành "control snapshot" trước khi có sự cố. Sau khi restore, chạy đúng câu trên và so từng dòng: cùng so_tai_khoan và tong_so_du theo mỗi currency nghĩa là bảng accounts khôi phục toàn vẹn. Kỹ thuật này áp dụng được cho mọi bảng lõi (thêm tổng theo transactions.kind, đếm khách theo customers.city, v.v.) và là bằng chứng đối soát để trình kiểm toán.

BCP: quy trình vận hành khi sự cố

DR là kỹ thuật; BCP là tổ chức. Khi thảm hoạ xảy ra, con người cần biết ai làm gì:

• Runbook DR: tài liệu từng-bước để khôi phục từng hệ thống. Ai bấm nút failover, restore theo thứ tự nào, kiểm tra ra sao. Runbook phải nằm ở nơi truy cập được khi hệ thống chính chết (không thể để runbook trên chính wiki đang down).
• Vai trò & escalation: Incident Commander điều phối, người khôi phục kỹ thuật, người liên lạc nghiệp vụ/kiểm toán, người ra quyết định (declare disaster).
• Ưu tiên hệ thống trọng yếu: khôi phục theo tier — Tier 0 (báo cáo tuân thủ, số dư) trước, Tier 2 (marketing mart) sau. Không được phân tán nguồn lực đều.
• Phương án nghiệp vụ tạm thời: trong lúc DR chạy, nghiệp vụ chạy tiếp thế nào (báo cáo thủ công từ dữ liệu nguồn, hoãn dashboard không trọng yếu).

Tuân thủ ngân hàng & kiểm thử DR (game day)

Ngành ngân hàng không chỉ yêu cầu có kế hoạch DR/BCP mà còn yêu cầu bằng chứng vận hành được:

• Kiểm thử khôi phục định kỳ: restore backup vào sandbox theo lịch, đối soát control-total, lưu log.
• Game day / diễn tập DR: chủ động giả lập thảm hoạ (tắt một vùng, giả định mất bảng lõi) và cho đội thực hiện khôi phục có bấm giờ. Đây là cách duy nhất biết RTO/RPO thực tế so với mục tiêu.
• Đo lường: sau mỗi game day, ghi RTO/RPO đạt được thực tế. Nếu mục tiêu 4 giờ mà diễn tập mất 9 giờ → chiến lược chưa đủ, cần nâng cấp (từ backup-restore lên warm-standby chẳng hạn).
• Đối soát sau khôi phục: bắt buộc trình bằng chứng control-total khớp trước/sau, phục vụ kiểm toán nội bộ và NHNN.

Việc đo và diễn tục này liên hệ với vận hành production nói chung — xem K8s 8 — Production ops về failover và diễn tập ở tầng hạ tầng.

Use case thực tế

Bối cảnh: NCB có nền tảng lakehouse trên object storage phục vụ báo cáo tuân thủ NHNN (Tier 0). Ban lãnh đạo chốt RTO ≤ 4 giờ, RPO ≤ 15 phút cho nhóm bảng báo cáo.

Thiết kế DR được triển khai:

1. Dữ liệu: bật cross-region replication object storage (region phụ). RPO thực tế ~5 phút → đạt mục tiêu 15 phút.
2. Metadata: Unity Catalog backup mỗi giờ; định nghĩa bảng và lineage xuất ra Git.
3. Mã: toàn bộ dbt project + DAG + Terraform ở Git, mirror sang repo dự phòng. Pipeline idempotent, hỗ trợ backfill theo data_interval.
4. Chiến lược: warm-standby — một cluster thu nhỏ luôn chạy ở region phụ, scale-up khi failover.
5. Chống ransomware: backup ở account riêng, bật object lock (WORM) retention 35 ngày, giữ 30 điểm thời gian.

Game day (quý 2): đội giả lập mất region chính lúc 9h sáng. Kết quả đo:

Phát hiện: bước restore metadata ban đầu bị kẹt quyền IAM ở region phụ — đã sửa runbook. Nếu không diễn tập, sự cố thật sẽ vỡ mục tiêu RTO. Đúng như nguyên tắc: backup và DR chưa test = chưa có.

Ghi nhớ

• Backup ≠ DR ≠ BCP: backup là bản sao dữ liệu; DR là khả năng kỹ thuật dựng lại hệ thống; BCP là khả năng tổ chức để nghiệp vụ không đứt. Có backup không nghĩa là có DR.
• Phòng cả sáu rủi ro: mất vùng, corruption, xoá nhầm, ransomware, pipeline hỏng bảng, mất metadata/mã. Xoá nhầm và pipeline lỗi là phổ biến nhất, cần lịch sử point-in-time.
• RTO (bao lâu khôi phục) và RPO (mất bao nhiêu dữ liệu) đặt theo tier của từng data product, không đặt đồng loạt — khắt khe hơn = đắt hơn.
• Bốn chiến lược đánh đổi chi phí/tốc độ: backup-restore → pilot-light → warm-standby → active-active. Analytics thường warm-standby cho Tier 0, backup-restore cho phần còn lại.
• Backup ba lớp: dữ liệu + metadata/catalog + mã ở Git. Mã đã version = một phần DR; reproducibility chính là DR.
• Lakehouse Time Travel khôi phục bảng bị pipeline làm hỏng trong giây; bổ sung (không thay thế) backup cross-region.
• Immutable/WORM + credential cô lập chống ransomware; quy tắc 3-2-1.
• Pipeline idempotent + backfill là điều kiện để build lại dữ liệu dẫn xuất từ nguồn.
• Đối soát control-total trước/sau restore là bằng chứng toàn vẹn cho kiểm toán.
• BCP cần runbook truy cập-được-khi-down, phân vai, ưu tiên tier trọng yếu.
• Game day có bấm giờ là cách duy nhất biết RTO/RPO thực tế. Backup/DR không test = không tồn tại.