Pozdrav!
Zovem se Mihail, zamjenik sam direktora za IT u tvrtki „Sportmaster“. Želim podijeliti priču o tome kako smo se nosili s izazovima koji su se pojavili tijekom pandemije.
U prvim danima novih stvarnosti, uobičajeni format offline prodaje „Sportmastera“ stagnirao je, a opterećenje na našem online kanalu, posebice u dijelu dostave na adresu kupcima, poraslo je deset puta. U nekoliko tjedana transformirali smo ogromno offline poslovanje u online, prilagodili smo uslugu potrebama naših klijenata.
Općenito, ono što je u biti bila naša sekundarna operacija postalo je glavni posao. Važnost svake internet narudžbe ekstremno je porasla. Morali smo zadržati svaki novčić koji je klijent donio u tvrtku.
Kako bismo odmah reagirali na zahtjeve kupaca, otvorili smo dodatni kontaktni centar u glavnom uredu tvrtke i sada možemo primiti oko 285 tisuća poziva tjedno. U isto vrijeme, prebacili smo 270 trgovina u novi format bezkontaktnog i sigurnog rada, što je omogućilo kupcima da preuzmu narudžbe, a zaposlenicima da zadrže svoja radna mjesta.
Tijekom transformacije imali smo dva glavna problema. Prvo, opterećenje na našim online resursima značajno je poraslo (o tome kako smo se borili s tim, govorit će Sergey). Drugo, broj rijetkih operacija (do COVID-a) višestruko je porastao, što je zauzvrat zahtijevalo veliku brzinu automatizacije. Kako bismo riješili ovaj problem, morali smo brzo prebaciti resurse s područja koja su ranije bila glavna. O tome kako smo to učinili, govoriti će Elena.
Eksploatacija online usluga
Kolesnikov Sergey, odgovara za eksploataciju internetske trgovine i mikroservisa
Od trenutka kada su naše maloprodajne trgovine počele zatvarati vrata kupcima, počeli smo bilježiti porast takvih metrika kao što su broj korisnika, broj narudžbi obrađenih u našoj aplikaciji, broj zahtjeva prema aplikacijama.
Broj narudžbi od 18. do 31. ožujka
Broj zahtjeva prema mikroservisima online plaćanja
Broj narudžbi napravljenih na web stranici
Na prvom grafikonu vidimo da je porast iznosio otprilike 14 puta, a na drugom — 4 puta. Najdokaznije mjerilo pri tome smatramo vremenom odgovora naših aplikacija.
Na ovom grafu vidimo odgovore frontova i aplikacija, a za sebe smo utvrdili da nismo primijetili nikakav rast.
Prvo, to je povezano s tim što smo započeli pripremne radove krajem 2019. godine. Sada su naši servisi rezervirani, osigurana je otpornost na kvarove na razini fizičkih servera, sustava virtualizacije, dockera i usluga unutar njih. Istodobno, kapaciteti naših serverskih resursa omogućuju nam da izdržimo višestruko opterećenje.
Glavni alat koji nam je pomogao u cijeloj ovoj priči postao je naš sustav nadzora. Ipak, još nedavno nismo imali jedinstveni sustav koji bi omogućio prikupljanje metrika na svim razinama, od fizičke opreme i hardvera do poslovnih metrika.
Formalno, monitoring je u kompaniji postojao, ali je obično bio raspršen i smatran odgovornošću konkretnih odjela. U stvarnosti, kada bi se dogodio neki incident, gotovo nikada nismo imali jedinstveno razumijevanje što se zapravo dogodilo, nije bilo informacija, a često je to vodilo do beskrajnog trčanja u potrazi za i lokalizacijom problema radi njegovog kasnijeg uklanjanja.
U nekom trenutku smo pomislili i odlučili da je dosta toga — potrebna nam je jedinstvena sustav, kako bismo vidjeli cijelu sliku u cjelini. Glavne tehnologije koje čine našu infrastrukturu su Zabbix kao centar za upozoravanje i pohranu metrika, Prometheus za prikupljanje i pohranu metrika aplikacija, Stack ELK za logiranje i pohranu podataka cijelog sustava nadzora, te Grafana za vizualizaciju, Swagger, Docker i druge korisne i poznate stvari.
Uz to, ne koristimo samo dostupne tehnologije na tržištu, već i razvijamo nešto sami. Na primjer, izrađujemo servise za integraciju sustava jednih s drugima, odnosno neku vrstu API-ja za prikupljanje metrika. Plus, radimo na vlastitim sustavima nadzora — na razini poslovnih metrika koristimo UI testove. Također, imamo bot u Telegramu za obavještavanje timova.
Pored toga, trudimo se učiniti sustav nadzora dostupnim timovima, kako bi oni mogli samostalno pohraniti svoje metrike i raditi s njima, uključujući podešavanje upozorenja na uskim metrikama koje imaju značaj, a ne široku primjenu.
U okviru cijelog sustava težimo proaktivnosti i maksimalno brzoj lokalizaciji incidenata. Osim toga, broj naših mikrosustava i sustava znatno je porastao u posljednje vrijeme, pa tako raste i broj integracija. U cilju optimizacije procesa dijagnostike incidenata na razini integracije razvijamo sustav koji omogućava provođenje međusustavnih provjera i prikazivanje rezultata, što omogućuje pronalaženje glavnih problema vezanih uz uvoze i međusobnu interakciju sustava.
Naravno, imamo još prostora za rast i razvoj u pogledu upravljanja sustavima, i aktivno radimo na tome. Više o našem sustavu praćenja možete pročitati .
Tehnička ispitivanja
Sergije Orlov vodi centar kompetencije za web i mobilni razvoj
Od početka zatvaranja fizičkih trgovina suočili smo se s raznim izazovima u pogledu razvoja. Prvo, skok opterećenja kao takvog. Jasno je da ako se ne poduzmu odgovarajuće mjere, pod jakim opterećenjem sustav se može s tužnim zvukom pretvoriti u bundevu, ili potpuno degradirati u performansama, ili uopće izgubiti svoju funkcionalnost.
Drugi aspekt, nešto manje očigledan, jest da je sustav pod visokim opterećenjem trebao biti vrlo brzo promijenjen, prilagođavajući se promjenama poslovnih procesa. Ponekad i nekoliko puta dnevno. Mnoge tvrtke imaju pravilo da prilikom velikih marketinških aktivnosti ne treba unositi nikakve promjene u sustav. Uopće nikakve, neka radi, čim radi.
A mi smo, u suštini, imali beskrajni crni petak, u kojem smo također morali mijenjati sustav. Svaka greška, problem ili kvar u sustavu bili bi vrlo skupi za poslovanje.
S obzirom na sve, mogu reći da smo uspjeli suočiti se s tim izazovima, svi sustavi su izdržali opterećenje, lako su se skalirali i nismo imali globalnih tehničkih kvarova.
Postoje četiri stuba na kojima se temelji sposobnost sustava da izdrži visoke skokovite opterećenja. Prvi od njih je praćenje, o kojem ste čitali malo prije. Bez izgrađenog sustava praćenja gotovo je nemoguće pronaći uska grla sustava. Dobar sustav praćenja je poput kućne odjeće, trebao bi biti udoban i prilagođen vama.
Drugi aspekt je testiranje. Ovo pitanje shvaćamo vrlo ozbiljno: pišemo klasične jedinice, integracijske, opterećenjske testove i mnoge druge za svaki sustav. Također pišemo strategiju testiranja, te nastojimo unaprijediti razinu testiranja do točke gdje nam više ne trebaju ručne provjere.
Treći stub je CI/CD Pipeline. Procesi izgradnje, testiranja i implementacije aplikacija trebaju biti maksimalno automatizirani, bez ručnih intervencija. Tema CI/CD Pipeline je prilično opsežna, i dotičem je samo površno. Vrijedi spomenuti da imamo kontrolni popis CI/CD Pipeline, prema kojem kroz centre kompetencija prolazi svaki razvojni tim.
Evo kontrolnog popisa
Na taj način postiže se mnogo ciljeva. To je verzioniranje API-ja, i feature toggle kako bi se izbjegli problemi s objavama, i postizanje razine pokrivenosti različitih testova tako da testiranje bude potpuno automatizirano, a implementacije besprijekorne i drugo.
Četvrti stub su arhitektonski principi i tehnička rješenja. O arhitekturi se može govoriti puno i dugo, ali želim naglasiti nekoliko principa na koje bih želio skrenuti pozornost.
Prvo, treba odabrati specijalizirane alate za specifične zadatke. Da, zvuči očigledno, i jasno je da se čavli trebaju zabijati čekićem, a ručni satovi rastavljati posebnim odvijačima. No, u naše doba mnogo alata teži univerzalizaciji kako bi obuhvatili maksimalan segment korisnika: baze podataka, keševe, okvire i ostalo. Na primjer, ako uzmemo bazu podataka MongoDB, ona radi s višedokumentarnim transakcijama, dok baza podataka Oracle radi s json-ima. I činilo bi se da se sve može koristiti za sve. Ali ako se zalagamo za performanse, moramo jasno razumjeti snage i slabosti svakog alata i koristiti one koji su nam potrebni za naš razred zadataka.
Drugo, prilikom projektiranja sustava svako povećanje složenosti treba biti opravdano. Trebamo stalno imati to na umu, princip niske povezanosti je svima poznat. Smatram da se treba primjenjivati i na razini konkretnog servisa, i na razini cijelog sustava, te na razini arhitektonskog pejzaža. Također je važna sposobnost horizontalnog skaliranja svakog komponeneta sustava pod opterećenjem. Ako imamo tu sposobnost, skaliranje neće biti nikakav problem.
Što se tiče tehničkih rješenja, zamolili smo proizvodne timove da pripreme svjež skup preporuka, ideja i rješenja koja su implementirali u pripremi za sljedeći val opterećenja.
Keševi
Moramo svjesno pristupiti izboru lokalnih i distribuiranih keševa. Ponekad ima smisla koristiti i jedne i druge unutar istog sustava. Na primjer, imamo sustave u kojima su neki podaci u osnovi izložbeni keš, što znači da se izvor ažuriranja nalazi izvan samog sustava, a sustavi ne mijenjaju te podatke. Za takav pristup koristimo lokalni Caffeine Cache.
A postoje podaci koje sustav aktivno mijenja tijekom rada, i tu već primjenjujemo distribuirani keš s Hazelcastom. Takav pristup nam omogućava da iskoristimo prednosti distribuiranog keša gdje su doista potrebne, i minimiziramo troškove servisa za cirkulaciju podataka klastera Hazelcast gdje možemo bez toga. O keševima smo puno pisali. i .
Osim toga, prelazak na Kryo serializer u Hazelcastu donio nam je dobar porast. A prijelaz s ReplicatedMap na IMap + Near Cache u Hazelcastu omogućio nam je minimiziranje kretanja podataka unutar klastera.
Mali savjet: pri masovnoj invalidaciji cache-a ponekad se može primijeniti taktika zagrijavanja drugog cache-a s kasnijim prebacivanjem na njega. Iako bi se na prvi pogled činilo da ćemo ovim pristupom dobiti dvostruku potrošnju memorije, u praksi, u sustavima gdje se to primjenjivalo, potrošnja memorije se smanjivala.
Reaktivni okvir
Reaktivni okvir koristimo već u prilično velikom broju sustava. U našem slučaju to je Webflux ili Kotlin s korutinama. Posebno dobro reaktivni okvir dolazi do izražaja kada očekujemo spore operacije ulaza i izlaza. Na primjer, pozivi sporih servisa, rad s datotečnim sustavima ili sustavima za pohranu.
Najvažniji princip je izbjegavati blokirajuće pozive. Ispod poklopca reaktivnih okvira radi manji broj aktivnih uslužnih niti. Ako nepažljivo dozvolimo sebi da napravimo izravan blokirajući poziv, kao što je poziv JDBC drajvera, sustav će jednostavno stati.
Pokušajte pretvoriti greške u vlastite runtime exceptione. Stvarna nit izvršenja programa prelazi na reaktivne okvire, izvršavanje koda postaje nelinearno. Kao posljedica, vrlo je teško dijagnosticirati probleme prema stack trace-ovima. Rješenje ovdje će biti stvaranje jasnih objektivnih runtime exceptiona za svaku grešku.
Elasticsearch
Prilikom korištenja Elastica ne odabirejte neiskorištene podatke. To je, u osnovi, vrlo jednostavan savjet, ali najčešće se upravo toga zaboravlja. Ako trebate odabrati više od 10 tisuća zapisa odjednom, potrebno je koristiti Scroll. U analogiji, to nalikuje kursoru u relacijskoj bazi podataka.
Ne koristite postfilter bez potrebe. Pri velikim podacima u osnovnom odabiru ova operacija jako opterećuje bazu podataka.
Koristite bulk operacije gdje je to primjenjivo.
API
Pri dizajniranju API-ja postavite zahtjeve za minimizaciju prenesenih podataka. To je posebno važno na spoju s front-endom: upravo na toj točki izlazimo iz kanala naših podatkovnih centara i već radimo na kanalu koji nas povezuje s klijentom. Ako postoje i najmanji problemi na njemu, preveliki promet izaziva negativno korisničko iskustvo.
I na kraju, nemojte preopteretiti podatke, jasno pristupite ugovoru između potrošača i dobavljača.
Organizacijska transformacija
Eroškina Jelena, zamjenica direktora za IT
U trenutku kada je došlo do karantene i nastala potreba za brzom digitalizacijom i uvođenjem omnichannel usluga, već smo bili u procesu organizacijske transformacije.
Dio naše strukture prešao je na rad prema principima i praksama produktnog pristupa. Formirane su ekipe koje sada odgovaraju za funkcioniranje i razvoj svakog proizvoda. Zaposlenici u tim timovima angažirani su 100% i organiziraju svoj rad prema Scrum ili Kanban metodi, ovisno o tome što im više odgovara, postavljaju konvejer za implementaciju, uvode tehničke prakse, prakse osiguravanja kvalitete i mnogo toga drugog.
Sretna okolnost je da je većina tih produktnih timova radila u području online i omnichannel usluga. To nam je omogućilo da u najkraćem mogućem roku (ozbiljno, doslovno za dva dana) pređemo u režim rada na daljinu bez gubitka učinkovitosti. Uspostavljeni proces omogućio je brzu prilagodbu novim uvjetima rada i održavanje prilično visokog tempa isporuke nove funkcionalnosti.
Osim toga, nastala je potreba da osnažimo timove koji su na prvoj liniji online posla. U tom trenutku postalo je jasno da to možemo učiniti samo korištenjem unutarnjih resursa. Otprilike 50 ljudi je u roku od dva tjedna promijenilo područje rada i uključilo se u rad na novom proizvodu.
Za to nisu bila potrebna posebna upravljačka nastojanja, jer uz organizaciju vlastitog procesa, tehničkim usavršavanjem proizvoda i praksom osiguravanja kvalitete, učimo naše timove samoupravljanju — upravljaju vlastitim proizvodnim procesom bez uključivanja administrativnih resursa.
Upravljački resurs smo uspjeli fokusirati upravo tamo gdje je to bilo potrebno u tom trenutku — na koordinaciju s poslovanjem: Što je sada važno za našeg klijenta, koja funkcionalnost treba biti prioritetno realizirana, što treba učiniti kako bismo povećali našu propusnost u dostavi i obradi narudžbi. Sve to i jasna uloga omogućili su nam tijekom ovog razdoblja da opteretimo naše proizvodne tokove stvaranja vrijednosti onim što zaista jest važno i potrebno.
Jasno je da se u uvjetima daljinskog rada i visoke dinamike promjena, kada poslovni pokazatelji ovise o sudjelovanju svakoga, ne može oslanjati isključivo na unutarnje osjećaje poput „Je li sve dobro? Pa, izgleda da jest“. Potrebne su objektivne metrike proizvodnog procesa. One su nam dostupne, svakome tko se interesira za metrike produktnih timova. Prvenstveno samom timu, poslovanju, suradnicima i menadžmentu.
Svake dvije sedmice s svakim timom održava se statusna sastanak, gdje se u razdoblju od 10 minuta analiziraju metrike, identificiraju uska grla proizvodnog procesa i razvija zajedničko rješenje: što se može učiniti kako bi se ta uska grla uklonila. Tamo se također može odmah zatražiti pomoć od menadžmenta u slučaju da je neki identificirani problem izvan dometa tima, ili savjet od kolega koji su se možda već susreli s sličnim problemom.
Unatoč tome, shvaćamo da za višestruko ubrzanje (a to je cilj koji smo postavili) još moramo mnogo naučiti i implementirati u svakodnevni rad. Točno sada nastavljamo s proširenjem produktnog pristupa na druge timove i nove proizvode. Za to smo morali savladati za nas novi format online škole metodologa.
Metodolozi, ljudi koji pomažu timovima da uspostave procese, poboljšaju komunikaciju i povećaju učinkovitost rada, zapravo su agenti promjena. Trenutno, diplomanti naše prve generacije rade s timovima i pomažu im da postanu uspješni.
Mislim da trenutna situacija otvara mogućnosti i perspektive koje možda još sami potpuno ne svjesni. No, iskustvo i praksa koju steknemo upravo sada potvrđuje da smo odabrali pravi put razvoja, te da nećemo propustiti te nove mogućnosti u budućnosti i da ćemo moći efikasno odgovarati na izazove koji će biti pred 'Sportmasterom'.
Zaključci
Tijekom ovog teškog razdoblja formulirali smo glavne principe na kojima se temelji razvoj softvera, koji će, mislim, biti relevantni za svaku tvrtku koja se tim bavi.
Ljudi. To je ono na čemu sve počiva. Zaposlenici trebaju uživati u radu, razumjeti ciljeve tvrtke i ciljeve proizvoda s kojima rade. I, naravno, moraju imati mogućnosti za profesionalni razvoj.
Tehnologija. Potrebno je da tvrtka zrelo pristupa radu sa svojim tehnološkim stogom i razvija kompetencije tamo gdje je to zaista potrebno. Zvuči vrlo jednostavno i očito. A često se ignorira.
Procesi. Važno je pravilno organizirati rad produktnih timova i centara kompetencija, uspostaviti suradnju s poslovanjem kako bi se radilo s njim kao s partnerom.
Uglavnom, otprilike tako smo i preživjeli. Glavna teza modernog doba još jednom je potvrđena, zvučno udarajući po čelu.
Čak i ako si ogroman offline biznis s mnoštvom trgovina i brojnim gradovima prisutnosti, razvijaj svoju online prisutnost. Ovo nije samo dodatni kanal prodaje ili lijepa aplikacija preko koje se također može nešto kupiti (a i zato što i konkurencija ima nešto slično). Ovo nije rezervni kotač za svaki slučaj, koji će pomoći prebroditi oluju.
To je apsolutna nužnost. Na koju trebaju biti spremne ne samo vaša tehnička snaga i infrastruktura, već i ljudi i procesi. Naime, brzo kupiti memoriju, prostor, implementirati nove instance i slično može se obaviti u nekoliko sati. No, ljude i procese treba pripremati unaprijed.
Izvor: habr.com
