می‌دانیم که عواملی مانند قطع شدن برق، خرابی سخت‌افزار و بحران‌هایی از این دست، ممکن است باعث بروز اختلال در پایگاه داده شود. در این مواقع کاربران و ادمین‌های سیستم، با یک موقعیت بحرانی مواجه هستند که باید پیشاپیش خود را برای مواجهه با آن آماده کرده باشند.
پایگاه داده اصلی‌ترین بخش سیستم برای بازیابی و راه‌اندازی مجدد است و در مواقع بحرانی دفاع از پایگاه داده، ضروری‌ترین اقدام است. برای بررسی اقداماتی که لازم است انجام دهیم تا در این مواقع کمترین آسیب متوجه پایگاه داده شود، می‌توانیم حداقل از سه منظر به موضوع نگاه کنیم و در نهایت با توجه به نیاز مجموعه یا سازمان خود، اقدامات لازم را به اجرا در بیاوریم.
سه پارامتری که در ارتباط با بهینه شدن عملکرد پایگاه داده و رسیدن به بیشترین پایداری ممکن، باید در نظر گرفته شوند به ترتیب زیر است:
- محاسبه هزینه‌ی قطع شدن سیستم
- تعیین مدت زمان مناسب برای بازیابی سیستم RTO
- حد قابل قبول از دست رفتن اطلاعات RPO
این سه پارامتر، علاوه بر کمک به بهینه شدن عملکرد سیستم در مواقع بحرانی ، می‌توانند در مواردی که به تصمیم خودمان و به صورت برنامه‌ریزی شده اقدام به قطع کردن سیستم می‌کنیم نیز منجر به اتخاذ بهترین تصمیم شوند.
طبیعی‌ست که اگر بخواهیم.بهترین تصمیم را در تهیه، نصب و نگهداری از پایگاه داده اتخاذ کنیم، لازم است که این سه منظر را بهتر درک کنیم و جایگاه مطلوب مجموعه خود را در نسبت با هرکدام از این سه پارامتر مشخص کنیم و با اولویت بندی و انتخاب بین آنها، به بهترین ترکیب ممکن دست پیدا کنیم.
برای مراقبت از پایگاه داده در مواجهه با بحران باید دقیق محاسبه کنیم و هوشمندانه برای پیشگیری اقدام کنیم.
هزینه‌ی قطع شدن سیستم Cost of Downtime
هزینه‌ها همیشه از نوع هزینه‌ی مستقیم کوتاه‌مدت نیستند؛ ما باید بتوانیم مجموع «خسارات» وارده از بابت قطع‌شدن سیستم، اعم از هزینه‌های کوتاه‌مدت و بلندمدت را محاسبه کنیم. خسارات کوتاه مدت می‌تواند ارتباط مستقیم با دستمزد افراد مشغول در مجموعه و هزینه های جاری روزانه، هفتگی و ماهیانه داشته باشد و خسارات بلندمدت را می‌توان با محاسباتی از قبیل تاثیری که قطع‌شدن سیستم می‌تواند بر اعتبار مجموعه بگذارد، مد نظر قرار داد.
بدیهی است که محاسبه‌ی این هزینه، به عوامل متعددی از جمله مقیاس مجموعه، میزان درآمد خالص، اهداف و استراتژی آن وابسته است و برخلاف ساده‌سازی انجام شده، تعیین میزان هزینه قطع‌شدن سیستم، اصلاً و ابداً کار ساده‌ای نیست و اگر بخواهیم هزینه‌های ناشی از « قطع‌شدن سیستم» را به حداقل برسانیم، چاره‌ای جز محاسبه‌ی دقیق کمیّت‌های تاثیرگذار بر آن و رسیدن به بازه مطلوب مدنظرمان نخواهیم داشت.
در نهایت برای اینکه اقدامات خود را هدفمند کنیم، نیاز به تعیین میزان پایداری سیستم داریم. به همین منظور و برای ساده‌تر شدن مسئله، جدولی تعبیه شده است که بتوانیم تا حد امکان تخمین بهتری از نیازمان داشته باشیم و به سمت تهیه محصولات و خدماتی برویم که این نیازها را ارضاء می‌کنند:
با توجه به جدول بالا، برای مثال اگر بازه‌ی یک ساله مدنظرمان باشد، طبیعتاً ۳۶۵ روز را باید مبنا بگذاریم و اگر بعد از بررسی به این نتیجه رسیدیم که در یک سال نهایتا ۳۶.۵ روز می‌توانیم قطع بودن سیستم‌مان را تحمل کنیم، معنایش این است که یک سیستم با درصد پایداری ۹۰ درصد می‌تواند پاسخگوی نیاز ما باشد.
مدت زمان بازیابی سیستم Recovery Time Objective
سوال اصلی این است که«چه میزان از قطع‌‌بودن سیستم مورد قبول است؟» با در نظر گرفتن حداکثر زمانی که می‌توانیم قطع بودن و عدم دسترسی به سیستم را در بازه‌های زمانی مختلف ، بدون آسیب رسیدن به اهداف استراتژیک مجموعه تحمل کنیم، می توانیم درصد پایداری مورد نیازمان را اندازه بگیریم و هدف خود را در این زمینه مشخص کنیم.
واضح است که برای تعیین Recovery Time Objective باید به عوامل متعددی توجه شود، چرا که وابستگی مستقیمی با تمامی فعالیت‌ها و اهداف مجموعه دارد؛ اما برای اینکه بتوانیم قدم اول را برداریم چاره‌ای جز این نداریم که تا حد امکان مسئله را ساده‌تر کنیم و با حداکثر شفافیت ممکن به آن پاسخ بدهیم.
دو عامل اساسی که در راه‌اندازی مجدد سیستم نقش بازی می‌کنند، «کیفیت تجهیزات» و «کارآمدی پرسنل» هستند. برای رسیدن به نقطه بهینه، باید بتوانیم به نسبت پایداری مدنظرمان، مناسب ترین تجهیزات و کارآمدترین افراد را در اختیار داشته باشیم.
دو عامل اساسی که در راه‌اندازی مجدد سیستم نقش بازی می‌کنند، «کیفیت تجهیزات» و «کارآمدی پرسنل» هستند.
حد قابل‌قبول از دست رفتن اطلاعات Recovery Point Objective
حداکثر اطلاعاتی که اگر از دست برود، منافع مجموعه‌ی ما را دچار اشکال یا صدمه جدی نمی‌کند چه میزان است؟
هدف ما از پاسخ دادن به این سوال این است که بتوانیم به یک «مدت زمان مشخص» برسیم. مدت زمانی که اگر در آن، از اطلاعات خود پشتیبان‌گیری‌ای نداشته باشیم، آسیب اساسی‌ای متوجه‌مان نمی‌شود.
«مدت زمان اطلاعات از دست رفته» بسته به اهمیتی که برای ما دارد، باید مشخص شود. برای مثال، اگر کسب‌وکار ما به نحوی باشد که در مدت زمان یک ساعت، ۱۰۰۰۰ عملیات با سیستم انجام بشود و اطلاعات زیادی در پایگاه داده ذخیره شود، در صورت «از دست دادن یک ساعت اطلاعات» دچار آسیب‌های جدیِ مالی و اعتباری خواهیم شد. اما اگر کسب و کارمان جوری باشد که نهایتاً دو عملیات در طی یک ساعت انجام شود، احتمالاً آسیب کمتری از «از دست دادن یک ساعت اطلاعات» خواهیم خورد. البته حتماً عوامل دیگری نظیر ارزش اطلاعات و حجم مبادلات مالی و …. هم باید در نظر گرفته شود تا بتوانیم به میزان بهینه RPO برسیم.
حالا تصور کنید که در فرایند ریکاوری، آخرین اطلاعاتِ سالم و قابل استفاده مربوط به ۱۰ ساعت قبل باشد و ما پیشاپیش خود را برای رسیدن به RPO بر مبنای ۱۴ ساعت آماده کرده باشیم. در این صورت خطر شدیدی متوجه کسبوکارمان نخواهد بود. اما اگر این تخمین اشتباه از کار در بیاید و ما مثلاً خود را برای رسیدن به Recovery Point Objective بر مبنای ۵ ساعت آماده کرده باشیم، آسیبی جدی متوجه‌مان خواهد شد که بعضاً ممکن است جبران‌ناپذیر باشد.
در اینجا نیز دو عامل اساسی که در «مدت زمان اطلاعات از دست رفته» نقش بازی می‌کنند، «مدل پشتیبان‌گیری» و «نظم پشتیبان‌گیری» هستند. برای رسیدن به نقطه بهینه ، بهینه‌سازی پشتیبان‌گیری اساسی‌ترین کاری‌ست که باید انجام شود.
دو عامل اساسی که در «مدت زمان اطلاعات از دست رفته» نقش بازی می‌کنند، «مدل پشتیبان‌گیری» و «نظم پشتیبان‌گیری» هستند.
قطع شدن ارتباط با Database چه هزینه‌هایی را به مجموعه تحمیل می‌کند؟
دو نوع هزینه‌ی کلی که متأثر از «مدت زمان راه اندازی مجدد» و « میزان اطلاعات از دست رفته» است و می‌تواند هم از لحاظ مالی مجموعه‌مان را متضرر کند و هم به اعتبار مجموعه خدشه وارد کند.
RTO و RPO و اقدام پیشگیرانه به هم چه ارتباطی دارند؟
هرچقدر مدت زمان RTO و RPO کمتر باشد، نشان‌دهنده‌ی آمادگی بالاتر ما برای مواجهه با بحران است.
برای درک بیشتر اهمیت دو شاخص RTO و RPO و میزان کارآمدی کسبوکارمان در زمان مواجهه با قطع‌شدن سیستم Downtime به کمک جدول زیر می‌توانیم تصمیم‌های موثرتری اتخاذ کنیم:
به زبان ساده تر، در واقع RPO را می‌توان بیشترین فاصله‌ی بین دو پشتیبان‌گیری(بکاپ) دانست که در حالت Active Data Guard به حداقل می‌رسد و RTO را نیز با روش‌های مختلفی بالاخص تجهیز سخت‌افزاری متناسب و مدیریت زمان در نصب و راه‌اندازی می‌توان به حداقل رساند و وقتی این اتفاق بیافتد، طبیعتاً کمترین آسیب متوجه پایگاه داده ما خواهد بود. چه قطع‌شدن سیستم‌مان خودخواسته باشد، چه ناخواسته!
