Các chỉ số chính của BCP và những lưu ý khi xây dựng DRS

1. Tổng quan

A. Định nghĩa

BCP (Business Continuity Planning, kế hoạch liên tục nghiệp vụ) là kế hoạch và hệ thống tổng thể được lập ra để duy trì các nghiệp vụ cốt lõi không gián đoạn (hoặc gián đoạn tối thiểu) ngay cả trong tình huống thảm họa hay sự cố, còn DRS (Disaster Recovery System, hệ thống phục hồi thảm họa) là phương tiện kỹ thuật hiện thực việc phục hồi hệ thống CNTT và dữ liệu trong đó.

BCP và DRS có quan hệ cấp trên – cấp dưới. BCP là chiến lược liên tục ở cấp quản trị bao trùm nhân lực, quy trình, cơ sở vật chất và CNTT, còn DRS đảm nhận phần "phục hồi hệ thống CNTT như thế nào" bên trong đó. Tức là DRS là điều kiện cần chứ không phải điều kiện đủ của BCP; dù hệ thống được phục hồi, nếu không có quy trình nghiệp vụ và ứng phó nhân lực thì tính liên tục vẫn không đạt được.

B. Sự cần thiết

Thảm họa không chỉ bao gồm các sự kiện vật lý như động đất, hỏa hoạn mà cả các mối đe dọa mạng như ransomware, sự cố hệ thống, và ngày nay khi mức phụ thuộc số hóa tăng cao, gián đoạn nghiệp vụ dẫn thẳng tới tổn thất doanh thu và niềm tin. Đặc biệt tại Hàn Quốc, các quy định pháp lý bắt buộc xây dựng hệ thống DR — như Quy định giám sát giao dịch tài chính điện tử đối với ngành tài chính, hệ thống quản lý hoạt động giảm nhẹ thảm họa đối với khu vực công — nên BCP/DRS đã trở thành bắt buộc chứ không còn là lựa chọn.

2. Quy trình lập BCP và các chỉ số chính

flowchart LR
  B[BIA<br/>phân tích tác động nghiệp vụ] --> R[Đánh giá rủi ro]
  R --> S[Lập chiến lược phục hồi]
  S --> P[Lập BCP·diễn tập]

Điểm xuất phát của BCP là BIA (Business Impact Analysis, phân tích tác động nghiệp vụ). Bảo vệ mọi nghiệp vụ như nhau là không hiệu quả, nên dùng BIA phân tích tác động khi từng nghiệp vụ bị gián đoạn để xác định thứ tự ưu tiên và mức phục hồi mục tiêu. Các chỉ số cốt lõi rút ra từ đây là RTO và RPO. RTO (thời gian phục hồi mục tiêu) là "phải phục hồi nhanh đến mức nào", quyết định mức dự phòng của hệ thống, còn RPO (điểm phục hồi mục tiêu) là "có thể chấp nhận mất bao nhiêu dữ liệu", quyết định chu kỳ sao lưu và sao chép.

Lấy ví dụ quan hệ giữa hai chỉ số: nếu RPO là "1 giờ" thì phải sao lưu (hoặc sao chép) ít nhất mỗi giờ một lần, và nếu RTO là "2 giờ" thì phải chuẩn bị sẵn hạ tầng có thể khôi phục hệ thống trong vòng 2 giờ. Yêu cầu RTO/RPO càng gần 0 thì chi phí càng tăng vọt, nên nguyên tắc là thiết lập khác biệt theo từng nghiệp vụ dựa trên kết quả BIA.

3. Các loại xây dựng DRS (mức phục hồi)

Loại DRS rốt cuộc được phân định bởi sự cân bằng giữa mục tiêu RTO và chi phí. Muốn phục hồi nhanh thì phải vận hành thường trực hệ thống chờ, và chi phí tăng tương ứng. Mirror Site dự phòng theo thời gian thực nên RTO hội tụ về 0 nhưng đắt nhất, còn Cold Site chỉ có không gian và thiết bị nên rẻ nhưng phục hồi mất vài tuần. Hot/Warm là phương án dung hòa ở giữa. Cách kết hợp là nghiệp vụ càng cốt lõi thì chọn loại cao hơn, nghiệp vụ ưu tiên thấp thì chọn loại thấp hơn.

4. Những lưu ý cốt lõi khi xây dựng DRS

flowchart LR
  T[Mục tiêu RTO/RPO] --> D[Khoảng cách giữa các trung tâm]
  D --> C[Phương thức sao chép dữ liệu]
  C --> E[Quy trình chuyển đổi·phục hồi]
  E --> M[Diễn tập mô phỏng·kiểm chứng]

Đánh đổi tinh tế nhất trong thiết kế DRS là điểm giao thoa giữa khoảng cách giữa các trung tâm và phương thức sao chép dữ liệu. Để thảm họa không đồng thời ập vào cả hai trung tâm thì phải đặt cách xa nhau đủ về địa lý, nhưng khoảng cách xa thì độ trễ truyền của sao chép đồng bộ tăng khiến hiệu năng vận hành giảm. Vì vậy, quyết định được đưa ra theo cách: giao dịch tài chính cần không mất dữ liệu (RPO=0) thì dùng sao chép đồng bộ và chấp nhận ràng buộc khoảng cách, còn hệ thống nhạy cảm với độ trễ thì đặt trung tâm ở xa với sao chép bất đồng bộ cho phép mất mát nhỏ. Ngoài ra, việc chuyển đổi (Failover) và phục hồi về (Failback) được thực hiện tự động hay thủ công, và đã được văn bản hóa trong RunBook hay chưa, sẽ quyết định thành công của việc phục hồi khi khủng hoảng thực sự xảy ra.

Trên hết, DRS không phải xây một lần là xong. Cấu hình hệ thống liên tục thay đổi, nên nếu không kiểm chứng bằng diễn tập mô phỏng định kỳ xem việc phục hồi thực tế có đạt trong thời gian mục tiêu không thì khi khủng hoảng có thể trở nên vô dụng. Kế hoạch DR không có diễn tập chỉ là "phục hồi trên giấy".

5. Những điều cần cân nhắc và hàm ý

• Tối ưu chi phí bằng DR đám mây: Các mẫu DR đám mây như pilot light, warm standby chỉ duy trì tài nguyên tối thiểu lúc bình thường và mở rộng (Scale-out) khi có thảm họa, đạt mức phục hồi cao hơn với chi phí thấp hơn trung tâm DR vật lý.
• Bảo đảm hiệu lực bằng diễn tập chứ không phải tài liệu: Giá trị của BCP/DRS không đến từ bản kế hoạch mà từ diễn tập và kiểm chứng định kỳ. Phải thực sự chạy thử quy trình phục hồi và cập nhật.
• Liên kết với khả năng phục hồi an ninh mạng (Cyber Resilience): Để phòng ransomware, thiết kế kèm sao lưu bất biến (Immutable Backup) và môi trường phục hồi tách biệt mạng.
• Liên tục tính toán lại RTO/RPO: Định kỳ cập nhật BIA theo thay đổi nghiệp vụ để duy trì chỉ số mục tiêu sát với thực tế.

Tóm tắt một câu: BCP lập kế hoạch liên tục nghiệp vụ bằng các chỉ số RTO, RPO, RSO, MTD dựa trên BIA, còn DRS được xây dựng với các lưu ý cốt lõi là mức phục hồi (Mirror~Cold), khoảng cách trung tâm, phương thức sao chép, quy trình chuyển đổi, diễn tập mô phỏng, nhưng hiệu lực chỉ được bảo đảm bằng diễn tập và kiểm chứng định kỳ chứ không phải tài liệu.