تداوم کسبوکار و برنامه بازیابی
هر سازمانی میگوید پشتیبانگیری دارد. سؤال بعدی معمولاً سکوت میسازد:
آخرین بار کِی از روی پشتیبان، بازیابی کردید؟
پشتیبانگیری، فرایندی است که هر شب اجرا میشود و کسی نگاهش نمیکند. بازیابی، کاری است که یک بار لازم میشود و آن یک بار همهچیز است. و سازمانهای زیادی روزی فهمیدهاند که فایلهای پشتیبانشان ماههاست خالی یا خراباند.
دو عددی که همهچیز را تعیین میکنند
پیش از هر تصمیم فنی، این دو عدد را از کسبوکار بگیرید. این کار مدیر است نه واحد فناوری.
RTO — چقدر میتوانیم پایین باشیم؟ از لحظهٔ خرابی تا بازگشت سرویس.
RPO — چقدر داده میتوانیم از دست بدهیم؟ فاصلهٔ بین آخرین پشتیبان سالم و لحظهٔ خرابی.
مثال روشن: اگر پشتیبانگیری شبانه دارید، RPO شما یک روز کامل است. یعنی اگر ساعت پنج عصر خرابی رخ دهد، کل کار آن روز از بین رفته. برای یک سامانهٔ گزارش داخلی قابل قبول است؛ برای سامانهٔ فروش، فاجعه.
این دو عدد، هزینه را تعیین میکنند و رابطهشان با هزینه خطی نیست:
| RTO / RPO | معماری لازم | هزینهٔ نسبی |
|---|---|---|
| ۲۴ ساعت | پشتیبان شبانه | ۱ |
| ۴ ساعت | پشتیبان مکرر + سرور آماده | ۳ |
| ۱ ساعت | نسخهٔ آمادهٔ گرم | ۶ |
| دقیقه | سامانهٔ فعال-فعال | ۱۵+ |
پس سؤال درست این نیست که «چقدر سریع میخواهید برگردید؟» — جواب همیشه «فوری» است. سؤال درست این است: «حاضرید چقدر بابت هر سطح بپردازید؟»
و به تفکیک سامانه بپرسید. سازمانی که برای همهٔ سامانههایش یک سطح تعریف کند، یا برای سامانهٔ کماهمیت زیادی خرج کرده یا برای سامانهٔ حیاتی کم.
قاعدهٔ ۳-۲-۱
استاندارد قدیمی که هنوز درست است:
سه نسخه از داده، روی دو نوع رسانهٔ متفاوت، یک نسخه در محل جغرافیایی دیگر.
آن بند آخر همان است که معمولاً رعایت نمیشود. پشتیبانی که روی همان سرور یا همان اتاق سرور است، در برابر آتشسوزی، سرقت و سیل هیچ محافظتی ندارد.
سه بند مکمل که در عمل تفاوت میسازند:
یک نسخه باید غیرقابل تغییر باشد. اگر مهاجم یا اشتباه انسانی به سامانه دسترسی دارد، به پشتیبانهای متصل هم دارد. باجافزار دقیقاً همین کار را میکند: اول پشتیبانها را رمز میکند.
پشتیبان باید رمزنگاریشده باشد. پشتیبانی که رمزنگارینشده جایی میرود، نشت دادهای است که هنوز اتفاق نیفتاده.
نگهداری چندنسلی. اگر فقط آخرین نسخه را دارید و خرابی داده سه هفته پیش شروع شده، پشتیبان شما هم خراب است. روزانه برای دو هفته، هفتگی برای سه ماه، ماهانه برای یک سال — نقطهٔ شروع معقولی است.
چیزهایی که در برنامه جا میمانند
پشتیبانگیری از پایگاه داده معمولاً انجام میشود. اینها معمولاً نه:
- فایلهای آپلودشده: تصاویر، اسناد، پیوستها. اغلب حجیمترند و اغلب فراموش میشوند.
- پیکربندی سرور. بازیابی داده روی سروری که نمیدانید چطور تنظیم شده بود، نصف کار است.
- گواهیها و کلیدها.
- تنظیمات سرویسهای بیرونی و اطلاعات دسترسیشان.
- خودِ کد، اگر مخزن جای دیگری آینه نشده باشد.
- دانش: چطور همهٔ اینها را کنار هم میگذارند.
آن آخری بزرگترین شکاف است. اگر بازیابی فقط در سر یک نفر باشد، برنامهٔ شما به حضور آن نفر در لحظهٔ بحران وابسته است.
سناریوها را جدا ببینید
هر خرابی یک شکل ندارد و پاسخها متفاوتاند:
خرابی سختافزار. سادهترین. سرور جدید، بازیابی، ادامه.
خطای انسانی. «جدول را اشتباهی پاک کردیم.» اینجا پشتیبان چندنسلی حیاتی است، چون ممکن است ساعتها بعد کشف شود.
باجافزار. بدترین. نیاز به نسخهٔ غیرقابل تغییر و جدا از شبکه دارد. پشتیبانی که روی درایو شبکهای متصل است، همراه بقیه رمز میشود.
قطع دسترسی به سرویس بیرونی. در بازار ما سناریوی واقعی و محتملی است — نه حادثه، بلکه تصمیم کسی در جای دیگر. اگر بخشی از عملیات به سرویس خارجی وابسته است، برنامهٔ جایگزینش را از قبل داشته باشید، نه در روزی که قطع شد.
از دست رفتن یک نفر. کلیدیترین آدم فنی میرود. این هم تداوم کسبوکار است و پاسخش مستندسازی است و دسترسی مشترک، نه پشتیبانگیری.
حالت کاغذی و کار با ظرفیت کاهشیافته
بخشی که مهندسان معمولاً نادیده میگیرند: در فاصلهٔ خرابی تا بازیابی، سازمان چه میکند؟
برای بعضی کسبوکارها جواب «تعطیل» است و قابل قبول. برای بیمارستان، فروشگاه و شرکت پخش نیست.
پس بخشی از برنامه باید غیرفنی باشد: فرم کاغذی جایگزین، اختیار موقت برای تصمیم دستی، و روش وارد کردن دادههای آن بازه پس از بازگشت. آن بند آخر معمولاً فراموش میشود و بعد از هر قطعی، هفتهها بینظمی میسازد.
و یک الزام فنی که ارزان است و اثرش زیاد: نسخهٔ فقطخواندنی. حتی اگر ثبت ممکن نباشد، دیدن اطلاعات باید ممکن بماند. در بیمارستان و انبار، این تفاوت بین «کند» و «متوقف» است.
تمرین، بدون آن برنامه فقط یک سند است
مهمترین بند این مقاله: سالی دستکم یک بار بازیابی را تمرین کنید.
نه بررسی اینکه فایل پشتیبان وجود دارد — بازیابی کامل روی یک محیط جدا، با سنجش زمان.
تقریباً همیشه چیزی پیدا میشود: فایلی که در پشتیبان نبود، رمزی که کسی نمیدانست، مرحلهای که در مستندات نیامده، یا اینکه بازیابی شش ساعت طول میکشد در حالی که RTO چهار ساعت اعلام شده بود.
پیدا کردن اینها در تمرین، بینهایت ارزانتر از پیدا کردنشان در بحران است.
و سه چیز را در تمرین بسنجید: واقعاً چقدر طول کشید، آیا بدون کمک آن یک نفر کلیدی هم ممکن بود، و آیا داده کامل بود.
نسخهٔ حداقلی برای سازمان کوچک
اگر امروز هیچ برنامهای ندارید، این پنج بند بیشتر ریسک را پوشش میدهد و در یک هفته قابل انجام است:
۱. پشتیبانگیری خودکار روزانه، شامل فایلها نه فقط پایگاه داده. ۲. یک نسخه در محل جغرافیایی دیگر و رمزنگاریشده. ۳. هشدار در صورت شکست پشتیبانگیری. پشتیبانی که سه هفته است اجرا نشده و کسی خبر ندارد، وجود ندارد. ۴. یک صفحه دستورالعمل بازیابی، نوشته و در دسترس بیرون از همان سامانه. ۵. یک تمرین بازیابی در سال.
بند سوم را دستکم نگیرید. شایعترین شکل شکست در این حوزه، پشتیبانگیریای است که ماههاست بیصدا خطا میدهد.
سازوکار پاسخ در لحظهٔ خرابی — نقشها، ترتیب کارها، اطلاعرسانی — موضوع جدایی است که در مدیریت رخداد نوشتهایم.