بازیابی زمان هدف (RTO) چیست؟
چه مدت یک شرکت می تواند توانایی داشتن یک سیستم مربوط به فرایند تجارت را داشته باشد؟ زمان بهبودی (RTO) در دقایقی ، چند ساعت یا چند روز اندازه گیری می شود. این قانون اعمال می شود: هرچه کوتاه تر باشد بهتر است. به عنوان مثال ، اگر یک RTO 24 ساعته باشد ، مدیریت متقاعد شده است که خراب کردن عملیات را می توان برای یک روز کامل مقابله کرد. اما بعد از 24 ساعت حداکثر ، شرکت می تواند خسارات جبران ناپذیری متحمل شود.
بهبودی نقطه هدف (RPO) چیست؟ سیستم مهم IT شکست می خورد؟ نقطه بازیابی (RPO) حداکثر مقدار داده را می توان در سناریوی فاجعه از بین برد. از آنجا که بیت ها و بایت ها چیزی در مورد کیفیت داده ها نمی گویند ، این متریک نیز در واحدهای زمانی ثبت می شود – با توجه به فرکانس با آنها پشتیبان گیری انجام می شود. موارد زیر در اینجا صدق می کند: هرچه کوچکتر بهتر باشد. هرچه زمان بین دو نسخه پشتیبان کوتاه تر باشد ، داده کمتری از دست می رود. اگر به هیچ وجه از دست دادن داده قابل تحمل نباشد ، RPO صفر ثانیه است. به عنوان مثال ، شرکت هایی که داده های خود را یک بار در روز از نیمه شب نسخه پشتیبان تهیه می کنند ، از نظر تئوری باید از یک RPO 24 ساعته استفاده کنند. زیرا اگر سیستم ها توسط پنج تا دوازده از بین بروند ، می توانند داده های به ارزش 24 ساعت را از دست دهند. با این حال ، اگر یک شرکت بتواند حداکثر هشت ساعت مقابله کند ، باید هرچه سریعتر چرخه های تهیه نسخه پشتیبان را کوتاه کند.
زمان بازیابی واقعی
سرانجام ، برنامه های بازیابی فاجعه یا برنامه های تداوم مشاغل نیز RTA ، زمان بازیابی واقعی (زمان بازیابی واقعی) را تعریف می کند: این شکل کلیدی ، زمان و روش مورد نیاز برای بازیابی سیستم های IT را پس از اضطراری مشخص می کند. RTA واقعی اغلب از طریق یک تمرین اضطراری یا ریکاوری مشخص می شود. کارشناسان IT ، مشابه تمرین آتش نشانی ، در محیط های شبیه سازی شده آزمایش می کنند که چه مدت طول می کشد تا با استفاده از آنها اقدامات لازم برای احیای محیط های معیوب سیستم یا بازسازی داده های از دست رفته انجام شود. RTA همچنین یک واحد زمان است. همین مسئله در اینجا نیز صدق می کند: کوتاهتر ، بهتر.
تجزیه و تحلیل های فردی مورد نیاز است.
هنگام مذاکره درباره قراردادهای میزبانی چارچوب – توافق نامه سطح خدمات (SLA) – ارقام کلیدی RTO و RPO نقش مهمی برای Adacor بازی می کنند. با این حال ، این معیارها را نمی توان از برنامه تجاری یا تجزیه و تحلیل داده ها استخراج کرد. آنها باید بطور جداگانه از الزامات شرکت مشتری مربوطه مشتق شوند.
RTO به الزامات عمومی تجارت اشاره دارد. و RTO همان RTO نیست! کد به شدت به واقعه خسارت بستگی دارد. چگونه می توان با خرابی سرور مقابله کرد؟ اثرات "خراب شدن" هارد دیسک چیست؟ چگونه با تهیه نسخه پشتیبان ناقص برخورد می کنید؟ و چه حوادث خسارت محتمل است؟ برای یک شرکت سفارش دهنده نامه آنلاین ، خرابی سرور سیستم وب در آستانه کریسمس مطمئناً معنای متفاوتی نسبت به یک بنیاد شرکتی دارد که از وب سایت خود در درجه اول برای اهداف تصویر و نمایش استفاده می کند. در اینجا مشخص می شود: RTO به مدل تجارت و کل زیرساختهای شرکت ، و نه فقط داده های ذخیره شده اشاره دارد. بنابراین تعیین RTO نسبتاً پیچیده است ، زیرا کلیه فرایندهای IT در کانون توجه قرار دارند.
برای تعیین RPO ، شرکت ها به نوبه خود باید از نزدیک به داده های خود – مقادیر ، ساختارها و کیفیتها نگاه کنند. از کدام داده ها باید نسخه پشتیبان تهیه شود و چند بار؟ ارزیابی این مسئله پیچیده تر از تعیین RTO است. برای دستیابی به اهداف RPO ، انجام نسخه پشتیبان تهیه در فاصله مناسب کافی است. به همین دلیل ، اقدامات برای دستیابی به اهداف RPO نیز می تواند بسیار خوب خودکار شود.
امنیت 100٪ وجود ندارد
Adacor از مشتریان در تعیین چهره های کلیدی مانند RTO و RPO برای شرکتشان پشتیبانی می کند. علاوه بر این ، ما به شما توصیه می کنیم که اقدامات امنیتی را می توان از معیارها بدست آورد. تمرکز روی این است که اقدامات معقول و قابل استفاده از نظر اقتصادی هستند. اطمینان حاصل کنید! مقدار ایده آل برای RTO و RPO صفر است: بدون خرابی و از دست دادن داده ها. با این حال ، تحقق این امر از لحاظ فنی – به عنوان مثال ، با آینه سازی مکرر همه برنامه های اصلی در حافظه اصلی در مراکز مختلف داده – فقط در موارد نادر موارد بسیار باورنکردنی و پرهزینه خواهد بود. با این حال ، این امر ضروری نیست زیرا تمام داده ها و فرآیندهای یک شرکت به همان اندازه حساس نیستند.
نحوه انجام Adacor با SLA ها و استراتژی ادامه کار
Adacor هنگام مذاکره با SLA و طراحی یک تجارت معنادار ، حساب می کند. استراتژی استمرار نکات زیر:
- کدام سناریو فاجعه احتمالاً وجود دارد (به عنوان مثال حملات هکرها ، خسارت های ابتدایی ناشی از آتش سوزی ، آب یا طوفان ، از بین رفتن سیستم ها یا داده های ناشی از سرقت یا خطاهای کاربر)؟
- برای کدام مناطق ارائه می دهد؟ سخت افزار جایگزینی یا زمان تحویل تضمین شده برای دستگاه های جایگزینی؟
- کدام استراتژی ها و چرخه های پشتیبان باید ایجاد ، تنظیم و نظارت شوند؟
- آیا می توان زمان بازیابی یک نسخه پشتیبان کامل داده را بهینه کرد؟ چه زمانی آخرین بار سیستم IT برای بدترین مورد آزمایش شده است؟
- آیا یک شرکت سناریوهایی در حال گذار را ایجاد کرده است که می تواند از آن استفاده کند تا بتواند زمان را تا زمان احیای حالت اصلی بازگرداند؟ به روشنی؟ کدام سرویس ها ، بخش ها یا کاربران باید اولین کسی باشند که پس از یک شکست به کار خود بازگشتند؟
نتیجه گیری: بهتر است RTO و RPO را بصورت جداگانه تعیین کنید
برای ایجاد یک برنامه بازیابی فناوری اطلاعات برای شرکتی که از یک شرکت زنده مانده در در صورت بروز اورژانس ، و همچنین ارزان قیمت است ، بهتر است RTO و RPO را تعیین کنید. این کار فقط برای شرکت مربوطه قابل انجام است: هیچ قاعده ای برای تعیین معیارها وجود ندارد. علاوه بر این ، RTO و RPO باید در فواصل منظم آزمایش شوند. شرکتها می توانند به همراه ارائه دهنده خدمات مدیریت شده یا کارشناسان واجد شرایط در زمینه امنیت فناوری اطلاعات ، یک طرح پاسخ ساختاری طراحی کنند که در صورت بروز یک حادثه غیرمترقبه فراخوانده شود. اگر مدیریت توسط ترس یا نیازهای امنیتی بیش از حد هدایت نشود ، بلکه با ارزیابی واقع بینانه از خطرات و محدودیت های تحمل ، از سرمایه گذاری های زیاد در حفاظت از RTO و RPO جلوگیری شود ، می توان از این کار جلوگیری کرد. همین امر در فناوری اطلاعات مانند زندگی "واقعی" نیز صدق می کند: هیچ چیزی به اندازه امنیت 100٪ وجود ندارد.
.
