Razmišljali smo o kreiranju sistema praćenja u fazi formiranja proizvodnih timova. Postalo je jasno da naš posao - eksploatacija - ne spada u ove timove. Žašto je to?
Činjenica je da su svi naši timovi izgrađeni oko pojedinačnih informacionih sistema, mikroservisa i frontova, tako da timovi ne vide ukupno zdravlje celog sistema u celini. Na primjer, možda ne znaju kako neki mali dio u dubokoj pozadini utječe na prednji kraj. Njihov opseg interesovanja je ograničen na sisteme sa kojima je njihov sistem integrisan. Ako tim i njegov servis A nemaju gotovo nikakve veze sa servisom B, onda je takav servis gotovo nevidljiv za tim.
Naš tim, pak, radi sa sistemima koji su međusobno veoma čvrsto integrisani: među njima postoji mnogo veza, ovo je veoma velika infrastruktura. A rad online prodavnice zavisi od svih ovih sistema (kojih, inače, imamo ogroman broj).
Tako ispada da naš odjel ne pripada nijednom timu, već se nalazi malo po strani. U cijeloj ovoj priči, naš zadatak je da sveobuhvatno shvatimo kako funkcioniraju informacioni sistemi, njihovu funkcionalnost, integracije, softver, mrežu, hardver i kako je sve to međusobno povezano.
Platforma na kojoj rade naše internet prodavnice izgleda ovako:
- prednji
- srednja kancelarija
- back office
Koliko god želimo, ne dešava se da svi sistemi rade glatko i besprekorno. Poenta je, opet, broj sistema i integracija – kod nečega poput našeg, neki incidenti su neizbježni, uprkos kvalitetu testiranja. Štaviše, kako unutar zasebnog sistema, tako iu smislu njihove integracije. I potrebno je sveobuhvatno pratiti stanje cijele platforme, a ne bilo kojeg pojedinačnog dijela.
U idealnom slučaju, praćenje zdravlja na cijeloj platformi bi trebalo biti automatizirano. I došli smo do monitoringa kao neizbježnog dijela ovog procesa. U početku je napravljen samo za front-line dio, dok su mrežni stručnjaci, softverski i hardverski administratori imali i još uvijek imaju svoje sisteme za praćenje slojeva po sloju. Svi ovi ljudi su pratili monitoring samo na svom nivou, niko nije imao ni sveobuhvatno razumijevanje.
Na primjer, ako se virtuelna mašina sruši, u većini slučajeva samo administrator odgovoran za hardver i virtuelnu mašinu zna za to. U takvim slučajevima, prvi tim je vidio samu činjenicu pada aplikacije, ali nije imao podatke o padu virtuelne mašine. A administrator može znati ko je kupac i imati grubu predstavu o tome šta se trenutno radi na ovoj virtuelnoj mašini, pod uslovom da je to neka vrsta velikog projekta. On najverovatnije ne zna za mališane. U svakom slučaju, administrator mora otići do vlasnika i pitati šta je bilo na ovoj mašini, šta treba restaurirati, a šta promijeniti. A ako bi se nešto zaista ozbiljno pokvarilo, počeli su da se vrte u krug - jer niko nije video sistem kao celinu.
U konačnici, takve različite priče utječu na cijeli frontend, korisnike i našu osnovnu poslovnu funkciju - online prodaju. S obzirom da nismo dio tima, već se bavimo funkcionisanjem svih ecommerce aplikacija kao dio online trgovine, preuzeli smo zadatak kreiranja sveobuhvatnog sistema praćenja ecommerce platforme.
Struktura sistema i stek
Počeli smo tako što smo identifikovali nekoliko slojeva nadgledanja za naše sisteme, unutar kojih bismo morali da prikupljamo metriku. I sve je to trebalo spojiti, što smo i uradili u prvoj fazi. Sada u ovoj fazi finaliziramo najkvalitetniju kolekciju metrika na svim našim slojevima kako bismo izgradili korelaciju i razumjeli kako sistemi utiču jedni na druge.
Nedostatak sveobuhvatnog nadzora u početnim fazama pokretanja aplikacije (s obzirom da smo je počeli graditi kada je većina sistema bila u proizvodnji) doveo je do toga da smo imali značajan tehnički dug za postavljanje monitoringa cijele platforme. Nismo mogli priuštiti da se fokusiramo na postavljanje monitoringa za jedan IS i detaljno razradu monitoringa za njega, jer bi ostali sistemi neko vrijeme ostali bez nadzora. Da bismo riješili ovaj problem, identifikovali smo listu najpotrebnijih metrika za procjenu stanja informacionog sistema po slojevima i počeli da je implementiramo.
Stoga su odlučili da pojedu slona u dijelovima.
Naš sistem se sastoji od:
- hardver;
- operativni sistem;
- softver;
- UI dijelovi u aplikaciji za praćenje;
- poslovne metrike;
- integracijske aplikacije;
- sigurnost informacija;
- mreže;
- balanser saobraćaja.
U središtu ovog sistema je sam nadzor. Da biste općenito razumjeli stanje cijelog sistema, morate znati šta se dešava sa aplikacijama na svim ovim slojevima i u čitavom skupu aplikacija.
Dakle, o steku.
Koristimo softver otvorenog koda. U centru imamo Zabbix, koji koristimo prvenstveno kao sistem za uzbunjivanje. Svi znaju da je idealan za nadzor infrastrukture. Šta to znači? Upravo one metrike niske razine koje ima svaka kompanija koja održava svoj podatkovni centar (a Sportmaster ima svoje podatkovne centre) - temperatura servera, status memorije, raid, metrika mrežnih uređaja.
Integrirali smo Zabbix sa Telegram messenger-om i Microsoft timovima, koji se aktivno koriste u timovima. Zabbix pokriva sloj stvarne mreže, hardvera i nekog softvera, ali nije lijek. Ove podatke obogaćujemo iz nekih drugih servisa. Na primjer, na nivou hardvera se direktno povezujemo preko API-ja na naš virtuelizacijski sistem i prikupljamo podatke.
Šta još. Pored Zabbixa, koristimo Prometheus, koji nam omogućava praćenje metrike u aplikaciji dinamičkog okruženja. Odnosno, možemo primati metriku aplikacije preko HTTP krajnje tačke i ne brinuti o tome koje metrike učitati u nju, a koje ne. Na osnovu ovih podataka mogu se razviti analitički upiti.
Izvori podataka za druge slojeve, na primjer, poslovne metrike, podijeljeni su u tri komponente.
Prvo, to su eksterni poslovni sistemi, Google Analytics, mi prikupljamo metriku iz logova. Od njih dobijamo podatke o aktivnim korisnicima, konverzijama i svemu ostalom vezanom za poslovanje. Drugo, ovo je sistem za praćenje korisničkog interfejsa. Trebalo bi ga detaljnije opisati.
Nekada smo počeli s ručnim testiranjem, a ono je preraslo u automatska testiranja funkcionalnosti i integracija. Od toga smo napravili monitoring, ostavljajući samo glavnu funkcionalnost, i oslanjajući se na markere koji su što stabilniji i koji se ne mijenjaju često tokom vremena.
Nova struktura tima znači da su sve aplikacijske aktivnosti ograničene na timove proizvoda, tako da smo prestali raditi čisto testiranje. Umesto toga, napravili smo praćenje korisničkog interfejsa iz testova, napisanih na Javi, Selenu i Jenkinsu (koristi se kao sistem za pokretanje i generisanje izveštaja).
Imali smo dosta testova, ali smo na kraju odlučili da idemo na glavni put, metriku najvišeg nivoa. A ako imamo puno specifičnih testova, biće teško održavati podatke ažurnim. Svako naredno izdanje će značajno pokvariti cijeli sistem, a mi ćemo ga samo popraviti. Stoga smo se fokusirali na vrlo fundamentalne stvari koje se rijetko mijenjaju, a samo ih pratimo.
Konačno, treće, izvor podataka je centralizirani sistem evidentiranja. Koristimo Elastic Stack za dnevnike, a zatim možemo povući ove podatke u naš sistem za praćenje poslovnih metrika. Uz sve ovo, imamo i vlastiti Monitoring API servis, napisan u Pythonu, koji ispituje bilo koje usluge putem API-ja i prikuplja podatke od njih u Zabbix.
Još jedan neophodan atribut praćenja je vizualizacija. Naš je baziran na Grafani. Ističe se među ostalim sistemima za vizualizaciju po tome što vam omogućava da vizualizirate metriku iz različitih izvora podataka na kontrolnoj tabli. Možemo prikupiti metriku najvišeg nivoa za online prodavnicu, na primjer, broj narudžbi izvršenih u posljednjem satu iz DBMS-a, metriku performansi za OS na kojem ova online trgovina radi iz Zabbixa i metriku za primjere ove aplikacije od Prometeja. I sve će to biti na jednoj kontrolnoj tabli. Jasno i dostupno.
Dozvolite mi da napomenem o sigurnosti – trenutno finaliziramo sistem, koji ćemo kasnije integrirati sa globalnim sistemom za praćenje. Po mom mišljenju, glavni problemi sa kojima se e-trgovina susreće u oblasti informacione bezbednosti odnose se na botove, parsere i brutalnu silu. Moramo to paziti, jer sve to može kritično utjecati i na rad naših aplikacija i na našu reputaciju s poslovnog stanovišta. I sa odabranim stekom uspješno pokrivamo ove zadatke.
Još jedna važna stvar je da sloj aplikacije sastavlja Prometheus. On sam je također integriran sa Zabbixom. Takođe imamo sitespeed, uslugu koja nam omogućava da vidimo parametre kao što su brzina učitavanja naše stranice, uska grla, renderovanje stranice, učitavanje skripti, itd., takođe je integrisan API. Dakle, naše metrike se prikupljaju u Zabbix-u, i shodno tome, odatle i upozoravamo. Sva upozorenja se trenutno šalju na glavne načine slanja (za sada su to e-mail i telegram, nedavno je povezan i MS Teams). U planu je nadogradnja upozoravanja na takvo stanje da pametni botovi rade kao servis i pružaju informacije za praćenje svim zainteresiranim timovima proizvoda.
Za nas su metrike važne ne samo za pojedinačne informacione sisteme, već i opšte metrike za celokupnu infrastrukturu koju aplikacije koriste: klasteri fizičkih servera na kojima rade virtuelne mašine, balanseri saobraćaja, balanseri mrežnog opterećenja, sama mreža, korišćenje komunikacionih kanala . Plus metrike za naše vlastite podatkovne centre (imamo ih nekoliko i infrastruktura je prilično velika).
Prednosti našeg sistema praćenja su što uz njegovu pomoć vidimo zdravstveno stanje svih sistema i možemo procijeniti njihov uticaj jedni na druge i na zajedničke resurse. I na kraju, omogućava nam da se uključimo u planiranje resursa, što je i naša odgovornost. Upravljamo serverskim resursima - pulom u okviru e-trgovine, puštamo i stavljamo u pogon novu opremu, kupujemo dodatnu novu opremu, vršimo reviziju iskorištenosti resursa itd. Svake godine timovi planiraju nove projekte, razvijaju svoje sisteme, a nama je važno da im obezbijedimo resurse.
A uz pomoć metrike vidimo trend potrošnje resursa od strane naših informacionih sistema. I na osnovu njih možemo nešto planirati. Na nivou virtuelizacije prikupljamo podatke i vidimo informacije o raspoloživoj količini resursa po data centru. A već unutar data centra možete vidjeti recikliranje, stvarnu distribuciju i potrošnju resursa. Štaviše, i sa samostalnim serverima i virtuelnim mašinama i klasterima fizičkih servera na kojima se sve ove virtuelne mašine snažno okreću.
Perspektive
Sada imamo spremno jezgro sistema u cjelini, ali ima još puno stvari na kojima treba raditi. U najmanju ruku, ovo je sloj sigurnosti informacija, ali je također važno doći do mreže, razviti upozorenje i riješiti pitanje korelacije. Imamo mnogo slojeva i sistema, a na svakom sloju postoji mnogo više metrika. Ispada da je to matrjoška do stepena matrjoške.
Naš zadatak je da na kraju napravimo prava upozorenja. Na primjer, ako je postojao problem sa hardverom, opet, sa virtuelnom mašinom, i postojala je važna aplikacija, a usluga nije bila napravljena ni na koji način. Saznajemo da je virtuelna mašina umrla. Tada će vas poslovna metrika upozoriti: korisnici su negdje nestali, nema konverzije, korisničko sučelje u sučelju je nedostupno, softver i usluge su također umrli.
U ovoj situaciji, primat ćemo neželjenu poštu od upozorenja, a to se više ne uklapa u format ispravnog sistema za praćenje. Postavlja se pitanje korelacije. Stoga, idealno, naš sistem za praćenje bi trebao reći: „Momci, vaša fizička mašina je umrla, a sa njom i ova aplikacija i ove metrike“, uz pomoć jednog upozorenja, umjesto da nas bijesno bombarduje sa stotinu upozorenja. Trebalo bi prijaviti glavnu stvar - uzrok, koji pomaže u brzom uklanjanju problema zbog njegove lokalizacije.
Naš sistem obavještavanja i obrada upozorenja izgrađen je oko 24-časovne usluge dežurne linije. Sva upozorenja koja se smatraju obaveznim i koja su uključena u kontrolnu listu šalju se tamo. Svako upozorenje mora imati opis: šta se dogodilo, šta zapravo znači, na šta utiče. I također link do kontrolne ploče i upute o tome što učiniti u ovom slučaju.
Ovo je sve o zahtjevima za izradu upozorenja. Tada se situacija može razvijati u dva smjera – ili postoji problem i treba ga riješiti, ili je došlo do kvara u sistemu praćenja. Ali u svakom slučaju, morate otići i shvatiti to.
U prosjeku, sada primamo oko stotinu upozorenja dnevno, uzimajući u obzir činjenicu da korelacija upozorenja još nije pravilno konfigurirana. A ako trebamo obaviti tehničke radove, a nešto nasilno isključimo, njihov broj se značajno povećava.
Pored praćenja sistema kojima upravljamo i prikupljanja metrika koje se s naše strane smatraju važnim, sistem nadzora nam omogućava da prikupljamo podatke za timove proizvoda. Oni mogu uticati na sastav metrike unutar informacionih sistema koje pratimo.
Naš kolega može doći i tražiti da doda neki pokazatelj koji će biti koristan i za nas i za tim. Ili, na primjer, tim možda nema dovoljno osnovnih metrika koje mi imamo; oni moraju pratiti neke specifične. U Grafani kreiramo prostor za svaki tim i dodjeljujemo administratorska prava. Također, ako nekom timu trebaju dashboards, a oni sami ne mogu/ne znaju kako to učiniti, mi im pomažemo.
Budući da smo izvan toka kreiranja vrijednosti tima, njihovih izdanja i planiranja, postepeno dolazimo do zaključka da su izdanja svih sistema besprijekorna i da se mogu svakodnevno uvoditi bez koordinacije s nama. I važno nam je da pratimo ova izdanja, jer ona potencijalno mogu uticati na rad aplikacije i nešto pokvariti, a to je kritično. Za upravljanje izdanjima koristimo Bamboo, odakle primamo podatke putem API-ja i možemo vidjeti koja su izdanja objavljena u kojim informacionim sistemima i njihov status. A najvažnije je u koje vreme. Mi postavljamo markere izdanja na glavne kritične metrike, što je vizualno vrlo indikativno u slučaju problema.
Na ovaj način možemo vidjeti korelaciju između novih izdanja i novih problema. Glavna ideja je razumjeti kako sistem funkcionira na svim slojevima, brzo lokalizirati problem i jednako brzo ga riješiti. Uostalom, često se dešava da ono što oduzima najviše vremena nije rješavanje problema, već traženje uzroka.
I u ovoj oblasti u budućnosti želimo da se fokusiramo na proaktivnost. U idealnom slučaju, želio bih znati o problemu koji se približava unaprijed, a ne naknadno, kako bih ga mogao spriječiti, a ne riješiti. Ponekad se dešavaju lažni alarmi sistema za nadzor, kako zbog ljudske greške tako i zbog promjena u aplikaciji. I mi radimo na tome, otklanjamo greške i pokušavamo upozoriti korisnike koji ga koriste kod nas na to prije bilo kakve manipulacije nadzornim sistemom , ili izvršite ove aktivnosti u tehničkom prozoru.
Dakle, sistem je pokrenut i uspješno radi od početka proljeća... i pokazuje vrlo realne profite. Naravno, ovo nije njegova konačna verzija; uvest ćemo još mnogo korisnih funkcija. Ali upravo sada, s toliko integracija i aplikacija, automatizacija nadzora je zaista neizbježna.
Ako pratite i velike projekte sa značajnim brojem integracija, napišite u komentarima koji ste srebrni metak našli za ovo.
izvor: www.habr.com