RTO در برابر RPO و درک تفاوت آنها

Downtime برای سازمان‌های مدرنی که باید نیازها و انتظارات مشتریان خود را برآورده سازند، اتفاق خوبی نیست. حوادث مختلفی می‌تواند درآمد یا حتی تداوم کسب و کار شما را تحت تاثیر قرار دهد. ممکن است حمله یک باج افزار، قطع برق، زلزله یا اشتباهات ساده انسانی رخ دهند که تمام این اتفاقات، غیرقابل پیش بینی بوده و بهترین کاری که می‌توان انجام داد این است که آماده آنها باشید. آمادگی به این معناست که باید یک برنامه تداوم کسب و کار و برگشت از فاجعه (Business Continuity and Disaster Recovery یا به اختصار BCDR) درست و حسابی داشته باشیم، برنامه‌ای که مورد آزمایش قرار گرفته و می‌توان آن را به راحتی اجرا کرد. RTO و RPO دو پارامتر مهم هستند که یک برنامه‌ی BCDR را تعریف می‌کنند.

Recovery Point Objective یا به اختصار RPO حداکثر مقدار مجاز داده‌هایی است که تحمل از دست دادن آنها را داریم و همچنین در اندازه گیری اینکه چه مدت زمانی باید بین آخرین بکاپ و رخداد فاجعه وجود داشته باشد تا سازمان متحمل آسیب‌های جدی نشود، کمک می‌کند.

Recovery Time Objective یا به اختصار RTO به Downtime مربوط است و مدت زمان لازم برای برگشت از فاجعه تا زمانی که همه چیز به حالت عادی بازگردد را نشان می‌دهد.

با اینکه RPO و RTO ممکن است شبیه به نظر برسند، ولی اهداف متفاوتی را دنبال می‌کنند و در یک دنیای رویایی این دو پارامتر تا حد ممکن نزدیک به صفر است. با این حال در دنیای واقعی و در محیط عملیاتی هزینه به صفر رساندن این دو پارامتر بسیار بالا بوده و مقرون به صرفه نیست.

بگذارید نگاهی دقیق تر به اهداف این دو پارامتر بیندازیم. RPO در مورد میزان داده‌ای است که سازمان تحمل از دست دادن آن را دارد. برای مثال یک بانک را در نظر بگیرید که حتی از دست دادن 1 ساعت از داده‌ها می‌تواند فاجعه بار باشد چرا که میزان Transactionها و داده‌ها در یک ساعت بسیار زیاد است. RPO در اندازه کوچکتر نیز قابل اندازه گیری است؛ کامپیوتر شخصی شما هنگام کار روی یک سند به هر دلیلی خراب می‌شود و آخرین تغییراتی که روی سند انجام شده، از دست می‌رود. سوال اینجاست که حاضرید چه مقدار از داده‌هایی که وارد کردید را از دست دهید؟ و در صورت از دست دادن آنها چه تاثیری روی شما یا کارتان می‌گذارد؟  بنابراین RPO معیاری کلیدی برای تعیین زمان و دوره‌های بکاپ گیری است. برای مثال، فرض کنید در سازمانی که هر روز ساعت 12 شب بکاپ‌گیری انجام می‌شود، فاجعه‌ای در ساعت 8 صبح اتفاق می‌افتد. در این ‌حالت، احتمالاْ داده‌هایی که در این 8 ساعت ایجاد شده‌اند، از دست خواهد رفت. اگر RPO در این سازمان 24 ساعت یا بیشتر باشد، وضعیت خوبی داریم ولی اگر RPO چهار ساعت باشد، قطعاْ در وضعیت خیلی بدی قرار داریم.

از طرف دیگر RTO زمانی است که باید در طی آن سیستم و برنامه‌ها پس از وقوع فاجعه، احیا شوند. برای مثال اگر RTO در سازمان شما 24 ساعت باشد، معنی آن این است که شما تعیین کرده‌اید که سازمان بدون داده‌ها و زیرساخت IT می‌تواند برای 24 ساعت به فعالیت معمول خود ادامه دهد و اگر داده‌ها و زیرساخت در این مدت زمان به حالت اولیه بازنگردد، سازمان شما متحمل آسیب‌های جبران ناپذیری خواهد شد.

روش درست این است که RTO را از زمان وقوع فاجعه و قطع سیستم‌ها اندازه گیری کرد و نه از لحظه‌ای که تیم IT شروع به رفع مشکل می‌کنند!

طراحی یک برنامه برگشت از فاجعه

حقیقتاْ هچ برنامه مشخصی برای همه سازمان‌ها و زیرساخت‌های مختلف وجود ندارد. سازمان‌ها با یکدیگر تفاوت دارند، نیازهای متفاوتی دارند و قطعاْ براساس این نیازها، باید برنامه‌هایی متفاوت و مطابق با نیازهای خود داشته باشند. با این حال، یک روش معمول این است که اپلیکیشن‌ها و سرویس‌های سازمان را به گروه‌های مختلف تقسیم کنیم و پس از آن RPO و RTO را مطابق SLA که سازمان به آن متعهد است، محاسبه و تنظیم کنیم.

طبقه بندی حفاظت از داده‌ها برای تعیین نحوه ذخیره، دسترسی، محافظت، بازیابی و به روزرسانی کارآمدتر داده‌ها و اطلاعات بر اساس معیارهای خاص آنها، از اهمیت ویژه‌ای برخوردار است. تجزیه و تحلیل سرویس‌ها و اپلیکیشن‌ها و تعیین اینکه کدامیک برای کسب و کار شما حیاتی‌اند و در درآمدزایی سازمان نقش ویژه‌ای دارند، عملیاتی مهم و ضروری است. این فرآیند که برای یک برنامه‌ی تداوم کسب و کار بسیار ضروری است، Business Impact Analysis یا به اختصار BIA گفته می‌شود. در حقیقت BIA پروتکل‌ها و اقدامات لازم برای مواجهه با یک فاجعه را تعیین می‌کند.

به عنوان مثال ، می توانید از یک مدل سه لایه برای طراحی برنامه تداوم کسب وکار استفاده کنید:

گروه اول: اپلیکیشن‌های Mission-Critical که RTPO آنها باید کمتر از 15 دقیقه باشد.

گروه دوم: اپلیکیشن‌های Business-Critical که باید RTO و RPO آنها به ترتیب 2 ساعت و 4 ساعت باشد.

گروه سوم: اپلیکیشن‌های Non-Critical که باید ‌RTO و RPO آنها به ترتیب 4 ساعت و 24 ساعت باشد.

بخاطر داشته باشید که اپلیکیشن‌های Mission-Critical و Business-Critical و Non-Critical در هر سازمانی متفاوت هستند و هر سازمان براساس نیازها و نوع فعالیتی که دارد این گروه‌ها را تعریف می‌کند. بعد از اینکه اپلیکیشن‌ها و سرویس‌های خود را گروه بندی کردید و مشخص شد که در صورت بروز حوادث چه تاثیراتی خواهند داشت، باید ابزار مناسبی را پیدا کنید تا به شما در محافظت از زیرساخت IT و داده‌ها کمک کند.

حرف آخر

برای طراحی یک برنامه BCDR  که هم بقای کسب و کار شما را تضمین کند و هم مقرون به صرفه باشد، باید RTO و RPO را در نظر بگیریم و همچنین باید با آزمایش این برنامه، اطمینان کسب کنیم که برنامه طراحی شده موثر و کارآمد باشد.

در عین حال، برای صرفه جویی در هزینه‌ها باید از سرمایه گذاری بیش از حد در تضمین RTO و RPO نیز دوری کرد. برای مثال، اگر RTO در سازمان شما 4 ساعت باشد و در حال حاضر امکان بازیابی 2 ساعته را دارید، سرمایه گذاری مجدد برای کاهش این زمان به 1 ساعت غیرضروری است.