Го следиме Спортмастер - како и со што

Размислувавме да создадеме систем за следење во фазата на формирање тимови за производи. Стана јасно дека нашиот бизнис - експлоатација - не спаѓа во овие тимови. Зошто е тоа?

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

Нашиот тим, пак, работи со системи кои се многу силно интегрирани едни со други: има многу врски меѓу нив, ова е многу голема инфраструктура. И работата на онлајн продавницата зависи од сите овие системи (од кои, патем, имаме огромен број).

Значи, излегува дека нашиот оддел не припаѓа на ниту еден тим, туку е сместен малку настрана. Во целата оваа приказна, наша задача е сеопфатно да разбереме како функционираат информациските системи, нивната функционалност, интеграции, софтвер, мрежа, хардвер и како сето тоа е поврзано едно со друго.

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

• пред
• средна канцеларија
• back-office

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

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

На пример, ако виртуелната машина се урна, во повеќето случаи само администраторот одговорен за хардверот и виртуелната машина знае за тоа. Во такви случаи, тимот на првата линија го виде самиот факт на падот на апликацијата, но немаше податоци за падот на виртуелната машина. А администраторот може да знае кој е клиентот и да има груба претстава за тоа што моментално работи на оваа виртуелна машина, под услов да се работи за некој вид голем проект. Тој најверојатно не знае за малите. Во секој случај, администраторот треба да оди кај сопственикот и да праша што има на оваа машина, што треба да се обнови и што треба да се смени. И ако нешто навистина сериозно се расипе, тие почнаа да трчаат во кругови - затоа што никој не го гледаше системот како целина.

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

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

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

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

Затоа, решиле да го изедат слонот на делови.

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

• хардвер;
• операционен систем;
• софтвер;
• UI делови во апликацијата за следење;
• деловни метрики;
• апликации за интеграција;
• безбедност на информации;
• мрежи;
• сообраќаен балансер.

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

Значи, за магацинот.

Ние користиме софтвер со отворен код. Во центарот го имаме Zabbix, кој го користиме првенствено како систем за предупредување. Секој знае дека е идеален за следење на инфраструктурата. Што значи тоа? Само оние метрики на ниско ниво што ги има секоја компанија што одржува сопствен центар за податоци (а Sportmaster има свои центри за податоци) - температура на серверот, статус на меморија, рација, метрика на мрежни уреди.

Го интегриравме Zabbix со месинџерот Telegram и Microsoft Teams, кои активно се користат во тимови. Zabbix го покрива слојот на вистинската мрежа, хардверот и одреден софтвер, но тоа не е лек. Ги збогатуваме овие податоци од некои други услуги. На пример, на ниво на хардвер, ние директно се поврзуваме преку API со нашиот систем за виртуелизација и собираме податоци.

Што друго. Покрај Zabbix, ние користиме Prometheus, кој ни овозможува да ја следиме метриката во апликација за динамично опкружување. Односно, можеме да примаме метрика на апликацијата преку крајната точка на HTTP и да не се грижиме за тоа која метрика да ја вчитаме во неа, а која не. Врз основа на овие податоци, може да се развијат аналитички прашања.

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

Прво, ова се надворешни деловни системи, Google Analytics, ние собираме метрика од дневници. Од нив добиваме податоци за активни корисници, конверзии и се останато поврзано со бизнисот. Второ, ова е систем за следење на интерфејсот. Треба да се опише подетално.

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

Новата тимска структура значи дека сите активности на апликацијата се ограничени на тимови на производи, па затоа престанавме да правиме чисто тестирање. Наместо тоа, направивме следење на интерфејсот од тестовите, напишани на Java, Selenium и Jenkins (кои се користат како систем за лансирање и генерирање извештаи).

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

Конечно, трето, изворот на податоци е централизиран систем за логирање. Ние користиме Elastic Stack за дневници, а потоа можеме да ги повлечеме овие податоци во нашиот систем за следење за деловни метрики. Дополнително на сето ова, имаме сопствена услуга за следење API, напишана во Python, која бара какви било услуги преку API и собира податоци од нив во Zabbix.

Друг незаменлив атрибут на мониторингот е визуелизацијата. Нашиот е базиран на Графана. Се издвојува меѓу другите системи за визуелизација по тоа што ви овозможува да визуелизирате метрика од различни извори на податоци на контролната табла. Можеме да собереме метрика на највисоко ниво за онлајн продавница, на пример, бројот на нарачки направени во последниот час од DBMS, метрика на перформанси за оперативниот систем на кој работи оваа онлајн продавница од Zabbix и метрика за примери на оваа апликација од Прометеј. И сето ова ќе биде на една контролна табла. Јасно и достапно.

Да напоменам за безбедноста - моментално го финализираме системот, кој подоцна ќе го интегрираме со глобалниот систем за мониторинг. Според мене, главните проблеми со кои се соочува е-трговијата во областа на информациската безбедност се поврзани со ботови, парсери и брутална сила. Треба да внимаваме на ова, бидејќи сето ова може критички да влијае и на работата на нашите апликации и на нашата репутација од деловна гледна точка. И со избраниот стек успешно ги покриваме овие задачи.

Друга важна точка е дека слојот за апликација е склопен од Прометеј. И самиот тој е интегриран со Zabbix. Исто така, имаме брзина на страницата, услуга која ни овозможува да гледаме параметри како што се брзината на вчитување на нашата страница, тесни грла, прикажување на страници, скрипти за вчитување итн., исто така е интегриран во API. Значи, нашите метрики се собрани во Zabbix, и соодветно, ние исто така предупредуваме од таму. Сите предупредувања моментално се испраќаат до главните методи за испраќање (засега тоа се е-пошта и телеграма, неодамна се поврзани и MS Teams). Има планови за надградба на предупредувањето до таква состојба што паметните ботови работат како услуга и обезбедуваат информации за следење на сите заинтересирани тимови за производи.

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

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

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

Изгледите

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

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

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

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

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

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

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

Нашиот колега може да дојде и да побара да додаде некоја метрика која ќе биде корисна и за нас и за тимот. Или, на пример, тимот можеби нема доволно основни показатели што ги имаме; тие треба да следат некои специфични. Во Графана создаваме простор за секој тим и доделуваме администраторски права. Исто така, ако на тимот му се потребни контролни табли, но тие самите не можат/не знаат како да го направат тоа, ние му помагаме.

Бидејќи сме надвор од протокот на создавање вредност на тимот, нивните изданија и планирање, постепено доаѓаме до заклучок дека изданијата на сите системи се беспрекорни и може да се продаваат секојдневно без координација со нас. И за нас е важно да ги следиме овие изданија, бидејќи тие потенцијално би можеле да влијаат на работата на апликацијата и да скршат нешто, а тоа е критично. За да управуваме со изданијата, користиме Bamboo, од каде добиваме податоци преку API и можеме да видиме кои изданија се објавени во кои информациски системи и нивниот статус. И најважно е во кое време. Ние ги ставаме маркерите за ослободување на главните критични метрики, што е визуелно многу индикативно во случај на проблеми.

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

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

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

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

Извор: www.habr.com