Пратимо Спортмастер - како и чиме

Размишљали смо о креирању система за праћење у фази формирања производних тимова. Постало је јасно да наш посао – експлоатација – не спада у ове тимове. Зашто је то?

Чињеница је да су сви наши тимови изграђени око појединачних информационих система, микросервиса и фронтова, тако да тимови не виде укупно здравље целог система у целини. На пример, можда не знају како неки мали део у дубокој позадини утиче на предњи крај. Њихов опсег интересовања је ограничен на системе са којима је њихов систем интегрисан. Ако тим и његов сервис А немају скоро никакве везе са сервисом Б, онда је такав сервис тиму скоро невидљив.

Наш тим, заузврат, ради са системима који су међусобно веома снажно интегрисани: међу њима постоји много веза, ово је веома велика инфраструктура. А рад онлине продавнице зависи од свих ових система (којих, иначе, имамо огроман број).

Тако испада да наше одељење не припада ниједном тиму, већ се налази мало по страни. У целој овој причи, наш задатак је да свеобухватно разумемо како функционишу информациони системи, њихову функционалност, интеграције, софтвер, мрежу, хардвер и како је све то међусобно повезано.

Платформа на којој раде наше онлајн продавнице изгледа овако:

• предњи
• средња канцеларија
• назад канцеларија

Колико год желели, не дешава се да сви системи раде глатко и беспрекорно. Поента је, опет, број система и интеграција – са нечим попут нашег, неки инциденти су неизбежни, упркос квалитету тестирања. Штавише, како у оквиру посебног система, тако иу смислу њихове интеграције. И морате свеобухватно да пратите стање целе платформе, а не само било ког њеног појединачног дела.

У идеалном случају, праћење здравља на нивоу платформе требало би да буде аутоматизовано. И дошли смо до праћења као неизбежног дела овог процеса. У почетку је направљен само за фронт-лине део, док су стручњаци за мрежу, софтверски и хардверски администратори имали и још увек имају сопствене системе за праћење слојева. Сви ови људи су пратили мониторинг само на свом нивоу, нико није имао свеобухватно разумевање.

На пример, ако се виртуелна машина сруши, у већини случајева само администратор одговоран за хардвер и виртуелну машину зна за то. У таквим случајевима, први тим је видео саму чињеницу пада апликације, али није имао податке о паду виртуелне машине. А администратор може да зна ко је купац и да има грубу представу о томе шта се тренутно ради на овој виртуелној машини, под условом да је то нека врста великог пројекта. Он највероватније не зна за мале. У сваком случају, администратор треба да оде до власника и да пита шта је било на овој машини, шта треба рестаурирати, а шта променити. А ако би се нешто заиста озбиљно покварило, почели су да се врте у круг – јер нико није видео систем као целину.

На крају крајева, такве различите приче утичу на цео фронтенд, кориснике и нашу основну пословну функцију - онлајн продају. Пошто нисмо део тима, већ се бавимо радом свих апликација за е-трговину као део онлајн продавнице, преузели смо задатак креирања свеобухватног система за праћење е-трговине платформе.

Структура система и стек

Почели смо тако што смо идентификовали неколико слојева надгледања за наше системе, у оквиру којих бисмо морали да прикупљамо метрику. И све је то требало комбиновати, што смо и урадили у првој фази. Сада у овој фази завршавамо најквалитетнију колекцију метрика на свим нашим слојевима како бисмо изградили корелацију и разумели како системи утичу једни на друге.

Недостатак свеобухватног праћења у почетним фазама покретања апликације (с обзиром да смо почели да је градимо када је већина система била у производњи) довео је до тога да смо имали значајан технички дуг за постављање мониторинга целе платформе. Нисмо могли да приуштимо да се фокусирамо на постављање мониторинга за један ИС и детаљно разраду мониторинга за њега, пошто би остали системи остали без надзора неко време. Да бисмо решили овај проблем, идентификовали смо листу најпотребнијих метрика за процену стања информационог система по слојевима и почели да је примењујемо.

Стога су одлучили да поједу слона у деловима.

Наш систем се састоји од:

• хардвер;
• Оперативни систем;
• софтвер;
• УИ делови у апликацији за праћење;
• пословне метрике;
• интеграционе апликације;
• безбедност информација;
• мреже;
• балансер саобраћаја.

У средишту овог система је сам надзор. Да бисте уопштено разумели стање целог система, морате да знате шта се дешава са апликацијама на свим овим слојевима и у целом скупу апликација.

Дакле, о стеку.

Користимо софтвер отвореног кода. У центру имамо Заббик, који користимо првенствено као систем за узбуњивање. Сви знају да је идеалан за надзор инфраструктуре. Шта ово значи? Управо оне метрике ниског нивоа које има свака компанија која одржава сопствени дата центар (а Спортмастер има своје дата центре) – температура сервера, статус меморије, раид, метрика мрежних уређаја.

Интегрисали смо Заббик са Телеграм месинџером и Мицрософт тимовима, који се активно користе у тимовима. Заббик покрива слој стварне мреже, хардвера и неког софтвера, али није панацеја. Ове податке обогаћујемо из неких других сервиса. На пример, на нивоу хардвера, директно се повезујемо преко АПИ-ја на наш систем виртуелизације и прикупљамо податке.

Шта још. Поред Заббик-а, користимо Прометхеус, који нам омогућава да пратимо метрику у апликацији за динамичко окружење. То јест, можемо да примамо метрику апликације преко ХТТП крајње тачке и не бринемо о томе које метрике да учитамо у њу, а које не. На основу ових података могу се развити аналитички упити.

Извори података за друге слојеве, на пример, пословне метрике, подељени су у три компоненте.

Прво, то су екстерни пословни системи, Гоогле аналитика, ми прикупљамо метрику из логова. Од њих добијамо податке о активним корисницима, конверзијама и свему осталом у вези са пословањем. Друго, ово је систем за праћење корисничког интерфејса. Требало би га детаљније описати.

Некада смо почели са ручним тестирањем и то је прерасло у аутоматске тестове функционалности и интеграције. Од овога смо направили праћење, остављајући само главну функционалност, и ослањајући се на маркере који су што стабилнији и који се не мењају често током времена.

Нова структура тима значи да су све активности апликације ограничене на тимове производа, тако да смо престали да радимо чисто тестирање. Уместо тога, направили смо праћење корисничког интерфејса из тестова, написаних на Јави, Селену и Џенкинсу (који се користи као систем за покретање и генерисање извештаја).

Имали смо много тестова, али смо на крају одлучили да идемо на главни пут, метрику највишег нивоа. А ако имамо много специфичних тестова, биће тешко да ажурирамо податке. Свако следеће издање ће значајно покварити цео систем, а ми ћемо само да га поправимо. Стога смо се фокусирали на веома фундаменталне ствари које се ретко мењају и само их пратимо.

Коначно, треће, извор података је централизовани систем евидентирања. Користимо Еластиц Стацк за евиденцију, а затим можемо да повучемо ове податке у наш систем за праћење пословних метрика. Поред свега овога, имамо сопствену услугу Мониторинг АПИ, написану у Питхон-у, која испитује било које услуге преко АПИ-ја и прикупља податке од њих у Заббик.

Још један неопходан атрибут праћења је визуелизација. Наш је заснован на Графани. Истиче се међу осталим системима за визуелизацију по томе што вам омогућава да визуелизујете метрику из различитих извора података на контролној табли. Можемо да прикупљамо метрику највишег нивоа за онлајн продавницу, на пример, број поруџбина послатих у последњем сату из ДБМС-а, метрику перформанси за ОС на којем ова онлајн продавница ради са Заббик-а и метрике за примере ове апликације од Прометеја. И све ово ће бити на једној контролној табли. Јасно и доступно.

Дозволите ми да напоменем о безбедности – тренутно финализујемо систем, који ћемо касније интегрисати са глобалним системом за праћење. По мом мишљењу, главни проблеми са којима се е-трговина суочава у области информационе безбедности односе се на ботове, парсере и грубу силу. Морамо да пазимо на ово, јер све то може критично утицати и на рад наших апликација и на нашу репутацију са пословне тачке гледишта. И са изабраним стеком успешно покривамо ове задатке.

Још једна важна тачка је да слој апликације саставља Прометхеус. Он сам је такође интегрисан са Заббик-ом. Такође имамо ситеспеед, услугу која нам омогућава да видимо параметре као што су брзина учитавања наше странице, уска грла, приказивање странице, учитавање скрипти, итд., такође је интегрисан АПИ. Дакле, наше метрике се прикупљају у Заббик-у, и сходно томе, такође упозоравамо одатле. Сва упозорења се тренутно шаљу на главне методе слања (за сада су то е-пошта и телеграм, МС Теамс је такође недавно повезан). Постоје планови за надоградњу упозорења на такво стање да паметни ботови раде као услуга и пружају информације о праћењу свим заинтересованим тимовима производа.

За нас су метрике важне не само за појединачне информационе системе, већ и опште метрике за целокупну инфраструктуру коју апликације користе: кластери физичких сервера на којима раде виртуелне машине, балансери саобраћаја, балансери мрежног оптерећења, сама мрежа, коришћење комуникационих канала . Плус метрике за наше сопствене центре података (имамо их неколико и инфраструктура је прилично велика).

Предности нашег система за праћење су у томе што уз његову помоћ видимо здравствено стање свих система и можемо проценити њихов утицај једни на друге и на заједничке ресурсе. И на крају, омогућава нам да се укључимо у планирање ресурса, што је такође наша одговорност. Управљамо серверским ресурсима – пулом у оквиру е-трговине, пуштамо у рад и стављамо нову опрему из употребе, купујемо додатну нову опрему, вршимо ревизију искоришћености ресурса итд. Сваке године тимови планирају нове пројекте, развијају своје системе, а нама је важно да им обезбедимо ресурсе.

А уз помоћ метрике видимо тренд потрошње ресурса од стране наших информационих система. И на основу њих можемо нешто да планирамо. На нивоу виртуелизације прикупљамо податке и видимо информације о расположивој количини ресурса по дата центру. И већ унутар дата центра можете видети рециклажу, стварну дистрибуцију и потрошњу ресурса. Штавише, како са самосталним серверима, тако и са виртуелним машинама и кластерима физичких сервера на којима се све ове виртуелне машине снажно окрећу.

Изгледи

Сада имамо спремно језгро система у целини, али има још много ствари на којима још треба да се ради. Као минимум, ово је слој безбедности информација, али је такође важно доћи до мреже, развити упозорење и решити питање корелације. Имамо много слојева и система, а на сваком слоју постоји много више метрика. Испада да је матрјошка до степена матрјошке.

Наш задатак је да на крају направимо права упозорења. На пример, ако је постојао проблем са хардвером, опет, са виртуелном машином, и постојала је важна апликација, а услуга није направљена ни на који начин. Сазнајемо да је виртуелна машина умрла. Тада ће вас пословни показатељи упозорити: корисници су негде нестали, нема конверзије, кориснички интерфејс у ​​интерфејсу је недоступан, софтвер и услуге су такође умрли.

У овој ситуацији, примаћемо нежељену пошту од упозорења, а то се више не уклапа у формат одговарајућег система за праћење. Поставља се питање корелације. Зато, идеално, наш систем за праћење би требало да каже: „Момци, ваша физичка машина је умрла, а са њом и ова апликација и ове метрике“, уз помоћ једног упозорења, уместо да нас бесно бомбардује са стотину упозорења. Требало би извести главну ствар - узрок, који помаже у брзом отклањању проблема због његове локализације.

Наш систем за обавештавање и обрада упозорења је изграђен око 24-часовне услуге дежурне линије. Сва упозорења која се сматрају обавезним и која су укључена у контролну листу шаљу се тамо. Свако упозорење мора имати опис: шта се догодило, шта заправо значи, на шта утиче. И такође линк до контролне табле и упутства шта да радите у овом случају.

Ово је све о захтевима за прављење упозорења. Тада се ситуација може развијати у два правца – или постоји проблем и треба га решити, или је дошло до квара у систему праћења. Али у сваком случају, морате отићи и схватити то.

У просеку, сада добијамо око стотину упозорења дневно, узимајући у обзир чињеницу да корелација упозорења још увек није правилно конфигурисана. А ако треба да обавимо техничке радове, а нешто насилно искључимо, њихов број се значајно повећава.

Поред праћења система којима управљамо и прикупљања метрика које се сматрају важним са наше стране, систем надзора нам омогућава да прикупљамо податке за тимове производа. Они могу утицати на састав метрике унутар информационих система које пратимо.

Наш колега може да дође и затражи да дода неку метрику која ће бити корисна и за нас и за тим. Или, на пример, тим можда нема довољно основних метрика које ми имамо; они морају да прате неке специфичне. У Графани креирамо простор за сваки тим и дајемо администраторска права. Такође, ако тиму требају контролне табле, али они сами не могу/не знају како то да ураде, ми им помажемо.

Пошто смо изван тока креирања вредности тима, њихових издања и планирања, постепено долазимо до закључка да су издања свих система беспрекорна и да се могу увести свакодневно без координације са нама. И за нас је важно да пратимо ова издања, јер она потенцијално могу утицати на рад апликације и нешто покварити, а то је критично. За управљање издањима користимо Бамбоо, одакле примамо податке преко АПИ-ја и можемо да видимо која су издања објављена у којим информационим системима и њихов статус. А најважније је у које време. Ми постављамо маркере издања на главне критичне метрике, што је визуелно веома индикативно у случају проблема.

На овај начин можемо видети корелацију између нових издања и нових проблема. Главна идеја је разумети како систем функционише на свим слојевима, брзо локализовати проблем и исто тако брзо га решити. Уосталом, често се дешава да оно што одузима највише времена није решавање проблема, већ тражење узрока.

И у овој области у будућности желимо да се фокусирамо на проактивност. У идеалном случају, желео бих да знам о проблему који се приближава унапред, а не накнадно, како бих могао да га спречим, а не да га решим. Понекад се јављају лажни аларми система за надзор, како због људске грешке тако и због промена у апликацији. И ми радимо на томе, отклањамо грешке и покушавамо да упозоримо кориснике који га користе код нас о томе пре било какве манипулације системом за праћење , или извршите ове активности у техничком прозору.

Дакле, систем је покренут и успешно ради од почетка пролећа... и показује веома реалне профите. Наравно, ово није његова коначна верзија; представићемо још много корисних функција. Али управо сада, са толико интеграција и апликација, аутоматизација надгледања је заиста неизбежна.

Ако пратите и велике пројекте са значајним бројем интеграција, напишите у коментарима који сте сребрни метак нашли за ово.

Извор: ввв.хабр.цом