Hallo!
Myn namme is Mikhail, ik bin de plakferfangend direkteur fan IT by it bedriuw Sportmaster. Ik wol it ferhaal diele oer hoe't wy omgeane mei de útdagings dy't ûntstienen tidens de pandemy.
Yn 'e earste dagen fan' e nije realiteiten beferzen it gewoane offline hannelsformaat fan Sportmaster, en de lading op ús online kanaal, benammen yn termen fan levering oan it adres fan 'e klant, ferhege 10 kear. Yn mar in pear wiken hawwe wy in gigantysk offline bedriuw omfoarme ta in online en de tsjinst oanpast oan 'e behoeften fan ús kliïnten.
Yn prinsipe, wat wie yn wêzen ús kant operaasje waard ús kearnbedriuw. It belang fan elke online bestelling is ekstreem tanommen. It wie nedich om elke roebel te bewarjen dy't de klant nei it bedriuw brocht.
Om fluch te reagearjen op oanfragen fan klanten, iepene wy in ekstra kontaktsintrum op it haadkantoar fan it bedriuw, en kinne no sawat 285 tûzen oproppen per wike ûntfange. Tagelyk hawwe wy 270 winkels ferpleatst nei in nij kontaktleas en feilich bedriuwsformaat, wêrtroch klanten opdrachten en meiwurkers kinne ûntfange om har wurk te behâlden.
Tidens it transformaasjeproses tsjinkamen wy twa haadproblemen. As earste is de lading op ús online boarnen gâns tanommen (Sergey sil jo fertelle hoe't wy dit dogge). Twads is de stream fan seldsume (pre-COVID) operaasjes in protte kearen tanommen, wat op syn beurt in grutte hoemannichte rappe automatisearring fereaske. Om dit probleem op te lossen, moasten wy boarnen fluch oerdrage fan gebieten dy't earder de wichtichste wiene. Elena sil jo fertelle hoe't wy hjirmei omgien binne.
Operaasje fan online tsjinsten
Kolesnikov Sergey, ferantwurdlik foar de eksploitaasje fan de online winkel en microservices
Fanôf it momint dat ús retailwinkels begon te sluten foar besikers, begon wy in ferheging fan metriken op te nimmen, lykas it oantal brûkers, it oantal oarders pleatst yn ús applikaasje, en it oantal oanfragen foar applikaasjes.
Oantal oarders fan 18 maart oant 31 maartOantal oanfragen foar online betellingsmikrotsjinstenOantal oarders pleatst op de webside
Yn 'e earste grafyk sjogge wy dat de ferheging sawat 14 kear wie, yn' e twadde - 4 kear. Wy beskôgje de antwurdtiidmetriek fan ús applikaasjes as de meast yndikatyf.
Yn dizze grafyk sjogge wy it antwurd fan fronten en applikaasjes, en foar ússels hawwe wy bepaald dat wy gjin groei as sadanich opmurken hawwe.
Dat komt benammen troch it feit dat wy ein 2019 mei it tariedend wurk begûn binne. No binne ús tsjinsten reservearre, fouttolerânsje wurdt garandearre op it nivo fan fysike servers, virtualisaasjesystemen, dockers en tsjinsten dêryn. Tagelyk lit de kapasiteit fan ús serverboarnen ús meardere loads ferneare.
It wichtichste ark dat ús holp yn dit hiele ferhaal wie ús tafersjochsysteem. Wier, oant frij resint hienen wy gjin inkeld systeem dat ús mooglik makket om metriken op alle lagen te sammeljen, fan it nivo fan fysike apparatuer en hardware oant it nivo fan saaklike metriken.
Formeel wie der tafersjoch yn it bedriuw, mar as regel wie it ferspraat en wie op it mêd fan ferantwurdlikens fan spesifike ôfdielingen. Yn feite, doe't in ynsidint barde, wy hast nea hie in mienskiplik begryp fan wat der krekt barde, der wie gjin kommunikaasje, en faaks dit late ta it rinnen yn sirkels te finen en isolearje it probleem sadat it koe wurde reparearre.
Op in stuit tochten en besletten wy dat wy genôch hiene om dit te fernearen - wy hienen in unifoarm systeem nedich om it heule byld yn folslein te sjen. De wichtichste technologyen dy't opnommen binne yn ús stapel binne Zabbix as in warskôgings- en metriken-opslachsintrum, Prometheus foar it sammeljen en opslaan fan applikaasjemetriken, Stack ELK foar it loggen en opslaan fan gegevens fan it heule monitorsysteem, lykas Grafana foar fisualisaasje, Swagger, Docker en oare nuttich en dingen dy't jo bekend binne.
Tagelyk brûke wy net allinich technologyen dy't op 'e merke beskikber binne, mar ûntwikkelje ek guon fan ús. Wy meitsje bygelyks tsjinsten foar it yntegrearjen fan systemen mei elkoar, dat is in soarte fan API foar it sammeljen fan metriken. Plus wy wurkje oan ús eigen tafersjochsystemen - op it nivo fan saaklike metriken brûke wy UI-tests. En ek in bot yn Telegram om teams te melden.
Wy besykje ek it tafersjochsysteem tagonklik te meitsjen foar teams, sadat se selsstannich har metriken kinne opslaan en wurkje, ynklusyf it ynstellen fan warskôgings foar guon smelle metriken dy't net in soad brûkt wurde.
Yn it hiele systeem stribje wy nei proaktiviteit en lokalisaasje fan ynsidinten sa gau mooglik. Derneist is it oantal fan ús mikrotsjinsten en systemen de lêste tiid signifikant tanommen, en it oantal yntegraasjes is dêrmei groeid. En as ûnderdiel fan it optimalisearjen fan it proses fan diagnoaze fan ynsidinten op yntegraasjenivo, ûntwikkelje wy in systeem wêrmei jo cross-systeemkontrôles kinne útfiere en it resultaat sjen litte, wêrtroch jo de wichtichste problemen kinne fine yn ferbân mei ymport en ynteraksje fan systemen mei elkoar.
Fansels hawwe wy noch romte om te groeien en te ûntwikkeljen op it mêd fan bestjoeringssystemen, en wy wurkje hjir aktyf oan. Jo kinne mear lêze oer ús tafersjochsysteem .
Technyske tests
Orlov Sergey, haad fan it kompetinsjesintrum foar web- en mobile ûntwikkeling
Sûnt de sluten fan 'e fysike winkel begon, hawwe wy ferskate útdagings te krijen út in ûntwikkelingsperspektyf. Earst fan alles, de lading surge as sadanich. It is dúdlik dat as der gjin passende maatregels wurde nommen, as in hege lading wurdt tapast op it systeem, kin it feroarje yn in pompoen mei in tryste klap, of folslein degradearje yn prestaasjes, of sels syn funksjonaliteit ferlieze.
It twadde aspekt, in bytsje minder fanselssprekkend, is dat it systeem ûnder hege load tige fluch feroare wurde moast, oanpasse oan feroaringen yn bedriuwsprosessen. Soms ferskate kearen deis. In protte bedriuwen hawwe in regel dat as d'r in protte marketingaktiviteit is, d'r gjin ferlet is om feroaringen oan it systeem te meitsjen. Hielendal gjinien, lit it wurkje sa lang as it wurket.
En wy hienen yn wêzen in einleaze Black Friday, wêryn't it nedich wie om it systeem te feroarjen. En elke flater, probleem of mislearring yn it systeem soe heul kostber wêze foar it bedriuw.
Foarútsjen sil ik sizze dat wy dizze tests slaggen om te gean, alle systemen stiene de lading, wiene maklik skaalber, en wy hawwe gjin globale technyske flaters ûnderfûn.
D'r binne fjouwer pylders wêrop it fermogen fan it systeem om hege surge loads te wjerstean. De earste fan har is tafersjoch, dêr't jo krekt hjirboppe lêze. Sûnder in ynboud tafersjochsysteem is it hast ûnmooglik om systeemknelpunten te finen. In goed tafersjochsysteem is as thúsklean; it moat noflik en op jo maat wêze.
It twadde aspekt is testen. Wy nimme dit punt tige serieus: wy skriuwe klassike ienheden, yntegraasjetests, loadtests en in protte oaren foar elk systeem. Wy skriuwe ek in teststrategy, en besykje tagelyk it nivo fan testen te ferheegjen oant it punt dat wy gjin hânmjittige kontrôles mear nedich binne.
De tredde pylder is CI / CD Pipeline. De prosessen fan it bouwen, testen en ynsetten fan in applikaasje moatte safolle mooglik automatisearre wurde; d'r moat gjin hânmjittich yntervinsje wêze. It ûnderwerp fan CI / CD Pipeline is frij djip, en ik sil allinne oanreitsje it koart. It is allinnich de muoite wurdich opskriuwen dat wy hawwe in CI / CD Pipeline checklist, dêr't elk produkt team giet troch mei help fan kompetinsje sintra.
En hjir is de checklist
Op dizze manier wurde in protte doelen berikt. Dit is API-ferzjeferzje en funksje-skeakel om de releasetrein te foarkommen, en it berikken fan dekking fan ferskate tests op sa'n nivo dat testen folslein automatisearre is, ynset binne naadloos, ensfh.
De fjirde pylder is arsjitektoanyske prinsipes en technyske oplossingen. Wy kinne lang in protte oer arsjitektuer prate, mar ik wol in pear begjinsels beklamje dêr't ik my graach op rjochtsje soe.
Earst moatte jo spesjalisearre ark kieze foar spesifike taken. Ja, it klinkt fanselssprekkend, en it is dúdlik dat spikers moatte wurde dreaun yn mei in hammer, en polshorloazjes moatte wurde demonteare mei spesjale schroevendraaiers. Mar yn ús tiid stribje in protte ark nei universalisaasje om it maksimale segmint fan brûkers te dekken: databases, caches, kaders en de rest. As jo bygelyks de MongoDB-database nimme, wurket it mei transaksjes mei meardere dokuminten, en de Oracle-database wurket mei json. En it liket derop dat alles foar alles brûkt wurde kin. Mar as wy foar produktiviteit steane, dan moatte wy de sterke en swakke punten fan elk ark dúdlik begripe en dejingen brûke dy't wy nedich binne foar ús klasse fan taken.
Twads, by it ûntwerpen fan systemen, moat elke tanimming fan kompleksiteit wurde rjochtfeardige. Wy moatte dit hieltyd yn 'e rekken hâlde, it prinsipe fan lege koppeling is elkenien bekend. Ik leau dat it tapast wurde moat op it nivo fan in spesifike tsjinst, en op it nivo fan it hiele systeem, en op it nivo fan it arsjitektoanyske lânskip. De mooglikheid om elke systeemkomponint horizontaal te skaaljen lâns it loadpaad is ek wichtich. As jo dizze mooglikheid hawwe, sil skaalfergrutting net dreech wêze.
Sprekend oer technyske oplossingen, hawwe wy produktteams frege om in nije set oanbefellings, ideeën en oplossingen ta te rieden, dy't se ymplementeare as tarieding op 'e folgjende weach fan wurkdruk.
Keshi
It is needsaaklik om bewust te benaderjen de kar fan lokale en ferspraat caches. Soms is it logysk om beide binnen itselde systeem te brûken. Wy hawwe bygelyks systemen wêryn guon fan 'e gegevens yn essinsje in showcase-cache binne, dat is, de boarne fan updates leit efter it systeem sels, en de systemen feroarje net. dizze gegevens. Foar dizze oanpak brûke wy lokale kafee-cache.
En d'r binne gegevens dy't it systeem aktyf feroaret tidens operaasje, en hjir brûke wy al in ferspraat cache mei Hazelcast. Dizze oanpak lit ús de foardielen fan in ferspraat cache brûke wêr't se echt nedich binne, en minimalisearje de tsjinstkosten fan sirkulearjen fan Hazelcast-klustergegevens wêr't wy sûnder kinne dwaan. Wy hawwe in protte oer caches skreaun. и .
Derneist joech it feroarjen fan de serializer nei Kryo yn Hazelcast ús in goede ympuls. En de oergong fan ReplicatedMap nei IMap + Near Cache yn Hazelcast liet ús de beweging fan gegevens oer it kluster minimalisearje.
In lyts advys: yn gefal fan ûnjildichheid fan massa-cache is de taktyk om de twadde cache op te waarmjen en dêrnei oer te skeakeljen soms fan tapassing. It soe lykje dat wy mei dizze oanpak dûbeld ûnthâld konsumpsje moatte krije, mar yn 'e praktyk, yn dy systemen dêr't dit waard oefene, ûnthâld konsumpsje ôfnommen.
Reaktive stack
Wy brûke de reaktive stack yn nochal in grut oantal systemen. Yn ús gefal is dit Webflux of Kotlin mei coroutines. De reaktive stapel is benammen goed wêr't wy trage ynput-útfier operaasjes ferwachtsje. Bygelyks oproppen nei trage tsjinsten, wurkje mei it bestânsysteem of opslachsystemen.
It wichtichste prinsipe is om petearen te blokkearjen. Reaktive kaders hawwe in lyts oantal live tsjinst threads dy't ûnder de kap rinne. As wy ússels sûnder soarch tastean om in direkte blokkearjende oprop te meitsjen, lykas in JDBC-bestjoerderoprop, sil it systeem gewoan stilhâlde.
Besykje flaters te feroarjen yn jo eigen runtime-útsûndering. De eigentlike stream fan programma-útfiering feroaret nei reaktive kaders, en koade-útfiering wurdt net-lineêr. As gefolch is it heul lestich om problemen te diagnostearjen mei stacksporen. En de oplossing hjir soe wêze om dúdlike, objektive runtime-útsûnderings te meitsjen foar elke flater.
Elastyskesearch
Selektearje net brûkte gegevens as jo Elasticsearch brûke. Dit is yn prinsipe ek hiel ienfâldich advys, mar meastentiids is dit wat fergetten wurdt. As jo mear as 10 tûzen records tagelyk moatte selektearje, moatte jo Scroll brûke. Om in analogy te brûken, is it in bytsje as in rinnerke yn in relasjonele databank.
Brûk gjin postfilter as it net nedich is. Mei grutte gegevens yn 'e haadprobe, laadt dizze operaasje de databank sterk.
Brûk bulk operaasjes wêr fan tapassing.
API
By it ûntwerpen fan in API, befetsje easken foar it minimalisearjen fan oerdroegen gegevens. Dit is benammen wier yn ferbân mei de foarkant: it is op dit knooppunt dat wy fierder gean as de kanalen fan ús datasintra en wurkje al oan it kanaal dat ús ferbine mei de klant. As it it minste probleem hat, feroarsaket te folle ferkear in negative brûkersûnderfining.
En as lêste, smyt net in hiele boskje gegevens út, wês dúdlik oer it kontrakt tusken konsuminten en leveransiers.
Organisatoaryske transformaasje
Eroshkina Elena, plakferfangend direkteur foar IT
Op it momint dat karantine barde, en de need ûntstie om it tempo fan online ûntwikkeling skerp te ferheegjen en omnichannel-tsjinsten yn te fieren, wiene wy al yn it proses fan organisatoaryske transformaasje.
In diel fan ús struktuer waard oerdroegen oan it wurk neffens de prinsipes en praktiken fan 'e produktoanpak. Teams binne foarme dy't no ferantwurdlik binne foar de eksploitaasje en ûntwikkeling fan elk produkt. Meiwurkers yn sokke teams binne 100% belutsen en strukturearje har wurk mei Scrum of Kanban, ôfhinklik fan wat har de foarkar is, it opsetten fan in ynsetpipeline, it ymplementearjen fan technyske praktiken, kwaliteitssoarchpraktiken, en folle mear.
Mei gelok wie it grutste part fan ús produktteams op it mêd fan online en omnichannel tsjinsten. Dit liet ús yn 'e koartst mooglike tiid oerskeakelje nei wurk op ôfstân (serieus, letterlik yn twa dagen) sûnder ferlies fan effisjinsje. It oanpaste proses koe ús fluch oanpasse oan nije arbeidsomstannichheden en in frij heech tempo fan levering fan nije funksjonaliteit behâlde.
Derneist hawwe wy behoefte om dy teams te fersterkjen dy't op 'e grins binne fan online bedriuw. Op dat stuit waard dúdlik dat wy dat allinnich mei ynterne middels dwaan koene. En sa'n 50 minsken yn twa wiken feroare it gebiet dêr't se earder wurken en belutsen by it wurkjen oan in produkt dat nij wie foar har.
Dit hat gjin spesjale managementynspanningen nedich, om't tegearre mei it organisearjen fan ús eigen proses, technyske ferbettering fan it produkt, en kwaliteitsfersekeringpraktiken, leare wy ús teams om sels te organisearjen - om har eigen produksjeproses te behearjen sûnder bestjoerlike boarnen te belûken.
Wy koene ús behearsboarnen krekt rjochtsje wêr't it op dat stuit nedich wie - op koördinearjen tegearre mei it bedriuw: wat is op dit stuit wichtich foar ús klant, hokker funksjonaliteit moat earst ymplementearre wurde, wat moat dien wurde om ús trochsetfermogen te fergrutsjen om bestellingen te leverjen en te ferwurkjen. Dit alles en in dúdlik rolmodel makken it yn dizze perioade mooglik om ús produksjeweardestreamen te laden mei wat echt wichtich en needsaaklik is.
It is dúdlik dat mei wurk op ôfstân en in heech tempo fan feroaring, as saaklike yndikatoaren ôfhinklik binne fan elk syn dielname, jo net allinich kinne fertrouwe op ynterne gefoelens fan 'e searje "Giet alles goed mei ús? Ja, it liket goed." Objektive metriken fan it produksjeproses binne nedich. Wy hawwe dizze, se binne beskikber foar elkenien dy't ynteressearre is yn 'e metriken fan produktteams. Earst fan alles, it team sels, it bedriuw, subcontractors en management.
Ien kear yn de twa wiken wurdt mei elk team in status hâlden, wêrby't metriken 10 minuten analysearre wurde, knelpunten yn it produksjeproses wurde identifisearre en in mienskiplike oplossing ûntwikkele: wat kin dien wurde om dizze knelpunten te eliminearjen. Hjir kinne jo fuortendaliks freegje om help fan it management as in identifisearre probleem is bûten de sône fan ynfloed fan de teams, of de ekspertize fan kollega's dy't mooglik al tsjinkaam in ferlykber probleem.
Wy begripe lykwols dat om meardere kearen te fersnellen (en dit is krekt it doel dat wy foar ússels sette), wy noch in protte moatte leare en it yn ús deistich wurk útfiere. Op it stuit geane wy troch mei it skaaljen fan ús produktoanpak nei oare teams en nije produkten. Om dit te dwaan, moasten wy in nij formaat foar ús behearskje - in online skoalle fan metodologen.
Metodologen, minsken dy't teams helpe om in proses op te bouwen, kommunikaasje te fêstigjen en wurkeffektiviteit te ferbetterjen, binne yn essinsje aginten fan feroaring. Op it stuit wurkje ôfstudearden fan ús earste kohort mei teams en helpe se suksesfol te wurden.
Ik tink dat de hjoeddeistige situaasje kânsen en perspektyf foar ús iepenet dêr't wy miskien sels noch net folslein fan bewust binne. Mar de ûnderfining en praktyk dy't wy no ophelje, befêstigje dat wy it goede paad fan ûntwikkeling keazen hawwe, wy sille dizze nije kânsen yn 'e takomst net misse en sille like effektyf reagearje kinne op de útdagings dy't Sportmaster sil tsjinkomme.
befinings
Yn dizze drege tiid hawwe wy de haadprinsipes formulearre dêr't softwareûntwikkeling op rêst, dy't, tink ik, relevant wêze sil foar elk bedriuw dat dit dwaande hâldt.
minsken. Dit is wêr't alles op rêst. Meiwurkers moatte genietsje fan har wurk en begripe de doelen fan it bedriuw en de doelen fan 'e produkten dêr't se oan wurkje. En fansels kinne se profesjoneel ûntwikkelje.
Technology. It is needsaaklik foar it bedriuw om in folwoeksen oanpak te nimmen om te wurkjen mei syn technologystapel en kompetinsjes op te bouwen wêr't it echt nedich is. It klinkt hiel ienfâldich en fanselssprekkend. En hiel faak negearre.
Prozessen. It is wichtich om it wurk fan produktteams en kompetinsjesintra goed te organisearjen, ynteraksje mei it bedriuw te fêstigjen om dermei te wurkjen as partner.
Yn it algemien, dat is sa'n bytsje hoe't wy oerlibbe. De haadproef fan ús tiid waard nochris befêstige, mei in klinkende klik op 'e foarholle
Sels as jo in enoarm offline bedriuw binne mei in protte winkels en in boskje stêden wêr't jo operearje, ûntwikkelje jo online bedriuw. Dit is net allinich in ekstra ferkeapkanaal of in prachtige applikaasje wêrmei jo ek wat keapje kinne (en ek om't konkurrinten ek moaie hawwe). Dit is net in just-in-case reservebân om jo te helpen de stoarm troch te gean.
Dit is in absolute needsaak. Dêrfoar moatte net allinich jo technyske mooglikheden en ynfrastruktuer taret wurde, mar ek jo minsken en prosessen. Jo kinne ommers yn in pear oeren fluch ekstra ûnthâld, romte keapje, nije eksimplaren, ensfh. Mar minsken en prosessen moatte dêr fan tefoaren op taret wurde.
Boarne: www.habr.com