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