Zdravo!
Zovem se Mihail, zamenik sam direktora IT-a u kompaniji Sportmaster. Želim podijeliti priču o tome kako smo se nosili s izazovima koji su se pojavili tokom pandemije.
U prvim danima nove realnosti, uobičajeni format offline trgovanja Sportmastera se zamrznuo, a opterećenje na našem online kanalu, prvenstveno u pogledu isporuke na adresu klijenta, poraslo je 10 puta. Za samo nekoliko sedmica transformirali smo gigantski oflajn posao u online i prilagodili uslugu potrebama naših klijenata.
U suštini, ono što je u suštini bila naša sporedna operacija postalo je naš osnovni posao. Značaj svake online narudžbe je izuzetno porastao. Bilo je potrebno uštedjeti svaku rublju koju je klijent donio kompaniji.
Kako bismo brzo odgovorili na zahtjeve kupaca, otvorili smo dodatni kontakt centar u glavnoj kancelariji kompanije, te sada možemo primiti oko 285 hiljada poziva sedmično. Istovremeno smo 270 trgovina prebacili u novi beskontaktni i siguran format rada, koji je omogućio kupcima da primaju narudžbe, a zaposlenima da zadrže svoja radna mjesta.
Tokom procesa transformacije naišli smo na dva glavna problema. Prvo, opterećenje na našim online resursima se značajno povećalo (Sergey će vam reći kako smo se nosili s tim). Drugo, tok rijetkih (prije COVID-a) operacija se višestruko povećao, što je zauzvrat zahtijevalo veliku količinu brze automatizacije. Da bismo riješili ovaj problem, morali smo brzo prebaciti resurse iz oblasti koje su ranije bile glavne. Elena će vam reći kako smo to riješili.
Rad online usluga
Kolesnikov Sergej, odgovoran za rad internet prodavnice i mikroservisa
Od trenutka kada su se naši maloprodajni objekti počeli zatvarati posjetiteljima, počeli smo bilježiti porast metrika kao što su broj korisnika, broj narudžbi u našoj aplikaciji i broj zahtjeva za aplikacije.
Broj porudžbina od 18. marta do 31. martaBroj zahtjeva mikroservisima za online plaćanjeBroj porudžbina izvršenih na web stranici
Na prvom grafikonu vidimo da je povećanje bilo otprilike 14 puta, u drugom - 4 puta. Smatramo da je metrika vremena odgovora naših aplikacija najindikativnija.
Na ovom grafikonu vidimo odziv frontova i aplikacija, a za sebe smo utvrdili da nismo primijetili nikakav rast kao takav.
To je prvenstveno zbog činjenice da smo pripremne radove započeli krajem 2019. godine. Sada su naše usluge rezervisane, tolerancija grešaka je osigurana na nivou fizičkih servera, sistema virtuelizacije, docker-a i servisa u njima. Istovremeno, kapacitet naših serverskih resursa omogućava nam da izdržimo višestruka opterećenja.
Glavni alat koji nam je pomogao u cijeloj ovoj priči bio je naš sistem za praćenje. Istina, donedavno nismo imali niti jedan sistem koji bi nam omogućio prikupljanje metrike na svim nivoima, od nivoa fizičke opreme i hardvera do nivoa poslovnih metrika.
Formalno je u kompaniji postojao monitoring, ali je po pravilu bio disperziran i bio je u zoni odgovornosti pojedinih odjela. Zapravo, kada se desio incident, gotovo nikada nismo imali zajedničko razumijevanje o tome šta se tačno dogodilo, nije bilo komunikacije, a često je to dovodilo do trčanja u krug kako bismo pronašli i izolovali problem kako bi se mogao riješiti.
U jednom trenutku smo pomislili i zaključili da nam je dosta toga da trpimo – potreban nam je jedinstven sistem da bismo sagledali celu sliku u potpunosti. Glavne tehnologije koje su uključene u naš stack su Zabbix kao centar za pohranu upozorenja i metrike, Prometheus za prikupljanje i pohranjivanje metrike aplikacije, Stack ELK za evidentiranje i pohranjivanje podataka iz cijelog sistema za praćenje, kao i Grafana za vizualizaciju, Swagger, Docker i druge korisne i stvari koje su vam poznate.
Istovremeno, koristimo ne samo tehnologije dostupne na tržištu, već i razvijamo neke od svojih. Na primjer, pravimo usluge za međusobno integraciju sistema, odnosno neku vrstu API-ja za prikupljanje metrike. Osim toga, radimo na vlastitim sistemima za praćenje - na nivou poslovnih metrika koristimo UI testove. I također bot u Telegramu za obavještavanje timova.
Također pokušavamo učiniti sistem nadzora dostupnim timovima kako bi mogli samostalno pohranjivati i raditi sa svojim metričkim podacima, uključujući postavljanje upozorenja za neke uske metrike koje se ne koriste široko.
U cijelom sistemu težimo proaktivnosti i što bržem lokalizaciji incidenata. Osim toga, broj naših mikroservisa i sistema je u posljednje vrijeme značajno porastao, a shodno tome je porastao i broj integracija. I kao dio optimizacije procesa dijagnosticiranja incidenata na nivou integracije, razvijamo sistem koji vam omogućava da provodite međusistemske provjere i prikažete rezultat, koji vam omogućava da pronađete glavne probleme povezane s uvozom i interakcijom sistema sa jedan drugog.
Naravno, još uvijek imamo prostora za rast i razvoj u pogledu operativnih sistema i na tome aktivno radimo. Možete pročitati više o našem sistemu za praćenje .
Tehnički testovi
Orlov Sergey, vodi centar kompetencija za web i mobilni razvoj
Otkako je počelo fizičko zatvaranje prodavnica, suočili smo se sa raznim izazovima iz perspektive razvoja. Prije svega, porast opterećenja kao takav. Jasno je da ako se ne poduzmu odgovarajuće mjere, onda kada se sistem primijeni velikim opterećenjem, može se pretvoriti u bundevu s tužnim praskom, ili potpuno pogoršati performanse, ili čak izgubiti svoju funkcionalnost.
Drugi aspekt, malo manje očigledan, jeste da je sistem pod velikim opterećenjem morao da se menja veoma brzo, prilagođavajući se promenama u poslovnim procesima. Ponekad i nekoliko puta dnevno. Mnoge kompanije imaju pravilo da ako postoji mnogo marketinških aktivnosti, nema potrebe za bilo kakvim promjenama u sistemu. Nikakve, neka radi dok radi.
I u suštini smo imali beskrajni Crni petak, tokom kojeg je bilo potrebno promijeniti sistem. I svaka greška, problem ili kvar u sistemu bi bili veoma skupi za posao.
Gledajući unaprijed, reći ću da smo uspjeli izaći na kraj sa ovim testovima, svi sistemi su izdržali opterećenje, lako su se skalirali i nismo doživjeli globalne tehničke kvarove.
Postoje četiri stuba na kojima počiva sposobnost sistema da izdrži velika prenaponska opterećenja. Prvi od njih je monitoring, o kojem ste pročitali malo iznad. Bez ugrađenog sistema za praćenje, gotovo je nemoguće pronaći uska grla u sistemu. Dobar sistem za praćenje je kao kućna odjeća; trebao bi biti udoban i prilagođen vama.
Drugi aspekt je testiranje. Ovu tačku shvatamo veoma ozbiljno: pišemo klasične jedinice, integracijske testove, testove opterećenja i mnoge druge za svaki sistem. Pišemo i strategiju testiranja, a u isto vrijeme pokušavamo povećati nivo testiranja do te mjere da nam više nisu potrebne ručne provjere.
Treći stub je CI/CD Pipeline. Procesi izgradnje, testiranja i implementacije aplikacije trebaju biti automatizirani što je više moguće; ne bi trebalo biti ručne intervencije. Tema CI/CD Pipeline-a je prilično duboka i samo ću je se ukratko dotaknuti. Vrijedi samo spomenuti da imamo CI/CD Pipeline kontrolnu listu, kroz koju svaki proizvodni tim prolazi uz pomoć centara za kompetencije.
A evo i kontrolne liste
Na ovaj način se postižu mnogi ciljevi. Ovo je API verzija i prebacivanje funkcija kako bi se izbjeglo izdavanje, i postizanje pokrivenosti različitih testova na takvom nivou da je testiranje potpuno automatizirano, implementacije besprijekorne, itd.
Četvrti stub su arhitektonski principi i tehnička rješenja. O arhitekturi možemo mnogo pričati dugo, ali želim da istaknem nekoliko principa na koje bih se fokusirao.
Prvo morate odabrati specijalizirane alate za određene zadatke. Da, zvuči očigledno, i jasno je da eksere treba zabiti čekićem, a ručne satove rastavljati posebnim odvijačima. Ali u našem dobu mnogi alati teže univerzalizaciji kako bi pokrili maksimalan segment korisnika: baze podataka, keš memorije, okviri i ostalo. Na primjer, ako uzmete MongoDB bazu podataka, ona radi sa transakcijama sa više dokumenata, a Oracle baza podataka radi sa json-om. I čini se da se sve može koristiti za sve. Ali ako se zalažemo za produktivnost, onda moramo jasno razumjeti snage i slabosti svakog alata i koristiti one koje su nam potrebne za našu klasu zadataka.
Drugo, prilikom projektovanja sistema, svako povećanje složenosti mora biti opravdano. To moramo stalno imati na umu, princip niske sprege je svima poznat. Smatram da to treba primijeniti i na nivou određene usluge, i na nivou cijelog sistema, i na nivou arhitektonskog pejzaža. Mogućnost horizontalnog skaliranja svake komponente sistema duž putanje opterećenja je takođe važna. Ako imate ovu sposobnost, skaliranje neće biti teško.
Kada je riječ o tehničkim rješenjima, zamolili smo proizvodne timove da pripreme svježi set preporuka, ideja i rješenja, koje su implementirali u pripremi za sljedeći talas opterećenja.
Keshi
Potrebno je svjesno pristupiti izboru lokalnih i distribuiranih keša. Ponekad ima smisla koristiti i jedno i drugo u okviru istog sistema.Na primjer, imamo sisteme u kojima su neki od podataka u suštini keš vitrine, odnosno izvor ažuriranja se nalazi iza samog sistema, a sistemi se ne mijenjaju. ove podatke. Za ovaj pristup koristimo lokalni Cache Cache.
I postoje podaci da se sistem aktivno mijenja tokom rada, a ovdje već koristimo distribuirani keš sa Hazelcastom. Ovaj pristup nam omogućava da koristimo prednosti distribuirane keš memorije tamo gdje su one zaista potrebne i minimiziramo troškove usluge kruženja podataka Hazelcast klastera gdje možemo bez njih. Puno smo pisali o kešovima. и .
Osim toga, promjena serijalizera u Kryo u Hazelcastu dala nam je dobar poticaj. A prijelaz sa ReplicatedMap na IMAp + Near Cache u Hazelcastu nam je omogućio da minimiziramo kretanje podataka kroz klaster.
Mali savjet: u slučaju masovnog poništenja keša, ponekad je primjenjiva taktika zagrijavanja druge keš memorije, a zatim prelaska na nju. Čini se da bi ovakvim pristupom trebalo da dobijemo duplu potrošnju memorije, ali u praksi, u onim sistemima gde je to praktikovano, potrošnja memorije je smanjena.
Reaktivni stek
Reaktivni stek koristimo u prilično velikom broju sistema. U našem slučaju, ovo je Webflux ili Kotlin sa korutinama. Reaktivni stek je posebno dobar tamo gdje očekujemo spore ulazno-izlazne operacije. Na primjer, pozivi na spore usluge, rad sa sistemom datoteka ili sistemima za skladištenje.
Najvažniji princip je izbjegavanje blokiranja poziva. Reaktivni okviri imaju mali broj živih servisnih niti koje rade ispod haube. Ako nemarno dozvolimo sebi da izvršimo direktan blokirajući poziv, kao što je poziv JDBC drajvera, sistem će se jednostavno zaustaviti.
Pokušajte pretvoriti greške u vlastiti izuzetak vremena izvođenja. Stvarni tok izvršavanja programa prelazi na reaktivne okvire, a izvršavanje koda postaje nelinearno. Kao rezultat toga, vrlo je teško dijagnosticirati probleme pomoću praćenja steka. A rješenje bi ovdje bilo kreiranje jasnih, objektivnih izuzetaka vremena izvršavanja za svaku grešku.
Elasticsearch
Kada koristite Elasticsearch, nemojte birati neiskorištene podatke. Ovo je, u principu, i vrlo jednostavan savjet, ali najčešće se to zaboravlja. Ako trebate odabrati više od 10 hiljada zapisa odjednom, trebate koristiti Scroll. Da koristimo analogiju, to je pomalo kao kursor u relacijskoj bazi podataka.
Nemojte koristiti postfilter osim ako je potrebno. S velikim podacima u glavnom uzorku, ova operacija uvelike učitava bazu podataka.
Koristite masovne operacije gdje je to primjenjivo.
API
Kada dizajnirate API, uključite zahtjeve za minimiziranje prenesenih podataka. Ovo se posebno odnosi na prednji dio: upravo na ovoj raskrsnici izlazimo izvan kanala naših podatkovnih centara i već radimo na kanalu koji nas povezuje s klijentom. Ako ima i najmanji problem, previše prometa uzrokuje negativno korisničko iskustvo.
I na kraju, nemojte izbacivati gomilu podataka, budite jasni u vezi ugovora između potrošača i dobavljača.
Organizaciona transformacija
Eroshkina Elena, zamjenik direktora za IT
U trenutku kada je nastupila karantena, a ukazala se potreba za naglim povećanjem tempa online razvoja i uvođenjem omnichannel usluga, već smo bili u procesu organizacijske transformacije.
Dio naše strukture prebačen je na rad po principima i praksi proizvodnog pristupa. Formirani su timovi koji su sada odgovorni za rad i razvoj svakog proizvoda. Zaposlenici u takvim timovima su 100% uključeni i strukturiraju svoj rad koristeći Scrum ili Kanban, ovisno o tome što im je bolje, postavljanje cevovoda za implementaciju, implementaciju tehničkih praksi, prakse osiguranja kvaliteta i još mnogo toga.
Srećom, najveći dio naših proizvodnih timova bio je u području online i omnichannel usluga. To nam je omogućilo da u najkraćem mogućem roku (ozbiljno, bukvalno za dva dana) pređemo na daljinski rad bez gubitka efikasnosti. Prilagođeni proces nam je omogućio da se brzo prilagodimo novim uslovima rada i zadržimo prilično visok tempo isporuke nove funkcionalnosti.
Osim toga, imamo potrebu da ojačamo one timove koji su na granici online poslovanja. U tom trenutku je postalo jasno da to možemo učiniti samo koristeći interne resurse. A oko 50 ljudi u dvije sedmice promijenilo je područje u kojem su ranije radili i uključilo se u rad na proizvodu koji je za njih bio nov.
To nije zahtijevalo posebne napore menadžmenta, jer uz organizaciju vlastitog procesa, tehničko unapređenje proizvoda i prakse osiguranja kvaliteta, učimo naše timove da se samoorganiziraju – da upravljaju vlastitim proizvodnim procesom bez uključivanja administrativnih resursa.
Uspjeli smo usmjeriti naše upravljačke resurse upravo tamo gdje je to bilo potrebno u tom trenutku - na koordinaciju zajedno s poslovanjem: šta je trenutno važno za našeg klijenta, koju funkcionalnost prvo treba implementirati, šta treba učiniti da povećamo našu propusnu sposobnost za isporuku i obradu narudžbi. Sve to i jasan uzor omogućili su da u ovom periodu naše proizvodne tokove vrijednosti napunimo onim što je zaista važno i potrebno.
Jasno je da se uz rad na daljinu i veliki tempo promjena, kada pokazatelji poslovanja zavise od svačijeg učešća, ne možete osloniti samo na unutrašnje osjećaje iz serije „Je li kod nas sve dobro? Da, izgleda dobro." Potrebna je objektivna metrika proizvodnog procesa. Imamo ih, dostupni su svima koji su zainteresirani za metriku proizvodnih timova. Prije svega sam tim, biznis, podizvođači i menadžment.
Jednom u dvije sedmice održava se status sa svakim timom, gdje se metrika analizira 10 minuta, identifikuju uska grla u proizvodnom procesu i razvija se zajedničko rješenje: šta se može učiniti da se ta uska grla otklone. Ovdje možete odmah zatražiti pomoć od menadžmenta ako je bilo koji identificirani problem izvan zone utjecaja timova, odnosno stručnosti kolega koji su se možda već susreli sa sličnim problemom.
Međutim, shvaćamo da da bismo višestruko ubrzali (a to je upravo cilj koji smo sebi postavili), još uvijek moramo puno naučiti i implementirati u svakodnevnom radu. Upravo sada nastavljamo s skaliranjem našeg pristupa proizvoda drugim timovima i novim proizvodima. Da bismo to učinili, morali smo savladati novi format za nas - online školu metodičara.
Metodolozi, ljudi koji pomažu timovima da izgrade proces, uspostave komunikaciju i poboljšaju radnu efikasnost, u suštini su pokretači promjena. Upravo sada maturanti naše prve kohorte rade s timovima i pomažu im da postanu uspješni.
Mislim da nam trenutna situacija otvara mogućnosti i izglede kojih možda ni sami nismo u potpunosti svjesni. Ali iskustvo i praksa koje sada stječemo potvrđuje da smo odabrali pravi put razvoja, da nećemo propustiti ove nove prilike u budućnosti i da ćemo moći jednako efikasno odgovoriti na izazove sa kojima će se Sportmaster suočiti.
nalazi
U ovom teškom vremenu formulisali smo glavne principe na kojima počiva razvoj softvera, koji će, mislim, biti relevantni za svaku kompaniju koja se ovim bavi.
ljudi. To je ono na čemu sve počiva. Zaposleni moraju uživati u svom poslu i razumjeti ciljeve kompanije i ciljeve proizvoda na kojima rade. I, naravno, mogli bi se profesionalno razvijati.
tehnologija. Neophodno je da kompanija zauzme zreo pristup radu sa svojim tehnološkim stekom i izgradi kompetencije tamo gde je to zaista potrebno. Zvuči vrlo jednostavno i očigledno. I vrlo često ignorisani.
Procesi. Važno je pravilno organizovati rad proizvodnih timova i centara kompetencija, uspostaviti interakciju sa biznisom kako bi sa njim radili kao partner.
Uglavnom, tako smo preživjeli. Glavna teza našeg vremena još jednom je potvrđena, zvučnim škljocanjem na čelu
Čak i ako ste veliki oflajn biznis sa mnogo prodavnica i gomilom gradova u kojima poslujete, razvijajte svoje onlajn poslovanje. Ovo nije samo dodatni kanal prodaje ili lijepa aplikacija preko koje možete nešto i kupiti (a i zato što konkurenti imaju i lijepe). Ovo nije rezervna guma za svaki slučaj koja će vam pomoći da prebrodite oluju.
Ovo je apsolutna potreba. Za koje moraju biti pripremljene ne samo vaše tehničke mogućnosti i infrastruktura, već i vaši ljudi i procesi. Na kraju krajeva, možete brzo kupiti dodatnu memoriju, prostor, implementirati nove instance, itd. za nekoliko sati. Ali ljudi i procesi moraju biti pripremljeni za to unaprijed.
izvor: www.habr.com