title: "Disaster Recovery: Dùng AI lập kế hoạch backup & failover"
series: "AI-Native Solutions Architect: Từ Coder đến Kiến trúc sư AI"
season: "Season 2 — AI-Augmented Architecture & System Design"
order: 19
audience: "Software Engineer hướng tới Solutions Architect"
reading_time: "13 phút"
tags: ["disaster-recovery", "rto-rpo", "backup-strategy", "failover", "business-continuity", "ai-architecture"]

Disaster Recovery: Dùng AI lập kế hoạch backup & failover

2 giờ sáng, một kỹ sư chạy nhầm migration trên production, xoá mất một bảng dữ liệu khách hàng quan trọng. Team lao vào tìm bản backup gần nhất — và phát hiện ra job snapshot tự động đã âm thầm lỗi 9 ngày liên tiếp vì một thay đổi IAM policy không ai để ý. Bản backup "gần nhất" thực chất là của 9 ngày trước. 9 ngày dữ liệu giao dịch, đơn hàng, thanh toán — biến mất vĩnh viễn.

Đây không phải kịch bản hư cấu để doạ bạn — đây là mẫu số chung của phần lớn sự cố mất dữ liệu nghiêm trọng trong thực tế: không phải vì thiếu backup, mà vì backup có tồn tại nhưng chưa từng được kiểm chứng là dùng được, và kế hoạch phục hồi chỉ được viết ra sau khi sự cố đã xảy ra — lúc đó thì quá muộn, thứ bạn đang làm gọi là "khắc phục hậu quả", không còn là "disaster recovery" theo đúng nghĩa chuẩn bị trước.

Vấn đề mang tính hệ thống: Disaster Recovery (DR) là một trong số ít hạng mục kiến trúc mà chi phí đầu tư luôn "cảm giác lãng phí" cho đến đúng một ngày nó là thứ duy nhất cứu công ty. Vì cảm giác đó, DR thường bị đẩy xuống cuối backlog, giao cho một junior "làm cho có", hoặc bị bỏ qua hoàn toàn cho tới khi có sự cố thật. Bài này nói về cách dùng AI để xây dựng DR plan một cách có hệ thống, theo khung RTO/RPO, và quan trọng không kém — cách tránh cái bẫy lớn nhất: một kế hoạch DR đẹp trên giấy nhưng chưa từng được diễn tập.

Vấn đề

Ba dạng sai lầm phổ biến khiến DR chỉ tồn tại trên giấy, không tồn tại trong thực tế:

1. Nhầm lẫn giữa "có backup" và "có DR plan". Bật snapshot tự động cho RDS, cấu hình versioning cho S3 bucket — đó là điều kiện cần, không phải điều kiện đủ. DR plan phải trả lời được: khi sự cố xảy ra, ai là người quyết định failover, quyết định trong bao lâu, restore theo quy trình nào, và làm sao biết restore đã đúng và đủ.

2. Không định lượng được mức độ chấp nhận rủi ro. Câu hỏi "hệ thống được phép downtime bao lâu?" và "được phép mất tối đa bao nhiêu dữ liệu?" hiếm khi có câu trả lời rõ ràng bằng số trước khi có sự cố. Không có con số, mọi quyết định kiến trúc (chọn multi-AZ hay single-AZ, chọn cross-region replication hay không, chọn snapshot mỗi giờ hay mỗi ngày) đều là đoán mò, và thường bị chi phối bởi ngân sách hơn là bởi rủi ro nghiệp vụ thực sự.

3. DR plan chưa từng được diễn tập (DR drill). Đây là cái bẫy nguy hiểm nhất, sẽ quay lại ở phần Cạm bẫy — một kế hoạch tồn tại trên Confluence, có sơ đồ đẹp, có danh sách bước thực hiện, nhưng chưa từng ai chạy thử phục hồi từ backup thật, trên môi trường thật. Cảm giác an toàn giả (false sense of security) này còn nguy hiểm hơn việc thẳng thắn thừa nhận "chúng ta chưa có DR plan", vì nó khiến team ngừng lo lắng về rủi ro mà lẽ ra vẫn đang tồn tại nguyên vẹn.

Giải pháp không phải là một công cụ hay một dịch vụ cloud cụ thể — mà là một khung tư duy: định lượng rủi ro chấp nhận được bằng RTO/RPO, rồi thiết kế chiến lược backup/failover tương ứng, rồi bắt buộc kiểm chứng bằng drill thực tế theo lịch định kỳ.

Kỹ thuật cốt lõi

RTO và RPO — hai trục định lượng rủi ro chấp nhận được

RTO (Recovery Time Objective) — thời gian tối đa chấp nhận được, tính từ lúc sự cố xảy ra đến lúc hệ thống hoạt động trở lại. RTO = 1 giờ nghĩa là: nếu production sập lúc 2:00, hệ thống phải online lại chậm nhất 3:00, dù chỉ với chức năng tối thiểu.

RPO (Recovery Point Objective) — lượng dữ liệu tối đa chấp nhận mất, tính theo thời gian giữa lần backup/replicate gần nhất và thời điểm sự cố. RPO = 15 phút nghĩa là: sau khi phục hồi, dữ liệu có thể thiếu tối đa 15 phút giao dịch gần nhất so với thời điểm sập — không hơn.

timeline
    title Trục thời gian RTO/RPO khi sự cố xảy ra
    section Trước sự cố
        Lần backup/replicate gần nhất : điểm RPO — dữ liệu sau mốc này có nguy cơ mất
    section Sự cố xảy ra
        Hệ thống sập : t = 0
    section Sau sự cố
        Phát hiện + quyết định failover : phải nhanh
        Hệ thống online trở lại : deadline = RTO

Hai trục này không tồn tại độc lập — chúng quyết định trực tiếp chiến lược kỹ thuật và chi phí. Nguyên tắc chung: RTO/RPO càng ngắn, chi phí hạ tầng và độ phức tạp vận hành càng tăng theo cấp số nhân, không phải tuyến tính.

Việc chọn chiến lược nào không phải quyết định kỹ thuật thuần tuý — nó là quyết định kinh doanh: chấp nhận trả bao nhiêu tiền hạ tầng để đổi lấy bao nhiêu phút downtime tránh được. Đây chính xác là chỗ AI hỗ trợ tốt: khi được cho biết mục tiêu RTO/RPO cụ thể và kiến trúc hệ thống hiện tại, AI có thể liệt kê nhanh các kịch bản rủi ro dễ bị bỏ sót (không chỉ "server chết" mà còn "region outage", "xoá nhầm dữ liệu do lỗi người", "ransomware mã hoá cả backup"), và map từng kịch bản sang chiến lược phù hợp — nhưng quyết định đánh đổi chi phí/rủi ro cuối cùng vẫn phải là con người, vì AI không biết ngân sách thật, không biết mức độ chấp nhận rủi ro thật của doanh nghiệp bạn.

AI hỗ trợ ở đâu, và không hỗ trợ ở đâu

AI làm tốt: liệt kê đầy đủ kịch bản rủi ro (checklist đầy đủ hơn khi con người tự nghĩ do thiên kiến "chỉ nhớ sự cố từng gặp"), sinh runbook chi tiết theo template, sinh IaC config cho backup/replication theo best practice, review một DR plan có sẵn để tìm lỗ hổng logic (ví dụ: bước 3 phụ thuộc vào một service mà chính sự cố đang làm service đó down).

AI làm không tốt, hoặc không nên giao: quyết định RTO/RPO mục tiêu (đây là quyết định nghiệp vụ, cần input từ stakeholder không phải kỹ thuật), đánh giá chi phí thực tế của từng chiến lược trên hạ tầng cụ thể của bạn (AI không biết giá cloud provider bạn đang trả, không biết discount/reserved instance bạn đang có), và — quan trọng nhất — AI không thể thay bạn chạy DR drill thật. Một kế hoạch do AI viết ra chi tiết đến đâu vẫn chỉ là giả thuyết cho đến khi được kiểm chứng bằng hành động thật trên hệ thống thật.

Thực hành

Prompt mẫu: yêu cầu AI đề xuất DR plan với RTO 1 giờ, RPO 15 phút

Prompt dưới đây khai đầy đủ bối cảnh kỹ thuật, mục tiêu định lượng, và yêu cầu output có cấu trúc — áp dụng nguyên tắc "context đầy đủ" đã nói ở Bài 3:

Vai trò: Bạn là Solutions Architect giúp tôi xây dựng Disaster Recovery Plan
cho một hệ thống CRM backend production.

Bối cảnh hạ tầng hiện tại:
- Backend: NestJS chạy trên AWS ECS Fargate, 2 task tối thiểu, multi-AZ.
- Database: MySQL trên AWS RDS, hiện tại single-AZ, automated snapshot 1 lần/ngày.
- Cache/session: Redis (ElastiCache), không có replica.
- Message queue: RabbitMQ (self-managed trên EC2), không có backup định kỳ.
- File storage: AWS S3 cho tài liệu khách hàng, versioning đang TẮT.
- Hạ tầng quản lý bằng Terraform, region chính là ap-southeast-1 (Singapore).

Mục tiêu định lượng:
- RTO (Recovery Time Objective): tối đa 1 giờ cho toàn bộ hệ thống.
- RPO (Recovery Point Objective): tối đa 15 phút dữ liệu mất cho MySQL,
  tối đa 1 giờ cho các thành phần không giao dịch (cache, queue).

Yêu cầu:
1. Liệt kê tối thiểu 5 kịch bản rủi ro cụ thể (không chỉ "server chết") có thể
   ảnh hưởng đến hệ thống trên, xếp theo mức độ nghiêm trọng.
2. Với mỗi kịch bản, đề xuất chiến lược backup/failover cụ thể để đạt được
   RTO 1 giờ / RPO 15 phút, chỉ rõ thành phần AWS/công nghệ cần thay đổi
   so với hiện trạng (ví dụ: bật Multi-AZ cho RDS, bật point-in-time recovery).
3. Với kịch bản nghiêm trọng nhất, viết một runbook từng bước (ai làm gì,
   theo thứ tự nào, lệnh/cấu hình cụ thể) để team on-call có thể làm theo
   ngay trong lúc khủng hoảng mà không cần đọc tài liệu dài.
4. Chỉ ra khoảng cách (gap) cụ thể giữa hạ tầng hiện tại và mục tiêu RTO/RPO
   đã nêu — hiện tại đang KHÔNG đạt được mục tiêu ở những điểm nào.
5. Ước tính hạng mục nào cần thay đổi Terraform config, liệt kê resource
   cụ thể cần thêm/sửa.

Output dạng: bảng "Kịch bản rủi ro | RTO/RPO mục tiêu | Chiến lược backup/failover
| Bước thực hiện cụ thể", theo sau là 1 runbook chi tiết cho kịch bản nghiêm
trọng nhất, và 1 danh sách gap hạ tầng hiện tại.

Bảng kế hoạch DR — điền sẵn ví dụ

Đây là bảng kết quả mẫu, dạng bạn sẽ nhận được (đã biên tập lại cho gọn) sau khi chạy prompt trên, dùng được ngay làm điểm khởi đầu để team review:

Bảng trên chỉ là điểm khởi đầu — nhiệm vụ của kiến trúc sư là ngồi lại với AI để tinh chỉnh từng dòng theo hạ tầng thật, và quan trọng hơn, biến từng dòng "Bước thực hiện cụ thể" thành lệnh thật, đã test thật, không phải mô tả chung chung như "restore từ backup" mà không ai biết chính xác lệnh gì, tham số gì.

Ví dụ cấu hình Terraform cho backup tự động (AWS Backup)

Một phần AI hỗ trợ tốt là sinh nhanh IaC cho các hạng mục backup còn thiếu trong bảng gap ở trên — ví dụ bật AWS Backup Vault Lock (immutable backup) cho kịch bản ransomware:

# dr-backup.tf
resource "aws_backup_vault" "crm_dr_vault" {
  name        = "${var.project}-${var.environment}-dr-vault"
  kms_key_arn = aws_kms_key.backup_encryption.arn

  tags = {
    Environment = var.environment
    Project     = var.project
    ManagedBy   = "terraform"
  }
}

resource "aws_backup_vault_lock_configuration" "crm_dr_vault_lock" {
  backup_vault_name  = aws_backup_vault.crm_dr_vault.name
  min_retention_days = 30
  max_retention_days = 90
  # changeable_for_days không đặt = Vault Lock ở compliance mode,
  # KHÔNG ai (kể cả root account) xoá được backup trước hạn, kể cả bị chiếm quyền.
}

resource "aws_backup_plan" "crm_rds_daily" {
  name = "${var.project}-${var.environment}-rds-daily"

  rule {
    rule_name         = "daily-backup-15min-rpo"
    target_vault_name = aws_backup_vault.crm_dr_vault.name
    schedule          = "cron(0/15 * * * ? *)" # mỗi 15 phút, khớp RPO mục tiêu
    lifecycle {
      delete_after = 30
    }
  }
}

resource "aws_backup_selection" "crm_rds_selection" {
  name         = "${var.project}-${var.environment}-rds-selection"
  plan_id      = aws_backup_plan.crm_rds_daily.id
  iam_role_arn = aws_iam_role.backup_service_role.arn

  resources = [
    aws_db_instance.crm_main.arn,
  ]
}

Lưu ý: đoạn Terraform trên minh hoạ cấu trúc chuẩn, không phải config production-ready dán vào là chạy — bạn vẫn cần điều chỉnh theo IAM policy, KMS key, và naming convention thật của tổ chức mình.

Cạm bẫy thường gặp

1. Kế hoạch DR chưa từng được diễn tập (DR drill) — cạm bẫy nguy hiểm nhất. Một DR plan viết ra chi tiết đến đâu, có AI hỗ trợ tinh vi đến đâu, vẫn chỉ là giả thuyết cho tới khi được test bằng hành động thật: thật sự restore từ backup, thật sự failover sang region phụ, thật sự đo xem RTO thực tế là bao nhiêu phút chứ không phải con số ước lượng trên giấy. Rất nhiều team dừng lại ở bước viết plan, coi đó là "đã xong việc DR", rồi 8 tháng sau khi sự cố thật xảy ra mới phát hiện: script restore đã lỗi thời vì hạ tầng đổi tên, IAM role bị thu hồi quyền, hoặc đơn giản là không ai trong team hiện tại từng chạy quy trình đó. Một kế hoạch DR chưa test không đáng tin cậy hơn việc không có kế hoạch — vì nó tạo ra cảm giác an toàn giả khiến team ngừng đầu tư thêm vào rủi ro mà thực chất vẫn còn nguyên. Lịch trình tối thiểu hợp lý: DR drill toàn phần (game day) ít nhất 2 lần/năm, drill từng phần (restore thử một bảng, failover thử một service) hàng quý.

2. RTO/RPO được kỹ sư tự đặt ra mà không hỏi bên nghiệp vụ. Rất dễ rơi vào bẫy: kỹ sư tự quyết định "RTO 1 giờ nghe hợp lý", rồi thiết kế cả hệ thống theo con số tự đặt đó — trong khi bên kinh doanh có thể chấp nhận downtime 4 giờ (tiết kiệm chi phí đáng kể) hoặc ngược lại, cần RTO 5 phút vì mỗi phút downtime tương ứng với thiệt hại hợp đồng SLA cụ thể. RTO/RPO là quyết định kinh doanh cần được thống nhất bằng con số rõ ràng với stakeholder, không phải giả định kỹ thuật.

3. Backup tồn tại nhưng chưa từng kiểm chứng khả năng restore, hoặc restore ra dữ liệu đã hỏng từ trước. Có hai biến thể: (a) file backup bị lỗi/corrupt mà không ai biết vì chưa từng mở ra dùng thử; (b) nghiêm trọng hơn — snapshot được chụp SAU khi dữ liệu đã bị hỏng logic (ví dụ: một bug âm thầm ghi sai dữ liệu suốt 3 ngày trước khi bị phát hiện), khiến mọi bản snapshot gần đó đều mang theo lỗi. Đây là lý do RPO không chỉ nói về "khoảng cách thời gian" mà còn cần chiến lược retention đủ dài (giữ nhiều điểm phục hồi trong quá khứ, không chỉ điểm gần nhất) để có thể lùi về trước khi lỗi logic bắt đầu.

🧭 Góc nhìn Solutions Architect
Lần cuối cùng team bạn thực sự restore từ backup — không phải đọc lại tài liệu, mà chạy lệnh thật — là khi nào? Nếu câu trả lời là "chưa từng", con số RTO/RPO trong tài liệu DR plan của bạn có ý nghĩa gì, hay chỉ là ước lượng chưa kiểm chứng? Và ai là người có quyền quyết định "chúng ta chính thức tuyên bố disaster, bắt đầu failover" lúc 3 giờ sáng — đã có quy trình rõ ràng, hay vẫn đang giả định "ai đó sẽ biết phải làm gì"?

🔗 Bài viết liên quan

• [Bài 15] Event-Driven Design: AI hỗ trợ thiết kế Event-Bus và Async flow (ans-15-event-driven-design-ai-ho-tro.md) — retry/DLQ là một dạng "recovery" ở tầng message, bổ trợ trực tiếp cho DR ở tầng hạ tầng.
• [Bài 17] Infrastructure as Code: Terraform & CDK (ans-17-infrastructure-as-code-terraform-cdk.md) — hạ tầng DR (pilot light, cross-region) chỉ đáng tin khi được định nghĩa và test lại được bằng IaC, không phải click tay trên console.

Bài trước: Scalability Strategy · Bài tiếp theo: AI Integration Patterns