Khách hỏi “sập thì mất bao nhiêu dữ liệu?”: FDE trả lời bằng RPO, RTO và một lần khôi phục thật

Demo vừa xong, giám đốc vận hành bên khách hỏi một câu nghe rất đơn giản: “Nếu hệ thống sập thì chúng tôi mất bao nhiêu dữ liệu?” Phản xạ của nhiều engineer là đáp “anh yên tâm, có backup hằng ngày”. Câu đó nghe trấn an, nhưng thực ra nó né câu hỏi.

Khách không hỏi bạn có backup hay không. Họ hỏi một con số. Bạn đưa được hai con số có căn cứ, và nói thẳng giới hạn của chúng, thì sẽ được tin hơn bất kỳ slide kiến trúc nào. Bạn né, thì họ sẽ tự tìm ra con số thật vào ngày tệ nhất.

Với FDE, đây là kỹ năng đi theo bạn qua mọi deployment. Hệ thống bạn dựng ở chỗ khách chạm vào dữ liệu thật của họ. Thế nên sớm muộn gì câu hỏi này cũng đến, thường là từ người có quyền ký hợp đồng.

Một câu hỏi, thật ra là hai

AWS Well-Architected định nghĩa RTO (Recovery Time Objective) là khoảng trễ tối đa chấp nhận được giữa lúc dịch vụ gián đoạn và lúc dịch vụ được khôi phục. Còn RPO (Recovery Point Objective) là khoảng thời gian tối đa chấp nhận được, đếm từ lần cuối dữ liệu được lưu lại để có thể khôi phục.

Hướng dẫn DR của Google Cloud nói RPO theo cách dễ hiểu hơn: đó là khoảng thời gian dài nhất mà dữ liệu có thể bị mất khi xảy ra sự cố lớn.

Có một cách dễ nhớ: RTO đếm tiến từ lúc sập đến lúc chạy lại. RPO đếm lùi về quá khứ, tới bản sao tốt cuối cùng. “Mất bao nhiêu dữ liệu” là câu hỏi về RPO, nhưng người hỏi gần như luôn quan tâm cả RTO, chỉ là chưa nói ra.

AWS yêu cầu xác định hai con số này cho từng workload chứ không đặt chung một con số cho cả công ty. Phần sau sẽ cho thấy chi tiết này quan trọng đến mức nào.

Backup lúc 2 giờ sáng thì RPO là bao nhiêu?

Thử hình dung khách là một chuỗi bán lẻ. Database đơn hàng được snapshot mỗi ngày lúc 02:00. Nếu disk hỏng lúc 23:00, bản tốt nhất bạn có là bản 02:00, vậy là mất 21 giờ đơn hàng.

Giờ xét trường hợp xấu nhất: sự cố xảy ra lúc 01:59, một phút trước lần snapshot kế tiếp. Bạn mất gần trọn 24 giờ. RPO thật của hệ thống này là 24 giờ, và đó mới là con số cần nói với khách.

Whitepaper DR của AWS nói thẳng rằng tần suất chạy backup quyết định recovery point bạn đạt được. Advisera, một đơn vị đào tạo ISO 27001, đưa ra một quy tắc dễ dùng: RPO là bốn giờ thì phải backup ít nhất bốn giờ một lần. Nếu khách chỉ chịu mất tối đa một giờ đơn hàng, snapshot hằng ngày không đủ, và bạn cần backup dày hơn hẳn.

RTO thì phải đo, không đoán được. Restore một database lớn, kiểm tra tính toàn vẹn, trỏ ứng dụng sang, xả cache: mỗi bước ngốn thời gian theo cách mà chỉ một lần chạy thật mới cho bạn biết.

Vì sao không bao giờ được hứa “không mất dữ liệu”

Đến đây nhiều người nghĩ ngay tới replication liên tục để RPO bằng 0. AWS thừa nhận replication liên tục cho độ trễ sao lưu gần như bằng 0. Nhưng nó có thể không bảo vệ được bạn khi dữ liệu bị hỏng (corruption) hoặc bị xoá có chủ đích.

Lý do khá dễ hiểu. Một script migration lỗi xoá mất bảng orders, và replica sẽ làm theo trong vài giây.

AWS viết rằng ngay cả mô hình multi-site active/active cũng vậy: khi dữ liệu bị hỏng, bị xoá hay bị xáo trộn đến mức không dùng được, thời gian phục hồi luôn lớn hơn 0 và điểm phục hồi luôn nằm trước thời điểm sự cố được phát hiện.

AWS còn đi xa hơn: dù áp dụng đủ mọi best practice, RTO và RPO vẫn lớn hơn 0, nghĩa là vẫn mất một ít availability và dữ liệu.

Well-Architected xếp việc chọn mục tiêu phi thực tế như “zero data loss” vào danh sách anti-pattern. Danh sách đó còn có cả việc đặt mục tiêu quá gắt khiến chi phí tăng trong khi doanh nghiệp không cần đến.

Hỏi trước, đề xuất sau

Một FDE giỏi không mở đầu bằng giải pháp. AWS gợi ý vài câu discovery rất đáng mượn: lượng dữ liệu tối đa có thể mất trước khi doanh nghiệp bị tác động ở mức không chấp nhận được là bao nhiêu? Dữ liệu đó có tái tạo được từ nguồn khác không?

Câu thứ hai thường thay đổi cả thiết kế. Nếu đơn hàng online đối soát được từ cổng thanh toán, RPO của bảng đơn hàng có thể nới ra. Ngược lại, ghi chú tư vấn mà nhân viên gõ tay thì mất là mất hẳn.

Sau đó hãy phân tầng. AWS khuyên chia workload theo tác động kinh doanh, gồm critical, high, medium và low, mỗi tầng có RTO/RPO riêng. Bảng dưới đây là một ví dụ giả định cho khách bán lẻ ở trên, chỉ để minh hoạ cách nghĩ:

Workload (giả định)	Tầng	RPO đề xuất	Cách đạt
Thanh toán, đơn hàng	Critical	Vài phút	Backup log liên tục + snapshot định kỳ
Tồn kho	High	1 giờ	Backup ít nhất mỗi giờ
Báo cáo BI	Medium	24 giờ	Snapshot hằng ngày, tái tạo từ nguồn
Log pipeline AI	Low	Có thể mất	Chạy lại từ dữ liệu gốc

RTO quyết định mô hình DR. AWS phân biệt rõ: pilot light chưa xử lý được request nếu chưa có thêm thao tác, còn warm standby nhận traffic ngay, dù ở công suất thấp hơn. Tầng medium thì pilot light hoặc restore từ backup là đủ.

Khi đã có số, câu trả lời của bạn trong phòng họp có thể như sau:

“Với đơn hàng, dữ liệu mất tối đa vài phút nếu hạ tầng hỏng, và hệ thống chạy lại trong khoảng thời gian chúng tôi đã đo khi diễn tập. Nếu dữ liệu bị xoá nhầm, chúng tôi khôi phục về bản sao gần nhất trước lúc phát hiện. Đó là giới hạn của mọi hệ thống, và chúng tôi có cảnh báo để rút ngắn khoảng phát hiện.”

Backup trên giấy và 18 giờ của GitLab

Postmortem năm 2017 của GitLab là bài học nhiều người vận hành hệ thống nhắc lại. GitLab.com sập khoảng 18 giờ, và chính đội ngũ GitLab viết rằng họ không hề biết backup đang thất bại cho đến khi đã quá muộn. Backup có tồn tại, nhưng chỉ tồn tại trên giấy.

Google Cloud khuyên làm đúng điều GitLab đã bỏ qua: lập xong kế hoạch DR thì phải test định kỳ, ghi lại mọi vấn đề phát sinh và điều chỉnh kế hoạch theo đó. Với FDE, buổi diễn tập restore chính là cách duy nhất để con số RTO bạn nói với khách là con số đo được.

Ở deployment tiếp theo, bạn có thể làm theo thứ tự sau. Đầu tiên, liệt kê mọi kho dữ liệu trong deployment, kể cả vector store và object storage mà nhiều người hay quên.

Tiếp theo, ngồi với khách để phân tầng và chốt RTO/RPO bằng văn bản. Sau đó, chỉnh lịch backup cho khớp RPO, chạy restore thật, bấm giờ, và gắn cảnh báo khi một job backup thất bại.

Có bốn lỗi rất hay gặp, và lỗi nào cũng tạo ra một lời hứa mà bạn không giữ được:

• Nói về việc “có backup” thay vì nói RPO.
• Coi replica như backup.
• Đặt chung một con số cho mọi hệ thống.
• Chưa bao giờ restore thử.

Nếu đang muốn chuyển sang FDE, bạn có thể đưa kỹ năng này vào CV bằng một dòng cụ thể: “Thiết kế backup theo RPO 1 giờ, diễn tập restore hằng quý, RTO đo được X phút.” Khi đọc JD, để ý các cụm như “disaster recovery”, “on-call” hay “customer-facing incidents”.

Gặp những cụm đó, bạn nên chuẩn bị sẵn câu trả lời cho đúng câu mà vị giám đốc vận hành kia đã hỏi, phòng khi buổi phỏng vấn đi vào chủ đề này.

Lần tới có khách hỏi “sập thì mất bao nhiêu?”, bạn đã có sẵn câu trả lời từ lần diễn tập gần nhất, kèm giờ chạy và con số đo được.