در زمان بحرانهایی مانند جنگ، معمولاً اولین چیزی که به ذهن می‌رسد ساختمان‌های تخریب‌شده و زیرساخت‌های فیزیکی آسیب‌دیده است. اما برای یک سازمان، بحران میتواند شکل دیگری هم داشته باشد: از دست رفتن دادهها و توقف سرویس‌دهی.
حتی اگر ساختمان و تجهیزات فیزیکی سالم بمانند، از دست رفتن اطلاعات یا خارج شدن سرویس‌های حیاتی از دسترس میتواند فعالیت یک کسب‌وکار را برای ساعت‌ها، روزها یا حتی بیشتر مختل کند. به همین دلیل، حفاظت از داده و برنامه‌ریزی برای ادامه سرویس در بحران، بخشی جدی از مدیریت زیرساخت فناوری اطلاعات است.
از دست رفتن دیتا؛ بحرانی فراتر از حذف چند فایل
وقتی دیتای یک سازمان از بین می‌رود، مسئله فقط حذف چند فایل یا دیتابیس نیست. بخشی از حافظه سازمان، سوابق عملیاتی، ارتباط با مشتریان و اطلاعات موردنیاز برای ادامه فعالیت از دسترس خارج میشود.
در چنین شرایطی ممکن است:
- قراردادها، سوابق مشتریان و اطلاعات مالی از بین بروند یا در دسترس نباشند.
- سرویس‌های سازمان برای ساعت‌ها یا روزها متوقف شوند.
- تیم‌ها مجبور شوند بخشی از فرآیندها را از ابتدا بازسازی کنند.
- اعتماد مشتریان و اعتبار سازمان تحت تأثیر قرار بگیرد.
تجربه آوید از مدیریت بحران دادهها
در جریان بحران اخیر، ما در رایانش ابری آوید با موقعیت‌هایی روبه‌رو شدیم که اهمیت آمادگی قبلی سازمان‌ها را بیش از گذشته نشان داد. سازمان‌هایی که برای حفاظت از دادهها، بکاپ و ادامه سرویس برنامه مشخص‌تری داشتند، امکان بیشتری برای حفظ سرویس‌های حیاتی یا بازیابی سریع‌تر آن‌ها داشتند.
این تجربه یک نکته مهم را دوباره یادآوری کرد: برنامه‌ریزی برای بحران نباید از روز وقوع بحران آغاز شود.
در ادامه، از این زاویه به موضوع نگاه می‌کنیم که دیزاستر ریکاوری دقیقاً چه نقشی دارد، بکاپ چگونه باید در کنار آن قرار بگیرد و یک سازمان برای افزایش آمادگی خود چه اقداماتی میتواند انجام دهد.
دیتا، قلب کسب‌وکار شماست
تجهیزات سخت‌افزاری را می‌توان تعمیر یا جایگزین کرد؛ اما درباره داده همیشه چنین امکانی وجود ندارد. اطلاعات مشتریان، دیتابیس‌ها، فایل‌های عملیاتی، تنظیمات سرویسها و سوابق سازمانی در طول زمان شکل گرفته‌اند و از دست رفتن آن‌ها میتواند مستقیماً بر فعالیت سازمان اثر بگذارد.
از دست رفتن داده ممکن است به توقف فرآیندهای عملیاتی، دوباره‌کاری گسترده، اختلال در ارائه خدمات و افزایش هزینه بازیابی منجر شود.
به همین دلیل، حفاظت از داده و تداوم سرویس باید بخشی از استراتژی فناوری اطلاعات سازمان باشد. دو مفهوم مهم در این حوزه عبارت‌اند از:
- دیزاستر ریکاوری (Disaster Recovery)
- تداوم کسب‌وکار (Business Continuity)
دیزاستر ریکاوری چیست؟
دیزاستر ریکاوری (Disaster Recovery) مجموعهای از برنامه‌ها، فرآیندها و زیرساخت‌هایی است که برای بازیابی دادهها و سرویس‌های فناوری اطلاعات پس از یک اختلال جدی در نظر گرفته میشود.
هدف این است که اگر سایت اصلی سازمان، بخشی از زیرساخت یا یک سرویس حیاتی از دسترس خارج شد، مسیر مشخصی برای بازیابی و ادامه فعالیت وجود داشته باشد.
در یک سناریوی مناسب دیزاستر ریکاوری، سازمان از قبل می‌داند چه سرویس‌هایی باید در اولویت بازیابی قرار بگیرند، دادهها از کجا بازیابی شوند و زیرساخت جایگزین چگونه در دسترس قرار گیرد.
ساختار دیزاستر ریکاوری در عمل
یک سناریوی دیزاستر ریکاوری میتواند بر اساس نیاز و معماری هر سازمان متفاوت باشد، اما معمولاً سایت اصلی و یک زیرساخت پشتیبان در آن نقش کلیدی دارند.
سایت اصلی (Primary Site)
سایت اصلی همان زیرساختی است که سرویس‌های روزمره سازمان روی آن اجرا می‌شوند و کاربران در شرایط عادی از آن استفاده می‌کنند.
سایت پشتیبان یا سایت بحران (DR Site)
سایت بحران، زیرساختی جدا از سایت اصلی است که برای بازیابی دادهها یا اجرای سرویس‌های موردنیاز در زمان اختلال در نظر گرفته میشود.
جداسازی مناسب سایت اصلی و سایت بحران اهمیت زیادی دارد؛ زیرا یکی از اهداف DR این است که یک رخداد واحد نتواند هم‌زمان زیرساخت اصلی و پشتیبان را از دسترس خارج کند.
پیاده‌سازی دیزاستر ریکاوری الزاماً به معنای ساخت یک زیرساخت بزرگ و مشابه سایت اصلی نیست. نقطه شروع میتواند حفاظت از دادهها و سرویس‌هایی باشد که توقف یا از دست رفتن آن‌ها بیشترین آسیب را به سازمان وارد میکند.
آیا زیرساخت بحران باید هم‌اندازه سایت اصلی باشد؟
لزومی ندارد ظرفیت سایت بحران در همه سناریوها دقیقاً برابر با سایت اصلی باشد. نیاز واقعی باید بر اساس سرویس‌های حیاتی، ظرفیت موردنیاز در زمان بحران، اهداف بازیابی و بودجه سازمان تعیین شود.
در گام اول؛ حفاظت از داده‌های حیاتی
در سطح اولیه، تمرکز میتواند روی حفاظت از مهم‌ترین داده‌های سازمان باشد؛ از جمله دیتابیس‌ها، فایل‌های کلیدی، تنظیمات و پیکربندی‌های ضروری.
در گام بعد؛ ادامه سرویس‌های ضروری
پس از حفاظت از دادهها، باید مشخص شود کدام سرویسها در زمان بحران باید فعال بمانند و چه میزان ظرفیت پردازشی برای ارائه حداقل سطح قابل‌قبول خدمت لازم است.
این رویکرد کمک میکند سازمان به‌جای متوقف کردن پروژه به دلیل هزینه یا پیچیدگی، پیاده‌سازی DR را بر اساس اولویت‌های واقعی خود مرحله‌بندی کند.
بکاپ؛ بخش جدایی‌ناپذیر برنامه بازیابی
وجود سایت بحران به‌تنهایی کافی نیست. دادهها نیز باید با یک سیاست مشخص، منظم و قابل‌آزمون محافظت شوند. بکاپ زمانی ارزش واقعی خود را نشان میدهد که نسخه موردنیاز سالم باشد و امکان بازیابی آن وجود داشته باشد.
در طراحی سیاست بکاپ، دو موضوع اهمیت ویژه‌ای دارند:
بکاپ‌های چندلایه و استراتژی ۳-۲-۱
یکی از الگوهای شناخته‌شده برای کاهش ریسک از دست رفتن اطلاعات، استراتژی بکاپ ۳-۲-۱ است. در این الگو:
- حداقل سه نسخه از دادهها در نظر گرفته میشود.
- نسخه‌ها روی حداقل دو نوع رسانه یا بستر متفاوت نگهداری می‌شوند.
- حداقل یک نسخه خارج از محل اصلی نگهداری میشود.
خروج بکاپ از سازمان (Offsite Backup)
اگر تمام نسخه‌های پشتیبان در همان ساختمان یا همان زیرساخت اصلی نگهداری شوند، یک حادثه گسترده میتواند نسخه اصلی و بکاپها را هم‌زمان تحت تأثیر قرار دهد.
به همین دلیل، نگهداری حداقل یک نسخه در یک موقعیت مستقل، دیتاسنتر دیگر یا زیرساخت ابری میتواند بخشی از سیاست حفاظت از داده باشد.
نگاه آوید به بکاپ و دیزاستر ریکاوری
در رایانش ابری آوید، بکاپ و بازیابی بخشی از ملاحظات طراحی سرویس‌های ابری هستند. هدف این است که حفاظت از داده صرفاً به تهیه یک نسخه پشتیبان محدود نشود و سناریوی بازیابی نیز در طراحی زیرساخت مورد توجه قرار گیرد.
بکاپ به‌عنوان بخشی از طراحی سرویس
- سناریوی بکاپ از مرحله طراحی سرویس مورد توجه قرار می‌گیرد.
- بازیابی اطلاعات باید در کنار تهیه نسخه پشتیبان دیده شود.
- سیاست نگهداری داده بر اساس نیاز زیرساخت و سرویس تعریف میشود.
زیرساخت مکمل برای سناریوی بحران
بر اساس نیاز هر سازمان، می‌توان زیرساخت پشتیبان را به‌گونه‌ای طراحی کرد که در زمان اختلال، بخشی از دادهها یا سرویس‌های حیاتی امکان بازیابی روی زیرساخت مکمل را داشته باشند.
تجربه آوید در اجرای پروژه‌های زیرساختی نشان داده است که آنچه در روز بحران اهمیت پیدا میکند، صرفاً وجود تجهیزات نیست؛ بلکه داشتن سناریویی است که پیش از بحران طراحی و آزموده شده باشد.
یک تجربه واقعی؛ وقتی بکاپ آوید به اولویت تبدیل شد
در جریان بحران، تماس‌هایی از کارفرمایان داشتیم که دغدغه اصلی آن‌ها دیگر توسعه زیرساخت نبود؛ مسئله این بود که چگونه از داده‌های موجود محافظت کنند و سرویس‌های حیاتی را در دسترس نگه دارند.
در یکی از این تماس‌ها، یکی از کارفرمایان آوید درباره تجربه خود از سرویس بکاپ گفت:
«به‌خاطر تجربه‌هایی که داشتیم، من اطمینان خاطر بسیار بالایی به بکاپ شما دارم. برای من، در این بحران، اولویت اول بکاپ آوید است؛ بقیه زیرساخت‌ها بعد از آن می‌آید.»
اهمیت چنین تجربه‌ای در این است که ارزش بکاپ در زمان تهیه آن مشخص نمی‌شود؛ لحظه‌ای مشخص میشود که سازمان واقعاً به اطلاعات خود نیاز دارد.
اگر فقط دو هفته فرصت داشته باشید، از کجا شروع کنید؟
برای سازمانی که هنوز سناریوی مشخصی برای بحران ندارد، لازم نیست همه چیز از روز اول کامل باشد. می‌توان با شناسایی نقاط حیاتی شروع کرد و در یک برنامه فشرده، حداقل‌های لازم برای افزایش آمادگی را ایجاد کرد.
ممیزی سریع وضعیت فعلی؛ روزهای ۱ تا ۳
- مشخص کنید کدام سرویسها برای فعالیت سازمان حیاتی هستند.
- محل نگهداری بکاپها و تعداد نسخه‌های موجود را بررسی کنید.
- مشخص کنید آخرین تست بازیابی چه زمانی انجام شده است.
- بررسی کنید آیا برای از دسترس خارج شدن زیرساخت اصلی، سناریوی مشخصی وجود دارد یا خیر.
طراحی حداقل سناریوی دیزاستر ریکاوری؛ روزهای ۳ تا ۷
در این مرحله باید سرویس‌های حیاتی و اهداف بازیابی مشخص شوند. دو شاخص مهم برای این تصمیم‌گیری عبارت‌اند از:
- RTO: حداکثر زمانی که سازمان میتواند توقف یک سرویس را تحمل کند.
- RPO: میزان داده‌ای که سازمان میتواند در یک رخداد از دست بدهد.
تعیین این دو شاخص کمک میکند طراحی زیرساخت بحران بر اساس نیاز واقعی کسب‌وکار انجام شود، نه بر اساس حدس.
پیاده‌سازی زیرساخت پشتیبان و بکاپ؛ روزهای ۷ تا ۱۴
- زیرساخت پشتیبان متناسب با سناریوی تعریف‌شده آماده شود.
- زمان‌بندی تهیه و نگهداری بکاپ مشخص شود.
- حداقل یک نسخه از بکاپ در موقعیتی مستقل از سایت اصلی نگهداری شود.
- حداقل یک فرآیند بازیابی آزمایش و نتیجه آن مستند شود.
این برنامه جایگزین طراحی جامع تداوم کسب‌وکار و دیزاستر ریکاوری نیست، اما میتواند نقطه شروعی برای کاهش ریسک‌های فوری باشد.
آوید چگونه در طراحی زیرساخت بحران همراه سازمان‌هاست؟
نیاز سازمان‌ها در حوزه دیزاستر ریکاوری یکسان نیست. حجم داده، نوع سرویسها، معماری فعلی، RTO، RPO و بودجه، همگی روی سناریوی مناسب اثر می‌گذارند.
در آوید، مسیر طراحی زیرساخت بحران میتواند از بررسی شرایط فعلی آغاز شود و سپس بر اساس نیاز سازمان، سناریوی بکاپ، بازیابی و زیرساخت پشتیبان تعریف شود.
- بررسی زیرساخت موجود: شناسایی سرویسها و داده‌هایی که باید در اولویت حفاظت قرار بگیرند.
- طراحی سناریوی متناسب: تعیین سطح موردنیاز برای بکاپ، بازیابی و زیرساخت پشتیبان.
- پیاده‌سازی: آماده‌سازی زیرساخت موردنیاز بر اساس سناریوی تعریف‌شده.
- آزمون بازیابی: بررسی عملی فرآیند بازیابی به‌جای اتکا به وجود فایل‌های بکاپ.
جمع‌بندی؛ فردای بحران، امروز ساخته میشود
بحران‌ها یک واقعیت ساده را پررنگ می‌کنند: داده یکی از مهم‌ترین دارایی‌های هر سازمان است و حفاظت از آن فقط به تهیه بکاپ محدود نمی‌شود.
دیزاستر ریکاوری زمانی مؤثر است که سازمان از قبل بداند چه دادهها و سرویس‌هایی حیاتی هستند، چه مدت میتواند توقف آن‌ها را تحمل کند، نسخه‌های پشتیبان کجا قرار دارند و در صورت وقوع حادثه چگونه باید سرویس را بازیابی کند.
اگر بکاپ‌های سازمان شما به‌طور منظم تهیه می‌شوند اما بازیابی آن‌ها تاکنون آزمایش نشده، اگر سایت پشتیبان مشخصی ندارید یا اگر در صورت از دسترس خارج شدن زیرساخت اصلی نمی‌دانید کدام سرویس باید ابتدا بازیابی شود، هنوز بخشی از مسیر آمادگی باقی مانده است.
برای آمادگی در برابر بحران از کجا شروع کنیم؟
نقطه شروع میتواند بررسی وضعیت فعلی باشد: چه داده‌هایی حیاتی هستند، بکاپها کجا نگهداری می‌شوند، RTO و RPO موردنیاز سازمان چیست و در صورت توقف سایت اصلی چه گزینه‌ای برای ادامه سرویس وجود دارد.
تیم رایانش ابری آوید میتواند بر اساس وضعیت زیرساخت سازمان، نیازهای بازیابی و اولویت سرویس‌های حیاتی، در بررسی و طراحی سناریوی مناسب بکاپ و دیزاستر ریکاوری همراه شما باشد.
برای بررسی وضعیت فعلی زیرساخت و سناریوی بازیابی سازمان، با تیم آوید در ارتباط باشید.
