Дури и за време на катастрофа, секогаш има време за чаша чај
DRP (план за обновување од катастрофи) е нешто што идеално никогаш нема да биде потребно. Но, ако ненадејно дабарите кои мигрираат за време на сезоната на парење го нагризат оптичкото влакно на 'рбетот или помладиот администратор ја испушти продуктивната база, дефинитивно сакате да бидете сигурни дека ќе имате однапред подготвен план што да правите со сета оваа срамота.
Додека клиентите во паника почнуваат да ги прекинуваат телефоните за техничка поддршка, јуниорот бара цијанид, вие мудро го отворате црвениот плик и почнувате да ставате сè во ред.
Во овој пост сакам да споделам препораки за тоа како да се напише DRP и што треба да содржи. Ќе ги разгледаме и следните работи:
- Да научиме да размислуваме како негативец.
- Ајде да ги погледнеме придобивките од шолја чај за време на апокалипсата.
- Ајде да размислиме за пригодна структура на DRP
- Ајде да видиме како да го тестираме
За кои компании ова може да биде корисно?
Многу е тешко да се повлече линијата кога на одделот за ИТ почнува да му требаат такви работи. Јас би рекол дека дефинитивно ви треба DRP ако:
- Запирањето на сервер, апликација или губење на некоја база на податоци ќе доведе до значителни загуби за бизнисот како целина.
- Имате полноправно ИТ оддел. Во смисла на оддел во форма на полноправна единица на компанијата, со сопствен буџет, а не само неколку уморни вработени кои поставуваат мрежа, чистат вируси и дополнуваат принтери.
- Имате реален буџет за барем делумно технолошки вишок во случај на итност.
Кога одделот за ИТ бара со месеци барем неколку хард дискови на стар сервер за резервни копии, веројатно нема да можете да организирате целосно преместување на неуспешна услуга за да резервирате капацитет. Иако овде документацијата нема да биде излишна.
Документацијата е важна
Започнете со документација. Да речеме дека вашата услуга работи на Perl скрипта што е напишана пред три генерации од администратори, но никој не знае како функционира. Насобраниот технички долг и недостигот на документација неизбежно ќе ве застрелаат не само во коленото, туку и во другите екстремитети, повеќе е прашање на време.
Откако ќе имате добар опис на компонентите на услугата, побарајте статистика за несреќи. Речиси сигурно ќе бидат сосема типични. На пример, вашиот диск се полни од време на време, што предизвикува јазолот да не успее додека не се исчисти рачно. Или клиентската услуга станува недостапна поради фактот што некој повторно заборавил да го обнови сертификатот, а Let's Encrypt не можел или не сакал да го конфигурира.
Мисли како саботер
Најтешкиот дел е во предвидувањето на оние несреќи што никогаш претходно не се случиле, но кои потенцијално може целосно да го уништат вашиот сервис. Овде јас и моите колеги обично глумиме негативци. Пијте многу кафе и нешто вкусно и затворете се во сала за состаноци. Само погрижете се во истите преговори да ги затворите оние инженери кои самите ја развија целната услуга или редовно работат со неа. Потоа, или на табла или на хартија, почнувате да ги цртате сите можни ужаси што би можеле да се случат на вашата услуга. Не е неопходно да се навлегува во детали до одредена чистачка и да се вадат кабли, доволно е да се разгледа сценариото за „Повреда на интегритетот на локалната мрежа“.
Вообичаено, повеќето типични итни ситуации спаѓаат во следниве типови:
- Неуспех на мрежата
- Неуспех на услугите на ОС
- Неуспех на апликацијата
- Неуспех на железо
- Неуспех на виртуелизација
Само поминете низ секој тип и видете што се однесува на вашата услуга. На пример, демонот Nginx може да падне и да не се крене - ова значи неуспеси од страна на ОС. Ретка ситуација што предизвикува откажување на вашата веб-апликација е софтверски дефект. Додека се работи низ оваа фаза, важно е да се утврди дијагнозата на проблемот. Како да разликувате замрзнат интерфејс при виртуелизација од паднат cis диск и мрежна несреќа, на пример. Ова е важно за брзо да се пронајдат одговорните и да се започне со влечење на нивната опашка додека не се реши несреќата.
Откако ќе се запишат типичните проблеми, истураме повеќе кафе и почнуваме да ги разгледуваме најчудните сценарија, кога некои параметри почнуваат да одат многу подалеку од нормата. На пример:
- Што се случува ако времето на активниот јазол се помести една минута наназад во однос на другите во кластерот?
- Што ако времето оди напред, што ако за 10 години?
- Што се случува ако кластерскиот јазол ненадејно ја изгуби својата мрежа за време на синхронизацијата?
- Што ќе се случи ако два јазли не го делат водството поради привремена изолација еден на друг на мрежата?
Во оваа фаза, обратниот пристап е многу корисен. Го земате најтврдоглавиот член на тимот со болна имагинација и му давате задача да организира саботажа во најкус можен рок што ќе ја урне услугата. Ако е тешко да се дијагностицира, уште подобро. Нема да верувате какви чудни и кул идеи смислуваат инженерите ако им дадете идеја да скршат нешто. И ако им ветите тест клупа за ова, тоа е апсолутно во ред.
Што е ова твое DRP?!
Значи, го дефиниравте вашиот модел за закана. Тие, исто така, ги зедоа предвид локалните жители кои сечеа оптички кабли во потрага по бакар и воен радар кој испушта радио реле линија строго во петок во 16:46 часот. Сега треба да разбереме што да правиме со сето ова.
Ваша задача е да ги напишете оние многу црвени пликови што ќе се отворат во итен случај. Веднаш очекувајте дека кога (не ако!) се ќе заврши, во близина ќе биде само најнеискусниот практикант, чии раце силно ќе се тресат од ужасот на она што се случува. Погледнете како се спроведуваат знаците за итни случаи во медицинските ординации. На пример, што да се прави во случај на анафилактичен шок. Медицинскиот персонал ги знае сите протоколи напамет, но кога човек во близина почнува да умира, многу често сите беспомошно се држат за сè на повидок. За да го направите ова, на ѕидот има јасни инструкции со ставки како „отворете го пакувањето со таков и онаков“ и „администрирајте толку многу единици од лекот интравенски“.
Тешко е да се размислува во итен случај! Треба да има едноставни упатства за парсирање на 'рбетниот мозок.
Еден добар DRP се состои од неколку едноставни блокови:
- Кој да извести за почеток на несреќа. Ова е важно за да се паралелизира процесот на елиминација колку што е можно повеќе.
- Како правилно да се дијагностицира - направете трага, погледнете во име на услугата статус systemctl и така натаму.
- Колку време можете да потрошите на секоја сцена? Ако немате време да го поправите рачно во времето на SLA, виртуелната машина е убиена и вратена од вчерашната резервна копија.
- Како да бидете сигурни дека несреќата е завршена.
Запомнете дека DRP започнува кога услугата целосно пропаднала и завршува кога услугата е обновена, дури и со намалена ефикасност. Едноставното губење на резервацијата не треба да предизвика DRP. Можете исто така да напишете чаша чај во DRP. Сериозно. Според статистичките податоци, многу несреќи се претвораат од непријатни во катастрофални поради фактот што персоналот во паника брза да поправи нешто, истовремено убивајќи го единствениот жив јазол со податоци или конечно завршувајќи го кластерот. Како по правило, 5 минути со шолја чај ќе ви дадат малку време да се смирите и да анализирате што се случува.
Не мешајте DRP и системски пасош! Не преоптоварувајте го со непотребни податоци. Само овозможете брзо и практично користење хиперврски за да отидете до саканиот дел од документацијата и да прочитате во проширен формат за потребните делови од архитектурата на услугата. А во самиот DRP има само директни инструкции каде и како да се поврзете со конкретни команди за copy-paste.
Како правилно да тестирате
Осигурајте се дека секој одговорен вработен може да ги заврши сите ставки. Во најклучниот момент, може да испадне дека инженерот нема права за пристап до потребниот систем, нема лозинки за потребната сметка или нема поим што „Поврзете се со конзолата за управување со услуги преку прокси на седиште“ значи. Секоја точка треба да биде исклучително едноставна.
Погрешно - „Одете на виртуелизација и рестартирајте го мртвиот јазол“
Правилно - „Поврзете се преку веб-интерфејсот со virt.example.com, во делот за јазли, рестартирајте го јазолот што ја предизвикува грешката.
Избегнувајте двосмисленост. Сетете се на исплашениот практикант.
Не заборавајте да го тестирате DRP. Ова не е само план за шоу - тоа е нешто што ќе ви овозможи вам и на вашите клиенти брзо да излезете од критична ситуација. Најдобро е да го направите ова неколку пати:
- Еден експерт и неколку специјализанти работат на тест клупа што симулира вистинска услуга колку што е можно повеќе. Експертот ја раскинува услугата на различни начини и им овозможува на специјализантите да ја обноват според DRP. Сите проблеми, нејаснотии во документацијата и грешки се евидентирани. Откако ќе се обучат специјализантите, DRP се проширува и поедноставува во нејасни области.
- Тестирање на вистинска услуга. Всушност, никогаш не можете да создадете совршена копија на вистинска услуга. Затоа, неколку пати годишно е неопходно рутински да се исклучуваат некои од серверите, да се прекинат врските и да се предизвикаат други катастрофи од списокот на закани за да се процени постапката за обновување. Планиран дефект за 10 минути во средината на ноќта е подобар од ненадеен дефект неколку часа при максимално оптоварување со загуба на податоци.
- Вистинско решавање проблеми. Да, и ова е дел од тестирањето. Доколку се случи несреќа што не била на списокот на закани, неопходно е да се дополни и финализира DRP врз основа на резултатите од нејзината истрага.
Клучните точки
- Ако може да се случи срање, тоа не само што ќе се случи, туку ќе го направи тоа во најкатастрофалното можно сценарио.
- Проверете дали имате ресурси за итен пренос на товарот.
- Погрижете се да имате резервни копии, тие автоматски се креираат и редовно се проверуваат за конзистентност.
- Размислете за типични сценарија за закана.
- Дајте им можност на инженерите да излезат со нестандардни опции за испорака на услугата.
- DRP треба да биде едноставна и тапа инструкција. Целата сложена дијагностика се спроведува само откако ќе се врати услугата на клиентите. Дури и ако има резервен капацитет.
- Обезбедете клучни телефонски броеви и контакти во DRP.
- Редовно тестирајте го разбирањето на DRP на вработените.
- Организирајте планирани несреќи на производствените локации. Трибините не можат да заменат сè.
Извор: www.habr.com