Всички говорят за процесите на разработка и тестване, обучение на персонала, повишаване на мотивацията, но тези процеси не са достатъчни, когато една минута престой в услугата струва огромни суми пари. Какво да правите, когато извършвате финансови транзакции съгласно строго SLA? Как да увеличите надеждността и устойчивостта на грешки на вашите системи, като изключите разработката и тестването от уравнението?
Следващата конференция HighLoad++ ще се проведе на 6 и 7 април 2020 г. в Санкт Петербург. Подробности и билети за . 9 ноември, 18:00ч. HighLoad++ Москва 2018, Делхи + зала Колката. Тезиси и .
Евгений Кузовлев (по-нататък – ЕК): - Приятели, здравейте! Казвам се Кузовлев Евгений. Аз съм от компанията EcommPay, специално подразделение е EcommPay IT, ИТ подразделението на групата компании. И днес ще говорим за престоите - за това как да ги избегнем, за това как да минимизираме последствията от тях, ако не могат да бъдат избегнати. Темата е формулирана по следния начин: „Какво да правим, когато една минута престой струва $100 000“? Гледайки напред, нашите числа са сравними.
Какво прави EcommPay IT?
Кои сме ние? Защо стоя тук пред теб? Защо имам право да ти казвам нещо тук? И за какво ще говорим тук по-подробно?
Групата компании EcommPay е международен придобиващ. Ние обработваме плащания по целия свят - в Русия, Европа, Югоизточна Азия (в целия свят). Имаме 9 офиса, общо 500 служители, като приблизително малко по-малко от половината от тях са IT специалисти. Всичко, което правим, всичко, от което правим пари, го направихме сами.
Ние написахме всички наши продукти (и имаме доста от тях - в нашата линия от големи ИТ продукти имаме около 16 различни компонента) сами; Сами пишем, сами се развиваме. И в момента извършваме около милион транзакции на ден (милиони е може би правилният начин да го кажем). Ние сме доста млада компания - ние сме само на около шест години.
Преди 6 години беше такъв стартъп, когато момчетата се появиха заедно с бизнеса. Бяха обединени от една идея (нямаше нищо друго освен идея) и ние хукнахме. Като всеки стартъп, работихме по-бързо... За нас скоростта беше по-важна от качеството.
В един момент спряхме: разбрахме, че вече някак си не можем да живеем с тази скорост и с това качество и трябва първо да се съсредоточим върху качеството. В този момент решихме да напишем нова платформа, която да бъде правилна, мащабируема и надеждна. Те започнаха да пишат тази платформа (започнаха да инвестират, да разработват разработка, да тестват), но в един момент осъзнаха, че разработката и тестването не ни позволяват да достигнем ново ниво на качество на услугата.
Правиш нов продукт, пускаш го в производство, но все някъде нещо ще се обърка. И днес ще говорим за това как да достигнем ново ниво на качество (как го направихме, за нашия опит), като извадим развитието и тестването от уравнението; ще говорим за това, което е на разположение на операцията - какво операцията може да направи сама, какво може да предложи на тестване, за да повлияе на качеството.
Престой. Заповеди за работа.
Винаги основният крайъгълен камък, това, за което всъщност ще говорим днес, е престой. Ужасна дума. Ако имаме престой, всичко е лошо за нас. Бягаме да го вдигнем, администраторите държат сървъра - дай Боже да не падне, както се казва в онази песен. За това ще говорим днес.
Когато започнахме да променяме подхода си, формирахме 4 заповеди. Представих ги на слайдовете:
Тези заповеди са доста прости:
- Бързо идентифицирайте проблема.
- Отървете се от него още по-бързо.
- Помогнете да разберете причината (по-късно, за разработчиците).
- И стандартизирайте подходите.
Бих искал да обърна внимание на точка № 2. Ние се освобождаваме от проблема, а не го решаваме. Решаването е второстепенно. За нас основното нещо е потребителят да е защитен от този проблем. То ще съществува в някаква изолирана среда, но тази среда няма да има никакъв контакт с него. Всъщност ще преминем през тези четири групи проблеми (някои по-подробно, други по-малко), ще ви кажа какво използваме, какъв съответен опит имаме в решенията.
Отстраняване на неизправности: Кога се случват и какво да правя с тях?
Но ще започнем не по ред, ще започнем с точка No2 - как бързо да се отървете от проблема? Има проблем - трябва да го поправим. „Какво трябва да направим по въпроса?“ - основният въпрос. И когато започнахме да мислим как да отстраним проблема, разработихме за себе си някои изисквания, които отстраняването на неизправности трябва да следва.
За да формулираме тези изисквания, решихме да си зададем въпроса: „Кога имаме проблеми“? И проблемите, както се оказа, възникват в четири случая:
- Хардуерна повреда.
- Външните услуги са неуспешни.
- Промяна на версията на софтуера (същото внедряване).
- Експлозивно нарастване на натоварването.
За първите две няма да говорим. Хардуерната неизправност може да бъде разрешена съвсем просто: трябва да имате всичко дублирано. Ако това са дискове, дисковете трябва да бъдат събрани в RAID; ако това е сървър, сървърът трябва да бъде дублиран; ако имате мрежова инфраструктура, трябва да предоставите второ копие на мрежовата инфраструктура, тоест взимате го и дублирайте го. И ако нещо не успее, превключвате на резервна мощност. Тук е трудно да се каже нещо повече.
Второто е провалът на външни услуги. За повечето системата изобщо не е проблем, но не и за нас. Тъй като обработваме плащания, ние сме агрегатор, който стои между потребителя (който въвежда данните за своята карта) и банките, платежните системи (Visa, MasterCard, Mira и др.). Нашите външни услуги (платежни системи, банки) са склонни да се провалят. Нито ние, нито вие (ако имате такива услуги) можем да повлияем на това.
Какво да правим тогава? Тук има два варианта. Първо, ако можете, трябва да дублирате тази услуга по някакъв начин. Например, ако можем, прехвърляме трафик от една услуга към друга: например, картите са обработени чрез Сбербанк, Сбербанк има проблеми - прехвърляме трафик [условно] към Райфайзен. Второто нещо, което можем да направим, е да забележим повредата на външни услуги много бързо и затова ще говорим за скоростта на реакция в следващата част на доклада.
Всъщност от тези четири можем конкретно да повлияем на промяната на версиите на софтуера - да предприемем действия, които ще доведат до подобряване на ситуацията в контекста на внедрявания и в контекста на експлозивно нарастване на натоварването. Всъщност това и направихме. Тук отново една малка забележка...
От тези четири проблема няколко се решават веднага, ако имате облак. Ако сте в облаците на Microsoft Azhur, Ozone или използвате нашите облаци от Yandex или Mail, тогава поне хардуерната неизправност става техен проблем и всичко веднага става наред за вас в контекста на хардуерна неизправност.
Ние сме малко нетрадиционна компания. Тук всички говорят за „Кубернец“, за облаци - нямаме нито „Кубернец“, нито облаци. Но имаме стелажи с хардуер в много центрове за данни и сме принудени да живеем на този хардуер, принудени сме да носим отговорност за всичко това. Затова ще говорим в този контекст. И така, за проблемите. Първите две бяха извадени от скоби.
Промяна на версията на софтуера. Бази
Нашите разработчици нямат достъп до продукцията. Защо така? Просто ние сме PCI DSS сертифицирани и нашите разработчици просто нямат право да влизат в „продукта“. Това е, точка. Изобщо. Следователно отговорността за разработката приключва точно в момента, в който разработката изпрати компилацията за пускане.
Втората ни база, която имаме и която също много ни помага, е липсата на уникални недокументирани знания. Надявам се и при теб да е така. Защото ако това не е така, ще имате проблеми. Проблеми ще възникнат, когато това уникално, недокументирано знание не присъства в точното време на правилното място. Да кажем, че имате един човек, който знае как да разположи определен компонент - човекът го няма, на почивка е или е болен - това е, имате проблеми.
И третата основа, до която стигнахме. Стигнахме до него с болка, кръв, сълзи - стигнахме до извода, че всеки наш билд съдържа грешки, дори и да е без грешки. Решихме това за себе си: когато внедрим нещо, когато внедрим нещо в производство, имаме компилация с грешки. Ние сме формирали изискванията, на които трябва да отговаря нашата система.
Изисквания за промяна на версията на софтуера
Има три изисквания:
- Трябва бързо да отменим внедряването.
- Трябва да сведем до минимум въздействието на неуспешно внедряване.
- И ние трябва да можем бързо да разположим паралелно.
Точно в този ред! Защо? Защото, на първо място, когато внедрявате нова версия, скоростта не е важна, но е важно за вас, ако нещо се обърка, бързо да се върнете назад и да имате минимално въздействие. Но ако имате набор от версии в производство, за които се оказва, че има грешка (изневиделица не е имало внедряване, но има грешка) - скоростта на последващото внедряване е важна за вас. Какво направихме, за да отговорим на тези изисквания? Прибягнахме до следната методика:
Това е доста добре известно, ние никога не сме го измисляли - това е Blue/Green deploy. Какво е? Трябва да имате копие за всяка група сървъри, на които са инсталирани вашите приложения. Копието е „топло“: към него няма трафик, но във всеки момент този трафик може да бъде изпратен към това копие. Това копие съдържа предишната версия. И по време на внедряването вие разгръщате кода в неактивно копие. След това превключвате част от трафика (или целия) към новата версия. По този начин, за да промените потока на трафика от старата версия към новата, трябва да направите само едно действие: трябва да промените балансира нагоре по течението, да промените посоката - от едно нагоре по течението към друго. Това е много удобно и решава проблема с бързото превключване и бързото връщане назад.Тук решението на втория въпрос е минимизиране: можете да изпратите само част от трафика си към нова линия, към линия с нов код (нека да бъде например 2%). И тези 2% не са 100%! Ако сте загубили 100% от трафика си поради неуспешно внедряване, това е страшно; ако сте загубили 2% от трафика си, това е неприятно, но не е страшно. Освен това потребителите най-вероятно дори няма да забележат това, защото в някои случаи (не във всички) същият потребител, натискайки F5, ще бъде отведен до друга, работеща версия.
Синьо/зелено внедряване. Маршрутизиране
Въпреки това, не всичко е толкова просто “Blue/Green deploy”... Всички наши компоненти могат да бъдат разделени на три групи:
- това е фронтендът (страниците за плащане, които нашите клиенти виждат);
- ядро за обработка;
- адаптер за работа с платежни системи (банки, MasterCard, Visa...).
И тук има един нюанс - нюансът се крие в маршрутизирането между редовете. Ако просто прехвърлите 100% от трафика, нямате тези проблеми. Но ако искате да смените 2%, започвате да задавате въпроси: „Как да направя това?“ Най-простото нещо е направо напред: можете да настроите Round Robin в nginx чрез произволен избор и имате 2% отляво, 98% отдясно. Но това не винаги е подходящо.
Например, в нашия случай потребител взаимодейства със системата с повече от една заявка. Това е нормално: 2, 3, 4, 5 заявки - вашите системи може да са еднакви. И ако за вас е важно всички заявки на потребителя да идват на същия ред, на който е дошла първата заявка, или (втора точка) всички заявки на потребителя да идват на новия ред след превключването (той можеше да започне да работи по-рано с система, преди превключването), - тогава това произволно разпределение не е подходящо за вас. След това има следните опции:
Първият вариант, най-простият, се основава на основните параметри на клиента (IP Hash). Имате IP и го разделяте от дясно на ляво по IP адрес. Тогава вторият случай, който описах, ще работи за вас, когато е настъпило внедряването, потребителят вече може да започне да работи с вашата система и от момента на внедряване всички заявки ще отидат на нов ред (на същия, да речем).Ако по някаква причина това не ви устройва и трябва да изпратите заявки до реда, където е дошла първоначалната, първоначална заявка на потребителя, тогава имате две възможности...
Първи вариант: можете да закупите платен nginx+. Има механизъм Sticky sessions, който при първоначална заявка на потребителя присвоява сесия на потребителя и я свързва с един или друг upstream. Всички последващи потребителски заявки в рамките на жизнения цикъл на сесията ще бъдат изпратени до същия възходящ поток, където е публикувана сесията.Това не ни устройваше, защото вече имахме обикновен nginx. Преминаването към nginx+ не означава, че е скъпо, просто беше малко болезнено за нас и не беше много правилно. „Sticks Sessions“ например не работи за нас по простата причина, че „Sticks Sessions“ не позволява маршрутизиране въз основа на „Или-или“. Там можете да посочите какво правим ние „Sticks Sessions“, например чрез IP адрес или чрез IP адрес и бисквитки или чрез постпараметър, но там „Или-или“ е по-сложно.
Следователно стигнахме до четвъртия вариант. Взехме nginx на стероиди (това е openresty) - това е същият nginx, който допълнително поддържа включването на последните скриптове. Можете да напишете последен скрипт, да му дадете „отворена почивка“ и този последен скрипт ще бъде изпълнен, когато дойде потребителската заявка.
И ние написахме всъщност такъв скрипт, зададохме си „openresti“ и в този скрипт сортираме 6 различни параметъра чрез конкатенация „Или“. В зависимост от наличието на един или друг параметър, ние знаем, че потребителят е стигнал до една или друга страница, един или друг ред.
Синьо/зелено внедряване. Предимства и недостатъци
Разбира се, вероятно е било възможно да го направим малко по-просто (използвайте същите „Sticky Sessions“), но имаме и такъв нюанс, че не само потребителят взаимодейства с нас в рамките на една обработка на една транзакция ... Но платежните системи също взаимодействат с нас: След като обработим транзакцията (чрез изпращане на заявка до платежната система), получаваме кулбек.
И да кажем, ако вътре в нашата верига можем да препращаме IP адреса на потребителя във всички заявки и да разделяме потребителите въз основа на IP адреса, тогава няма да кажем на същата „Visa“: „Пич, ние сме такава ретро компания, изглеждаме да бъде международен (на уебсайта и в Русия)... Моля, предоставете ни IP адреса на потребителя в допълнително поле, вашият протокол е стандартизиран”! Ясно е, че няма да се съгласят.
Следователно това не проработи за нас - направихме openresty. Съответно с маршрутизирането получихме нещо подобно:Blue/Green Deployment съответно има предимствата, които споменах, и недостатъците.
Два недостатъка:
- трябва да се занимавате с маршрутизиране;
- вторият основен недостатък е разходът.
Имате нужда от два пъти повече сървъри, имате нужда от два пъти повече оперативни ресурси, трябва да похарчите два пъти повече усилия, за да поддържате целия този зоопарк.
Между другото, сред предимствата има още нещо, което не споменах досега: имате резерв в случай на увеличаване на натоварването. Ако имате експлозивно нарастване на натоварването, имате голям брой потребители, тогава просто включвате втория ред в разпределението 50 към 50 - и веднага имате x2 сървъра във вашия клъстер, докато не решите проблема с наличието на повече сървъри.
Как да направите бързо внедряване?
Говорихме за това как да решим проблема с минимизирането и бързото връщане назад, но остава въпросът: „Как да разположим бързо?“
Тук е кратко и просто.- Трябва да имате CD система (непрекъсната доставка) - не можете да живеете без нея. Ако имате един сървър, можете да разположите ръчно. Имаме около хиляда и половина сървъри и хиляда и половина манипулатори, разбира се – можем да създадем отдел с размера на тази стая само за разгръщане.
- Разгръщането трябва да е паралелно. Ако вашето внедряване е последователно, тогава всичко е лошо. Един сървър е нормален, ще разполагате хиляди и половина сървъри през целия ден.
- Отново, за ускорение, това вероятно вече не е необходимо. По време на внедряването проектът обикновено се изгражда. Имаш уеб проект, има front-end част (там правиш web pack, компилираш npm - нещо такова) и този процес по принцип е краткотраен - 5 минути, но тези 5 минути може бъди критичен. Ето защо, например, ние не правим това: премахнахме тези 5 минути, внедряваме артефакти.
Какво е артефакт? Артефактът е сглобена конструкция, в която всички части за сглобяване вече са завършени. Ние съхраняваме този артефакт в хранилището за артефакти. По едно време използвахме две такива хранилища - това беше Nexus и сега jFrog Artifactory) Първоначално използвахме "Nexus", защото започнахме да практикуваме този подход в java приложения (много му пасна). След това поставят там някои от приложенията, написани на PHP; и „Nexus“ вече не беше подходящ и затова избрахме jFrog Artefactory, който може да артифакторизира почти всичко. Дори стигнахме дотам, че в това хранилище на артефакти съхраняваме нашите собствени двоични пакети, които събираме за сървъри.
Експлозивно нарастване на натоварването
Говорихме за промяна на версията на софтуера. Следващото нещо, което имаме, е експлозивно увеличаване на натоварването. Тук вероятно имам предвид под експлозивно нарастване на товара не съвсем правилното нещо...
Написахме нова система - тя е ориентирана към услугите, модерна, красива, работници навсякъде, опашки навсякъде, асинхрон навсякъде. И в такива системи данните могат да преминават през различни потоци. За първата транзакция може да се използва 1-ви, 3-ти, 10-ти работник, за втора транзакция - 2-ри, 4-ти, 5-ти. И днес, да речем, сутринта имате поток от данни, който използва първите трима работни, а вечерта се променя драстично и всичко използва другите трима работни.
И тук се оказва, че трябва по някакъв начин да мащабирате работниците, трябва по някакъв начин да мащабирате услугите си, но в същото време да предотвратите раздуването на ресурсите.
Ние сме определили нашите изисквания. Тези изисквания са съвсем прости: да има откриване на услуги, параметризация - всичко е стандартно за изграждане на такива мащабируеми системи, с изключение на една точка - амортизация на ресурса. Казахме, че не сме готови да амортизираме ресурси, така че сървърите да отопляват въздуха. Взехме "Консул", взехме "Номад", които управляват нашите работници.Защо това е проблем за нас? Да се върнем малко назад. Сега имаме около 70 платежни системи зад гърба си. Сутринта трафикът минава през Сбербанк, след това Сбербанк падна, например, и го превключваме на друга платежна система. Имахме 100 служители преди Сбербанк, а след това трябва рязко да увеличим 100 работници за друга платежна система. И е желателно всичко това да става без човешко участие. Защото, ако има човешко участие, трябва да има инженер, който да седи 24/7, който да прави само това, защото такива повреди, когато 70 системи са зад гърба ти, се случват редовно.
Затова разгледахме Nomad, който има отворен IP, и написахме нашето собствено нещо, Scale-Nomad - ScaleNo, което прави приблизително следното: следи растежа на опашката и намалява или увеличава броя на работниците в зависимост от динамиката на опашката. Когато го направихме, си помислихме: „Може би можем да го отворим?“ После я погледнаха - тя беше проста като две копейки.
Засега не сме го отворили, но ако изведнъж след доклада, след като разберете, че имате нужда от такова нещо, имате нужда от него, моите контакти са в последния слайд - моля, пишете ми. Ако има поне 3-5 човека, ще го спонсорираме.
Как работи? Нека да разгледаме! Гледайки напред: от лявата страна има част от нашия мониторинг: това е един ред, в горната част е времето за обработка на събитието, в средата е броят на транзакциите, в долната част е броят на работниците.Ако погледнете, има проблем в тази снимка. В горната класация една от класациите се срина за 45 секунди - една от платежните системи падна. Веднага трафикът беше въведен за 2 минути и опашката започна да расте в друга платежна система, където нямаше работници (ние не използвахме ресурси - напротив, разпоредихме ресурса правилно). Не искахме да топлим - имаше минимален брой, около 5-10 работници, но не можаха да се справят.
Последната графика показва „гърбица“, което просто означава, че „Скалено“ е удвоило тази сума. И тогава, когато графиката падна малко, той я намали малко - броят на работниците се промени автоматично. Така става това нещо. Говорихме за точка номер 2 - „Как бързо да се отървем от причините“.
Мониторинг. Как бързо да идентифицирате проблема?
Сега първата точка е „Как бързо да идентифицираме проблема?“ Мониторинг! Трябва бързо да разберем някои неща. Кои неща трябва да разберем бързо?
Три неща!- Трябва да разберем и да разберем бързо ефективността на нашите собствени ресурси.
- Трябва бързо да разбираме неизправностите и да наблюдаваме ефективността на системите, които са външни за нас.
- Третата точка е идентифицирането на логически грешки. Това е, когато системата ви работи, всичко е нормално по всички показатели, но нещо се обърка.
Вероятно няма да ви кажа нищо толкова готино тук. Аз ще бъда Captain Obvious. Потърсихме какво има на пазара. Имаме „забавна зоологическа градина“. Ето такъв зоопарк имаме сега:
Използваме Zabbix за наблюдение на хардуера, за наблюдение на основните показатели на сървърите. Използваме Okmeter за бази данни. Използваме „Графана“ и „Прометей“ за всички останали показатели, които не отговарят на първите два, някои с „Графана“ и „Прометей“, а други с „Графана“ с „Инфлукс“ и Телеграф.Преди година искахме да използваме New Relic. Готино нещо, може всичко. Но колкото може всичко, толкова е скъпа. Когато нараснахме до обем от 1,5 хиляди сървъра, един доставчик дойде при нас и каза: „Нека сключим споразумение за следващата година.“ Погледнахме цената и казахме не, няма да го направим. Сега изоставяме New Relic, имаме около 15 сървъра, останали под наблюдението на New Relic. Цената се оказа абсолютно дива.
И има един инструмент, който внедрихме сами - това е Debugger. Първо го нарекохме „Bagger“, но след това учител по английски мина, изсмя се лудо и го преименува на „Debagger“. Какво е? Това е инструмент, който всъщност за 15-30 секунди на всеки компонент, като „черна кутия“ на системата, провежда тестове за цялостната производителност на компонента.
Например, ако има външна страница (страница за плащане), той просто я отваря и гледа как трябва да изглежда. Ако това е обработка, той изпраща тестова „транзакция“ и се уверява, че тази „транзакция“ пристига. Ако това е връзка с платежни системи, ние съответно задействаме тестова заявка, където можем, и виждаме, че всичко е наред с нас.
Какви показатели са важни за наблюдение?
Какво основно наблюдаваме? Какви показатели са важни за нас?
- Времето за реакция / RPS на фронтовете е много важен показател. Той веднага отговаря, че нещо не е наред с вас.
- Броят на обработените съобщения във всички опашки.
- Брой работници.
- Основни показатели за коректност.
Последната точка е показател „бизнес“, „бизнес“. Ако искате да наблюдавате едно и също нещо, трябва да дефинирате една или две метрики, които са основните индикатори за вас. Нашият показател е пропускателна способност (това е съотношението на броя на успешните транзакции към общия поток от транзакции). Ако нещо се промени в него на интервал от 5-10-15 минути, това означава, че имаме проблеми (ако се промени радикално).
Това, което изглежда за нас, е пример за една от нашите дъски:
От лявата страна има 6 графики, това е според редовете - броя на работниците и броя на съобщенията в опашките. От дясната страна – RPS, RTS. По-долу е същият „бизнес“ показател. И в показателя „бизнес“ веднага можем да видим, че нещо се е объркало в двете средни графики... Това е просто още една система, която стои зад нас и е паднала.Второто нещо, което трябваше да направим, беше да наблюдаваме спада на външните платежни системи. Тук взехме OpenTracing - механизъм, стандарт, парадигма, която ви позволява да проследявате разпределени системи; и беше малко променено. Стандартната парадигма на OpenTracing казва, че изграждаме проследяване за всяка отделна заявка. Нямахме нужда от това и го опаковахме в обобщена, обобщена следа. Направихме инструмент, който ни позволява да проследяваме скоростта на системите зад нас.
Графиката ни показва, че една от платежните системи започна да реагира след 3 секунди - имаме проблеми. Освен това това нещо ще реагира, когато започнат проблемите, на интервал от 20-30 секунди.И третият клас грешки при наблюдение, които съществуват, е логическият мониторинг.
Честно казано, не знаех какво да нарисувам на този слайд, защото дълго време търсихме на пазара нещо, което да ни подхожда. Не намерихме нищо, така че трябваше да го направим сами.
Какво имам предвид под логично наблюдение? Ами представете си: правите си система (например клонинг на Tinder); ти го направи, пусна го. Успешният мениджър Вася Пупкин го слага на телефона си, вижда момиче там, харесва я... и харесването не отива на момичето - харесването отива на охранителя Михалич от същия бизнес център. Управителят слиза долу и след това се чуди: „Защо този охранител Михалич му се усмихва толкова мило?“В такива ситуации... За нас тази ситуация звучи малко по-различно, защото (написах) това е загуба на репутация, която индиректно води до финансови загуби. Нашата ситуация е обратната: може да понесем преки финансови загуби - например, ако сме извършили транзакция като успешна, но тя е била неуспешна (или обратното). Трябваше да напиша свой собствен инструмент, който проследява броя на успешните транзакции във времето, използвайки бизнес индикатори. Не намерих нищо на пазара! Точно тази идея исках да предам. На пазара няма нищо, което да реши този проблем.
Това беше за това как бързо да идентифицирате проблема.
Как да определим причините за разгръщането
Третата група проблеми, които решаваме, е след като сме идентифицирали проблема, след като сме се отървали от него, би било добре да разберем причината за разработката, за тестването и да направим нещо по въпроса. Съответно трябва да проучим, трябва да вдигнем трупите.
Ако говорим за регистрационни файлове (основната причина са регистрационни файлове), по-голямата част от нашите регистрационни файлове са в ELK Stack - почти всеки има същото. За някои може да не е в ELK, но ако пишете регистрационни файлове в гигабайти, тогава рано или късно ще стигнете до ELK. Записваме ги в терабайти.
Тук има проблем. Поправихме го, коригирахме грешката за потребителя, започнахме да копаем какво има там, изкачихме се в Kibana, въведохме идентификатора на транзакцията там и получихме кърпа за крака като тази (показва много). И абсолютно нищо не е ясно в тази кърпа. Защо? Да, защото не е ясно коя част на кой работник принадлежи, коя част на кой компонент принадлежи. И в този момент осъзнахме, че имаме нужда от проследяване - същият OpenTracing, за който говорих.Мислихме това преди година, насочихме вниманието си към пазара и там имаше два инструмента - „Zipkin“ и „Jaeger“. “Jager” всъщност е такъв идеологически наследник, идеологически приемник на “Zipkin”. Всичко е добро в Zipkin, с изключение на това, че не знае как да агрегира, не знае как да включва регистрационни файлове в проследяването, само проследяване на времето. И "Jager" подкрепи това.
Разгледахме „Jager“: можете да инструментирате приложения, можете да пишете в Api (стандартът Api за PHP по това време обаче не беше одобрен - това беше преди година, но сега вече е одобрен), но има не беше абсолютно никакъв клиент. „Добре“, помислихме ние и написахме собствения си клиент. Какво получихме? Ето така изглежда приблизително:
В Jaeger се създават обхвати за всяко съобщение. Тоест, когато потребителят отвори системата, той вижда един или два блока за всяка входяща заявка (1-2-3 - броят на входящите заявки от потребителя, броят на блоковете). За да улесним потребителите, добавихме тагове към регистрационните файлове и времеви следи. Съответно, в случай на грешка, нашето приложение ще маркира дневника със съответния етикет за грешка. Можете да филтрирате по етикет за грешка и ще се показват само участъци, които съдържат този блок с грешка. Ето как изглежда, ако разширим обхвата:
Вътре в участъка има набор от следи. В този случай това са три тестови следи, като третата следа ни казва, че е възникнала грешка. В същото време тук виждаме времева следа: имаме времева скала в горната част и виждаме в какъв интервал от време е записан този или онзи дневник.Съответно нещата ни се получиха. Написахме собствено разширение и го отворихме. Ако искате да работите с проследяване, ако искате да работите с „Jager“ в PHP, има нашето разширение, добре дошли да използвате, както се казва:
Имаме това разширение - това е клиент за OpenTracing Api, направено е като php-разширение, тоест ще трябва да го сглобите и инсталирате в системата. Преди година нямаше нищо по-различно. Сега има други клиенти, които са като компоненти. Тук зависи от вас: или изпомпвате компонентите с композитор, или използвате разширение според вас.Корпоративни стандарти
Говорихме за трите заповеди. Четвъртата заповед е да се стандартизират подходите. За какво се отнася? Става въпрос за това:
Защо тук е думата „корпоративен“? Не защото сме голяма или бюрократична компания, не! Исках да използвам думата „корпоративен“ тук в контекста, че всяка компания, всеки продукт трябва да има свои собствени стандарти, включително и вие. Какви стандарти имаме?
- Имаме правила за разполагане. Никъде не мърдаме без него, не можем. Ние разполагаме около 60 пъти седмично, тоест разполагаме почти постоянно. В същото време имаме, например, в правилника за разполагане табу за разполагане в петък - по принцип не разполагаме.
- Изискваме документация. Нито един нов компонент не влиза в производство, ако няма документация за него, дори ако е роден под писалката на нашите RnD специалисти. Ние изискваме от тях инструкции за внедряване, карта за наблюдение и грубо описание (е, както програмистите могат да напишат) на това как работи този компонент, как да го отстраните.
- Решаваме не причината за проблема, а проблема - това, което вече казах. За нас е важно да защитим потребителя от проблеми.
- Имаме разрешения. Например, ние не считаме за престой, ако загубим 2% от трафика в рамките на две минути. Това по принцип не е включено в нашата статистика. Ако е повече процентно или временно, вече броим.
- И винаги пишем аутопсии. Каквото и да се случи с нас, всяка ситуация, при която някой се е държал необичайно в производството, ще бъде отразена в аутопсия. Аутопсията е документ, в който записвате какво ви се е случило, подробно време, какво сте направили, за да го коригирате и (това е задължителен блок!) какво ще направите, за да предотвратите това да се случи в бъдеще. Това е задължително и необходимо за последващ анализ.
Какво се счита за престой?
До какво доведе всичко това?Това доведе до факта, че (имахме известни проблеми със стабилността, това не устройваше нито клиентите, нито нас) през последните 6 месеца нашият показател за стабилност беше 99,97. Можем да кажем, че това не е много. Да, има към какво да се стремим. От този показател около половината е стабилността, така да се каже, не на нашата, а на защитната стена на нашето уеб приложение, която стои пред нас и се използва като услуга, но клиентите не се интересуват от това.
Научихме се да спим през нощта. Най-накрая! Преди шест месеца не можахме. И на тази бележка с резултатите бих искал да направя една бележка. Снощи имаше чудесен репортаж за системата за управление на ядрен реактор. Ако хората, които са написали тази система, могат да ме чуят, моля, забравете какво казах за „2% не е престой“. За вас 2% е престой, дори и за две минути!
Това е всичко! Вашите въпроси.
Относно балансьорите и миграцията на бази данни
Въпрос от публиката (по-нататък – Б): – Добър вечер. Благодаря ви много за такъв доклад на администратора! Кратък въпрос за вашите балансьори. Споменахте, че имате WAF, тоест, както разбирам, използвате някакъв вид външен балансьор...
ЕК: – Не, ние използваме нашите услуги като балансьор. В този случай WAF е изключително средство за защита от DDoS за нас.
AT: – Можете ли да кажете няколко думи за балансьорите?
ЕК: – Както вече казах, това е група сървъри в openresty. Сега имаме 5 резервни групи, които отговарят изключително... тоест сървър, който работи изключително openresty, той само прокси трафик. Съответно, за да разберем колко държим: сега имаме редовен трафик от няколкостотин мегабита. Справят се, чувстват се добре, дори не се напрягат.
AT: – Също прост въпрос. Ето синьо/зелено внедряване. Какво правите например с миграциите на бази данни?
ЕК: - Добър въпрос! Вижте, при синьо/зелено внедряване имаме отделни опашки за всяка линия. Тоест, ако говорим за опашки от събития, които се предават от работник на работник, има отделни опашки за синята линия и за зелената линия. Ако говорим за самата база данни, тогава умишлено я стеснихме, доколкото можахме, преместихме всичко практически в опашки; в базата данни съхраняваме само стек от транзакции. И нашият стек от транзакции е еднакъв за всички линии. С базата данни в този контекст: ние не я разделяме на синя и зелена, защото и двете версии на кода трябва да знаят какво се случва с транзакцията.
Приятели, имам и една малка награда, с която да ви стимулирам - книга. И трябва да го наградя за най-добър въпрос.
AT: - Здравейте. Благодаря за доклада. Въпросът е следният. Следите плащанията, наблюдавате услугите, с които комуникирате ... Но как следите, така че човек по някакъв начин да дойде на страницата ви за плащане, да направи плащане и проектът да го кредитира с пари? Тоест, как следите дали търговецът е наличен и е приел вашето обратно повикване?
ЕК: – „Търговец“ за нас в този случай е точно същата външна услуга като платежната система. Следим скоростта на реакция на търговеца.
Относно криптирането на базата данни
AT: - Здравейте. Имам малко свързан въпрос. Имате PCI DSS чувствителни данни. Исках да знам как съхранявате PAN в опашки, в които трябва да прехвърлите? Използвате ли някакво криптиране? И това води до втория въпрос: според PCI DSS е необходимо периодично да се криптира базата данни в случай на промени (уволнение на администратори и т.н.) - какво се случва с достъпността в този случай?
ЕК: - Прекрасен въпрос! Първо, ние не съхраняваме PAN в опашки. По принцип нямаме право да съхраняваме PAN никъде в ясна форма, затова използваме специална услуга (наричаме я „Kademon“) - това е услуга, която прави само едно нещо: получава съобщение като вход и изпраща изведете криптирано съобщение. И ние съхраняваме всичко с това криптирано съобщение. Съответно дължината на нашия ключ е под килобайт, така че това е сериозно и надеждно.AT: – Имате ли нужда от 2 килобайта сега?
ЕК: – Сякаш вчера бяха 256... Е, къде другаде?!
Съответно това е първото. И второ, решението, което съществува, поддържа процедурата за повторно криптиране - има две двойки "keks" (ключове), които дават "колоди", които криптират (ключ са ключовете, dek са производни на ключовете, които криптират) . И ако процедурата бъде стартирана (това се случва редовно, от 3 месеца до ± някои), изтегляме нова двойка „торти“ и повторно шифроваме данните. Имаме отделни услуги, които извличат всички данни и ги криптират по нов начин; Данните се съхраняват до идентификатора на ключа, с който са криптирани. Съответно, щом криптираме данните с нови ключове, изтриваме стария ключ.
Понякога плащанията трябва да се извършват ръчно...
AT: – Тоест, ако е пристигнало възстановяване за някаква операция, пак ли ще го дешифрирате със стария ключ?
ЕК: - Да.
AT: – Тогава още един малък въпрос. Когато възникне някакъв вид повреда, падане или инцидент, е необходимо транзакцията да се извърши ръчно. Има такава ситуация.
ЕК: - Да понякога.
AT: – Откъде черпите тези данни? Или сам отиваш до това хранилище?
ЕК: – Не, добре, разбира се, имаме някаква бек-офис система, която съдържа интерфейс за нашата поддръжка. Ако не знаем в какъв статус е транзакцията (например, докато платежната система не отговори с таймаут), ние не знаем априори, тоест задаваме крайния статус само с пълна увереност. В този случай присвояваме на транзакцията специален статус за ръчна обработка. Сутринта, на следващия ден, веднага щом поддръжката получи информация, че такива и такива транзакции остават в платежната система, те ги обработват ръчно в този интерфейс.
AT: – Имам няколко въпроса. Един от тях е продължението на PCI DSS зоната: как регистрирате тяхната верига? Този въпрос е, защото разработчикът може да е поставил всичко в регистрационните файлове! Втори въпрос: как пускате актуални корекции? Използването на манипулатори в базата данни е една опция, но може да има безплатни горещи корекции - каква е процедурата там? И третият въпрос вероятно е свързан с RTO, RPO. Вашата наличност беше 99,97, почти четири деветки, но както разбирам, имате втори център за данни, трети център за данни и пети център за данни... Как ги синхронизирате, репликирате и всичко останало?ЕК: - Да започнем с първото. Първият въпрос за трупите ли беше? Когато пишем регистрационни файлове, имаме слой, който маскира всички чувствителни данни. Тя гледа маската и допълнителните полета. Съответно нашите логове излизат с вече маскирани данни и PCI DSS верига. Това е една от редовните задачи, възложени на отдела за тестване. Те са длъжни да проверяват всяка задача, включително логовете, които пишат, и това е една от редовните задачи по време на прегледи на кода, за да се контролира дали разработчикът не е записал нещо. Последващи проверки за това се извършват редовно от отдела за информационна сигурност около веднъж седмично: регистрационните файлове за последния ден се вземат избирателно и те преминават през специален скенер-анализатор от тестови сървъри, за да се провери всичко.
Относно горещите корекции. Това е включено в нашите разпоредби за внедряване. Имаме отделна клауза за актуални корекции. Ние вярваме, че внедряваме актуални корекции денонощно, когато имаме нужда. Веднага щом се сглоби версията, веднага щом се стартира, щом имаме артефакт, имаме дежурен системен администратор на обаждане от поддръжката и той го внедрява в момента, в който е необходимо.За "четири деветки". Цифрата, която имаме сега, наистина е постигната и ние се стремихме към нея в друг център за данни. Сега имаме втори център за данни и започваме да маршрутизираме между тях, а въпросът за репликацията между центрове за данни е наистина нетривиален въпрос. Опитахме се да го решим по едно време с различни средства: опитахме се да използваме същата „Тарантула“ - не ни се получи, ще ви кажа веднага. Ето защо в крайна сметка поръчахме "сенса" ръчно. Всъщност всяко приложение в нашата система изпълнява необходимата синхронизация „промяна – извършена“ между центровете за данни асинхронно.
AT: – Ако имаш второ, защо не си взело и трето? Защото все още никой няма раздвоен мозък...
ЕК: – Но ние нямаме Split Brain. Поради факта, че всяко приложение се управлява от мултимастър, за нас няма значение в кой център е постъпила заявката. Ние сме готови за факта, че ако един от нашите центрове за данни се провали (ние разчитаме на това) и по средата на потребителска заявка превключи към втория център за данни, ние наистина сме готови да загубим този потребител; но това ще бъдат единици, абсолютни единици.
AT: - Добър вечер. Благодаря за доклада. Говорихте за вашия дебъгер, който изпълнява някои тестови транзакции в производството. Но разкажете ни за тестови транзакции! Колко дълбоко е?
ЕК: – Преминава през пълния цикъл на целия компонент. За компонент няма разлика между тестова транзакция и производствена. Но от логическа гледна точка това е просто отделен проект в системата, върху който се изпълняват само тестови транзакции.
AT: -Къде го отрязваш? Тук Core изпрати...
ЕК: – Ние сме зад „Kor“ в този случай за тестови транзакции... Имаме такова нещо като маршрутизиране: „Kor“ знае към коя платежна система да изпрати - ние изпращаме към фалшива платежна система, която просто дава http сигнал и това е всичко.
AT: – Кажете ми, моля, вашето приложение беше ли написано в един огромен монолит или го разделихте на някои услуги или дори на микроуслуги?
ЕК: – Ние, разбира се, нямаме монолит, имаме приложение, ориентирано към услугата. Шегуваме се, че сервизът ни е монолитен – наистина са доста големи. Трудно е да го наречем микроуслуги, но това са услуги, в които работят служители на разпределени машини.
Ако услугата на сървъра е компрометирана...
AT: – Тогава имам следващия въпрос. Дори и да беше монолит, все пак казахте, че имате много от тези мигновени сървъри, всички те основно обработват данни и въпросът е: „В случай на компрометиране на един от мигновените сървъри или приложение, всяка отделна връзка , имат ли някакъв вид контрол на достъпа? Кой от тях какво може? Към кого да се обърна за каква информация?
ЕК: - Да, определено. Изискванията за сигурност са доста сериозни. Първо, имаме отворени движения на данни и портовете са само тези, през които очакваме движението на трафика предварително. Ако компонент комуникира с базата данни (да речем с Muskul) чрез 5-4-3-2, само 5-4-3-2 ще бъде отворен за него и други портове и други посоки на трафика няма да бъдат достъпни. Освен това трябва да разберете, че в нашето производство има около 10 различни вериги за сигурност. И дори ако приложението е било компрометирано по някакъв начин, не дай си Боже, атакуващият няма да може да получи достъп до конзолата за управление на сървъра, защото това е различна зона за сигурност на мрежата.AT: – И в този контекст за мен е по-интересно, че имаш определени договори със службите – какво могат да правят, чрез какви „действия“ могат да контактуват помежду си... И в нормален поток някои специфични служби изискват някакви ред, списък с „действия“ от другата. Изглежда не се обръщат към другите в нормална ситуация и имат други области на отговорност. Ако една от тях е компрометирана, ще може ли да наруши „действията“ на тази услуга?..
ЕК: - Разбирам. Ако в нормална ситуация с друг сървър комуникацията изобщо беше разрешена, тогава да. Съгласно договора за SLA, ние не следим дали са ви разрешени само първите 3 „действия“ и не са ви разрешени 4-те „действия“. За нас това може би е излишно, защото вече имаме 4-степенна система за защита по принцип за вериги. Предпочитаме да се защитим с контурите, отколкото на нивото на вътрешностите.
Как работят Visa, MasterCard и Sberbank
AT: – Искам да изясня нещо относно превключването на потребител от един център за данни в друг. Доколкото знам, Visa и MasterCard работят с двоичен синхронен протокол 8583 и там има смеси. И исках да знам, сега имаме предвид превключване – директно „Visa“ и „MasterCard“ ли е или преди платежни системи, преди обработка?
ЕК: - Това е преди миксовете. Нашите миксове се намират в същия център за данни.
AT: – Грубо казано, имате ли една връзка?
ЕК: – “Visa” и “MasterCard” – да. Просто защото Visa и MasterCard изискват доста сериозни инвестиции в инфраструктура, за да сключат отделни договори за получаване на втори чифт миксове например. Те са запазени в рамките на един дейта център, но ако, не дай си Боже, нашият център за данни, където има миксове за връзка с Visa и MasterCard, умре, тогава ще имаме изгубена връзка с Visa и MasterCard...
AT: – Как могат да бъдат запазени? Знам, че Visa позволява само една връзка по принцип!
ЕК: – Сами доставят техниката. Във всеки случай получихме оборудване, което е напълно излишно вътре.
AT: – Значи стойката е от техния Connects Orange?..
ЕК: - Да.
AT: – Но какво ще кажете за този случай: ако вашият център за данни изчезне, как можете да продължите да го използвате? Или трафикът просто спира?
ЕК: - Не. В този случай ние просто ще прехвърлим трафика към друг канал, което естествено ще бъде по-скъпо за нас и по-скъпо за нашите клиенти. Но трафикът няма да минава през нашата директна връзка с Visa, MasterCard, а през условната Sberbank (много преувеличена).
Много се извинявам, ако съм обидил служителите на Сбербанк. Но според нашата статистика сред руските банки Сбербанк пада най-често. Не минава месец без нещо да падне в Сбербанк.
Малко реклами 🙂
Благодарим ви, че останахте с нас. Харесвате ли нашите статии? Искате ли да видите още интересно съдържание? Подкрепете ни, като направите поръчка или препоръчате на приятели, , уникален аналог на сървъри от начално ниво, който беше изобретен от нас за вас: (предлага се с RAID1 и RAID10, до 24 ядра и до 40GB DDR4).
Dell R730xd 2 пъти по-евтин в центъра за данни Equinix Tier IV в Амстердам? Само тук в Холандия! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - от $99! Прочети за
Източник: www.habr.com