حتی در هنگام فاجعه، همیشه زمانی برای یک فنجان چای وجود دارد.
DRP (طرح بازیابی بلایا) چیزی است که در حالت ایده آل هرگز مورد نیاز نخواهد بود. اما اگر ناگهان سگ‌هایی که در طول فصل جفت‌گیری مهاجرت می‌کنند فیبر نوری اصلی را می‌بلند یا یک مدیر جوان یک پایگاه تولیدی را رها می‌کند، قطعاً می‌خواهید مطمئن باشید که برنامه‌ای از پیش ساخته خواهید داشت که با این همه شرم چه کاری انجام دهید.
در حالی که مشتریان وحشت زده شروع به تماس با پشتیبانی فنی می کنند، یک جوان به دنبال سیانور است، شما عاقلانه پاکت قرمز را باز می کنید و شروع به مرتب کردن همه چیز می کنید.
در این پست، می‌خواهم توصیه‌هایی در مورد نحوه نوشتن یک DRP و آنچه باید داشته باشد را به اشتراک بگذارم. همچنین موارد زیر را بررسی خواهیم کرد:
- یاد بگیرید مثل یک شرور فکر کنید.
- بیایید مزایای یک فنجان چای را در زمان آخرالزمان تجزیه و تحلیل کنیم.
- به یک ساختار مناسب DRP فکر کنید
- بیایید ببینیم چگونه آن را آزمایش کنیم
کدام شرکت ها ممکن است از این مزیت بهره مند شوند؟
زمانی که بخش فناوری اطلاعات شروع به نیاز به این چیزها می کند، خط کشی بسیار دشوار است. من می گویم که شما تضمین می کنید که به DRP نیاز دارید اگر:
- توقف یک سرور، یک برنامه کاربردی یا از دست دادن برخی از پایگاه داده ها منجر به زیان های قابل توجهی برای کسب و کار به عنوان یک کل می شود.
- شما یک بخش فناوری اطلاعات کامل دارید. منظور من این است که یک بخش به عنوان یک واحد تمام عیار از شرکت، با بودجه خاص خود، و نه فقط چند کارمند خسته که یک شبکه را راه اندازی می کنند، ویروس ها را تمیز می کنند و پرینترها را دوباره پر می کنند.
- شما یک بودجه واقعی برای حداقل بخشی از کار در مواقع اضطراری دارید.
وقتی بخش فناوری اطلاعات برای ماه‌ها حداقل چند هارد دیسک برای یک سرور قدیمی برای پشتیبان‌گیری درخواست کرده است، بعید است که بتوانید یک جابجایی کامل سرویس سقوط کرده به ظرفیت‌های اضافی سازماندهی کنید. اگرچه اسناد در اینجا نیز اضافی نخواهد بود.
مستندات مهم است
با مستندسازی شروع کنید. فرض کنید که سرویس شما بر روی یک اسکریپت پرل اجرا می شود که سه نسل پیش از ادمین ها نوشته شده بود و هیچ کس نمی داند چگونه کار می کند. بدهی فنی انباشته و نداشتن مستندات به ناچار نه تنها به زانو، بلکه در سایر اندام ها نیز تیراندازی می کند، بلکه مسئله زمان است.
هنگامی که توضیحات خوبی از اجزای سرویس در دسترس دارید، آمار خرابی را افزایش دهید. تقریباً مطمئناً آنها کاملاً معمولی خواهند بود. به عنوان مثال، شما هر از گاهی یک دیسک پر دارید، که باعث می شود گره از کار بیفتد تا زمانی که به صورت دستی پاک شود. یا سرویس مشتری به دلیل این واقعیت که شخصی دوباره فراموش کرده است گواهی را تمدید کند، در دسترس نیست، اما نتوانست یا نمی خواهد Let's Encrypt را راه اندازی کند.
افکاری شبیه یک خرابکار
سخت ترین بخش پیش بینی حوادثی است که قبلاً هرگز اتفاق نیفتاده است، اما به طور بالقوه می تواند خدمات شما را به طور کامل خراب کند. در اینجا ما معمولاً با همکاران شرور بازی می کنیم. مقدار زیادی قهوه و یک چیز خوشمزه بخورید و خود را در اتاق جلسه حبس کنید. فقط مطمئن شوید که در همان جلسه مهندسانی را که خودشان سرویس هدف را بالا برده اند یا به طور منظم با آن کار می کنند، قفل کرده اید. سپس، یا روی تخته یا روی کاغذ، شروع به ترسیم تمام وحشت های احتمالی می کنید که ممکن است برای خدمت شما اتفاق بیفتد. لازم نیست به یک خانم نظافتچی خاص و بیرون کشیدن کابل ها جزئیات دهید، کافی است سناریوی "نقض یکپارچگی شبکه محلی" را در نظر بگیرید.
معمولاً اکثر موارد اضطراری معمولی در انواع زیر قرار می گیرند:
- شکست شبکه
- خرابی سرویس سیستم عامل
- شکست برنامه
- شکست آهن
- خطای مجازی سازی
فقط کافی است هر نما را مرور کنید و ببینید چه چیزی برای سرویس شما اعمال می شود. به عنوان مثال، شبح Nginx ممکن است سقوط کند و بالا نرود - این یک شکست از طرف سیستم عامل است. یک موقعیت نادر که برنامه وب شما را به حالت غیر کار می برد، یک خرابی نرم افزار است. در طول توسعه این مرحله، تشخیص مشکل مهم است. به عنوان مثال، چگونه یک رابط آویزان در مجازی سازی را از یک سیسکو سقوط کرده و یک خرابی شبکه تشخیص دهیم. این مهم است که به سرعت مسئولین را پیدا کنید و شروع به کشیدن دم آنها کنید تا تصادف برطرف شود.
پس از نوشتن مشکلات معمولی، قهوه بیشتری می ریزیم و شروع به بررسی عجیب ترین سناریوها می کنیم، زمانی که برخی از پارامترها شروع به فراتر از حد معمول می کنند. مثلا:
- اگر زمان گره فعال نسبت به سایرین در خوشه یک دقیقه به عقب برگردد چه اتفاقی می افتد؟
- و اگر زمان به جلو حرکت کند، و اگر 10 سال؟
- اگر یک گره خوشه به طور ناگهانی شبکه را در طول همگام سازی از دست بدهد، چه اتفاقی می افتد؟
- و اگر دو گره به دلیل جداسازی موقت یکدیگر در شبکه، رهبری مشترک نداشته باشند، چه اتفاقی می‌افتد؟
در این مرحله روش معکوس کمک زیادی می کند. سرسخت ترین عضو تیم را با یک تخیل بیمار بگیرید و به او این وظیفه را بدهید که در کمترین زمان ممکن یک انحراف ترتیب دهد، که سرویس را از بین می برد. اگر تشخیص آن دشوار است، حتی بهتر است. ایده های عجیب و غریب و جالبی که مهندسان وقتی ایده شکستن چیزی به ذهنشان می رسد را باور نخواهید کرد. و اگر به آنها قول بدهید که یک پایه آزمایشی برای این کار داشته باشید، بسیار خوب است.
این DRP شما چیه؟!
بنابراین شما مدل تهدید را تعریف کرده اید. آنها همچنین ساکنان محلی را که کابل های فیبر نوری را در جستجوی مس قطع می کردند و یک رادار نظامی که خط رله رادیویی را به شدت جمعه ها در ساعت 16:46 رها می کند، در نظر گرفتند. حالا باید بفهمیم که با همه اینها چه کنیم.
وظیفه شما نوشتن همان پاکت های قرمز است که در مواقع اضطراری باز می شوند. فوراً انتظار داشته باشید که وقتی (نه اگر!) همه چیز خراب شود، فقط بی تجربه ترین کارآموز در این نزدیکی است که دستانش به شدت از وحشت آنچه اتفاق می افتد می لرزد. نحوه اجرای علائم اورژانس در مطب ها را ببینید. به عنوان مثال، با شوک آنافیلاکتیک چه کنیم؟ کادر پزشکی همه پروتکل‌ها را از روی قلب می‌دانند، اما وقتی فردی در نزدیکی شروع به مرگ می‌کند، اغلب همه با درماندگی به همه چیز چنگ می‌زنند. برای انجام این کار، یک دستورالعمل واضح با مواردی مانند "بسته فلان را باز کنید" و "تزریق وریدی این همه واحد از دارو" روی دیوار آویزان است.
فکر کردن در شرایط اضطراری سخت است! باید دستورالعمل های ساده ای برای تجزیه ستون فقرات وجود داشته باشد.
یک DRP خوب از چند بلوک ساده تشکیل شده است:
- شروع تصادف را به چه کسی اطلاع دهیم. این به منظور موازی کردن روند حذف تا حد امکان مهم است.
- نحوه تشخیص صحیح - ما ردیابی می کنیم، به نام سرویس وضعیت systemctl و غیره نگاه می کنیم.
- برای هر مرحله چقدر زمان می توان صرف کرد. اگر در طول زمان SLA وقت ندارید آن را با دستان خود تعمیر کنید، ماشین مجازی از پشتیبان دیروز کشته و رول می شود.
- چگونه مطمئن شویم که سقوط به پایان رسیده است.
به یاد داشته باشید که DRP زمانی شروع می شود که سرویس به طور کامل از کار بیفتد و با بازیابی کامل می شود، حتی با کاهش کارایی. صرفاً از دست دادن رزرو نباید DRP را فعال کند. همچنین می توانید یک فنجان چای را در DRP تجویز کنید. به طور جدی. طبق آمار، بسیاری از تصادفات از ناخوشایند به فاجعه‌بار تبدیل می‌شوند، زیرا کارکنان در وحشت برای تعمیر چیزی عجله می‌کنند و به طور همزمان تنها گره زنده با داده را می‌کشند یا در نهایت خوشه را به پایان می‌رسانند. به عنوان یک قاعده، 5 دقیقه برای یک فنجان چای به شما زمان کمی می دهد تا آرام شوید و آنچه را که اتفاق می افتد تجزیه و تحلیل کنید.
DRP و پاسپورت سیستم را اشتباه نگیرید! آن را با داده های غیر ضروری بیش از حد بارگذاری نکنید. فقط این فرصت را به شما بدهید که به سرعت و به راحتی از طریق پیوندها به بخش مورد نیاز اسناد بروید و بخش های ضروری معماری خدمات را در قالب گسترده بخوانید. و در خود DRP، فقط دستورالعمل های مستقیم در مورد مکان و نحوه اتصال با دستورات خاص برای کپی پیست وجود دارد.
چگونه درست تست کنیم
اطمینان حاصل کنید که هر کارمند مسئول قادر به تکمیل تمام موارد است. در حساس ترین لحظه، ممکن است معلوم شود که مهندس حقوق دسترسی به سیستم مورد نیاز را ندارد، هیچ رمز عبوری برای حساب مورد نیاز وجود ندارد، یا او نمی داند که "از طریق یک پروکسی به کنسول مدیریت خدمات متصل شوید. دفتر مرکزی» یعنی. هر مورد باید تا حد امکان ساده باشد.
اشتباه - "به مجازی سازی بروید و گره مرده را راه اندازی مجدد کنید"
به درستی - "از طریق رابط وب به virt.example.com وصل شوید، در قسمت node، گره ای که باعث خطا می شود را دوباره بارگیری کنید."
از ابهام بپرهیزید. کارآموز ترسیده را به یاد بیاورید.
حتما DRP را تست کنید. این فقط یک طرح برای نمایش نیست - چیزی است که به شما و مشتریانتان اجازه می دهد تا به سرعت از یک موقعیت بحرانی خارج شوید. بهتر است این کار را چندین بار انجام دهید:
- یک کارشناس و چند کارآموز روی نیمکت آزمایشی کار می کنند که تا حد امکان از یک سرویس واقعی تقلید می کند. کارشناس به طرق مختلف سرویس را می شکند و کارآموزان را قادر می سازد تا آن را مطابق DRP بازیابی کنند. تمامی مشکلات، ابهامات موجود در مستندات و خطاها ثبت می شود. پس از آموزش به کارآموزان، DRP در مکان های مبهم تکمیل و ساده می شود.
- تست روی یک سرویس واقعی در واقع، شما هرگز نمی توانید یک کپی کامل از یک سرویس واقعی ایجاد کنید. بنابراین، چند بار در سال لازم است بخشی از سرورها را به صورت برنامه ریزی شده خاموش کنید، اتصالات را قطع کنید و سایر حوادث را از لیست تهدیدات ترتیب دهید تا دستور بازیابی ارزیابی شود. بهتر است یک خاموشی برنامه ریزی شده 10 دقیقه ای در نیمه شب داشته باشید تا یک خرابی ناگهانی برای چندین ساعت در اوج بار همراه با از دست دادن اطلاعات.
- حذف واقعی حادثه. بله، این نیز بخشی از آزمایش است. در صورت وقوع حادثه ای که در لیست تهدیدات نبود، لازم است DRP بر اساس نتایج بررسی آن تکمیل و نهایی شود.
امتیاز کلیدی
- اگر چرندیات اتفاق بیفتد، نه فقط اتفاق می افتد، بلکه در فاجعه بارترین سناریو این کار را انجام می دهد.
- مطمئن شوید که منابع لازم برای failover را دارید.
- اطمینان حاصل کنید که پشتیبان دارید، آنها به طور خودکار ایجاد می شوند و به طور منظم برای سازگاری بررسی می شوند.
- سناریوهای تهدید معمولی را در نظر بگیرید.
- به مهندسان این فرصت را بدهید تا گزینه‌های غیر استانداردی برای ارائه خدمات ارائه دهند.
- DRP باید دستورالعمل ساده و گنگ باشد. همه تشخیص های پیچیده فقط پس از اینکه مشتریان خدمات را بازیابی کردند. حتی اگر در حالت آماده به کار باشد.
- شماره تلفن های کلیدی و مخاطبین را در DRP فهرست کنید.
- به طور منظم کارکنان را برای درک DRP آزمایش کنید.
- حوادث برنامه ریزی شده را روی محصول ترتیب دهید. پایه ها نمی توانند جایگزین همه چیز شوند.
منبع: www.habr.com