Дори по време на бедствие винаги има време за чаша чай
DRP (план за възстановяване след бедствие) е нещо, което в идеалния случай никога няма да е необходимо. Но ако внезапно бобри, мигриращи по време на сезона на чифтосване, прегризат опорното оптично влакно или младши администратор изпусне продуктивната база, определено искате да сте сигурни, че ще имате предварително направен план какво да правите с целия този позор.
Докато клиентите в паника започват да прекъсват телефоните за техническа поддръжка, младшият търси цианид, вие мъдро отваряте червения плик и започвате да подреждате всичко.
В тази публикация искам да споделя препоръки как да напиша DRP и какво трябва да съдържа. Ще разгледаме и следните неща:
- Да се научим да мислим като злодей.
- Нека да разгледаме ползите от чаша чай по време на апокалипсис.
- Нека помислим за удобна DRP структура
- Нека видим как да го тестваме
За кои компании може да е полезно това?
Много е трудно да се тегли чертата, когато ИТ отделът започне да има нужда от такива неща. Бих казал, че определено имате нужда от DRP, ако:
- Спирането на сървър, приложение или загубата на база данни ще доведе до значителни загуби за бизнеса като цяло.
- Имате пълноценен ИТ отдел. В смисъл на отдел под формата на пълноценно звено на компанията, със собствен бюджет, а не само няколко уморени служители, които полагат мрежа, почистват вируси и зареждат принтери.
- Имате реалистичен бюджет за поне частично съкращаване в случай на спешност.
Когато ИТ отделът се моли с месеци за поне няколко твърди диска в стар сървър за архивиране, е малко вероятно да успеете да организирате пълноценно преместване на неуспешна услуга към резервен капацитет. Въпреки че тук документацията няма да бъде излишна.
Документацията е важна
Започнете с документацията. Да приемем, че вашата услуга работи на Perl скрипт, който е написан преди три поколения от администратори, но никой не знае как работи. Натрупаният технически дълг и липсата на документация неминуемо ще ви прострелят не само в коляното, но и в други крайници, по-скоро е въпрос на време.
След като имате добро описание на компонентите на услугата, потърсете статистика за произшествията. Те почти сигурно ще бъдат напълно типични. Например, вашият диск се запълва от време на време, което води до повреда на възела, докато не бъде почистен ръчно. Или клиентската услуга става недостъпна поради факта, че някой отново е забравил да поднови сертификата и Let's Encrypt не може или не желае да конфигурира.
Мисли като саботьор
Най-трудната част е в предвиждането на тези злополуки, които никога не са се случвали преди, но които потенциално биха могли напълно да сринат вашата услуга. Тук аз и моите колеги обикновено играем злодеи. Вземете много кафе и нещо вкусно и се заключете в заседателната зала. Просто се уверете, че в същите преговори заключвате онези инженери, които сами са разработили целевата услуга или редовно работят с нея. След това или на дъската, или на хартия, започвате да рисувате всички възможни ужаси, които могат да се случат на вашата услуга. Не е необходимо да навлизаме в подробности до конкретна чистачка и издърпване на кабели, достатъчно е да разгледаме сценария „Нарушаване на целостта на локалната мрежа“.
Обикновено повечето типични извънредни ситуации попадат в следните видове:
- Грешка в мрежата
- Грешка в услугите на ОС
- Неуспешно приложение
- Повреда на желязото
- Грешка във виртуализацията
Просто прегледайте всеки тип и вижте какво се отнася за вашата услуга. Например, демонът Nginx може да падне и да не се издигне - това означава неуспехи от страна на операционната система. Рядка ситуация, която причинява отказ на вашето уеб приложение, е софтуерна грешка. Докато работите през този етап, е важно да се установи диагнозата на проблема. Как да различим замръзнал интерфейс при виртуализация от повреден цис диск и повреда на мрежата, например. Това е важно, за да се намерят бързо виновните и да започнат да им дърпат опашката, докато аварията бъде отстранена.
След като типичните проблеми са записани, наливаме още кафе и започваме да обмисляме най-странните сценарии, когато някои параметри започват да надхвърлят нормата. Например:
- Какво се случва, ако времето на активния възел се премести една минута назад спрямо другите в клъстера?
- Ами ако времето се премести напред, ами ако с 10 години?
- Какво се случва, ако клъстерен възел внезапно загуби мрежата си по време на синхронизация?
- Какво ще се случи, ако два възела не споделят лидерството поради временна изолация един от друг в мрежата?
На този етап обратният подход е много полезен. Взимате най-упорития член на екипа с болно въображение и му давате задачата да организира саботаж в най-кратки срокове, който ще срине услугата. Ако е трудно да се диагностицира, още по-добре. Няма да повярвате какви странни и готини идеи измислят инженерите, ако им дадете идея да счупят нещо. И ако им обещаете тестов стенд за това, това е абсолютно добре.
Какъв е този твой DRP?!
Така дефинирахте своя модел на заплаха. Те също взеха предвид местните жители, които режат оптични кабели в търсене на мед, и военен радар, който пуска радиорелейна линия строго в петък в 16:46. Сега трябва да разберем какво да правим с всичко това.
Вашата задача е да напишете онези много червени пликове, които ще бъдат отворени при спешни случаи. Веднага очаквайте, че когато (не ако!) всичко свърши, наблизо ще бъде само най-неопитен стажант, чиито ръце ще треперят силно от ужаса на случващото се. Вижте как се прилагат знаци за спешни случаи в медицинските кабинети. Например какво да правим в случай на анафилактичен шок. Медицинският персонал знае всички протоколи наизуст, но когато човек наблизо започне да умира, много често всички се вкопчват безпомощно във всичко, което му се види. За да направите това, има ясни инструкции на стената с елементи като „отворете опаковката от такова и такова“ и „приложете толкова много единици от лекарството интравенозно“.
Трудно е да се мисли в спешен случай! Трябва да има прости инструкции за анализ на гръбначния мозък.
Добрият DRP се състои от няколко прости блока:
- Кого да уведомим за началото на авария. Това е важно, за да паралелизира процеса на елиминиране колкото е възможно повече.
- Как да диагностицираме правилно - извършете проследяване, погледнете в systemctl status servicename и т.н.
- Колко време можете да отделите за всеки етап? Ако нямате време да го поправите ръчно в рамките на времето за SLA, виртуалната машина се убива и се връща обратно от вчерашното архивиране.
- Как да се уверите, че аварията е отминала.
Не забравяйте, че DRP започва, когато услугата е напълно неуспешна, и завършва, когато услугата бъде възстановена, дори и с намалена ефективност. Простата загуба на резервация не трябва да задейства DRP. Можете също да напишете чаша чай в DRP. Сериозно. Според статистиката много аварии се превръщат от неприятни в катастрофални поради факта, че персоналът в паника се втурва да поправи нещо, като едновременно с това убива единствения жив възел с данни или накрая довършва клъстера. По правило 5 минути с чаша чай ще ви дадат малко време да се успокоите и да анализирате какво се случва.
Не бъркайте DRP и системния паспорт! Не го претоварвайте с ненужни данни. Просто направете възможно бързо и удобно използване на хипервръзки, за да отидете до желания раздел от документацията и да прочетете в разширен формат за необходимите раздели от архитектурата на услугата. А в самия DRP има само директни инструкции къде и как да се свържете с конкретни команди за copy-paste.
Как да тествате правилно
Уверете се, че всеки отговорен служител може да завърши всички елементи. В най-важния момент може да се окаже, че инженерът няма права за достъп до необходимата система, няма пароли за необходимия акаунт или няма представа какво е „Свържете се с конзолата за управление на услугата чрез прокси на централен офис“ означава. Всяка точка трябва да бъде изключително проста.
погрешно — „Отидете на виртуализация и рестартирайте мъртвия възел“
правилно - „Свържете се чрез уеб интерфейса към virt.example.com, в секцията с възли рестартирайте възела, който причинява грешката.“
Избягвайте двусмислието. Спомнете си уплашения стажант.
Не забравяйте да тествате DRP. Това не е просто план за шоу - това е нещо, което ще позволи на вас и вашите клиенти бързо да излезете от критична ситуация. Най-добре е да направите това няколко пъти:
- Един експерт и няколко обучаеми работят на тестов стенд, който максимално симулира реална услуга. Експертът прекъсва услугата по различни начини и дава възможност на обучаемите да я възстановят според DRP. Всички проблеми, неясноти в документацията и грешки се записват. След като обучаемите са обучени, DRP се разширява и опростява в неясни области.
- Тестване в реален сервиз. Всъщност никога не можете да създадете перфектно копие на истинска услуга. Следователно, няколко пъти в годината е необходимо рутинно да се изключват някои от сървърите, да се прекъсват връзките и да се причиняват други бедствия от списъка със заплахи, за да се оцени процедурата за възстановяване. Планиран отказ за 10 минути посред нощ е по-добър от внезапен отказ за няколко часа по време на пиково натоварване със загуба на данни.
- Реално отстраняване на неизправности. Да, това също е част от тестването. Ако възникне авария, която не е била в списъка на заплахите, е необходимо да се допълни и финализира DRP въз основа на резултатите от нейното разследване.
Ключови точки
- Ако могат да се случат глупости, то не само ще се случи, но ще го направи при възможно най-катастрофалния сценарий.
- Уверете се, че имате ресурси за аварийно прехвърляне на товара.
- Уверете се, че имате резервни копия, те се създават автоматично и редовно се проверяват за последователност.
- Помислете за типични сценарии за заплаха.
- Дайте възможност на инженерите да измислят нестандартни опции за предоставяне на услугата.
- DRP трябва да бъде проста и тъпа инструкция. Цялата комплексна диагностика се извършва само след възстановяване на обслужването на клиента. Дори и с резервен капацитет.
- Предоставете ключови телефонни номера и контакти в DRP.
- Тествайте редовно разбирането на служителите за DRP.
- Организирайте планирани аварии на производствените обекти. Стойките не могат да заменят всичко.
Източник: www.habr.com