از دسترس خارج شدن سرورها، حملات باج افزاری، خرابی تجهیزات، حذف اشتباه فایل ها و قطعی دیتاسنتر می توانند فعالیت یک کسب و کار را متوقف کنند. در چنین شرایطی فقط داشتن نسخه پشتیبان کافی نیست. سازمان باید از قبل مشخص کرده باشد که چه مقدار از اطلاعات قابل از دست رفتن است و بازیابی سرویس ها حداکثر چقدر می تواند طول بکشد. دو شاخص RPO و RTO برای پاسخ دادن به همین سوال ها استفاده می شوند. RPO میزان قابل تحمل از دست رفتن اطلاعات را مشخص می کند و RTO نشان می دهد یک سامانه تا چه مدت می تواند از دسترس خارج باشد. تعیین دقیق این دو شاخص به کسب و کار کمک می کند روش بکاپ گیری، زیرساخت جایگزین، معماری شبکه و برنامه بازیابی بحران را متناسب با نیاز واقعی خود طراحی کند. در ادامه بررسی می کنیم RPO و RTO چیست، چه تفاوتی دارند و چگونه باید مقدار مناسب آنها را تعیین کرد.
RPO چیست و چه مقدار از دست رفتن اطلاعات قابل تحمل است؟
راه اندازی شبکه اصولی فقط شامل اتصال سیستم ها و نصب تجهیزات نیست. برای جلوگیری از خسارت های جدی، باید مشخص شود در صورت وقوع خرابی چه مقدار از اطلاعات جدید سازمان قابل بازیابی خواهد بود. RPO مخفف Recovery Point Objective است و می توان آن را هدف نقطه بازیابی اطلاعات ترجمه کرد. RPO مشخص می کند یک سازمان حداکثر چه بازه ای از اطلاعات خود را می تواند از دست بدهد. این شاخص معمولا با زمان بیان می شود. برای مثال، RPO برابر با ۱ ساعت یعنی پس از وقوع حادثه باید بتوان اطلاعات را تا حداکثر ۱ ساعت قبل از خرابی بازیابی کرد. در این حالت از دست رفتن اطلاعات بیشتر از ۱ ساعت قابل قبول نیست. فرض کنید سرور یک فروشگاه اینترنتی ساعت ۱۶ از کار افتاده و آخرین نسخه سالم اطلاعات مربوط به ساعت ۱۵ باشد. در این شرایط، سفارش ها و تغییراتی که بین ساعت ۱۵ تا ۱۶ ثبت شده اند ممکن است از بین بروند. اگر RPO تعیین شده برای این فروشگاه ۳۰ دقیقه باشد، روش فعلی بکاپ گیری مناسب نیست؛ زیرا میزان واقعی از دست رفتن اطلاعات از حد قابل قبول بیشتر شده است. مقدار RPO مستقیما بر فاصله زمانی بکاپ ها تاثیر دارد. سامانه ای با RPO روزانه ممکن است با یک نسخه پشتیبان در پایان هر روز مدیریت شود، اما سامانه مالی یا فروشگاهی با RPO چند دقیقه ای به بکاپ های پرتکرار، تکثیر اطلاعات یا راهکارهای محافظت پیوسته از داده نیاز دارد. هرچه اطلاعات سریع تر تغییر کنند و بازسازی آنها دشوارتر باشد، RPO باید کوتاه تر انتخاب شود. از دست رفتن چند ساعت اطلاعات در یک سایت شرکتی شاید خسارت زیادی ایجاد نکند، اما حذف چند ساعت تراکنش بانکی، اطلاعات بیماران یا سفارش های مشتریان می تواند پیامدهای مالی و قانونی جدی داشته باشد.
RTO چیست و بازیابی سرویس چقدر باید طول بکشد؟
خدمات شبکه زمانی موثر است که برای بازگرداندن سرویس های حیاتی، زمان هدف مشخصی وجود داشته باشد. RTO مخفف Recovery Time Objective است و حداکثر زمان قابل قبول برای بازیابی یک سامانه، نرم افزار یا فرایند کاری پس از وقوع حادثه را نشان می دهد. برای مثال، اگر RTO یک سامانه فروش آنلاین ۲ ساعت باشد، تیم فنی باید بتواند حداکثر تا ۲ ساعت پس از خرابی، سرویس را به وضعیت قابل استفاده بازگرداند. این زمان می تواند شامل تشخیص مشکل، تصمیم گیری، آماده سازی سرور جایگزین، بازیابی اطلاعات، راه اندازی نرم افزار و بررسی سلامت سیستم باشد. RTO با زمان واقعی بازیابی تفاوت دارد. RTO یک هدف از پیش تعیین شده است، اما زمان واقعی بازیابی مقداری است که در یک حادثه یا آزمایش ثبت می شود. اگر RTO برابر با ۲ ساعت باشد ولی بازگرداندن سرویس ۵ ساعت طول بکشد، برنامه بازیابی سازمان نتوانسته است هدف تعیین شده را برآورده کند. کوتاه بودن RTO معمولا به زیرساخت قوی تر و هزینه بیشتری نیاز دارد. سازمانی که نمی تواند حتی چند دقیقه قطعی را تحمل کند، ممکن است به سرورهای آماده، ذخیره سازی تکرارشده، دیتاسنتر جایگزین و Failover خودکار نیاز داشته باشد. در مقابل، یک سامانه کم اهمیت ممکن است با بازیابی دستی و RTO چند ساعته یا چند روزه نیز قابل مدیریت باشد. برای تعیین RTO باید هزینه هر ساعت قطعی بررسی شود. کاهش فروش، توقف فعالیت کارکنان، از دست رفتن مشتریان، جریمه های قراردادی و آسیب به اعتبار برند از جمله هزینه هایی هستند که باید در این محاسبه در نظر گرفته شوند.
تفاوت RPO و RTO چیست؟
خدمات پشتیبانی شبکه باید هم از اطلاعات محافظت کند و هم مدت زمان قطعی سرویس را کاهش دهد. به همین دلیل RPO و RTO در کنار یکدیگر تعریف می شوند، اما مفهوم یکسانی ندارند. RPO به میزان اطلاعات از دست رفته مربوط است، در حالی که RTO مدت زمان از دسترس خارج بودن سرویس را مشخص می کند.
| معیار مقایسه | RPO | RTO |
|---|---|---|
| تعریف اصلی | حداکثر میزان قابل تحمل از دست رفتن اطلاعات | حداکثر زمان قابل تحمل برای قطعی سرویس |
| سوال کلیدی | چه مقدار اطلاعات را می توان از دست داد؟ | سیستم تا چه مدت می تواند قطع باشد؟ |
| جهت اندازه گیری | از زمان حادثه به سمت آخرین نسخه سالم | از زمان حادثه تا بازگشت سرویس |
| تاثیر بر زیرساخت | تعیین فاصله بکاپ و روش تکثیر اطلاعات | تعیین سرعت بازیابی و نوع زیرساخت جایگزین |
| نمونه | تحمل از دست رفتن ۳۰ دقیقه اطلاعات | بازگرداندن سرویس حداکثر در ۲ ساعت |
فرض کنید یک سرور ساعت ۱۲ از کار افتاده است. آخرین نسخه سالم اطلاعات مربوط به ساعت ۱۱:۳۰ است و سرویس نیز در ساعت ۱۴ دوباره راه اندازی می شود. در این مثال، میزان واقعی از دست رفتن اطلاعات ۳۰ دقیقه و زمان واقعی بازیابی ۲ ساعت است. اکنون باید این اعداد با RPO و RTO تعیین شده مقایسه شوند.
ممکن است یک سازمان RPO برابر با ۱۵ دقیقه و RTO برابر با ۳ ساعت داشته باشد. در این حالت از دست رفتن ۳۰ دقیقه اطلاعات قابل قبول نیست، اما بازیابی ۲ ساعته در محدوده هدف قرار دارد. به همین دلیل موفقیت در RTO به معنای موفقیت در RPO نیست و هر دو شاخص باید جداگانه اندازه گیری شوند.
چگونه RPO و RTO مناسب را برای کسب و کار تعیین کنیم؟
راه اندازی vdi و سایر راهکارهای مجازی سازی می توانند سرعت بازیابی محیط کاری، نرم افزارها و اطلاعات کاربران را افزایش دهند، اما پیش از انتخاب هر فناوری باید نیاز واقعی کسب و کار به دقت مشخص شود. تعیین RPO و RTO نباید بر اساس حدس، انتخاب عددهای بسیار کوتاه یا در نظر گرفتن یک مقدار یکسان برای تمام سامانه ها انجام شود. هر سرویس در سازمان اهمیت، میزان تغییر اطلاعات، هزینه قطعی و وابستگی متفاوتی دارد؛ بنابراین لازم است اهداف بازیابی برای هر بخش به صورت جداگانه تعیین شوند. برای مثال، توقف چند ساعته سایت معرفی یک شرکت ممکن است تاثیر محدودی بر فعالیت روزانه داشته باشد، اما قطعی سیستم فروش، نرم افزار مالی یا پایگاه داده مشتریان می تواند باعث از دست رفتن درآمد، توقف کارکنان و ایجاد نارضایتی در کاربران شود. از طرف دیگر، تعیین RPO و RTO بسیار کوتاه برای سامانه های کم اهمیت، هزینه زیرساخت و نگهداری را بدون ایجاد ارزش واقعی افزایش می دهد.
شناسایی سامانه ها و فرایندهای حیاتی
نخستین مرحله برای تعیین RPO و RTO، شناسایی تمام سامانه ها، سرورها، نرم افزارها، پایگاه های داده و سرویس هایی است که فعالیت روزانه کسب و کار به آنها وابسته است. این فهرست نباید فقط شامل تجهیزات اصلی شبکه باشد، بلکه باید سرویس های ابری، نرم افزارهای حسابداری، سامانه های فروش، فایل سرورها، ایمیل سازمانی، پایگاه داده مشتریان، سیستم تلفنی و ابزارهای ارتباط داخلی را نیز در بر بگیرد. پس از تهیه فهرست، باید مشخص شود توقف هر سامانه چه تاثیری بر فروش، تولید، ارتباط با مشتری، انجام تعهدات قراردادی و فعالیت کارکنان دارد. برای مثال، از دسترس خارج شدن سامانه ثبت سفارش در یک فروشگاه اینترنتی مستقیما باعث توقف فروش می شود، در حالی که قطعی یک آرشیو قدیمی ممکن است فقط دسترسی به برخی اسناد را برای مدت کوتاهی محدود کند. همچنین باید وابستگی میان سامانه ها بررسی شود. ممکن است یک نرم افزار به ظاهر کم اهمیت، پیش نیاز فعالیت چند سرویس حیاتی باشد. برای نمونه، اگر سامانه احراز هویت از دسترس خارج شود، کاربران نمی توانند وارد نرم افزار مالی، سیستم فروش یا پنل مدیریت شوند. در چنین شرایطی اهمیت واقعی آن سرویس بیشتر از چیزی است که در نگاه اول تصور می شود.
محاسبه هزینه قطعی سرویس
برای تعیین مقدار مناسب RTO باید مشخص شود هر ساعت یا هر دقیقه قطعی یک سرویس چه مقدار خسارت برای سازمان ایجاد می کند. این خسارت فقط به فروش مستقیم از دست رفته محدود نیست. توقف فعالیت کارکنان، پاسخگو نبودن به مشتریان، تاخیر در تحویل خدمات، جریمه قراردادها، کاهش بهره وری و هزینه اضافه کاری تیم فنی نیز باید در محاسبات در نظر گرفته شوند. برای مثال، اگر قطعی یک سامانه فروش باعث شود شرکت در هر ساعت ۵۰ سفارش را از دست بدهد، می توان ارزش متوسط هر سفارش را محاسبه کرد و زیان مستقیم فروش را به دست آورد. علاوه بر این، بخشی از مشتریان ممکن است پس از مشاهده اختلال به سراغ رقیب بروند یا اعتماد خود را به برند از دست بدهند. این نوع خسارت اعتباری شاید به صورت فوری قابل اندازه گیری نباشد، اما می تواند در بلندمدت تاثیر بیشتری نسبت به زیان مستقیم داشته باشد. در بعضی کسب و کارها، قطعی سرویس پیامدهای قانونی و قراردادی نیز دارد. برای مثال، شرکت ارائه دهنده خدمات آنلاین ممکن است در قرارداد سطح خدمات تعهد کرده باشد که سامانه در درصد مشخصی از زمان در دسترس باشد. عبور از این حد می تواند باعث پرداخت جریمه، بازپرداخت هزینه مشتری یا حتی فسخ قرارداد شود. چنین هزینه هایی باید هنگام تعیین RTO لحاظ شوند.
بررسی ارزش و سرعت تغییر اطلاعات
برای تعیین RPO باید مشخص شود اطلاعات هر سامانه با چه سرعتی تولید یا تغییر می کنند و از دست رفتن آنها چه پیامدی برای سازمان دارد. سامانه ای که در هر دقیقه تعداد زیادی تراکنش، سفارش یا اطلاعات مشتری را ثبت می کند، به RPO کوتاه تری نسبت به سامانه ای نیاز دارد که اطلاعات آن فقط چند بار در هفته به روز می شود.برای مثال، یک فروشگاه اینترنتی ممکن است در هر دقیقه چندین سفارش، پرداخت و تغییر موجودی ثبت کند. اگر آخرین نسخه پشتیبان مربوط به ۴ ساعت قبل باشد، در صورت خرابی سرور حجم زیادی از اطلاعات مالی و سفارش های مشتریان از دست خواهد رفت. بازسازی دستی این اطلاعات نیز ممکن است زمان بر، پرهزینه یا حتی غیر ممکن باشد. در چنین شرایطی استفاده از بکاپ های پرتکرار یا تکثیر اطلاعات ضروری است. در مقابل، اطلاعات یک سایت معرفی خدمات ممکن است هفته ای یک یا دو بار تغییر کنند. برای چنین سامانه ای، RPO چند ساعته یا حتی یک روزه می تواند کافی باشد؛ زیرا محتوای از دست رفته را می توان با هزینه و زمان محدود دوباره ایجاد کرد. بنابراین ارزش داده و دشواری بازسازی آن، نقش مهمی در تعیین RPO دارند.
سخن پایانی درباره RPO و RTO
RPO و RTO دو شاخص اصلی برای طراحی برنامه بکاپ و بازیابی بحران هستند. RPO مشخص می کند چه مقدار از اطلاعات قابل از دست رفتن است و RTO حداکثر زمان مجاز برای بازگرداندن سرویس را نشان می دهد. تعیین عددهای غیر واقعی یا یکسان برای تمام سامانه ها می تواند هزینه های زیرساخت را افزایش دهد یا سازمان را در برابر حوادث آسیب پذیر کند. بهترین روش این است که اهمیت هر سرویس، سرعت تغییر اطلاعات، هزینه قطعی و بودجه کسب و کار بررسی شود و سپس راهکارهای فنی مناسب برای رسیدن به اهداف تعیین شده اجرا و آزمایش شوند.
سوالات متداول درباره RPO و RTO
- RPO صفر به چه معناست؟RPO صفر یعنی سازمان نمی تواند هیچ بخشی از اطلاعات را از دست بدهد. دستیابی به این هدف معمولا به تکثیر همزمان اطلاعات، ذخیره سازی مقاوم و زیرساخت های پیشرفته نیاز دارد. RPO صفر برای تمام کسب و کارها ضروری یا مقرون به صرفه نیست.
- آیا RTO و RPO باید مقدار یکسانی داشته باشند؟خیر. RPO و RTO دو نیاز متفاوت را اندازه گیری می کنند. ممکن است یک سامانه RPO برابر با ۱۵ دقیقه و RTO برابر با ۴ ساعت داشته باشد. مقدار هر شاخص باید بر اساس اهمیت اطلاعات و میزان تحمل قطعی تعیین شود.
- آیا داشتن بکاپ برای رسیدن به RPO و RTO کافی است؟خیر. بکاپ فقط یکی از بخش های برنامه بازیابی است. سلامت نسخه پشتیبان، سرعت Restore، دسترسی به زیرساخت جایگزین، مستندات و آمادگی تیم فنی نیز بر دستیابی به RPO و RTO تاثیر مستقیم دارند.
