Failover: перфекционизмът и... мързелът ни съсипват

През лятото както покупателната активност, така и интензивността на промените в инфраструктурата на уеб проектите традиционно намаляват, ни казва Captain Obvious. Просто защото дори IT специалистите понякога излизат на почивка. И CTO също. Още по-трудно е за тези, които остават на поста, но не това е важното сега: може би затова лятото е най-добрият период за бавно обмисляне на съществуващата схема за резервации и съставяне на план за подобряването й. И опитът на Егор Андреев от Административен отдел, за които той говори на конференцията Ден на работа.

Има няколко клопки, в които можете да попаднете, когато създавате резервни сайтове. И е абсолютно невъзможно да се хванете в тях. И това, което ни съсипва във всичко това, както и в много други неща, е перфекционизмът и... мързелът. Опитваме се да правим всичко, всичко, всичко перфектно, но не е нужно да го правим перфектно! Трябва да правите само определени неща, но да ги правите правилно, да ги завършите, така че да работят правилно.

Преминаването към отказ не е нещо забавно, забавно; това е нещо, което трябва да направи точно едно нещо - да намали времето за престой, така че услугата, компанията да губи по-малко пари. И във всички методи за резервация предлагам да мислите в следния контекст: къде са парите?

Първи капан: когато изграждаме големи, надеждни системи и участваме в резервиране, ние намаляваме броя на авариите. Това е ужасно погрешно схващане. Когато предприемем съкращения, има вероятност да увеличим броя на злополуките. И ако направим всичко правилно, тогава заедно ще намалим времето за престой. Ще има повече аварии, но те ще се случват с по-ниски разходи. Какво е резервация? - това е усложнение на системата. Всяко усложнение е лошо: имаме повече зъбни колела, повече зъбни колела, с една дума, повече елементи - и следователно по-голям шанс за повреда. И те наистина ще се счупят. И ще се чупят по-често. Прост пример: да кажем, че имаме уебсайт с PHP и MySQL. И спешно трябва да се резервира.

Shtosh (c) Взимаме втория сайт, изграждаме идентична система... Сложността става два пъти по-голяма - имаме два обекта. Ние също така внедряваме определена логика за прехвърляне на данни от един сайт към друг - тоест репликация на данни, копиране на статични данни и т.н. Така че логиката на репликация обикновено е много сложна и следователно общата сложност на системата може да бъде не 2, а 3, 5, 10 пъти по-голяма.

Втори капан: когато изграждаме наистина големи сложни системи, ние фантазираме какво искаме да получим в крайна сметка. Ето: искаме да получим супернадеждна система, която работи без никакви прекъсвания, превключва за половин секунда (или още по-добре незабавно) и започваме да сбъдваме мечтите. Но тук има и нюанс: колкото по-кратко е желаното време за превключване, толкова по-сложна става системната логика. Колкото по-сложна трябва да направим тази логика, толкова по-често системата ще се разваля. И можете да се окажете в много неприятна ситуация: ние се опитваме с всички сили да намалим времето на престой, но всъщност правим всичко по-сложно и когато нещо се обърка, времето на престой в крайна сметка ще бъде по-дълго. Тук често се улавяте да си мислите: добре... по-добре да не правите резервация. Би било по-добре, ако работи самостоятелно и с разбираемо прекъсване.

Как можете да се борите с това? Трябва да спрем да се лъжем, да спрем да се ласкаем, че сега ще построим космически кораб тук, но да разберем адекватно колко дълго може да лежи проектът. И за това максимално време ще изберем какви методи реално ще използваме, за да увеличим надеждността на нашата система.

Време е за “истории от w”... от живота, разбира се.

Пример номер едно

Представете си сайт-визитка на Тръбовалцов завод № 1 в град Н. Там пише с големи букви - ТРЪБОВАЛЦОВ ЗАВОД № 1. Точно отдолу е лозунгът: „Нашите лули са най-кръглите лули в N.” И по-долу е телефонният номер на главния изпълнителен директор и неговото име. Разбираме, че трябва да направите резервация - това е много важно нещо! Нека започнем да разберем от какво се състои. Html-статика - тоест няколко снимки, където генералният мениджър всъщност обсъжда някаква следваща сделка на масата в банята с партньора си. Започваме да мислим за престой. Идва на ум: трябва да лежите там пет минути, не повече. И тогава възниква въпросът колко продажби изобщо имаше от този наш сайт? Колко-колко? Какво означава "нула"? А това означава: защото генералът направи и четирите транзакции миналата година на една и съща маса, със същите хора, с които ходят на баня и седят на масата. И ние разбираме, че дори ако сайтът седи за един ден, нищо ужасно няма да се случи.

Въз основа на уводната информация има ден за повдигане на тази история. Нека започнем да мислим за схема за съкращения. И ние избираме най-идеалната схема за резервиране за този пример: ние не използваме резервиране. Цялото това нещо може да се повдигне от всеки админ за половин час с паузи за дим. Инсталирайте уеб сървър, добавете файлове - това е всичко. Ще работи. Не е нужно да следите нищо, не е нужно да обръщате специално внимание на нищо. Тоест изводът от пример номер едно е съвсем очевиден: услуги, които не трябва да се резервират, не трябва да се резервират.

Пример номер две

Фирмен блог: специално обучени хора пишат новини там, участвахме в такова и такова изложение, но пуснахме друг нов продукт и т.н. Да кажем, че това е стандартен PHP с WordPress, малка база данни и малко статика. Разбира се, отново идва на ум, че в никакъв случай не трябва да лежите - „не повече от пет минути!“ Това е всичко. Но нека помислим по-нататък. Какво прави този блог? Хората идват там от Yandex, от Google въз основа на някакви заявки, органично. Страхотен. Продажбите имат ли нещо общо с това? Богоявление: всъщност не. Рекламният трафик отива към основния сайт, който е на друга машина. Нека започнем да мислим за схема за резервации. В добрия смисъл трябва да се отгледа за няколко часа и би било хубаво да се подготвите за това. Би било разумно да вземете машина от друг център за данни, да прехвърлите средата върху нея, тоест уеб сървър, PHP, WordPress, MySQL, и да я оставите там. В момента, в който разберем, че всичко е счупено, трябва да направим две неща - да разгърнем дъмпа на mysql на 50 метра, той ще отлети там след минута и да разточим определен брой снимки от архива там. Това също го няма от Бог знае колко време. Така за половин час втасва цялата. Без репликация, или Бог да ме прости, автоматичен отказ. Заключение: това, което можем бързо да внедрим от резервно копие, не е необходимо да се архивира.

Пример номер три, по-сложен

Онлайн магазин. PhP с отворено сърце е малко променен, mysql със солидна основа. Доста статично (все пак онлайн магазинът има красиви HD изображения и всички тези неща), Redis за сесията и Elasticsearch за търсене. Започваме да мислим за престой. И тук, разбира се, е очевидно, че онлайн магазинът не може да лежи безболезнено за един ден. В крайна сметка, колкото по-дълго лежи, толкова повече пари губим. Струва си да се ускори. Колко? Мисля, че ако полежим един час, никой няма да полудее. Да, ще загубим нещо, но ако започнем да работим здраво, ще стане по-зле. Определяме схема на допустимия престой на час.

Как всичко това може да бъде запазено? Във всеки случай имате нужда от кола: един час време е доста малко. Mysql: тук вече имаме нужда от репликация, репликация на живо, защото след час 100 GB най-вероятно няма да бъдат добавени към дъмпа. Статика, снимки: отново след час 500 GB може да нямат време да бъдат добавени. Затова е по-добре да копирате снимките веднага. Redis: тук нещата стават интересни. В Redis сесиите се съхраняват - не можем просто да ги вземем и да ги погребем. Защото това няма да е много добре: всички потребители ще бъдат излезли, техните кошници ще бъдат изпразнени и т.н. Хората ще бъдат принудени да въведат отново своето потребителско име и парола и много хора може да се откъснат и да не завършат покупката. Отново реализациите ще намалеят. От друга страна, Redis е директно актуален, като последните влезли потребители вероятно също не са необходими. И добър компромис е да вземете Redis и да го възстановите от архив от вчера или, ако го правите на всеки час, от преди час. За щастие, възстановяването му от резервно копие означава копиране на един файл. И най-интересната история е Elasticsearch. Кой някога се е занимавал с репликация на MySQL? Кой някога се е занимавал с репликация на Elasticsearch? И при кого след това работеше нормално? Това, което имам предвид, е, че виждаме определен обект в нашата система. Изглежда полезно - но е сложно.
Сложен в смисъл, че нашите колеги инженери нямат опит в работата с него. Или има негативен опит. Или разбираме, че това все още е сравнително нова технология с нюанси или необработеност. Ние мислим... По дяволите, еластичният също е здрав, също отнема много време, за да го възстановите от резервно копие, какво да правя? Разбираме, че еластичният в нашия случай се използва за търсене. Как се продава нашият онлайн магазин? Отиваме при търговците и питаме откъде идват хората. Те отговарят: „90% от Yandex Market идват директно в продуктовата карта.“ И или го купуват, или не. Следователно търсенето е необходимо на 10% от потребителите. И поддържането на еластична репликация, особено между различни центрове за данни в различни зони, наистина има много нюанси. Кой изход? Вземаме ластик от запазен сайт и не правим нищо с него. Ако се проточи въпросът, сигурно ще го повдигнем някой ден, но това не е сигурно. Всъщност изводът е същият, плюс или минус: ние отново не запазваме услуги, които не влияят на парите. За да бъде диаграмата по-проста.

Пример номер четири, още по-труден

Интегратор: продажба на цветя, обаждане на такси, продажба на стоки, като цяло, всичко. Сериозно нещо, което работи 24/7 за голям брой потребители. С пълноценен интересен стек, където има интересни основи, решения, високо натоварване и най-важното е, че боли да лежите повече от 5 минути. Не само и не толкова защото хората няма да купуват, а защото хората ще видят, че това нещо не работи, ще се разстроят и може изобщо да не се върнат.

ДОБРЕ. Пет минути. Какво ще правим по въпроса? В този случай ние, като възрастни, използваме всички пари, за да изградим истински резервен сайт, с репликация на всичко и може би дори да автоматизираме превключването към този сайт, доколкото е възможно. И в допълнение към това, трябва да запомните да направите едно важно нещо: всъщност да напишете правилата за превключване. Правилата, дори ако имате всичко автоматизирано, могат да бъдат много прости. От поредицата „изпълнете такъв и такъв ansible скрипт“, „щракнете върху такова и такова квадратче за отметка в маршрут 53“ и така нататък - но това трябва да е някакъв точен списък с действия.

И всичко изглежда ясно. Превключването на репликация е тривиална задача или ще се превключи сама. Пренаписването на име на домейн в DNS е от същата серия. Проблемът е, че когато такъв проект се провали, започва паника и дори най-силните, брадати администратори могат да бъдат податливи на нея. Без ясни инструкции „отворете терминала, елате тук, адресът на нашия сървър все още е такъв“, е трудно да се спази 5-минутното време, определено за реанимация. Е, освен това, когато използваме тези разпоредби, е лесно да запишем някои промени в инфраструктурата, например, и да променим разпоредбите съответно.
Е, ако системата за резервация е много сложна и в даден момент сме направили грешка, тогава можем да унищожим резервния си сайт и освен това да превърнем данните в тиква и на двата сайта - това ще бъде напълно тъжно.

Пример номер пет, пълен хардкор

Международна услуга със стотици милиони потребители по целия свят. Има всички часови зони, голямо натоварване при максимална скорост, изобщо не можете да легнете. Минута - и ще бъде тъжно. Какво да правя? Резервирайте отново по пълната програма. Направихме всичко, за което говорих в предишния пример, и малко повече. Идеален свят и нашата инфраструктура е според всички концепции на IaaC devops. Тоест всичко е в git и просто натискаш бутона.

Какво липсва? Едно - упражнения. Без тях не може. Изглежда, че при нас всичко е перфектно, общо взето всичко е под контрол. Натискаме бутона, всичко става. Дори това да е така - а ние разбираме, че не се случва по този начин - нашата система взаимодейства с някои други системи. Например, това е dns от маршрут 53, s3 съхранение, интеграция с някои api. Няма да можем да предвидим всичко в този спекулативен експеримент. И докато не дръпнем превключвателя, няма да знаем дали ще работи или не.

Това е може би всичко. Не бъдете мързеливи и не прекалявайте. И нека ъптаймът е с вас!

Източник: www.habr.com