Det som hjalp oss raskt å tilpasse oss netthandel under de nye forholdene

Hei!

Mitt navn er Mikhail, jeg er assisterende direktør for IT i Sportmaster-selskapet. Jeg vil dele historien om hvordan vi taklet utfordringene som oppsto under pandemien.

I de første dagene av de nye virkelighetene frøs det vanlige offline-handelsformatet til Sportmaster, og belastningen på nettkanalen vår, først og fremst når det gjelder levering til kundens adresse, økte 10 ganger. På bare noen få uker forvandlet vi en gigantisk offline virksomhet til en online og tilpasset tjenesten til kundenes behov.

I utgangspunktet ble det som i hovedsak var vår sidedrift vår kjernevirksomhet. Betydningen av hver nettbestilling har økt ekstremt. Det var nødvendig å spare hver rubel som klienten brakte til selskapet. 

For raskt å svare på kundeforespørsler åpnet vi et ekstra kontaktsenter på selskapets hovedkontor, og kan nå motta ca. 285 tusen oppringninger per uke. Samtidig flyttet vi 270 butikker til et nytt kontaktløst og trygt driftsformat, som gjorde det mulig for kunder å motta bestillinger og ansatte for å opprettholde jobbene sine.

Under transformasjonsprosessen møtte vi to hovedproblemer. For det første har belastningen på våre nettressurser økt betydelig (Sergey vil fortelle deg hvordan vi taklet dette). For det andre har strømmen av sjeldne (pre-COVID) operasjoner økt mange ganger, noe som igjen krevde en stor mengde rask automatisering. For å løse dette problemet måtte vi raskt overføre ressurser fra områder som tidligere var de viktigste. Elena vil fortelle deg hvordan vi taklet dette.

Drift av nettjenester

Kolesnikov Sergey, ansvarlig for driften av nettbutikken og mikrotjenester

Fra det øyeblikket butikkene våre begynte å nærme seg besøkende, begynte vi å registrere en økning i beregninger som antall brukere, antall bestillinger i applikasjonen vår og antall forespørsler til applikasjoner. 

Antall bestillinger fra 18. mars til 31. marsAntall forespørsler til nettbaserte betalingsmikrotjenesterAntall bestillinger plassert på nettsiden

I den første grafen ser vi at økningen var omtrent 14 ganger, i den andre - 4 ganger. Vi anser responstiden for søknadene våre som den mest veiledende. 

I denne grafen ser vi responsen fra fronter og applikasjoner, og for oss selv bestemte vi at vi ikke merket noen vekst som sådan.

Dette skyldes først og fremst at vi startet forberedende arbeid i slutten av 2019. Nå er tjenestene våre reservert, feiltoleranse er sikret på nivå med fysiske servere, virtualiseringssystemer, dockere og tjenester i dem. Samtidig lar kapasiteten til serverressursene våre oss tåle flere belastninger.

Hovedverktøyet som hjalp oss i hele denne historien var vårt overvåkingssystem. Riktignok hadde vi inntil ganske nylig ikke et enkelt system som ville tillate oss å samle inn beregninger på alle lag, fra nivået av fysisk utstyr og maskinvare til nivået av forretningsberegninger. 

Formelt var det overvåking i selskapet, men som regel var det spredt og var innenfor ansvarsområdet til spesifikke avdelinger. Faktisk, når en hendelse inntraff, hadde vi nesten aldri en felles forståelse av hva som skjedde, det var ingen kommunikasjon, og ofte førte dette til at vi løp i sirkler for å finne og isolere problemet slik at det kunne fikses.

På et tidspunkt tenkte og bestemte vi oss for at vi hadde nok av å tåle dette – vi trengte et enhetlig system for å se hele bildet i sin helhet. Hovedteknologiene som er inkludert i stabelen vår er Zabbix som et varslings- og metrikklagringssenter, Prometheus for innsamling og lagring av applikasjonsberegninger, Stack ELK for logging og lagring av data fra hele overvåkingssystemet, samt Grafana for visualisering, Swagger, Docker og andre nyttige og ting som er kjent for deg.

Samtidig bruker vi ikke bare teknologier som er tilgjengelige på markedet, men utvikler også noen av våre egne. For eksempel lager vi tjenester for å integrere systemer med hverandre, det vil si en slags API for innsamling av beregninger. I tillegg jobber vi med våre egne overvåkingssystemer - på nivået av forretningsmålinger bruker vi UI-tester. Og også en bot i Telegram for å varsle team.

Vi prøver også å gjøre overvåkingssystemet tilgjengelig for team slik at de uavhengig kan lagre og jobbe med sine beregninger, inkludert å sette opp varsler for noen smale beregninger som ikke er mye brukt. 

Gjennom hele systemet tilstreber vi proaktivitet og lokalisering av hendelser så raskt som mulig. I tillegg har antallet av våre mikrotjenester og systemer vokst betydelig den siste tiden, og antallet integrasjoner har tilsvarende vokst. Og som en del av å optimalisere prosessen med å diagnostisere hendelser på integrasjonsnivå, utvikler vi et system som lar deg gjennomføre tverrsystemkontroller og vise resultatet, som lar deg finne hovedproblemene knyttet til import og samhandling av systemer med hverandre. 

Vi har selvsagt fortsatt rom for å vokse og utvikle oss når det gjelder operativsystemer, og dette jobber vi aktivt med. Du kan lese mer om vårt overvåkingssystem her. 

Tekniske tester 

Orlov Sergey, leder kompetansesenteret for web- og mobilutvikling

Siden de fysiske butikknedleggelsene startet, har vi møtt ulike utfordringer i et utviklingsperspektiv. Først av alt, lastøkningen som sådan. Det er klart at hvis det ikke tas hensiktsmessige tiltak, så når en høy belastning påføres systemet, kan det bli til et gresskar med et trist smell, eller fullstendig forringe ytelsen, eller til og med miste funksjonaliteten.

Det andre aspektet, litt mindre åpenbart, er at systemet under høy belastning måtte endres veldig raskt, tilpasset endringer i forretningsprosesser. Noen ganger flere ganger om dagen. Mange bedrifter har en regel om at dersom det er mye markedsføringsaktivitet, er det ikke nødvendig å gjøre noen endringer i systemet. Ingen i det hele tatt, la det virke så lenge det fungerer.

Og vi hadde egentlig en endeløs Black Friday, der det var nødvendig å endre systemet. Og enhver feil, problem eller feil i systemet vil være svært kostbart for virksomheten.

Når vi ser fremover, vil jeg si at vi klarte å takle disse testene, alle systemene tålte belastningen, ble lett skalert, og vi opplevde ingen globale tekniske feil.

Det er fire pilarer som systemets evne til å motstå høye overspenningsbelastninger hviler på. Den første av dem er overvåking, som du leste om rett ovenfor. Uten et innebygd overvåkingssystem er det nesten umulig å finne systemflaskehalser. Et godt overvåkingssystem er som hjemmeklær; det skal være komfortabelt og skreddersydd for deg.

Det andre aspektet er testing. Vi tar dette punktet veldig seriøst: vi skriver klassiske enheter, integrasjonstester, belastningstester og mange andre for hvert system. Vi skriver også en teststrategi, og prøver samtidig å øke testnivået til det punktet at vi ikke lenger trenger manuelle kontroller.

Den tredje søylen er CI/CD Pipeline. Prosessene for å bygge, teste og distribuere en applikasjon bør automatiseres så mye som mulig; det skal ikke være noen manuell intervensjon. Temaet CI/CD Pipeline er ganske dypt, og jeg skal bare berøre det kort. Det er bare verdt å nevne at vi har en CI/CD Pipeline-sjekkliste, som hvert produktteam går gjennom ved hjelp av kompetansesentre.

Og her er sjekklisten

På denne måten oppnås mange mål. Dette er API-versjons- og funksjonsveksling for å unngå utgivelsestoget, og oppnå dekning av ulike tester på et slikt nivå at testing er helautomatisert, utrullinger er sømløse, og så videre.

Den fjerde pilaren er arkitektoniske prinsipper og tekniske løsninger. Vi kan snakke mye om arkitektur lenge, men jeg vil fremheve et par prinsipper som jeg gjerne vil fokusere på.

Først må du velge spesialiserte verktøy for spesifikke oppgaver. Ja, det høres selvsagt ut, og det er klart at spiker skal slås inn med hammer, og armbåndsur skal demonteres med spesielle skrutrekkere. Men i vår tid streber mange verktøy etter universalisering for å dekke det maksimale segmentet av brukere: databaser, cacher, rammer og resten. Hvis du for eksempel tar MongoDB-databasen, fungerer den med transaksjoner med flere dokumenter, og Oracle-databasen fungerer med json. Og det ser ut til at alt kan brukes til alt. Men hvis vi står for produktivitet, må vi tydelig forstå styrkene og svakhetene til hvert verktøy og bruke de vi trenger for oppgaveklassen vår. 

For det andre, når man designer systemer, må hver økning i kompleksitet begrunnes. Dette må vi hele tiden ha i bakhodet, prinsippet om lavkobling er kjent for alle. Jeg mener at det bør brukes på nivået av en spesifikk tjeneste, og på nivået av hele systemet, og på nivået av det arkitektoniske landskapet. Evnen til å skalere hver systemkomponent horisontalt langs lastbanen er også viktig. Hvis du har denne evnen, vil skalering ikke være vanskelig.

Når vi snakker om tekniske løsninger, ba vi produktteam utarbeide et nytt sett med anbefalinger, ideer og løsninger, som de implementerte som forberedelse til neste bølge av arbeidsbelastning.

Keshi

Det er nødvendig å bevisst nærme seg valg av lokale og distribuerte cacher. Noen ganger er det fornuftig å bruke begge i samme system. For eksempel har vi systemer der noen av dataene i hovedsak er en utstillingscache, det vil si at kilden til oppdateringer ligger bak selve systemet, og systemene endres ikke. disse dataene. For denne tilnærmingen bruker vi lokal koffeinbuffer. 

Og det er data som systemet aktivt endrer under drift, og her bruker vi allerede en distribuert cache med Hazelcast. Denne tilnærmingen lar oss bruke fordelene med en distribuert cache der de virkelig trengs, og minimere servicekostnadene ved å sirkulere Hazelcast-klyngedata der vi kan klare oss uten dem. Vi har skrevet mye om cacher. her и her.

I tillegg ga endring av serializer til Kryo i Hazelcast oss et godt løft. Og overgangen fra ReplicatedMap til IMap + Near Cache i Hazelcast tillot oss å minimere bevegelsen av data over klyngen. 

Et lite råd: i tilfelle massebufferugyldiggjøring, er taktikken med å varme opp den andre cachen og deretter bytte til den noen ganger aktuelt. Det ser ut til at vi med denne tilnærmingen burde få dobbelt minneforbruk, men i praksis, i de systemene der dette ble praktisert, sank minneforbruket.

Reaktiv stabel

Vi bruker den reaktive stabelen i ganske mange systemer. I vårt tilfelle er dette Webflux eller Kotlin med koroutiner. Den reaktive stabelen er spesielt god der vi forventer langsomme input-output-operasjoner. For eksempel anrop til trege tjenester, arbeid med filsystemet eller lagringssystemer.

Det viktigste prinsippet er å unngå å blokkere samtaler. Reaktive rammeverk har et lite antall aktive servicetråder under panseret. Hvis vi uforsiktig tillater oss å foreta et direkte blokkerende anrop, for eksempel et JDBC-driveranrop, vil systemet ganske enkelt stoppe opp. 

Prøv å gjøre feil til ditt eget kjøretidsunntak. Den faktiske flyten av programkjøring skifter til reaktive rammer, og kodekjøring blir ikke-lineær. Som et resultat er det svært vanskelig å diagnostisere problemer ved å bruke stabelspor. Og løsningen her ville være å lage klare, objektive kjøretidsunntak for hver feil.

Elasticsearch

Når du bruker Elasticsearch, ikke velg ubrukte data. Dette er i prinsippet også et veldig enkelt råd, men som oftest er det dette som glemmes. Hvis du trenger å velge mer enn 10 tusen poster om gangen, må du bruke Scroll. For å bruke en analogi, er det litt som en markør i en relasjonsdatabase. 

Ikke bruk etterfilter med mindre det er nødvendig. Med store data i hovedutvalget, belaster denne operasjonen databasen kraftig. 

Bruk bulkoperasjoner der det er aktuelt.

API

Når du designer et API, må du inkludere krav for å minimere overførte data. Dette gjelder spesielt i forbindelse med fronten: Det er i dette krysset vi går utover kanalene til datasentrene våre og jobber allerede med kanalen som forbinder oss med klienten. Hvis den har det minste problem, forårsaker for mye trafikk en negativ brukeropplevelse.

Og til slutt, ikke kast ut en hel haug med data, vær tydelig om kontrakten mellom forbrukere og leverandører.

Organisatorisk transformasjon

Eroshkina Elena, assisterende direktør for IT

I øyeblikket da karantene skjedde, og behovet oppsto for å øke tempoet i nettutvikling og introdusere omnikanaltjenester, var vi allerede i ferd med organisatorisk transformasjon. 

En del av strukturen vår ble overført til å arbeide i henhold til prinsippene og praksisene for produkttilnærmingen. Det er dannet team som nå er ansvarlige for drift og utvikling av hvert produkt. Ansatte i slike team er 100 % involvert og strukturerer arbeidet sitt ved å bruke Scrum eller Kanban, avhengig av hva som er å foretrekke for dem, setter opp en distribusjonspipeline, implementerer teknisk praksis, kvalitetssikringspraksis og mye mer.

Tilfeldigvis var hoveddelen av produktteamene våre innen online- og omnikanaltjenester. Dette tillot oss å bytte til ekstern arbeidsmodus på kortest mulig tid (seriøst, bokstavelig talt på to dager) uten tap av effektivitet. Den skreddersydde prosessen gjorde at vi raskt kunne tilpasse oss nye arbeidsforhold og opprettholde et ganske høyt tempo for levering av ny funksjonalitet.

I tillegg har vi et behov for å styrke de teamene som er på grensen til netthandel. I det øyeblikket ble det klart at vi bare kunne gjøre dette med interne ressurser. Og rundt 50 personer på to uker endret området der de jobbet før og ble involvert i å jobbe med et produkt som var nytt for dem. 

Dette krevde ingen spesiell ledelsesinnsats, for sammen med organisering av vår egen prosess, teknisk forbedring av produktet og kvalitetssikringspraksis, lærer vi teamene våre å selvorganisere – å styre sin egen produksjonsprosess uten å involvere administrative ressurser.

Vi var i stand til å fokusere ledelsesressursene våre akkurat der det var nødvendig i det øyeblikket - på å koordinere sammen med virksomheten: Hva er viktig for vår klient akkurat nå, hvilken funksjonalitet bør implementeres først, hva må gjøres for å øke vår gjennomstrømningsevne å levere og behandle bestillinger. Alt dette og et tydelig forbilde gjorde det mulig i denne perioden å laste våre produksjonsverdistrømmer med det som virkelig er viktig og nødvendig. 

Det er klart at med eksternt arbeid og et høyt endringstempo, når forretningsindikatorer avhenger av alles deltakelse, kan du ikke bare stole på interne følelser fra serien "Går alt bra med oss? Ja, det virker bra." Objektive beregninger av produksjonsprosessen er nødvendig. Vi har disse, de er tilgjengelige for alle som er interessert i beregningene til produktteam. Først og fremst teamet selv, virksomheten, underleverandører og ledelsen.

En gang annenhver uke holdes det en status med hvert team, hvor målinger analyseres i 10 minutter, flaskehalser i produksjonsprosessen identifiseres og en felles løsning utvikles: hva kan gjøres for å eliminere disse flaskehalsene. Her kan du umiddelbart be om hjelp fra ledelsen dersom et identifisert problem er utenfor innflytelsessonen til teamene, eller ekspertisen til kolleger som kanskje allerede har vært borti et lignende problem.

Imidlertid forstår vi at for å akselerere flere ganger (og dette er akkurat målet vi har satt oss), må vi fortsatt lære mye og implementere det i vårt daglige arbeid. Akkurat nå fortsetter vi å skalere vår produkttilnærming til andre team og nye produkter. For å gjøre dette måtte vi mestre et nytt format for oss – en nettskole for metodologer.

Metodologer, folk som hjelper team med å bygge en prosess, etablere kommunikasjon og forbedre arbeidseffektiviteten, er i hovedsak endringsagenter. Akkurat nå jobber nyutdannede fra vår første kohort med team og hjelper dem med å lykkes. 

Jeg tror at dagens situasjon åpner for muligheter og utsikter for oss som vi kanskje ikke selv er helt klar over ennå. Men erfaringen og praksisen som vi får akkurat nå bekrefter at vi har valgt den rette utviklingsveien, vi vil ikke gå glipp av disse nye mulighetene i fremtiden og vil være i stand til å svare like effektivt på utfordringene som Sportmaster vil møte.

Funn

I denne vanskelige tiden har vi formulert hovedprinsippene for hvilken programvareutvikling hviler, som jeg tror vil være relevante for enhver bedrift som driver med dette.

Folk. Det er dette alt hviler på. Ansatte må trives i arbeidet og forstå bedriftens mål og målene for produktene de jobber med. Og selvfølgelig kunne de utvikle seg faglig. 

Технология. Det er nødvendig for selskapet å ha en moden tilnærming til å jobbe med sin teknologistabel og bygge kompetanse der det virkelig trengs. Det høres veldig enkelt og åpenbart ut. Og veldig ofte ignorert.

prosesser. Det er viktig å organisere arbeidet til produktteam og kompetansesentre på riktig måte, for å etablere samhandling med virksomheten for å kunne jobbe med den som partner.

Generelt er det omtrent slik vi overlevde. Vår tids hovedtese ble bekreftet nok en gang, med et rungende klikk i pannen

Selv om du er en stor frakoblet virksomhet med mange butikker og en haug med byer der du opererer, kan du utvikle din online virksomhet. Dette er ikke bare en ekstra salgskanal eller en vakker applikasjon der du også kan kjøpe noe (og også fordi konkurrenter også har vakre). Dette er ikke et just-in-case reservedekk for å hjelpe deg med stormen.

Dette er en absolutt nødvendighet. Som ikke bare dine tekniske evner og infrastruktur må være forberedt, men også dine folk og prosesser. Tross alt kan du raskt kjøpe ekstra minne, plass, distribuere nye forekomster osv. på et par timer. Men mennesker og prosesser må være forberedt på dette på forhånd.

Kilde: www.habr.com