Phần lớn tài liệu về RTO và RPO dừng lại ở định nghĩa, và định nghĩa thì không khó: một con số nói bạn được phép mất bao lâu, con số kia nói bạn được phép mất bao nhiêu dữ liệu. Vấn đề nằm ở chỗ khác. Trong đa số tổ chức, hai con số này được điền vào một biểu mẫu, được duyệt, rồi không ai chạm tới cho đến lần kiểm toán tiếp theo. Chúng tồn tại như một cam kết trên giấy chứ không phải một ràng buộc thiết kế.
Bài viết này đi theo hướng ngược lại: hai con số đó nên được rút ra từ đâu, ai sở hữu chúng, chúng thay đổi cấu trúc runbook như thế nào, và làm sao phân biệt một con số bạn đã công bố với một con số bạn thực sự đạt được.
Rút hai con số từ tác động kinh doanh, không từ cảm tính kỹ thuật
Sai lầm phổ biến nhất là hỏi đội hạ tầng rằng họ có thể khôi phục nhanh đến mức nào, rồi ghi con số đó lại làm RTO. Cách này đảo ngược quan hệ nhân quả. RTO là một yêu cầu nghiệp vụ, và hạ tầng có nhiệm vụ đáp ứng nó hoặc nói rõ rằng không đáp ứng được với chi phí hiện tại.
Bắt đầu từ quy trình nghiệp vụ, không từ máy chủ
Danh sách máy chủ không cho bạn biết điều gì về mức độ chịu đựng của doanh nghiệp. Hãy bắt đầu từ các quy trình tạo ra doanh thu hoặc nghĩa vụ với khách hàng: tiếp nhận đơn hàng, thanh toán, giao hàng, hỗ trợ, chốt sổ. Với mỗi quy trình, hỏi người phụ trách nghiệp vụ một câu rất cụ thể: nếu quy trình này dừng vào một ngày làm việc bình thường, sau bao lâu thì hậu quả chuyển từ khó chịu sang nghiêm trọng, và sau bao lâu thì chuyển từ nghiêm trọng sang không thể khắc phục.
Câu trả lời hầu như không bao giờ là một con số duy nhất, và điều đó lại hữu ích. Thứ bạn cần là hình dạng của đường cong thiệt hại theo thời gian. Một số hệ thống có đường cong phẳng trong vài giờ rồi dốc đứng, thường vì có quy trình thủ công tạm thay thế được cho đến một ngưỡng nhất định. Một số khác dốc ngay từ phút đầu tiên. Hai hình dạng đó dẫn tới hai thiết kế khôi phục hoàn toàn khác nhau, dù RTO ghi trên giấy có thể trùng nhau.
RPO là câu hỏi về khối lượng công việc phải làm lại
RPO thường bị hiểu sai thành một tham số kỹ thuật của cơ chế sao lưu. Thực chất nó là câu hỏi: nếu mất dữ liệu của một khoảng thời gian, ai sẽ phải nhập lại, họ lấy nguồn từ đâu, và mất bao lâu. Nếu giao dịch có thể tái tạo từ chứng từ giấy hoặc từ hệ thống của đối tác, thì một RPO rộng hơn là chấp nhận được và rẻ hơn nhiều. Nếu dữ liệu chỉ tồn tại duy nhất trong hệ thống đó và không có nguồn tái tạo, thì mọi phút bị mất là mất vĩnh viễn, và con số phải chặt hơn hẳn.
Một cách kiểm tra nhanh: hỏi đội nghiệp vụ xem họ có quy trình nào để nhập bù dữ liệu sau sự cố hay không. Nếu câu trả lời là không, thì RPO trên giấy dù rộng đến đâu cũng không phản ánh khả năng chịu đựng thật.
Đừng đặt cùng một cặp số cho mọi hệ thống
Việc gán một cặp RTO và RPO chung cho toàn bộ hạ tầng luôn dẫn tới một trong hai kết quả: hoặc bạn tiêu tiền để bảo vệ hệ thống không cần đến mức đó, hoặc bạn để hệ thống quan trọng nhất được bảo vệ ở mức trung bình. Cả hai đều tệ, và cái thứ hai chỉ lộ ra đúng vào lúc bạn không muốn nó lộ ra.
Cách làm hợp lý là chia thành vài nhóm và gán mỗi nhóm một cặp số, kèm mô tả cơ chế đáp ứng tương ứng. Số nhóm nên đủ ít để đội vận hành nhớ được mà không tra cứu.
Đưa hai con số vào kế hoạch khôi phục
Một con số không có người chịu trách nhiệm thì không phải là cam kết. Đây là phần mà phần lớn kế hoạch khôi phục còn thiếu, và cũng là phần rẻ nhất để bổ sung.
Ai sở hữu con số
Mỗi cặp RTO và RPO cần một chủ sở hữu phía nghiệp vụ, tức là người có thẩm quyền nói rằng mức chịu đựng này là đúng và chấp nhận hệ quả ngân sách đi kèm. Nếu chủ sở hữu là một chức danh kỹ thuật, con số sẽ trôi dần về phía những gì hạ tầng hiện tại làm được, và mất hết ý nghĩa ràng buộc.
Ai chịu trách nhiệm đáp ứng
Song song với chủ sở hữu nghiệp vụ, cần một người chịu trách nhiệm kỹ thuật cho từng hệ thống: người biết chuỗi phụ thuộc, biết thứ tự khởi động, và có thể trả lời ngay rằng cơ chế hiện tại đủ hay không đủ. Danh sách này nên ghi tên người, kèm người thay thế, chứ không ghi tên phòng ban. Trong sự cố, một phòng ban không nhấc máy.
Ai có quyền tuyên bố và quyền quyết định
Đây là điểm khiến nhiều đợt khôi phục vượt RTO mà không phải vì lý do kỹ thuật. Kế hoạch cần nói rõ ai có thẩm quyền tuyên bố tình huống thảm họa và kích hoạt quy trình, vì thời gian trôi qua trong lúc mọi người còn tranh luận xem đây có phải sự cố nghiêm trọng hay không cũng được tính vào RTO.
Ngoài ra cần xác định trước một số quyền quyết định thường phát sinh giữa lúc căng thẳng: quyền chấp nhận mất một phần dữ liệu để phục hồi nhanh hơn, quyền quyết định chuyển sang hệ thống dự phòng thay vì tiếp tục sửa hệ thống chính, quyền dừng dịch vụ cho một nhóm người dùng để dồn năng lực cho nhóm khác, và quyền chi tiêu ngoài kế hoạch. Nếu những quyền này chưa được giao trước, chúng sẽ được tranh luận trong lúc đồng hồ đang chạy.
Ghi rõ ngưỡng leo thang theo thời gian
Kế hoạch tốt gắn mốc thời gian với hành động cụ thể chứ không chỉ với một hạn chót duy nhất. Ví dụ: tại mốc bằng một phần ba RTO, thông báo cho lãnh đạo nghiệp vụ; tại mốc hai phần ba, bắt đầu chuẩn bị phương án dự phòng song song thay vì chờ; tại mốc RTO, chuyển sang phương án đã chuẩn bị. Cách này biến con số thành một chuỗi quyết định thay vì một vạch đích mà bạn chỉ biết mình đã vượt qua khi đã quá muộn.
RTO công bố và RTO đã kiểm chứng
Có hai loại RTO trong mọi tổ chức. Loại thứ nhất nằm trong tài liệu và trong câu trả lời gửi khách hàng. Loại thứ hai là thời gian thực tế mà đội của bạn cần, đã đo bằng đồng hồ, trong một lần khôi phục thật. Khoảng cách giữa hai loại này là rủi ro thực của bạn, và nó chỉ đo được bằng cách diễn tập.
Con số đã kiểm chứng thường lớn hơn con số công bố, vì tính toán trên giấy hầu như luôn bỏ sót cùng một nhóm yếu tố: thời gian phát hiện sự cố, thời gian huy động đúng người ngoài giờ làm việc, thời gian ra quyết định, thời gian tìm và giải mã thông tin xác thực, thời gian khôi phục các hệ thống phụ thuộc trước khi tới lượt hệ thống chính, và thời gian nghiệp vụ xác nhận dữ liệu đúng trước khi mở lại cho người dùng.
Một kế hoạch trung thực nên ghi cả hai con số cạnh nhau, kèm ngày đo gần nhất. Ghi rằng RTO đã kiểm chứng đang lớn hơn mục tiêu là một thông tin quản trị hữu ích. Ghi một con số mục tiêu mà chưa ai từng đo thì không.
Hai con số định hình runbook như thế nào
Đây là lý do thực sự khiến việc xác định đúng RTO và RPO đáng để đầu tư công sức: chúng quyết định runbook phải được viết theo kiểu nào.
- RTO tính bằng ngày cho phép runbook ở dạng mô tả: nêu thứ tự các bước, giả định người thực hiện có thời gian tra cứu và suy nghĩ. Tự động hóa ở mức này thường không đáng chi phí.
- RTO tính bằng giờ đòi hỏi runbook ở dạng thao tác: từng câu lệnh cụ thể, đường dẫn chính xác, tiêu chí kiểm tra sau mỗi bước, và không có bước nào cần người thực hiện tự suy luận.
- RTO tính bằng phút loại bỏ phần lớn vai trò của tài liệu. Ở mức này, quy trình phải được tự động hóa và kiểm thử thường xuyên, còn runbook chủ yếu mô tả cách xác nhận rằng tự động hóa đã chạy đúng và cách xử lý khi nó không chạy.
- RPO tính bằng ngày phù hợp với sao lưu theo lịch cố định. RPO tính bằng phút đòi hỏi cơ chế ghi nhận liên tục và một quy trình xác định điểm khôi phục chính xác, vốn là bước tốn thời gian bất ngờ trong sự cố thật.
Hai con số cũng quyết định nhịp diễn tập. Hệ thống có RTO chặt nhất cần được diễn tập thường xuyên nhất, vì đó là nơi mà một quy trình lỗi thời gây hậu quả lớn nhất. Hệ thống có RTO rộng có thể diễn tập thưa hơn, nhưng không nên là không bao giờ. Một nguyên tắc thực dụng: diễn tập lại sau mỗi thay đổi kiến trúc đáng kể, sau mỗi thay đổi nhân sự trong nhóm chịu trách nhiệm, và theo một chu kỳ cố định đã cam kết bằng lịch.
Khi không đạt được con số
Sẽ có lúc kết quả diễn tập cho thấy hệ thống không thể đạt RTO đã cam kết với chi phí hiện tại. Đây không phải thất bại của quy trình, đây chính là kết quả mà quy trình sinh ra để phát hiện. Lúc đó chỉ có ba lựa chọn hợp lệ: đầu tư thêm để rút ngắn thời gian, nới con số và ghi nhận rủi ro ở cấp có thẩm quyền chấp nhận, hoặc thiết kế một phương án nghiệp vụ tạm thời để doanh nghiệp vẫn hoạt động được trong khoảng chênh lệch. Lựa chọn không hợp lệ duy nhất là giữ nguyên con số trên giấy và hy vọng.
HiTechCloud có thể hỗ trợ gì
HiTechCloud là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt trong nước. Chúng tôi hỗ trợ doanh nghiệp làm việc với các bộ phận nghiệp vụ để xác định RTO và RPO theo từng nhóm hệ thống, đối chiếu với năng lực hạ tầng hiện có, xây dựng runbook ở mức chi tiết phù hợp với con số đã chọn, và tổ chức diễn tập khôi phục có đo thời gian thực tế. Nếu bạn muốn biết khoảng cách giữa con số công bố và con số đạt được của mình, hãy liên hệ với đội ngũ của chúng tôi.
