Чак и током катастрофе увек има времена за шољицу чаја
ДРП (план опоравка од катастрофе) је ствар која у идеалном случају никада неће бити потребна. Али ако изненада даброви који мигрирају током сезоне парења прогризу оптичко влакно око кичме или млађи администратор испусти продуктивну базу, дефинитивно желите да будете сигурни да ћете имати унапред направљен план шта да радите са свом овом срамотом.
Док купци у паници почињу да прекидају телефоне техничке подршке, млађи тражи цијанид, ви мудро отварате црвену коверту и почињете да све доводите у ред.
У овом посту желим да поделим препоруке о томе како написати ДРП и шта треба да садржи. Такође ћемо размотрити следеће ствари:
- Научимо да размишљамо као негативац.
- Погледајмо предности шољице чаја током апокалипсе.
- Хајде да размислимо о прикладној ДРП структури
- Хајде да видимо како да га тестирамо
За које компаније би ово могло бити корисно?
Веома је тешко подвући црту када ИТ сектору почну да требају такве ствари. Рекао бих да вам је ДРП дефинитивно потребан ако:
- Заустављање сервера, апликације или губитак неке базе података довешће до значајних губитака за пословање у целини.
- Имате потпуно ИТ одељење. У смислу одељења у виду пуноправне јединице компаније, са сопственим буџетом, а не само неколико уморних запослених који постављају мрежу, чисте вирусе и пуне штампаче.
- Имате реалан буџет за бар делимично отпуштање у хитним случајевима.
Када ИТ одељење месецима моли за бар неколико ХДД-а у стари сервер за резервне копије, мало је вероватно да ћете моћи да организујете потпуни потез неуспелог сервиса да резервишете капацитет. Иако овде документација неће бити сувишна.
Документација је важна
Почните са документацијом. Рецимо да ваш сервис ради на Перл скрипти коју су пре три генерације написали администратори, али нико не зна како она функционише. Нагомилани технички дуг и недостатак документације ће вас неминовно погодити не само у колено, већ и у друге удове, више је питање времена.
Када добијете добар опис компоненти услуге, потражите статистику незгода. Они ће скоро сигурно бити потпуно типични. На пример, ваш диск се с времена на време пуни, што доводи до отказивања чвора док се ручно не очисти. Или клијентска услуга постаје недоступна због чињенице да је неко поново заборавио да обнови сертификат, а Лет'с Енцрипт није могао или није хтео да конфигурише.
Мисли као саботер
Најтежи део је у предвиђању оних незгода које се никада раније нису догодиле, али које би потенцијално могле у потпуности да сруше вашу услугу. Овде моје колеге и ја обично играмо негативце. Узмите пуно кафе и нешто укусно и закључајте се у салу за састанке. Само се побрините да у истим преговорима укључите оне инжењере који су сами развили циљну услугу или редовно раде са њом. Затим, било на табли или на папиру, почињете да цртате све могуће страхоте које би се могле догодити вашем сервису. Није потребно улазити у детаље до одређене чистачице и извлачења каблова, довољно је размотрити сценарио „Нарушавање интегритета локалне мреже“.
Типично, најчешће хитне ситуације спадају у следеће типове:
- Грешка мреже
- Квар ОС сервиса
- Грешка апликације
- Неуспех гвожђа
- Грешка виртуелизације
Само прођите кроз сваки тип и видите шта се односи на вашу услугу. На пример, Нгинк демон може пасти и не расти - то значи кварове на делу ОС-а. Ретка ситуација због које ваша веб апликација не успе је софтверски квар. Док радите кроз ову фазу, важно је утврдити дијагнозу проблема. Како разликовати замрзнути интерфејс на виртуелизацији од палог цис диска и мрежне несреће, на пример. Ово је важно да се брзо пронађу одговорни и почне да их вуче за реп док се несрећа не реши.
Након што су типични проблеми записани, сипамо још кафе и почињемо да разматрамо најчудније сценарије, када неки параметри почну да превазилазе норму. На пример:
- Шта се дешава ако се време на активном чвору помери за минут уназад у односу на друге у кластеру?
- Шта ако време крене напред, шта ако за 10 година?
- Шта се дешава ако чвор кластера изненада изгуби своју мрежу током синхронизације?
- Шта ће се догодити ако два чвора не деле вођство због привремене изолације један другог у мрежи?
У овој фази, обрнути приступ је од велике помоћи. Узмите најтврдокорнијег члана екипе болесне маште и дате му задатак да у најкраћем року организује саботажу која ће срушити сервис. Ако је тешко дијагностиковати, још боље. Нећете веровати до каквих чудних и цоол идеја долазе инжењери ако им дате идеју да нешто разбију. А ако им обећате тестну клупу за ово, то је сасвим у реду.
Шта је ово твој ДРП?!
Дакле, дефинисали сте свој модел претње. Узели су у обзир и локалне становнике који су пресекли оптичке каблове у потрази за бакром и војни радар који испушта радио релејну линију строго петком у 16:46. Сада треба да схватимо шта да радимо са свим овим.
Ваш задатак је да напишете оне веома црвене коверте које ће се отворити у хитним случајевима. Одмах очекујте да ће, када (не ако!) свему дође крај, у близини бити само најнеискуснији приправник, коме ће се руке жестоко трести од ужаса онога што се дешава. Погледајте како се постављају знакови за хитне случајеве у медицинским ординацијама. На пример, шта учинити у случају анафилактичког шока. Медицинско особље зна све протоколе напамет, али када неко у близини почне да умире, врло често се сви беспомоћно хватају за све што му се нађе на видику. Да бисте то урадили, постоје јасна упутства на зиду са ставкама као што су „отворите паковање таквог и таквог“ и „дајте толико јединица лека интравенозно“.
Тешко је размишљати у хитним случајевима! Требало би да постоје једноставна упутства за рашчлањивање кичмене мождине.
Добар ДРП се састоји од неколико једноставних блокова:
- Кога да обавести о почетку несреће. Ово је важно како би се што више упоредио процес елиминације.
- Како исправно дијагностиковати - извршите праћење, погледајте у системцтл статус сервиценаме и тако даље.
- Колико времена можете провести на свакој сцени? Ако немате времена да то поправите ручно у оквиру СЛА времена, виртуелна машина ће бити убијена и враћена из јучерашње резервне копије.
- Како се уверити да је несрећа завршена.
Запамтите да ДРП почиње када је услуга потпуно отказана и завршава се када се услуга врати, чак и са смањеном ефикасношћу. Просто губљење резервације не би требало да покрене ДРП. Такође можете уписати шољу чаја у ДРП. Озбиљно. Према статистикама, многе несреће се из непријатних претварају у катастрофалне због чињенице да особље у паници жури да нешто поправи, истовремено убијајући једини живи чвор са подацима или коначно завршавајући кластер. По правилу, 5 минута уз шољицу чаја даће вам времена да се смирите и анализирате шта се дешава.
Не мешајте ДРП и системски пасош! Немојте га преоптеретити непотребним подацима. Само омогућите брзу и практичну употребу хипервеза за одлазак до жељеног одељка документације и читање у проширеном формату о потребним деловима архитектуре услуге. А у самом ДРП-у постоје само директна упутства где и како да се повежете са одређеним командама за копирање-пејст.
Како исправно тестирати
Уверите се да је сваки одговорни запослени у стању да заврши све ставке. У најважнијем тренутку може се испоставити да инжењер нема права да приступи траженом систему, да нема лозинки за тражени налог или да нема појма шта „Повежи се на конзолу за управљање услугама преко проксија на централа” значи. Свака тачка треба да буде крајње једноставна.
Погрешно - „Идите на виртуелизацију и поново покрените мртви чвор“
Добро - „Повежите се преко веб интерфејса на вирт.екампле.цом, у одељку за чворове, поново покрените чвор који узрокује грешку.“
Избегавајте двосмисленост. Сетите се уплашеног приправника.
Обавезно тестирајте ДРП. Ово није само план за представу - то је нешто што ће вама и вашим клијентима омогућити да брзо изађете из критичне ситуације. Најбоље је то учинити неколико пута:
- Један стручњак и неколико приправника раде на испитној клупи која у највећој могућој мери симулира праву услугу. Стручњак разбија услугу на разне начине и омогућава полазницима да је рестаурирају по ДРП-у. Сви проблеми, нејасноће у документацији и грешке се евидентирају. Након што полазници прођу обуку, ДРП се проширује и поједностављује у нејасним областима.
- Тестирање на правом сервису. У ствари, никада не можете створити савршену копију праве услуге. Због тога је потребно неколико пута годишње рутински искључити неки од сервера, прекинути везе и изазвати друге катастрофе са листе претњи како би се проценио редослед опоравка. Планирани квар у трајању од 10 минута усред ноћи бољи је од изненадног квара током неколико сати током вршног оптерећења са губитком података.
- Право решавање проблема. Да, ово је такође део тестирања. Уколико дође до удеса који није био на листи претњи, потребно је допунити и финализирати ДРП на основу резултата његове истраге.
Кључне тачке
- Ако се срање може десити, не само да ће се десити, већ ће то учинити у најкатастрофалнијем могућем сценарију.
- Уверите се да имате ресурсе за хитан пренос оптерећења.
- Уверите се да имате резервне копије, оне се аутоматски креирају и редовно проверавају њихову доследност.
- Размислите о типичним сценаријима претњи.
- Дајте инжењерима прилику да смисле нестандардне опције за испоруку услуге.
- ДРП би требало да буде једноставна и тупа инструкција. Сва сложена дијагностика се спроводи тек након што је услуга клијента обновљена. Чак и ако је у резервном капацитету.
- Наведите кључне бројеве телефона и контакте у ДРП-у.
- Редовно тестирајте разумевање ДРП-а од стране запослених.
- Организовати планиране незгоде на производним местима. Сталци не могу све заменити.
Извор: ввв.хабр.цом