Bảo mật

RPO và RTO: đặt mục tiêu phục hồi cho máy chủ

RPO và RTO giúp biến yêu cầu 'hệ thống phải an toàn' thành mục tiêu có thể kiểm thử. RPO nói về mức mất dữ liệu theo thời gian có thể chấp nhận; RTO nói về thời gian mục tiêu để khôi phục hoạt động sau gián đoạn.

aigpu.vn
Ảnh minh họa: RPO và RTO: đặt mục tiêu phục hồi cho máy chủ

RPO và RTO giúp biến yêu cầu 'hệ thống phải an toàn' thành mục tiêu có thể kiểm thử. RPO nói về mức mất dữ liệu theo thời gian có thể chấp nhận; RTO nói về thời gian mục tiêu để khôi phục hoạt động sau gián đoạn.

Phân biệt bằng ví dụ

Mục tiêuCâu hỏiVí dụ giả định
RPOCó thể mất bao nhiêu thời gian dữ liệu?Tối đa 1 giờ giao dịch
RTOCó thể ngừng hoạt động bao lâu?Khôi phục trong 4 giờ
SLANhà cung cấp cam kết phần dịch vụ nào?Điện/mạng/host theo hợp đồng

Nếu backup gần nhất lúc 09:00 và sự cố lúc 11:30, phục hồi về bản đó có thể mất 2,5 giờ dữ liệu. Mục tiêu RPO một giờ chưa được đáp ứng. Nếu mất ba giờ để restore và thêm hai giờ kiểm tra ứng dụng, tổng năm giờ có thể vượt RTO bốn giờ.

Chọn theo nghiệp vụ

Hỏi đội sử dụng hệ thống: dữ liệu nào có thể nhập lại, giao dịch nào không được mất và thời gian dừng ảnh hưởng ra sao. Website giới thiệu, hệ thống đặt hàng và báo cáo nội bộ có nhu cầu khác nhau. Không áp dụng một RPO/RTO cho mọi ứng dụng chỉ vì chúng cùng chạy trên server.

  • Xác định hệ thống quan trọng và phụ thuộc giữa chúng.
  • Chỉ rõ dữ liệu và chức năng cần phục hồi trước.
  • Đặt mục tiêu với người chịu trách nhiệm nghiệp vụ.
  • Kiểm tra ngân sách và năng lực vận hành đáp ứng mục tiêu.

Từ mục tiêu đến phương án

Lịch backup cần đủ thường xuyên cho RPO, nhưng còn tính job thất bại và khoảng trễ sao chép. RTO cần bao gồm phát hiện, xác nhận sự cố, lấy bản sao, dựng môi trường, restore và kiểm tra. Không tính riêng thời gian copy file như toàn bộ phục hồi.

Replication có thể giảm mất dữ liệu hoặc hỗ trợ failover, nhưng lỗi xóa/sửa có thể lan sang replica. Cần bản sao theo thời điểm và quy trình kiểm tra cho từng kiểu sự cố.

Mất một VM khác mất toàn site

Tình huốngĐiều cần chuẩn bị
Lỗi ứng dụngArtifact cũ, rollback và kiểm tra dữ liệu
Mất VM/hostMôi trường thay thế và bản sao ngoài host
Mất storageBản sao độc lập và dung lượng phục hồi
Mất siteNguồn dữ liệu ngoài site, mạng và kế hoạch failover
Chiếm quyền quản trịQuyền backup tách biệt và khóa khôi phục

Thử nghiệm phục hồi

  1. Chọn tình huống và mốc dữ liệu cần lấy lại.
  2. Ghi thời gian bắt đầu cùng tiêu chí hoàn tất.
  3. Khôi phục trong môi trường tách biệt.
  4. Đối chiếu dữ liệu với bộ kiểm tra nghiệp vụ.
  5. Xác nhận chức năng và truy cập từ client.
  6. Ghi RPO/RTO thực đạt, lỗi và hành động cải thiện.

Nếu restore cần người giữ khóa đang vắng, đó cũng là hạn chế vận hành. Runbook phải nói người thay thế, cách truy cập được kiểm soát và thứ tự các bước. Không đưa secret trực tiếp vào tài liệu mọi người đều đọc.

Rà soát khi hệ thống tăng trưởng

Database lớn hơn có thể kéo dài restore; thêm tích hợp có thể tạo phụ thuộc mới. Lặp bài thử sau thay đổi lớn và theo lịch phù hợp rủi ro. Mục tiêu chỉ có giá trị khi số liệu gần với production hiện tại.

Khi thuê máy chủ, gửi yêu cầu RPO/RTO và hỏi phạm vi backup/restore. Đọc Tier và SLA để tránh coi chứng nhận DC là lời bảo đảm khôi phục toàn ứng dụng.

RPO bằng zero có dễ đạt không?

Đó là yêu cầu chặt cần thiết kế dữ liệu và vận hành phù hợp; không suy từ việc có replica hoặc backup thường xuyên.

RTO có phải thời gian nhà cung cấp phản hồi ticket?

Không. RTO hướng tới phục hồi hoạt động; phản hồi hỗ trợ chỉ là một bước trong chuỗi đó.

Cần GPU cho workload này?

NOC aigpu.vn hỗ trợ chọn GPU, VRAM và cấu hình phù hợp. PoC trong 24 giờ.

Bài viết liên quan

Xem tất cả bài viết
GọiFBZaloSalesZaloOA