RPO و RTO: اگر همین حالا سرور بسوزد، چقدر داده و چند ساعت از دست می‌دهید؟

در جلسه‌ای که دربارهٔ زیرساخت حرف می‌زنیم، معمولاً می‌پرسم: «اگر همین الان این سرور بسوزد، چند دقیقه داده از دست می‌رود و چند ساعت طول می‌کشد تا کار دوباره راه بیفتد؟» تا امروز، به‌ندرت کسی عدد داشته است. جواب رایج «بکاپ داریم» است، که جواب این سؤال نیست.

این دو عدد، هستهٔ هر برنامهٔ تداوم کارند و هر تصمیم فنی دیگری از آن‌ها بیرون می‌آید.

دو عدد، به زبان ساده

RPO — بیشترین مقدار داده‌ای که حاضرید از دست بدهید، بر حسب زمان. اگر بکاپ لاگ هر ۱۵ دقیقه گرفته می‌شود، RPO شما ۱۵ دقیقه است: در بدترین حالت، ۱۵ دقیقه آخر کار از بین می‌رود.

RTO — بیشترین مدتی که حاضرید سرویس پایین باشد. اگر بازگرداندن دیتابیس ۳ ساعت طول بکشد و نصب سرور تازه ۲ ساعت، RTO واقعی شما ۵ ساعت است، هر چقدر هم که در قرارداد نوشته باشید یک ساعت.

تفاوت کلیدی: RPO دربارهٔ گذشته است (چقدر از قبلِ حادثه گم می‌شود) و RTO دربارهٔ آینده (چقدر تا برگشتن طول می‌کشد). می‌شود RPO عالی و RTO افتضاح داشت: بکاپ لاگ هر دقیقه، ولی روی نواری که برگرداندنش یک روز طول می‌کشد.

عدد واقعی‌تان چقدر است؟ (نه عددی که آرزو دارید)

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

RTO واقعی‌تان مجموع این‌هاست، و تقریباً همیشه از تخمین اولیه بزرگ‌تر است:

• زمان تا فهمیدن حادثه (اگر پایش ندارید، می‌تواند ساعت‌ها باشد)
• زمان تا تصمیم‌گیری و جمع شدن آدم‌ها — نیمه‌شب، این عدد بزرگ است
• آماده کردن سخت‌افزار یا ماشین مجازی جایگزین
• نصب و پیکربندی SQL Server، برگرداندن master و msdb، لاگین‌ها و جاب‌ها
• کپی فایل‌های بکاپ از محل نگه‌داری (این را دست‌کم نگیرید: ۵۰۰ گیگ روی شبکهٔ یک‌گیگی، بیش از یک ساعت است)
• بازگرداندن: فول + آخرین دیفرنشیال + همهٔ لاگ‌های بعدش
• بررسی سلامت و صحت داده
• تغییر رشتهٔ اتصال اپلیکیشن‌ها و بالا آوردنشان

تنها راه دانستن این عدد، اندازه‌گیری است. یک بار در محیط آزمایشی انجامش دهید و زمان بگیرید. عددی که به دست می‌آید معمولاً دو تا سه برابر حدس اولیه است.

هزینه، همان چیزی است که تصمیم را می‌گیرد

RPO صفر و RTO صفر ممکن است — و گران. هر پله پایین آمدن، چند برابر هزینه دارد:

نکتهٔ مهم: این تصمیم فنی نیست، تجاری است. کار مهندس این است که هزینهٔ هر پله را روشن کند و بگذارد کسب‌وکار انتخاب کند. اشتباه رایج، برعکس است: تیم فنی خودش یک سطح را انتخاب می‌کند، کسی از هزینهٔ دو ساعت خوابیدن سرویس خبر ندارد، و روز حادثه معلوم می‌شود انتظارها با واقعیت یکی نبوده.

دسترس‌پذیری بالا، بکاپ نیست

این سوءتفاهم گران است. Always On و میررینگ و کلاستر در برابر خرابی سخت‌افزار محافظت می‌کنند. در برابر DELETE بی‌شرط محافظت نمی‌کنند — آن دستور با وفاداری کامل و در چند میلی‌ثانیه به همهٔ نسخه‌ها همانندسازی می‌شود.

باج‌افزار هم همین‌طور. یک نسخهٔ دوم که به‌صورت زنده هم‌گام است، نسخهٔ دوم رمزشده هم خواهد بود.

بنابراین: دسترس‌پذیری بالا برای RTO است، بکاپ برای RPO و برای خطای انسانی. یکی جای دیگری را نمی‌گیرد و هر دو لازم‌اند.

تمرین، وگرنه فقط یک سند است

برنامه‌ای که تمرین نشده، یک فایل Word است. حداقل سالی یک بار، ترجیحاً شش‌ماهه:

1. یک روز و ساعت مشخص کنید و وانمود کنید سرور اصلی از بین رفته.
2. فقط از چیزهایی استفاده کنید که در حادثهٔ واقعی در دسترس‌اند — نه از دیتابیس زنده، نه از دانشی که فقط در ذهن یک نفر است.
3. زمان هر مرحله را بنویسید.
4. هر جا گیر کردید، همان نقطهٔ شکست واقعی شماست. یادداشتش کنید.

چیزهایی که تقریباً همیشه در اولین تمرین پیدا می‌شوند: گذرواژه‌ای که کسی نمی‌داند، مجوزی که فقط روی سرور قدیمی بوده، جابی که به مسیری اشاره می‌کند که دیگر وجود ندارد، فایل بکاپی که ناقص کپی شده، و رشتهٔ اتصالی که در سه جای مختلف hardcode شده است.

حداقلِ قابل قبول

اگر می‌خواهید فقط سه کار انجام دهید:

1. دو عدد RPO و RTO را برای هر دیتابیس بنویسید و با کسی که مسئول کسب‌وکار است توافق کنید.
2. فاصلهٔ بکاپ لاگ را با RPO هماهنگ کنید و مطمئن شوید یک نسخه جای دیگری است.
3. یک بار بازیابی کامل را با کرنومتر انجام دهید و عدد واقعی RTO را ثبت کنید.

از آن به بعد، هر بار که چیزی تغییر می‌کند — دیتابیس بزرگ‌تر می‌شود، سرور عوض می‌شود — بدانید که این دو عدد هم تغییر کرده‌اند. اندازهٔ داده که دو برابر شود، RTO شما هم تقریباً دو برابر شده، بی آنکه کسی تصمیمی گرفته باشد.