حتی اگر سیل باشد، 1C باید کار کند! ما با کسب و کار در DR موافقیم

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

داستان توصیف شده یک فانتزی نیست، بلکه یک توصیف جمعی از چند رویداد سال 2020 است. در شرکت های بزرگ، یک طرح بازیابی بلایا یا طرح بازیابی فاجعه (DRP) همیشه برای این مورد در دسترس است. در شرکت ها، این مسئولیت بر عهده متخصصان تداوم کسب و کار است. اما در شرکت های متوسط ​​و کوچک، حل چنین مشکلاتی بر عهده خدمات فناوری اطلاعات است. شما باید منطق کسب و کار را خودتان درک کنید، بفهمید چه چیزی و کجا ممکن است شکست بخورد، محافظت کنید و آن را اجرا کنید. 

بسیار خوب است اگر یک متخصص فناوری اطلاعات بتواند با کسب و کار مذاکره کند و در مورد نیاز به حفاظت صحبت کند. اما من بیش از یک بار دیده ام که چگونه یک شرکت در راه حل بازیابی فاجعه (DR) صرفه جویی کرده است زیرا آن را اضافی می داند. هنگامی که یک حادثه رخ داد، یک بهبود طولانی تهدید زیان بود، و کسب و کار آماده نبود. می‌توانید هر چقدر که دوست دارید تکرار کنید: «به شما گفتم»، اما سرویس فناوری اطلاعات همچنان باید خدمات را بازیابی کند.

از موضع یک معمار، به شما خواهم گفت که چگونه از این وضعیت اجتناب کنید. در قسمت اول مقاله، کار مقدماتی را نشان خواهم داد: نحوه بحث در مورد سه سوال با مشتری برای انتخاب ابزارهای امنیتی: 

• ما از چه چیزی محافظت می کنیم؟
• از چه چیزی محافظت می کنیم؟
• چقدر محافظت می کنیم؟ 

در بخش دوم، ما در مورد گزینه هایی برای پاسخ به این سوال صحبت خواهیم کرد: چگونه از خود دفاع کنیم. من نمونه هایی از مواردی را بیان می کنم که چگونه مشتریان مختلف محافظت خود را ایجاد می کنند.

آنچه ما محافظت می کنیم: شناسایی عملکردهای حیاتی کسب و کار 

بهتر است آماده سازی را با بحث در مورد برنامه اقدام پس از اضطرار با مشتری تجاری شروع کنید. مشکل اصلی در اینجا یافتن یک زبان مشترک است. مشتری معمولاً اهمیتی نمی دهد که راه حل فناوری اطلاعات چگونه کار می کند. به او اهمیت می دهد که آیا این سرویس می تواند عملکردهای تجاری را انجام دهد و پول به همراه داشته باشد. به عنوان مثال: اگر سایت کار می کند، اما سیستم پرداخت خراب است، هیچ درآمدی از مشتریان وجود ندارد و "افراطی ها" هنوز متخصصان فناوری اطلاعات هستند. 

یک متخصص فناوری اطلاعات ممکن است در چنین مذاکراتی به چند دلیل مشکل داشته باشد:

• سرویس فناوری اطلاعات به طور کامل نقش سیستم اطلاعاتی در تجارت را درک نمی کند. به عنوان مثال، اگر هیچ توضیحی در مورد فرآیندهای کسب و کار یا یک مدل تجاری شفاف وجود نداشته باشد. 
• کل فرآیند به خدمات فناوری اطلاعات بستگی ندارد. به عنوان مثال، زمانی که بخشی از کار توسط پیمانکاران انجام می شود و متخصصان فناوری اطلاعات تأثیر مستقیمی روی آنها ندارند.

ساختار مکالمه را به این صورت انجام می دهم: 

1. ما به کسب و کارها توضیح می دهیم که حوادث برای همه اتفاق می افتد و بهبودی زمان می برد. بهترین کار این است که موقعیت ها را نشان دهیم، این که چگونه این اتفاق می افتد و چه عواقبی ممکن است.
2. ما نشان می‌دهیم که همه چیز به خدمات فناوری اطلاعات بستگی ندارد، اما شما آماده هستید تا با یک برنامه اقدام در حوزه مسئولیت خود کمک کنید.
3. از مشتری تجاری می خواهیم پاسخ دهد: اگر آخرالزمان اتفاق بیفتد، کدام فرآیند باید ابتدا بازیابی شود؟ چه کسی و چگونه در آن شرکت می کند؟ 

   یک پاسخ ساده از طرف کسب و کار مورد نیاز است، به عنوان مثال: مرکز تماس باید به ثبت درخواست ها 24/7 ادامه دهد.

4. از یک یا دو کاربر سیستم می خواهیم که این فرآیند را با جزئیات شرح دهند. 
   اگر شرکت شما تحلیلگر دارد بهتر است از یک تحلیلگر برای کمک استفاده کنید.

   برای شروع، توضیحات ممکن است به این صورت باشد: مرکز تماس درخواست ها را از طریق تلفن، از طریق پست و از طریق پیام های وب سایت دریافت می کند. سپس آنها را از طریق رابط وب وارد 1C می کند و تولید آنها را به این ترتیب از آنجا می برد.

5. سپس به بررسی راه حل های سخت افزاری و نرم افزاری این فرآیند می پردازیم. برای حفاظت جامع، ما سه سطح را در نظر می گیریم: 
   • برنامه ها و سیستم های داخل سایت (سطح نرم افزار)،   
   • خود سایتی که سیستم ها در آن اجرا می شوند (سطح زیرساخت)، 
   • شبکه (آنها اغلب آن را فراموش می کنند).

6. نقاط احتمالی خرابی را می یابیم: گره های سیستم که عملکرد سرویس به آنها بستگی دارد. ما به طور جداگانه گره هایی را که توسط شرکت های دیگر پشتیبانی می شوند، یادداشت می کنیم: اپراتورهای مخابراتی، ارائه دهندگان میزبانی، مراکز داده و غیره. با این کار می توانید برای مرحله بعدی به مشتری تجاری بازگردید.

آنچه ما از آن محافظت می کنیم: خطرات

در مرحله بعد، ما از مشتری تجاری در می یابیم که ابتدا از خود در برابر چه خطراتی محافظت می کنیم. تمام خطرات را می توان به دو گروه تقسیم کرد: 

• از دست دادن زمان به دلیل خرابی خدمات؛
• از دست دادن داده ها به دلیل تأثیرات فیزیکی، عوامل انسانی و غیره.

کسب و کارها از از دست دادن داده ها و زمان می ترسند - همه اینها منجر به از دست دادن پول می شود. بنابراین مجدداً برای هر گروه خطر سؤال می‌پرسیم: 

• برای این فرآیند، آیا می‌توانیم تخمین بزنیم که از دست دادن داده‌ها و زمان از دست دادن هزینه‌های پول چقدر است؟ 
• چه داده هایی را نمی توانیم از دست دهیم؟ 
• کجا نمی توانیم اجازه خرابی بدهیم؟ 
• چه وقایعی برای ما محتمل ترین و بیشتر تهدید کننده است؟

پس از بحث، نحوه اولویت بندی نقاط شکست را خواهیم فهمید. 

چقدر محافظت می کنیم: RPO و RTO 

هنگامی که نقاط بحرانی شکست مشخص است، شاخص های RTO و RPO را محاسبه می کنیم. 

بگذارید این را به شما یادآوری کنم RTO (هدف زمان بازیابی) — این مدت زمان مجاز از لحظه وقوع حادثه تا بازیابی کامل سرویس است. به زبان تجاری، این زمان خرابی قابل قبول است. اگر بدانیم این فرآیند چقدر پول به همراه داشته است، می‌توانیم ضررهای هر دقیقه از کار افتادگی را محاسبه کنیم و ضرر قابل قبول را محاسبه کنیم. 

RPO (هدف نقطه بازیابی) - نقطه بازیابی اطلاعات معتبر این زمان را تعیین می کند که در طی آن می توانیم داده ها را از دست دهیم. از نقطه نظر تجاری، از دست دادن داده ها می تواند منجر به جریمه شود. چنین ضررهایی را نیز می توان به پول تبدیل کرد. 

زمان بازیابی باید برای کاربر نهایی محاسبه شود: چه مدت می تواند به سیستم وارد شود. بنابراین ابتدا زمان بازیابی تمام پیوندهای زنجیره را جمع می کنیم. یک اشتباه اغلب در اینجا انجام می شود: آنها RTO ارائه دهنده را از SLA می گیرند و شرایط باقی مانده را فراموش می کنند.

بیایید به یک مثال خاص نگاه کنیم. کاربر وارد 1C می شود، سیستم با خطای پایگاه داده باز می شود. او با مدیر سیستم تماس می گیرد. پایگاه داده در فضای ابری قرار دارد، مدیر سیستم مشکل را به ارائه دهنده خدمات گزارش می دهد. فرض کنید همه ارتباطات 15 دقیقه طول می کشد. در فضای ابری، یک پایگاه داده با این اندازه از یک نسخه پشتیبان در یک ساعت بازیابی می شود، بنابراین، RTO در سمت ارائه دهنده خدمات یک ساعت است. اما این آخرین مهلت نیست، برای کاربر 15 دقیقه برای تشخیص مشکل به آن اضافه شده است. 
 
در مرحله بعد، مدیر سیستم باید بررسی کند که پایگاه داده صحیح است، آن را به 1C متصل کرده و خدمات را راه اندازی کند. این به یک ساعت دیگر نیاز دارد، به این معنی که RTO در سمت مدیر در حال حاضر 2 ساعت و 15 دقیقه است. کاربر به 15 دقیقه دیگر نیاز دارد: وارد شوید، بررسی کنید که تراکنش های لازم ظاهر شده اند. 2 ساعت 30 دقیقه کل زمان بازیابی سرویس در این مثال است.

این محاسبات به کسب و کار نشان می دهد که دوره بهبودی به چه عوامل خارجی بستگی دارد. به عنوان مثال، اگر دفتر آب گرفتگی دارد، ابتدا باید نشتی را پیدا کرده و آن را برطرف کنید. زمان می برد که به IT بستگی ندارد.  

چگونه محافظت می کنیم: انتخاب ابزار برای خطرات مختلف

پس از بحث در مورد تمام نکات، مشتری از قبل هزینه یک حادثه برای کسب و کار را درک می کند. اکنون می توانید ابزارها را انتخاب کنید و در مورد بودجه بحث کنید. با استفاده از نمونه هایی از موارد مشتری، به شما نشان خواهم داد که چه ابزارهایی را برای کارهای مختلف ارائه می دهیم. 

بیایید با اولین گروه از خطرات شروع کنیم: ضررهای ناشی از توقف خدمات. راه حل های این مشکل باید RTO خوبی را ارائه دهد.

1. میزبانی برنامه در فضای ابری 

   برای شروع، می توانید به سادگی به فضای ابری بروید - ارائه دهنده قبلاً در مورد مسائل دسترسی بالا فکر کرده است. هاست های مجازی سازی در یک خوشه مونتاژ می شوند، برق و شبکه رزرو می شوند، داده ها در سیستم های ذخیره سازی مقاوم به خطا ذخیره می شوند و ارائه دهنده خدمات از نظر مالی مسئول خرابی است.

   به عنوان مثال، شما می توانید یک ماشین مجازی با یک پایگاه داده در فضای ابری میزبانی کنید. برنامه به صورت خارجی از طریق یک کانال ایجاد شده یا از همان ابر به پایگاه داده متصل می شود. اگر مشکلی با یکی از سرورهای کلاستر ایجاد شود، VM در کمتر از 2 دقیقه روی سرور همسایه راه اندازی مجدد می شود. پس از آن، DBMS در آن راه اندازی می شود و ظرف چند دقیقه پایگاه داده در دسترس قرار می گیرد.

   OTR: در دقیقه اندازه گیری می شود. این شرایط را می توان در قرارداد با ارائه دهنده مشخص کرد.
   هزینه: ما هزینه منابع ابری را برای برنامه شما محاسبه می کنیم. 
   چیزی که شما را از آن محافظت نمی کند: از خرابی های گسترده در سایت ارائه دهنده، به عنوان مثال، به دلیل تصادفات در سطح شهر.

2. برنامه را خوشه بندی کنید  

   اگر می خواهید RTO را بهبود ببخشید، می توانید گزینه قبلی را تقویت کنید و بلافاصله یک برنامه خوشه ای را در فضای ابری قرار دهید.

   شما می توانید یک خوشه را در حالت فعال-غیرفعال یا فعال-فعال پیاده سازی کنید. ما چندین VM را بر اساس نیازهای فروشنده ایجاد می کنیم. برای اطمینان بیشتر، ما آنها را در سرورهای مختلف و سیستم های ذخیره سازی توزیع می کنیم. اگر سرور با یکی از پایگاه های داده از کار بیفتد، گره پشتیبان در چند ثانیه بار را بر عهده می گیرد.

   OTR: در ثانیه اندازه گیری می شود.
   هزینه: کمی گران تر از یک ابر معمولی، منابع اضافی برای خوشه بندی مورد نیاز خواهد بود.
   چیزی که شما را از آن محافظت نمی کند: هنوز در برابر خرابی های عظیم در محل محافظت نمی کند. اما اختلالات محلی به این مدت طولانی نخواهد بود.

   از تمرین: شرکت خرده فروشی دارای چندین سیستم اطلاعاتی و وب سایت بود. تمامی پایگاه های داده به صورت محلی در دفتر شرکت قرار داشتند. هیچ DR فکر نمی شد تا زمانی که دفتر چندین بار متوالی بدون برق رها شد. مشتریان از خرابی وب سایت ناراضی بودند. 
    
   مشکل در دسترس بودن سرویس پس از انتقال به فضای ابری حل شد. به علاوه، ما موفق شدیم بار روی پایگاه‌های داده را با متعادل کردن ترافیک بین گره‌ها بهینه کنیم.

3. به یک ابر ضد فاجعه بروید

   اگر باید اطمینان حاصل کنید که کار حتی با یک بلای طبیعی در سایت اصلی قطع نمی شود، می توانید یک ابر مقاوم در برابر بلایا را انتخاب کنید. در این گزینه، ارائه دهنده خوشه مجازی سازی را در 2 مرکز داده پخش می کند. تکثیر همزمان ثابت بین مراکز داده، یک به یک رخ می دهد. کانال های بین مراکز داده رزرو شده و مسیرهای مختلفی را طی می کنند، بنابراین چنین خوشه ای از مشکلات شبکه نمی ترسد. 

   OTR: به 0 تمایل دارد.
   هزینه: گران ترین گزینه ابری. 
   چیزی که شما را از آن محافظت نمی کند: در برابر خرابی داده ها و همچنین از طریق عامل انسانی کمکی نمی کند، بنابراین توصیه می شود همزمان نسخه پشتیبان تهیه کنید. 

   از تمرین: یکی از مشتریان ما یک طرح جامع بازیابی بلایا ایجاد کرد. این راهبردی است که او انتخاب کرده است: 

   • یک ابر مقاوم در برابر بلایا از برنامه در برابر خرابی در سطح زیرساخت محافظت می کند. 
   • پشتیبان گیری دو سطحی در صورت بروز خطای انسانی محافظت می کند. دو نوع پشتیبان وجود دارد: "سرد" و "گرم". یک نسخه پشتیبان "سرد" در حالت غیرفعال است و برای استقرار زمان می برد. یک نسخه پشتیبان داغ از قبل آماده استفاده است و سریعتر بازیابی می شود. روی یک سیستم ذخیره سازی اختصاصی ذخیره می شود. نسخه سوم روی نوار ضبط شده و در اتاق دیگری ذخیره می شود. 

   یک بار در هفته، مشتری حفاظت را آزمایش می کند و عملکرد همه نسخه های پشتیبان، از جمله مواردی که از نوار تهیه شده است را بررسی می کند. این شرکت هر سال کل ابر مقاوم در برابر بلایا را آزمایش می کند. 

4. تکرار را در سایت دیگری سازماندهی کنید 

   گزینه دیگری در مورد چگونگی جلوگیری از مشکلات جهانی در سایت اصلی: ارائه رزرو جغرافیایی. به عبارت دیگر، ماشین های مجازی پشتیبان را در سایتی در شهر دیگر ایجاد کنید. راه حل های ویژه برای DR برای این مناسب است: در شرکت ما از VMware vCloud Availability (vCAV) استفاده می کنیم. با کمک آن، می توانید حفاظت را بین چندین سایت ارائه دهنده ابر پیکربندی کنید یا از یک سایت داخلی به ابر بازیابی کنید. من قبلاً با جزئیات بیشتری در مورد طرح کار با vCAV صحبت کرده ام اینجا. 

   RPO و RTO: از 5 دقیقه 

   هزینه: گران تر از گزینه اول، اما ارزان تر از تکرار سخت افزار در یک ابر ضد فاجعه. قیمت شامل هزینه مجوز vCAV، هزینه های مدیریت، هزینه منابع ابری و منابع ذخیره مطابق مدل PAYG (10٪ از هزینه منابع کاری برای ماشین های مجازی خاموش) است.

   از تمرین: مشتری 6 ماشین مجازی با پایگاه داده های مختلف را در فضای ابری ما در مسکو نگهداری می کرد. در ابتدا، حفاظت با پشتیبان‌گیری انجام می‌شد: برخی از نسخه‌های پشتیبان در فضای ابری در مسکو و برخی در سایت ما در سن پترزبورگ ذخیره می‌شدند. با گذشت زمان، حجم پایگاه‌های داده افزایش یافت و بازیابی از پشتیبان‌گیری زمان بیشتری می‌برد. 
    
   Replication بر اساس VMware vCloud Availability به نسخه پشتیبان اضافه شد. کپی ماشین های مجازی در یک سایت پشتیبان در سن پترزبورگ ذخیره می شوند و هر 5 دقیقه یکبار به روز می شوند. اگر خرابی در سایت اصلی رخ دهد، کارمندان به طور مستقل به نسخه‌ای از ماشین مجازی در سنت پترزبورگ می‌روند و به کار با آن ادامه می‌دهند. 

همه راه حل های در نظر گرفته شده دسترسی بالایی را ارائه می دهند، اما در برابر از دست دادن داده ها به دلیل ویروس باج افزار یا خطای تصادفی کارمند محافظت نمی کنند. در این صورت به پشتیبان هایی نیاز خواهیم داشت که RPO مورد نیاز را ارائه کنند.

5. پشتیبان گیری را فراموش نکنید

همه می دانند که شما نیاز به پشتیبان گیری دارید، حتی اگر جالب ترین راه حل ضد بلایا را داشته باشید. بنابراین من فقط چند نکته را به اختصار یادآوری می کنم.

به طور دقیق، پشتیبان گیری DR نیست. و به همین دلیل: 

• خیلی وقته. اگر داده ها بر حسب ترابایت اندازه گیری شوند، بازیابی بیش از یک ساعت طول می کشد. باید بازیابی کنید، شبکه ای را اختصاص دهید، بررسی کنید که روشن شود، ببینید که داده ها مرتب هستند. بنابراین شما می توانید یک RTO خوب را تنها در صورتی ارائه دهید که داده های کمی وجود داشته باشد. 
• ممکن است بار اول داده ها بازیابی نشوند و باید برای تکرار عمل زمان بگذارید. برای مثال، مواقعی وجود دارد که نمی دانیم دقیقا چه زمانی داده ها از بین رفته اند. فرض کنید از دست دادن در ساعت 15.00:15.00 مشاهده شد و هر ساعت یک نسخه از آن ساخته می شود. از ساعت 14:00 به تمام نقاط ریکاوری نگاه می کنیم: 13:00، XNUMX:XNUMX و غیره. اگر سیستم مهم است، سعی می کنیم سن نقطه ریکاوری را به حداقل برسانیم. اما اگر نسخه پشتیبان تازه حاوی داده های لازم نبود، نکته بعدی را می گیریم - این زمان اضافی است. 

در این صورت، برنامه پشتیبان می تواند موارد مورد نیاز را ارائه دهد RPO. برای پشتیبان گیری، ارائه رزرو جغرافیایی در صورت بروز مشکل در سایت اصلی مهم است. توصیه می شود برخی از نسخه های پشتیبان را جداگانه ذخیره کنید.

طرح نهایی بازیابی بلایا باید حداقل شامل 2 ابزار باشد:  

• یکی از گزینه های 1-4 که ​​سیستم ها را از خرابی و سقوط محافظت می کند.
• پشتیبان گیری برای محافظت از داده ها در برابر از دست دادن. 

در صورتی که ارائه دهنده اصلی اینترنت از کار بیفتد، مراقبت از یک کانال ارتباطی پشتیبان نیز ارزش دارد. و - voila! - DR با حداقل دستمزد از قبل آماده است. 

منبع: www.habr.com