Сите зборуваат за процесите на развој и тестирање, обука на персоналот, зголемување на мотивацијата, но овие процеси не се доволни кога една минута прекин на услугата чини огромни суми пари. Што да направите кога вршите финансиски трансакции според строг SLA? Како да ја зголемите доверливоста и толеранцијата на грешки на вашите системи, земајќи го развојот и тестирањето надвор од равенката?
Следната конференција HighLoad++ ќе се одржи на 6 и 7 април 2020 година во Санкт Петербург. Детали и билети за . 9 ноември, 18:00 часот. HighLoad++ Москва 2018 година, Делхи + сала Калкута. Тези и .
Евгениј Кузовлев (во натамошниот текст – ЕК): - Пријатели, здраво! Јас се викам Кузовлев Евгениј. Јас сум од компанијата EcommPay, специфична поделба е EcommPay IT, ИТ поделбата на групата компании. И денес ќе зборуваме за прекини - за тоа како да ги избегнете, за тоа како да ги минимизирате нивните последици ако не може да се избегне. Темата е наведена на следниов начин: „Што да се прави кога една минута прекин чини 100 долари“? Гледајќи напред, нашите бројки се споредливи.
Што прави EcommPay IT?
Кои сме ние? Зошто стојам овде пред тебе? Зошто имам право да ти кажам нешто овде? И за што ќе зборуваме овде подетално?
Групата на компании EcommPay е меѓународен стекнувач. Ние обработуваме плаќања низ целиот свет - во Русија, Европа, Југоисточна Азија (Сите низ светот). Имаме 9 канцеларии, вкупно 500 вработени, а приближно нешто помалку од половина од нив се ИТ специјалисти. Сè што правиме, сè од што заработуваме, сме направиле самите.
Сите наши производи (и ги имаме доста - во нашата линија на големи ИТ производи имаме околу 16 различни компоненти) самите ги напишавме; Сами се пишуваме, самите се развиваме. И во моментот извршуваме околу милион трансакции дневно (милиони веројатно е вистинскиот начин да се каже). Ние сме прилично млада компанија - имаме само околу шест години.
Пред 6 години беше таков стартап кога момците дојдоа заедно со бизнисот. Нив ги обедини една идеја (немаше ништо друго освен идеја), и истрчавме. Како и секој стартап, трчавме побрзо... За нас брзината беше поважна од квалитетот.
Во одреден момент застанавме: сфативме дека повеќе не можеме некако да живееме со таа брзина и со тој квалитет и треба прво да се фокусираме на квалитетот. Во овој момент, решивме да напишеме нова платформа која ќе биде правилна, скалабилна и сигурна. Почнаа да ја пишуваат оваа платформа (почнаа да инвестираат, развиваат развој, тестираат), но во одреден момент сфатија дека развојот и тестирањето не ни дозволуваат да достигнеме ново ниво на квалитет на услугата.
Правиш нов производ, го ставаш во производство, но сепак некаде нешто ќе тргне наопаку. И денес ќе зборуваме за тоа како да достигнеме ново ниво на квалитет (како го направивме тоа, за нашето искуство), вадејќи го развојот и тестирањето од равенката; ќе зборуваме за тоа што е достапно за работа - каква операција може сама да направи, што може да понуди на тестирањето за да влијае на квалитетот.
Застоји. Заповеди за работа.
Секогаш главниот камен-темелник, она за што всушност ќе зборуваме денес е времето на застој. Страшен збор. Ако имаме прекини, сè е лошо за нас. Трчаме да го кренеме, админите го држат серверот - дај Боже да не падне како што велат во таа песна. Ова е она за што ќе зборуваме денес.
Кога почнавме да ги менуваме нашите пристапи, формиравме 4 заповеди. Ги имам претставени на слајдовите:
Овие заповеди се прилично едноставни:
- Брзо идентификувајте го проблемот.
- Ослободете се од него уште побрзо.
- Помогнете да се разбере причината (подоцна, за програмерите).
- И стандардизирајте ги пристапите.
Би сакал да го свртам вашето внимание на точка бр. 2. Се ослободуваме од проблемот, а не го решаваме. Одлучувањето е споредно. За нас, примарна работа е што корисникот е заштитен од овој проблем. Ќе постои во некоја изолирана средина, но оваа средина нема да има никаков контакт со неа. Всушност, ќе ги поминеме овие четири групи на проблеми (некои подетално, некои помалку детали), ќе ви кажам што користиме, какво релевантно искуство имаме во решенијата.
Решавање проблеми: Кога се случуваат и што да се прави со нив?
Но, ќе започнеме без редослед, ќе започнеме со точка бр. 2 - како брзо да се ослободиме од проблемот? Има проблем - треба да го поправиме. „Што треба да правиме за ова? - главното прашање. И кога почнавме да размислуваме како да го решиме проблемот, развивме за себе некои барања што мора да ги следи отстранувањето на проблеми.
За да ги формулираме овие барања, решивме да си го поставиме прашањето: „Кога имаме проблеми“? И проблемите, како што се испостави, се јавуваат во четири случаи:
- Хардверски дефект.
- Надворешните услуги не успеаја.
- Промена на верзијата на софтверот (истото распоредување).
- Раст на експлозивно оптоварување.
Нема да зборуваме за првите две. Неисправноста на хардверот може да се реши многу едноставно: мора да имате сè дупликат. Ако тоа се дискови, дисковите мора да се склопат во RAID; ако ова е сервер, серверот мора да биде дупликат; ако имате мрежна инфраструктура, мора да обезбедите втора копија од мрежната инфраструктура, односно да ја земете и дуплирајте го. И ако нешто не успее, се префрлате на резервна моќност. Тешко е да се каже нешто повеќе овде.
Вториот е неуспехот на надворешните услуги. За повеќето, системот воопшто не е проблем, но не и за нас. Бидејќи ги обработуваме плаќањата, ние сме агрегатор кој стои помеѓу корисникот (кој ги внесува податоците на неговата картичка) и банките, платните системи (Visa, MasterCard, Mira итн.). Нашите надворешни услуги (платни системи, банки) имаат тенденција да пропаѓаат. Ниту ние, ниту вие (ако имате такви услуги) не можеме да влијаеме на ова.
Што да се прави тогаш? Тука има две опции. Прво, ако можете, треба да ја дуплирате оваа услуга на некој начин. На пример, ако можеме, пренесуваме сообраќај од една на друга услуга: на пример, картичките се обработуваа преку Сбербанк, Сбербанк има проблеми - го пренесуваме сообраќајот [условно] на Рајфајзен. Втората работа што можеме да ја направиме е многу брзо да забележиме неуспех на надворешните сервиси и затоа ќе зборуваме за брзината на одговор во следниот дел од извештајот.
Всушност, од овие четири, можеме конкретно да влијаеме на промената на верзиите на софтверот - да преземеме активности што ќе доведат до подобрување на ситуацијата во контекст на распоредувањата и во контекст на експлозивен раст на оптоварувањето. Всушност, тоа е она што го направивме. Еве, пак, мала забелешка...
Од овие четири проблеми, неколку се решаваат веднаш ако имате облак. Ако сте во Microsoft Azhur, облаците озон или ги користите нашите облаци, од Yandex или Mail, тогаш барем хардверската неисправност станува нивен проблем и сè веднаш ви станува во ред во контекст на дефект на хардверот.
Ние сме малку неконвенционална компанија. Овде сите зборуваат за „Кубернетс“, за облаци - немаме ниту „Кубернетс“ ниту облаци. Но, имаме хардверски лавици во многу центри за податоци, и принудени сме да живееме на овој хардвер, принудени сме да бидеме одговорни за сето тоа. Затоа, ќе разговараме во овој контекст. Значи, за проблемите. Првите две беа извадени од загради.
Промена на верзијата на софтверот. Основи
Нашите програмери немаат пристап до производство. Зошто е тоа? Едноставно, ние сме сертифицирани за PCI DSS, а нашите програмери едноставно немаат право да влезат во „производот“. Тоа е тоа, точка. Воопшто. Затоа, одговорноста за развој завршува токму во моментот кога развојот ја поднесува верзијата за објавување.
Нашата втора основа што ја имаме, а која исто така многу ни помага, е отсуството на единствено недокументирано знаење. Се надевам дека е исто и за тебе. Затоа што ако не е така, ќе имате проблеми. Проблемите ќе се појават кога ова единствено, недокументирано знаење не е присутно во вистинско време на вистинското место. Да речеме дека имате едно лице кое знае како да распореди одредена компонента - лицето не е таму, тој е на одмор или е болен - тоа е тоа, имате проблеми.
И третата основа до која дојдовме. Дојдовме до тоа преку болка, крв, солзи - дојдовме до заклучок дека која било наша градба содржи грешки, дури и ако е без грешки. Самите го решивме ова: кога распоредуваме нешто, кога нешто префрламе во производство, имаме градба со грешки. Ги формиравме барањата што нашиот систем мора да ги задоволи.
Барања за промена на верзијата на софтверот
Постојат три барања:
- Мора брзо да го вратиме распоредувањето.
- Мора да го минимизираме влијанието на неуспешното распоредување.
- И ние мора да можеме брзо да се распоредиме паралелно.
Токму по тој редослед! Зошто? Затоа што, пред сè, при распоредување на нова верзија, брзината не е важна, но важно е за вас, ако нешто тргне наопаку, брзо да се вратите назад и да имате минимално влијание. Но, ако имате сет на верзии во производство, за кои се испоставува дека има грешка (од ведро небо, немаше распоредување, но има грешка) - брзината на последователното распоредување е важна за вас. Што направивме за да ги исполниме овие барања? Прибегнавме кон следнава методологија:
Тоа е доста добро познато, никогаш не сме го измислиле - ова е Сино/Зелено распоредување. Што е тоа? Мора да имате копија за секоја група сервери на кои се инсталирани вашите апликации. Копијата е „топла“: нема сообраќај на неа, но во секој момент овој сообраќај може да се испрати до оваа копија. Оваа копија ја содржи претходната верзија. И во моментот на распоредување, го префрлате кодот во неактивна копија. Потоа префрлате дел од сообраќајот (или целиот) на новата верзија. Така, за да го промените протокот на сообраќај од старата верзија на новата, треба да направите само едно дејство: треба да го промените балансерот во возводно, да ја промените насоката - од една спротиводно до друга. Ова е многу погодно и го решава проблемот со брзо префрлување и брзо враќање назад.Овде решението за второто прашање е минимизирање: можете да испратите само дел од вашиот сообраќај до нова линија, до линија со нов код (нека биде, на пример, 2%). И овие 2% не се 100%! Ако изгубивте 100% од сообраќајот поради неуспешно распоредување, тоа е страшно; ако изгубивте 2% од сообраќајот, тоа е непријатно, но не е страшно. Покрај тоа, корисниците најверојатно нема ни да го забележат ова, бидејќи во некои случаи (не во сите) истиот корисник, притискајќи на F5, ќе биде префрлен во друга, работна верзија.
Сино/зелено распоредување. Рутирање
Сепак, не е сè толку едноставно „Сино/зелено распоредување“... Сите наши компоненти може да се поделат во три групи:
- ова е предниот дел (страниците за плаќање што ги гледаат нашите клиенти);
- јадро за обработка;
- адаптер за работа со платежни системи (банки, MasterCard, Visa...).
И тука има една нијанса - нијансата лежи во рутирањето меѓу линиите. Ако само префрлите 100% од сообраќајот, ги немате овие проблеми. Но, ако сакате да смените 2%, почнувате да поставувате прашања: „Како да го направите ова? Наједноставната работа е директно напред: можете да поставите Round Robin во nginx по случаен избор, а имате 2% лево, 98% десно. Но, ова не е секогаш погодно.
На пример, во нашиот случај, корисникот комуницира со системот со повеќе од едно барање. Ова е нормално: 2, 3, 4, 5 барања - вашите системи може да се исти. И ако ви е важно сите барања на корисникот да дојдат на истата линија на која дојде првото барање, или (втора точка) сите барања на корисникот да дојдат до новата линија по прекинувачот (тој можеше да почне да работи порано со систем, пред прекинувачот), - тогаш оваа случајна дистрибуција не е погодна за вас. Потоа, постојат следниве опции:
Првата опција, наједноставната, се базира на основните параметри на клиентот (IP Hash). Имате IP адреса и ја делите од десно кон лево по IP адреса. Тогаш вториот случај што го опишав ќе работи за вас, кога ќе се случи распоредувањето, корисникот веќе може да започне да работи со вашиот систем, а од моментот на распоредување сите барања ќе одат во нова линија (на истата, да речеме).Ако поради некоја причина ова не ви одговара и мора да испратите барања до линијата каде што дојде првичното, првично барање на корисникот, тогаш имате две опции...
Прва опција: можете да купите платен nginx+. Постои механизам за лепливи сесии, кој, по првично барање на корисникот, му доделува сесија на корисникот и ја врзува за еден или друг возводно. Сите последователни кориснички барања во рамките на животниот век на сесијата ќе бидат испратени до истиот горе каде што е објавена сесијата.Ова не ни одговараше затоа што веќе имавме редовен nginx. Префрлањето на nginx+ не е дека е скапо, само што ни беше донекаде болно и не е баш правилно. „Sticks Sessions“, на пример, не ни работеше од едноставна причина што „Sticks Sessions“ не дозволува рутирање врз основа на „Или-или“. Таму можете да одредите што правиме ние „Sticks Sessions“, на пример, по IP адреса или по IP адреса и колачиња или по постпараметар, но „Или-или“ е покомплицирано таму.
Затоа, дојдовме до четвртата опција. Зедовме nginx на стероиди (ова е openresty) - ова е истиот nginx, кој дополнително го поддржува вклучувањето на последните скрипти. Можете да напишете последна скрипта, да и дадете „отворен одмор“ и оваа последна скрипта ќе се изврши кога ќе дојде барањето на корисникот.
И ние напишавме, всушност, таква скрипта, си поставивме „openresti“ и во оваа скрипта подредуваме 6 различни параметри по конкатенација „Или“. Во зависност од присуството на еден или друг параметар, знаеме дека корисникот дошол на една или друга страница, една или друга линија.
Сино/зелено распоредување. Предности и недостатоци
Се разбира, веројатно беше можно да се направи малку поедноставно (користете ги истите „Sticky Sessions“), но имаме и таква нијанса што не само што корисникот комуницира со нас во рамките на една обработка на една трансакција... Но, платните системи, исто така, комуницираат со нас: Откако ќе ја обработиме трансакцијата (со испраќање барање до платниот систем), добиваме повратен одговор.
И да речеме, ако во нашето коло можеме да ја препраќаме IP адресата на корисникот во сите барања и да ги поделиме корисниците врз основа на IP адресата, тогаш нема да ја кажеме истата „Виза“: „Друже, ние сме таква ретро компанија, изгледа да биде меѓународен (на веб-локацијата и во Русија)... Ве молиме да ни ја дадете IP адресата на корисникот во дополнително поле, вашиот протокол е стандардизиран“! Јасно е дека нема да се согласат.
Затоа, ова не ни успеа - направивме openresty. Соодветно на тоа, со рутирање добивме вакво нешто:Сино/зелено распоредување има, соодветно, предностите што ги спомнав и недостатоците.
Две недостатоци:
- треба да се мачите со рутирање;
- вториот главен недостаток е трошокот.
Ви требаат двојно повеќе сервери, ви требаат двојно повеќе оперативни ресурси, треба да потрошите двојно повеќе труд за да ја одржувате целата оваа зоолошка градина.
Патем, меѓу предностите има уште една работа што не ја спомнав претходно: имате резерва во случај на раст на оптоварувањето. Ако имате експлозивен раст на оптоварувањето, имате голем број корисници, тогаш едноставно ја вклучувате втората линија во дистрибуцијата од 50 до 50 - и веднаш имате x2 сервери во вашиот кластер додека не го решите проблемот да имате повеќе сервери.
Како да направите брзо распоредување?
Разговаравме за тоа како да го решиме проблемот со минимизирање и брзо враќање, но останува прашањето: „Како да се распореди брзо?
Овде е кратко и едноставно.- Мора да имате ЦД систем (континуирана испорака) - не можете да живеете без него. Ако имате еден сервер, можете да го распоредите рачно. Имаме околу една и пол илјади сервери и една и пол илјади рачки, се разбира - можеме да засадиме оддел со големина на оваа просторија само за да се распореди.
- Распоредувањето мора да биде паралелно. Ако вашето распоредување е последователно, тогаш сè е лошо. Еден сервер е нормален, цел ден ќе распоредите илјада и пол сервери.
- Повторно, за забрзување, ова веројатно повеќе не е потребно. За време на распоредувањето, проектот обично се гради. Имаш веб-проект, има преден дел (таму правиш веб-пакет, компајлираш npm - нешто слично), и овој процес во принцип е краткотраен - 5 минути, но овие 5 минути можат бидете критични. Затоа, на пример, не го правиме тоа: ги отстранивме овие 5 минути, распоредуваме артефакти.
Што е артефакт? Артефакт е склопена конструкција во која сите монтажни делови се веќе завршени. Овој артефакт го складираме во складиштето за артефакти. Некогаш користевме две такви складишта - тоа беше Nexus и сега jFrog Artifactory). Потоа тие ставаат некои од апликациите напишани во 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 - „Како брзо да се ослободите од причините“.
Мониторинг. Како брзо да го идентификувате проблемот?
Сега првата точка е „Како брзо да го идентификувате проблемот? Мониторинг! Мора брзо да разбереме одредени работи. Кои работи треба брзо да ги разбереме?
Три работи!- Мораме брзо да ги разбереме и разбереме перформансите на нашите сопствени ресурси.
- Мора брзо да ги разбереме неуспесите и да ги следиме перформансите на системите што се надворешни за нас.
- Третата точка е идентификување на логички грешки. Ова е кога системот работи за вас, сè е нормално според сите индикатори, но нешто тргне наопаку.
Веројатно нема да ви кажам ништо толку кул овде. Ќе бидам капетан Очигледен. Баравме што има на пазарот. Имаме „забавна зоолошка градина“. Ова е вид на зоолошка градина што ја имаме сега:
Ние користиме Zabbix за следење на хардверот, за следење на главните индикатори на серверите. Ние користиме Okmeter за бази на податоци. Ги користиме „Графана“ и „Прометеј“ за сите други индикатори кои не одговараат на првите два, некои со „Графана“ и „Прометеј“, а некои со „Графана“ со „Прилив“ и Телеграф.Пред една година сакавме да користиме New Relic. Супер работа, може се. Но, колку и да може сè, толку е скапа. Кога пораснавме до волумен од 1,5 илјади сервери, ни дојде продавач и рече: „Ајде да склучиме договор за следната година“. Ја разгледавме цената и рековме не, нема да го направиме тоа. Сега го напуштаме New Relic, ни останаа околу 15 сервери под мониторинг на New Relic. Цената се покажа како апсолутно дива.
И постои една алатка што ја имплементиравме самите - ова е Debugger. Отпрвин го нарековме „Багер“, но потоа помина наставник по англиски јазик, диво се насмеа и го прекрсти во „Дебагер“. Што е тоа? Ова е алатка која, всушност, за 15-30 секунди на секоја компонента, како „црна кутија“ на системот, врши тестови за севкупните перформанси на компонентата.
На пример, ако има надворешна страница (страница за плаќање), тој едноставно ја отвора и гледа како треба да изгледа. Ако ова се обработува, тој испраќа тест „трансакција“ и се погрижува да пристигне оваа „трансакција“. Ако ова е поврзаност со платните системи, соодветно испраќаме барање за тестирање, каде што можеме, и гледаме дека сè е во ред со нас.
Кои индикатори се важни за следење?
Што главно следиме? Кои индикатори ни се важни?
- Времето на одговор / RPS на фронтови е многу важен индикатор. Веднаш одговара дека нешто не е во ред со тебе.
- Бројот на обработени пораки во сите редици.
- Број на работници.
- Основни метрики на исправност.
Последната точка е „деловна“, „деловна“ метрика. Ако сакате да го следите истото, треба да дефинирате една или две метрики кои се главни показатели за вас. Нашата метрика е пропусната моќ (ова е односот на бројот на успешни трансакции со вкупниот проток на трансакции). Ако нешто се промени во него во интервал од 5-10-15 минути, тоа значи дека имаме проблеми (ако радикално се промени).
Како тоа изгледа за нас е пример на една од нашите табли:
На левата страна има 6 графикони, ова е според линиите - бројот на работници и бројот на пораки во редиците. На десната страна - RPS, RTS. Подолу е истата „деловна“ метрика. И во „деловната“ метрика веднаш можеме да видиме дека нешто тргна наопаку на двата средни графикони... Ова е само уште еден систем што стои зад нас кој падна.Втората работа што требаше да ја направиме е да го следиме падот на надворешните платежни системи. Овде го зедовме OpenTracing - механизам, стандардна, парадигма што ви овозможува да ги следите дистрибуираните системи; и малку се смени. Стандардната парадигма OpenTracing вели дека градиме трага за секое поединечно барање. Не ни требаше ова и го завиткавме во резиме, збирна трага. Направивме алатка која ни овозможува да ја следиме брзината на системите зад нас.
Графиконот ни покажува дека еден од платните системи почна да реагира за 3 секунди - имаме проблеми. Покрај тоа, оваа работа ќе реагира кога ќе започнат проблемите, во интервал од 20-30 секунди.И третата класа на грешки при мониторинг што постои е логично следење.
Да бидам искрен, не знаев што да нацртам на овој слајд, бидејќи долго време баравме на пазарот нешто што ќе ни одговара. Не најдовме ништо, па моравме сами да го направиме тоа.
Што подразбирам под логично следење? Па, замислете: си правите систем (на пример, клон на Тиндер); го направивте, го лансиравте. Успешниот менаџер Васија Пупкин го ставил на телефонот, гледа девојка таму, ѝ се допаѓа... и сличното не оди кај девојката - сличното оди кај чуварот Михалич од истиот деловен центар. Менаџерот оди долу, а потоа се прашува: „Зошто овој чувар Михалич толку пријатно му се насмевнува?Во такви ситуации... За нас оваа ситуација звучи малку поинаку, бидејќи (пишав) ова е загуба на угледот што индиректно води до финансиски загуби. Нашата ситуација е спротивна: може да претрпиме директни финансиски загуби - на пример, ако сме извршиле трансакција како успешна, но била неуспешна (или обратно). Морав да напишам своја алатка која го следи бројот на успешни трансакции со текот на времето користејќи деловни индикатори. Не најдов ништо на пазарот! Токму оваа идеја сакав да ја пренесам. Нема ништо на пазарот за да се реши ваков проблем.
Ова беше за тоа како брзо да се идентификува проблемот.
Како да се утврдат причините за распоредување
Третата група проблеми што ја решаваме е откако ќе го идентификуваме проблемот, откако ќе се ослободиме од него, би било добро да ја разбереме причината за развој, за тестирање и да направиме нешто околу тоа. Според тоа, треба да истражиме, треба да ги подигнеме трупците.
Ако зборуваме за дневници (главната причина се дневниците), најголемиот дел од нашите логови се во ELK Stack - скоро сите го имаат истото. За некои можеби не е во ЕЛК, но ако пишувате дневници во гигабајти, тогаш порано или подоцна ќе дојдете до ЕЛК. Ги пишуваме во терабајти.
Тука има проблем. Го поправивме, ја исправивме грешката на корисникот, почнавме да откопуваме што има, се качивме во Кибана, таму го внесевме идентификаторот на трансакцијата и добивме ваква крпа за нозете (покажува многу). И апсолутно ништо не е јасно во оваа крпа. Зошто? Да, затоа што не е јасно кој дел е на кој работник, кој дел на која компонента. И во тој момент сфативме дека ни треба трасирање - истиот OpenTracing за кој зборував.Го мислевме ова пред една година, го свртевме вниманието кон пазарот, а таму имаше две алатки - „Zipkin“ и „Jaeger“. „Јагер“ е всушност таков идеолошки наследник, идеолошки наследник на „Зипкин“. Се е добро во Zipkin, освен што не знае да агрегира, не знае да вклучи логови во трагата, само временска трага. И „Јагер“ го поддржа ова.
Го разгледавме „Јагер“: можете да инструментирате апликации, можете да пишувате во Api (стандардот Api за PHP во тоа време, сепак, не беше одобрен - ова беше пред една година, но сега веќе е одобрено), но таму немаше апсолутно никаков клиент. „Во ред“, си помисливме и му напишавме на нашиот клиент. Што добивме? Отприлика вака изгледа:
Во Јегер, се креираат распони за секоја порака. Тоа е, кога корисникот го отвора системот, тој гледа еден или два блока за секое дојдовно барање (1-2-3 - бројот на дојдовни барања од корисникот, бројот на блокови). За да им олесниме на корисниците, додадовме ознаки во дневниците и временските траги. Според тоа, во случај на грешка, нашата апликација ќе го означи дневникот со соодветната ознака за грешка. Може да филтрирате по ознака за грешка и ќе се прикажат само распони што го содржат овој блок со грешка. Вака изгледа ако го прошириме распонот:
Внатре во распонот има збир на траги. Во овој случај, ова се три тест траги, а третата трага ни кажува дека настанала грешка. Во исто време, овде гледаме временска трага: имаме временска скала на врвот и гледаме во кој временски интервал е снимен овој или оној дневник.Според тоа, работите тргнаа добро кај нас. Напишавме сопствена екстензија и ја набавивме со отворен код. Ако сакате да работите со следење, ако сакате да работите со „Jager“ во PHP, тука е нашата екстензија, добредојде да ја користите, како што велат:
Ја имаме оваа екстензија - таа е клиент за OpenTracing Api, направена е како php-екстензија, односно ќе треба да ја составите и инсталирате на системот. Пред една година немаше ништо поинаку. Сега има и други клиенти кои се како компоненти. Овде зависи од вас: или ќе ги испумпувате компонентите со композитор, или ќе користите екстензија до вас.Корпоративни стандарди
Разговаравме за трите заповеди. Четвртата заповед е да се стандардизираат пристапите. За што станува збор? Станува збор за ова:
Зошто тука е зборот „корпоративно“? Не затоа што сме голема или бирократска компанија, не! Сакав да го користам зборот „корпоративно“ овде во контекст дека секоја компанија, секој производ треба да има свои стандарди, вклучително и вие. Какви стандарди имаме?
- Имаме прописи за распоредување. Без него никаде не се движиме, не можеме. Распоредуваме околу 60 пати неделно, односно распоредуваме речиси постојано. Во исто време, имаме, на пример, во регулативата за распоредување табу за распоредувања во петок - во принцип, не распоредуваме.
- Потребна ни е документација. Ниту една нова компонента не влегува во производство ако нема документација за неа, дури и ако е родена под перото на нашите специјалисти за RnD. Ние бараме од нив инструкции за распоредување, карта за следење и груб опис (добро, како што програмерите можат да напишат) за тоа како функционира оваа компонента, како да се решат проблемите.
- Не ја решаваме причината за проблемот, туку проблемот - она што веќе го кажав. За нас е важно да го заштитиме корисникот од проблеми.
- Имаме одобренија. На пример, не го сметаме за застој ако изгубиме 2% од сообраќајот во рок од две минути. Ова во основа не е вклучено во нашата статистика. Ако е повеќе процентуално или привремено, веќе броиме.
- И секогаш пишуваме посмртници. Што и да ни се случи, секоја ситуација кога некој се однесувал ненормално во производството, ќе се одрази во постморта. Постмортемот е документ во кој пишувате што ви се случило, детален тајминг, што сте направиле за да го поправите и (ова е задолжителен блок!) што ќе направите за да спречите тоа да се случи во иднина. Ова е задолжително и неопходно за последователна анализа.
Што се смета за застој?
До што доведе сето ова?Ова доведе до фактот дека (имавме одредени проблеми со стабилноста, тоа не одговараше ниту на клиентите ниту нам) во изминатите 6 месеци нашиот индикатор за стабилност беше 99,97. Можеме да кажеме дека ова не е многу. Да, имаме кон што да се стремиме. Од овој индикатор, околу половина е стабилноста, како да се каже, не на нашата, туку на нашиот заштитен ѕид за веб-апликации, кој стои пред нас и се користи како услуга, но клиентите не се грижат за ова.
Научивме да спиеме ноќе. Конечно! Пред шест месеци не можевме. И на оваа забелешка со резултатите, би сакал да направам една забелешка. Синоќа имаше прекрасен извештај за системот за контрола на нуклеарен реактор. Ако луѓето што го напишаа овој систем можат да ме слушнат, ве молам заборавете на она што го реков за „2% не е прекин на работата“. За вас, 2% е застој, дури и ако за две минути!
Тоа е се! Вашите прашања.
За балансерите и миграцијата на базата на податоци
Прашање од публиката (во натамошниот текст – Б): – Добровечер. Ви благодариме многу за ваквиот извештај на администраторот! Кратко прашање за вашите балансери. Ти спомна дека имаш WAF, односно како што јас разбирам користиш некаков надворешен балансер...
ЕК: – Не, ние ги користиме нашите услуги како балансер. Во овој случај, WAF е исклучиво алатка за заштита на DDoS за нас.
НА: – Можете ли да кажете неколку зборови за балансерите?
ЕК: – Како што веќе реков, ова е група на сервери во openresty. Сега имаме 5 резервни групи кои реагираат исклучиво... односно, сервер кој работи исклучиво openresty, тој само го проксира сообраќајот. Според тоа, за да разбереме колку држиме: сега имаме редовен проток на сообраќај од неколку стотици мегабити. Се справуваат, се чувствуваат добро, не се ни напрегаат.
НА: – Исто така едноставно прашање. Еве сино/зелено распоредување. Што правите, на пример, со миграциите на базата на податоци?
ЕК: - Добро прашање! Видете, во распоредувањето Сино/Зелено имаме посебни редици за секоја линија. Односно, ако зборуваме за редици за настани кои се пренесуваат од работник до работник, постојат посебни редици за сината линија и за зелената линија. Ако зборуваме за самата база на податоци, тогаш намерно ја стеснивме колку што можевме, преместивме сè практично во редици; во базата на податоци складираме само куп трансакции. И нашиот оџак за трансакции е ист за сите линии. Со базата на податоци во овој контекст: не ја делиме на сина и зелена, бидејќи и двете верзии на кодот мора да знаат што се случува со трансакцијата.
Пријатели, имам и мала награда за да ве поттикнам - книга. И треба да бидам награден за најдоброто прашање.
НА: - Здраво. Ви благодариме за извештајот. Прашањето е ова. Ги следите плаќањата, ги следите услугите со кои комуницирате... Но, како следите за да некој некако дојде на вашата страница за плаќање, изврши уплата, а проектот го кредитираше со пари? Односно, како следите дека маршантот е достапен и дали го прифатил вашиот повратен повик?
ЕК: – „Трговец“ за нас во овој случај е токму истата надворешна услуга како платниот систем. Ја следиме брзината на одговор на трговецот.
За шифрирањето на базата на податоци
НА: - Здраво. Имам малку поврзано прашање. Имате податоци чувствителни на PCI DSS. Сакав да знам како ги складирате PAN-овите во редици во кои треба да ги префрлите? Дали користите шифрирање? И ова води до второто прашање: според PCI DSS, неопходно е периодично повторно да се шифрира базата на податоци во случај на промени (отпуштање на администратори, итн.) - што се случува со пристапноста во овој случај?
ЕК: - Прекрасно прашање! Прво, ние не складираме PAN во редици. Ние немаме право да складираме PAN насекаде во јасна форма, во принцип, затоа користиме специјална услуга (ние ја нарекуваме „Kademon“) - ова е услуга што прави само една работа: прима порака како влез и испраќа испратете шифрирана порака. И ние складираме сè со оваа шифрирана порака. Според тоа, нашата клучна должина е под килобајт, така што ова е сериозно и сигурно.НА: – Сега ти требаат 2 килобајти?
ЕК: – Изгледа баш вчера беше 256... Па, каде на друго место?!
Според тоа, ова е прв. И второ, решението што постои, ја поддржува процедурата за повторно шифрирање - има два пара „кекс“ (клучеви), кои даваат „палуби“ што шифрираат (клучот се клучевите, дек се деривати на клучевите што шифрираат) . И ако постапката е започната (тоа се случува редовно, од 3 месеци до ± некои), преземаме нов пар „колачи“ и повторно ги криптираме податоците. Имаме посебни услуги кои ги откопуваат сите податоци и ги шифрираат на нов начин; Податоците се чуваат веднаш до идентификаторот на клучот со кој е шифриран. Според тоа, штом ги шифрираме податоците со нови клучеви, го бришеме стариот клуч.
Понекогаш плаќањата треба да се вршат рачно...
НА: – Односно, ако пристигне рефундирање за некоја операција, дали сепак ќе го дешифрирате со стариот клуч?
ЕК: - Да.
НА: – Потоа уште едно мало прашање. Кога ќе се појави некаков неуспех, пад или инцидент, потребно е рачно да се протурка трансакцијата. Постои таква ситуација.
ЕК: - Да понекогаш.
НА: – Од каде ги добивате овие податоци? Или вие самите одите во овој објект за складирање?
ЕК: – Не, добро, се разбира, имаме некој вид на back-office систем кој содржи интерфејс за наша поддршка. Ако не знаеме во каков статус е трансакцијата (на пример, додека платниот систем не одговори со тајмаут), не знаеме априори, односно го доделуваме конечниот статус само со целосна доверба. Во овој случај, трансакцијата ја доделуваме на посебен статус за рачна обработка. Наутро, следниот ден, штом поддршката добие информација дека таквите трансакции остануваат во платниот систем, тие рачно ги обработуваат во овој интерфејс.
НА: – Имам неколку прашања. Еден од нив е продолжување на зоната PCI DSS: како да го регистрирате нивното коло? Ова прашање е затоа што развивачот можел да стави што било во дневниците! Второ прашање: како се поставуваат жешки поправки? Користењето рачки во базата на податоци е една опција, но може да има бесплатни поправки - каква е процедурата таму? И третото прашање е веројатно поврзано со RTO, RPO. Вашата достапност беше 99,97, скоро четири деветки, но како што разбрав, имате втор центар за податоци, трет центар за податоци и петти центар за податоци... Како ги синхронизирате, реплицирате и сè друго?ЕК: - Да почнеме со првиот. Дали првото прашање беше за трупци? Кога пишуваме дневници, имаме слој кој ги маскира сите чувствителни податоци. Таа гледа во маската и во дополнителните полиња. Според тоа, нашите дневници излегуваат со веќе маскирани податоци и коло PCI DSS. Ова е една од редовните задачи доделени на одделот за тестирање. Од нив се бара да ја проверат секоја задача, вклучувајќи ги и дневниците што ги пишуваат, и ова е една од редовните задачи за време на прегледите на кодот, со цел да се контролира дека развивачот не запишал нешто. Последователните проверки на ова се вршат редовно од страна на одделот за безбедност на информации околу еднаш неделно: дневниците за последниот ден се селективно се земаат и тие се водат преку специјален скенер-аналитичар од серверите за тестирање за да се провери сè.
За жешки поправки. Ова е вклучено во нашите прописи за распоредување. Имаме посебна клаузула за жешки поправки. Ние веруваме дека распоредуваме жешки поправки деноноќно кога ни треба. Веднаш штом се склопи верзијата, штом се стартува, штом имаме артефакт, имаме дежурен системски администратор на повик од поддршката и тој го распоредува во моментот кога е потребно.За „четири деветки“. Бројката што ја имаме сега е навистина постигната и се стремиме кон неа во друг центар за податоци. Сега имаме втор центар за податоци и почнуваме да се движиме меѓу нив, а прашањето за репликација на вкрстени центри за податоци е навистина нетривијално прашање. Се обидовме да го решиме во исто време користејќи различни средства: се обидовме да ја користиме истата „Тарантула“ - не ни успеа, ќе ви кажам веднаш. Затоа на крајот рачно ги нарачавме „сензорите“. Всушност, секоја апликација во нашиот систем асинхроно ја извршува потребната синхронизација „извршена промена“ помеѓу центрите за податоци.
НА: – Ако си добил втор, зошто не си добил трет? Затоа што никој сè уште нема поделен мозок...
ЕК: – Но, ние немаме Сплит Мозок. Поради фактот што секоја апликација е управувана од мултимастер, за нас не е важно во кој центар дојде барањето. Подготвени сме за фактот дека ако некој од нашите центри за податоци не успее (се потпираме на ова) и во средината на барањето на корисникот се префрли на вториот центар за податоци, ние сме подготвени да го изгубиме овој корисник, навистина; но тоа ќе бидат единици, апсолутни единици.
НА: - Добро попладне. Ви благодариме за извештајот. Зборувавте за вашиот дебагер, кој извршува некои тест трансакции во производството. Но, кажете ни за тест трансакции! Колку длабоко оди?
ЕК: – Го поминува целиот циклус на целата компонента. За компонента, нема разлика помеѓу тест трансакција и производствена трансакција. Но, од логична гледна точка, ова е едноставно посебен проект во системот, на кој се извршуваат само тест трансакции.
НА: -Каде го отсекуваш? Еве Core испрати ...
ЕК: – Ние стоиме зад „Кор“ во овој случај за тест трансакции... Имаме такво нешто како рутирање: „Кор“ знае до кој систем за плаќање да испрати - испраќаме до лажен платен систем, кој едноставно дава http сигнал и тоа е се.
НА: – Кажи ми, те молам, дали вашата апликација беше напишана во еден огромен монолит или ја пресековте на некои сервиси или дури и микросервиси?
ЕК: – Немаме монолит, се разбира, имаме услуга ориентирана апликација. Се шегуваме дека нашата услуга е направена од монолити - тие се навистина доста големи. Тешко е да се нарече микросервис, но тоа се услуги во кои работат работниците на дистрибуирани машини.
Ако услугата на серверот е компромитирана...
НА: – Тогаш го имам следното прашање. Дури и да беше монолит, сепак речете дека имате многу од овие инстант сервери, сите тие во основа обработуваат податоци, а прашањето е: „Во случај на компромис на еден од инстант серверите или апликација, која било индивидуална врска , дали имаат некаква контрола на пристап? Кој од нив што може да направи? Со кого да контактирам за какви информации?
ЕК: - Да дефинитивно. Барањата за безбедност се доста сериозни. Прво, имаме отворени движења на податоци, а пристаништата се само оние преку кои однапред го предвидуваме движењето на сообраќајот. Ако компонентата комуницира со базата на податоци (да речеме, со Muskul) преку 5-4-3-2, само 5-4-3-2 ќе биде отворена за неа, а другите пристаништа и други сообраќајни насоки нема да бидат достапни. Покрај тоа, треба да разберете дека во нашето производство има околу 10 различни безбедносни јамки. И дури и ако апликацијата беше некако компромитирана, не дај Боже, напаѓачот нема да може да пристапи до конзолата за управување со серверот, бидејќи ова е различна мрежна безбедносна зона.НА: – И во овој контекст, она што ми е поинтересно е што имате одредени договори со услуги - што можат да направат, преку какви „дејствија“ можат да контактираат меѓу себе... И во нормален тек, некои конкретни служби бараат некои ред, од друга страна листа на „дејства“. Се чини дека тие не се свртуваат кон другите во нормална ситуација и имаат други области на одговорност. Ако некој од нив е компромитиран, дали ќе може да ги наруши „дејствата“ на таа услуга?..
ЕК: - Разбирам. Ако во нормална ситуација со друг сервер воопшто беше дозволена комуникација, тогаш да. Според договорот за SLA, ние не следиме дека ви се дозволени само првите 3 „дејства“, а не ви се дозволени 4 „дејства“. Ова е веројатно излишно за нас, бидејќи веќе имаме систем за заштита од 4 нивоа, во принцип, за кола. Претпочитаме да се браниме со контурите, отколку на нивото на внатрешноста.
Како функционираат Visa, MasterCard и Sberbank
НА: – Сакам да разјаснам точка за префрлување на корисник од еден центар за податоци во друг. Колку што знам, Visa и MasterCard работат со користење на бинарниот синхрони протокол 8583, и таму има мешавини. И сакав да знам, сега мислиме на префрлување – дали е директно „Visa“ и „MasterCard“ или пред платежни системи, пред процесирање?
ЕК: - Ова е пред мешаниците. Нашите мешавини се наоѓаат во истиот центар за податоци.
НА: – Грубо кажано, имате ли една точка на поврзување?
ЕК: – „Visa“ и „MasterCard“ - да. Едноставно затоа што Visa и MasterCard бараат доста сериозни инвестиции во инфраструктурата за да склучат посебни договори за да се добие втор пар мешавини, на пример. Резервирани се во еден центар за податоци, но ако не дај Боже умре нашиот центар за податоци каде што има мешавини за поврзување со Visa и MasterCard, тогаш ќе имаме изгубена врска со Visa и MasterCard...
НА: – Како може да се резервираат? Знам дека Visa во принцип дозволува само една врска!
ЕК: – Опремата сами ја снабдуваат. Во секој случај добивме опрема која е целосно излишна внатре.
НА: – Значи штандот е од нивниот Connects Orange?..
ЕК: - Да.
НА: – Но, што е со овој случај: ако вашиот центар за податоци исчезне, како можете да продолжите да го користите? Или сообраќајот само запира?
ЕК: - Не. Во овој случај, едноставно ќе го префрлиме сообраќајот на друг канал, кој, нормално, ќе биде поскап за нас и поскап за нашите клиенти. Но, сообраќајот нема да оди преку нашата директна врска со Visa, MasterCard, туку преку условната Сбербанк (многу претерано).
Диво се извинувам ако ги навредив вработените во Сбербанк. Но, според нашата статистика, меѓу руските банки, Сбербанк најчесто паѓа. Ниту еден месец не поминува без нешто да падне во Сбербанк.
Некои реклами 🙂
Ви благодариме што останавте со нас. Дали ви се допаѓаат нашите написи? Сакате да видите поинтересна содржина? Поддржете не со нарачка или препорака на пријатели, , уникатен аналог на сервери на почетно ниво, кој беше измислен од нас за вас: (достапен со RAID1 и RAID10, до 24 јадра и до 40 GB 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