RTO và RPO là gì trong luyện thi chứng chỉ AWS Solution Architect?

Trong quá trình học và luyện thi chứng chỉ AWS Solution Architect nói riêng hay Architect nói chung, thuật ngữ RTO và RPO được nhắc đi nhắc lại nhiều lần ở cả level Associate lẫn Professional. Việc hiểu biết thuật ngữ nền tảng này rất có ý nghĩa trong xây dựng và thiết kế giải pháp cho khách hàng. Bài này iGà chia sẻ RTO, RPO có nghĩa là gì, ví dụ RTO, RPO trong thực tiễn.

RTO (Recovery Time Objective) là gì?

RTO – Time to recovery the system back to normal.

Đây là thời gian tối đa để khôi phục lại hệ thống. Chỉ số này quan tâm đến thời gian khôi phục lại hệ thống khi có sự cố hơn là dữ liệu. Số càng lớn thì thời gian khôi phục càng lâu và ngược lại. RTO cũng là thời gian downtime của dịch vụ.

Ví dụ nếu hệ thống thiết kế cần RTO = 01 hour, có nghĩa là khi có sự cố hệ thống này cần phục hồi trong tối đa 01 giờ. Giả sử hệ thống sự cố lúc 10 giờ tối, thì phục hồi lại hệ thống muộn nhất là 11 giờ tối cùng ngày.

RPO (Recovery Point Objective) là gì?

RPO – Amount of data can be lost.

Đây là thời gian dữ liệu có thể bị mất khi có sự cố trở về quá khứ. Chỉ số này quan tâm dữ liệu bị mất nhiều hay ít. Số càng lớn thì dữ liệu càng mất nhiều và ngược lại.

Ví dụ: Nếu hệ thống thiết kế yêu cầu RPO = 30 phút, có nghĩa là hệ thống nếu có sự cố phục hồi lại thì chỉ mất dữ liệu trong 30 phút từ lúc xảy ra sự cố tính về trước. Giả sử hệ thống bị sự cố lúc 10 giờ tối thì dữ liệu khôi phục cần phải có bản backup đâu đó tệ nhất là 9h30 tối hoặc sau đó (eg: 9h40…), nếu bản backup có lúc 9h tối là bị vi phạm điều kiện này.

Ví dụ: RPO = 1 hour, RTO=2 hours

  • Thời gian khôi phục kể lúc có sự cố tối đa 02 giờ. Downtime tối đa 02 hours.
  • Dữ liệu bị mất tối đa trong 01 giờ từ lúc có sự cố trở về trước.

Ví dụ: RPO = 0, RTO = 0

  • Hệ thống không có downtime.
  • Hệ thống không mất dữ liệu khi có downtime.

Trong thực tế rất hiếm có hệ thống nào có RPO=0 và RTO=0 vì đòi hỏi chi phí rất cao trong thiết kế vì phải đáp ứng nhiều tier mà vẫn phải đảm bảo bảo mật (Security), hiệu năng (Performance) và trải nghiệm (UX) khi sử dụng. Thông thường, SA sẽ thiết kế tối thiểu RPO và RTO cho các thành phần quan trọng (Critical Components), có thể tiệm cận về 0. Tuy nhiên, việc này cần trao đổi và thiết lập mức mong đợi với khách hàng.

Là một SA, bạn nên thiết lập mức độ mong đợi rõ ràng ở yêu cầu này để đảm bảo tính thành công dự án trong tương lai. iGà xin kết thúc bài chia sẻ bằng một tấm hình sau, đây là một vấn đề muôn thuở mà SA cùng đội ngũ dự án phải giải quyết.

Mong nhận được chia sẻ kinh nghiệm từ các bạn.

Share to be shared,

iGà

[email protected]

Topics #100 #DR #HA #rpo #rto