Hi!
Mit navn er Mikhail, jeg er vicedirektør for IT hos Sportmaster-virksomheden. Jeg vil gerne dele historien om, hvordan vi håndterede de udfordringer, der opstod under pandemien.
I de første dage af de nye realiteter frøs det sædvanlige offline-handelsformat af Sportmaster, og belastningen på vores online-kanal, primært med hensyn til levering til kundens adresse, steg 10 gange. På få uger forvandlede vi en gigantisk offline forretning til en online og tilpassede servicen til vores kunders behov.
Grundlæggende blev det, der i bund og grund var vores sidedrift, vores kerneforretning. Betydningen af enhver online ordre er steget ekstremt. Det var nødvendigt at spare hver rubel, som kunden bragte til virksomheden.
For hurtigt at kunne reagere på kundeønsker åbnede vi et ekstra kontaktcenter på virksomhedens hovedkontor og kan nu modtage omkring 285 tusinde opkald om ugen. Samtidig flyttede vi 270 butikker til et nyt kontaktløst og sikkert driftsformat, som gjorde det muligt for kunderne at modtage ordrer og medarbejdere til at fastholde deres job.
Under transformationsprocessen stødte vi på to hovedproblemer. For det første er belastningen på vores onlineressourcer steget markant (Sergey vil fortælle dig, hvordan vi håndterede dette). For det andet er strømmen af sjældne (præ-COVID) operationer steget mange gange, hvilket igen krævede en stor mængde hurtig automatisering. For at løse dette problem var vi nødt til hurtigt at overføre ressourcer fra områder, der tidligere var de vigtigste. Elena vil fortælle dig, hvordan vi håndterede dette.
Drift af onlinetjenester
Kolesnikov Sergey, ansvarlig for driften af onlinebutikken og mikrotjenester
Fra det øjeblik, vores detailbutikker begyndte at lukke for besøgende, begyndte vi at registrere en stigning i målinger såsom antallet af brugere, antallet af ordrer placeret i vores applikation og antallet af anmodninger til applikationer.
Antal bestillinger fra 18. marts til 31. martsAntal anmodninger til online betalingsmikrotjenesterAntal afgivne ordrer på hjemmesiden
I den første graf ser vi, at stigningen var cirka 14 gange, i den anden - 4 gange. Vi anser responstiden for vores applikationer for at være den mest vejledende.
I denne graf ser vi responsen fra fronter og applikationer, og for os selv fastslog vi, at vi ikke mærkede nogen vækst som sådan.
Det skyldes primært, at vi startede det forberedende arbejde i slutningen af 2019. Nu er vores tjenester reserveret, fejltolerance er sikret på niveau med fysiske servere, virtualiseringssystemer, dockere og tjenester i dem. Samtidig giver kapaciteten af vores serverressourcer os mulighed for at modstå flere belastninger.
Det vigtigste værktøj, der hjalp os i hele denne historie, var vores overvågningssystem. Indtil for ganske nylig havde vi ikke et enkelt system, der ville give os mulighed for at indsamle metrikker på alle lag, fra niveauet af fysisk udstyr og hardware til niveauet af forretningsmetrik.
Formelt var der overvågning i virksomheden, men som regel var den spredt og lå inden for specifikke afdelingers ansvarsområde. Faktisk, når en hændelse opstod, havde vi næsten aldrig en fælles forståelse af, hvad der præcist skete, der var ingen kommunikation, og ofte førte det til, at vi løb i cirkler for at finde og isolere problemet, så det kunne løses.
På et tidspunkt tænkte og besluttede vi, at vi havde nok af at holde ud – vi havde brug for et samlet system for at se hele billedet. De vigtigste teknologier, der er inkluderet i vores stack, er Zabbix som et alarm- og metriklagercenter, Prometheus til indsamling og lagring af applikationsmetrikker, Stack ELK til logning og lagring af data fra hele overvågningssystemet, samt Grafana til visualisering, Swagger, Docker og andre nyttige og ting, som du kender.
Samtidig bruger vi ikke kun teknologier, der er tilgængelige på markedet, men udvikler også nogle af vores egne. For eksempel laver vi tjenester til at integrere systemer med hinanden, det vil sige en form for API til indsamling af metrics. Derudover arbejder vi på vores egne overvågningssystemer - på niveau med forretningsmålinger bruger vi UI-tests. Og også en bot i Telegram til at underrette hold.
Vi forsøger også at gøre overvågningssystemet tilgængeligt for teams, så de selvstændigt kan gemme og arbejde med deres metrics, herunder opsætning af alarmer for nogle smalle metrics, der ikke er meget udbredte.
I hele systemet tilstræber vi proaktivitet og lokalisering af hændelser så hurtigt som muligt. Derudover er antallet af vores mikrotjenester og systemer vokset markant på det seneste, og antallet af integrationer er tilsvarende vokset. Og som led i at optimere processen med at diagnosticere hændelser på integrationsniveau, udvikler vi et system, der giver dig mulighed for at foretage kontrol på tværs af systemer og vise resultatet, hvilket giver dig mulighed for at finde de vigtigste problemer forbundet med import og interaktion af systemer med hinanden.
Vi har selvfølgelig stadig plads til at vokse og udvikle os i forhold til styresystemer, og det arbejder vi aktivt på. Du kan læse mere om vores overvågningssystem .
Tekniske tests
Orlov Sergey, leder kompetencecentret for web- og mobiludvikling
Siden de fysiske butikslukninger begyndte, har vi stået over for forskellige udfordringer i et udviklingsperspektiv. Først og fremmest belastningsstigningen som sådan. Det er klart, at hvis der ikke træffes passende foranstaltninger, så når en høj belastning påføres systemet, kan det blive til et græskar med et trist bang, eller helt forringe ydeevnen eller endda miste dets funktionalitet.
Det andet aspekt, lidt mindre indlysende, er, at systemet under høj belastning skulle ændres meget hurtigt, tilpasset ændringer i forretningsprocesser. Nogle gange flere gange om dagen. Mange virksomheder har en regel om, at hvis der er stor markedsføringsaktivitet, er der ingen grund til at lave ændringer i systemet. Ingen overhovedet, lad det virke, så længe det virker.
Og vi havde i det væsentlige en endeløs Black Friday, hvor det var nødvendigt at ændre systemet. Og enhver fejl, problem eller fejl i systemet ville være meget dyrt for virksomheden.
Når vi ser fremad, vil jeg sige, at vi formåede at klare disse tests, alle systemer modstod belastningen, var let skalerede, og vi oplevede ingen globale tekniske fejl.
Der er fire søjler, hvorpå systemets evne til at modstå høje overspændingsbelastninger hviler. Den første af dem er overvågning, som du læser om lige ovenfor. Uden et indbygget overvågningssystem er det næsten umuligt at finde systemflaskehalse. Et godt overvågningssystem er som hjemmetøj; det skal være behageligt og skræddersyet til dig.
Det andet aspekt er testning. Vi tager dette punkt meget alvorligt: Vi skriver klassiske enheder, integrationstest, belastningstest og mange andre for hvert system. Vi skriver også en teststrategi, og forsøger samtidig at øge testniveauet til det punkt, at vi ikke længere har brug for manuelle kontroller.
Den tredje søjle er CI/CD Pipeline. Processerne med at bygge, teste og implementere en applikation bør automatiseres så meget som muligt; der bør ikke være nogen manuel indgriben. Emnet om CI/CD Pipeline er ret dybt, og jeg vil kun komme ind på det kort. Det er kun værd at nævne, at vi har en CI/CD Pipeline-tjekliste, som hvert produktteam gennemgår ved hjælp af kompetencecentre.
Og her er tjeklisten
På den måde opnås mange mål. Dette er API-versionering og funktionsskift for at undgå udgivelsestoget og opnå dækning af forskellige tests på et sådant niveau, at testning er fuldt automatiseret, implementeringer er problemfri, og så videre.
Den fjerde søjle er arkitektoniske principper og tekniske løsninger. Vi kan snakke meget om arkitektur i lang tid, men jeg vil gerne fremhæve et par principper, som jeg gerne vil fokusere på.
Først skal du vælge specialiserede værktøjer til specifikke opgaver. Ja, det lyder oplagt, og det er klart, at søm skal slås ind med en hammer, og armbåndsure skal skilles ad med specielle skruetrækkere. Men i vores tidsalder stræber mange værktøjer efter universalisering for at dække det maksimale segment af brugere: databaser, caches, rammer og resten. For eksempel, hvis du tager MongoDB-databasen, fungerer den med multidokumenttransaktioner, og Oracle-databasen fungerer med json. Og det ser ud til, at alt kan bruges til alt. Men hvis vi står for produktivitet, så skal vi klart forstå styrkerne og svaghederne ved hvert værktøj og bruge dem, vi har brug for til vores klasse af opgaver.
For det andet, når man designer systemer, skal hver stigning i kompleksitet begrundes. Det skal vi hele tiden huske på, princippet om lav kobling er kendt af alle. Jeg mener, at det skal anvendes på niveauet for en specifik service, og på niveauet for hele systemet og på niveauet af det arkitektoniske landskab. Evnen til at skalere hver systemkomponent vandret langs belastningsvejen er også vigtig. Hvis du har denne evne, vil skalering ikke være svært.
Når vi taler om tekniske løsninger, bad vi produktteams om at udarbejde et nyt sæt anbefalinger, ideer og løsninger, som de implementerede som forberedelse til den næste bølge af arbejdsbyrde.
Keshi
Det er nødvendigt bevidst at nærme sig valget af lokale og distribuerede caches. Nogle gange giver det mening at bruge begge dele inden for samme system. For eksempel har vi systemer, hvor nogle af dataene i det væsentlige er en udstillingscache, det vil sige, at kilden til opdateringer er placeret bag selve systemet, og systemerne ændrer sig ikke. disse data. Til denne tilgang bruger vi lokal koffein-cache.
Og der er data, som systemet aktivt ændrer under drift, og her bruger vi allerede en distribueret cache med Hazelcast. Denne tilgang giver os mulighed for at bruge fordelene ved en distribueret cache, hvor der virkelig er brug for dem, og minimere serviceomkostningerne ved at cirkulere Hazelcast-klyngedata, hvor vi kan undvære dem. Vi har skrevet meget om caches. и .
Derudover gav ændringen af serializeren til Kryo i Hazelcast os et godt løft. Og overgangen fra ReplicatedMap til IMap + Near Cache i Hazelcast gjorde det muligt for os at minimere bevægelsen af data på tværs af klyngen.
Et lille råd: I tilfælde af ugyldiggørelse af massecache er taktikken med at varme den anden cache op og derefter skifte til den nogle gange anvendelig. Det ser ud til, at vi med denne tilgang skulle få dobbelt hukommelsesforbrug, men i praksis faldt hukommelsesforbruget i de systemer, hvor dette blev praktiseret.
Reaktiv stak
Vi bruger den reaktive stak i et ret stort antal systemer. I vores tilfælde er dette Webflux eller Kotlin med koroutiner. Den reaktive stak er især god, hvor vi forventer langsomme input-output operationer. For eksempel opkald til langsomme tjenester, arbejde med filsystemet eller lagersystemer.
Det vigtigste princip er at undgå at blokere opkald. Reaktive rammer har et lille antal levende servicetråde, der løber under hætten. Hvis vi skødesløst tillader os selv at foretage et direkte blokeringsopkald, såsom et JDBC-driveropkald, vil systemet simpelthen gå i stå.
Prøv at omdanne fejl til din egen runtime-undtagelse. Det faktiske flow af programudførelse skifter til reaktive rammer, og kodeudførelse bliver ikke-lineær. Som et resultat er det meget vanskeligt at diagnosticere problemer ved hjælp af stakspor. Og løsningen her ville være at skabe klare, objektive runtime-undtagelser for hver fejl.
Elasticsearch
Når du bruger Elasticsearch, skal du ikke vælge ubrugte data. Dette er i princippet også et meget simpelt råd, men oftest er det det, der glemmes. Hvis du skal vælge mere end 10 poster ad gangen, skal du bruge Scroll. For at bruge en analogi, er det lidt ligesom en markør i en relationsdatabase.
Brug ikke postfilter, medmindre det er nødvendigt. Med store data i hovedeksemplet belaster denne operation databasen i høj grad.
Brug bulkoperationer, hvor det er relevant.
API
Når du designer en API, skal du inkludere krav til minimering af overførte data. Dette gælder især i forbindelse med fronten: Det er i dette knudepunkt, at vi går ud over vores datacentres kanaler og allerede arbejder på den kanal, der forbinder os med klienten. Hvis det har det mindste problem, forårsager for meget trafik en negativ brugeroplevelse.
Og endelig, smid ikke en hel masse data ud, vær klar over kontrakten mellem forbrugere og leverandører.
Organisatorisk transformation
Eroshkina Elena, vicedirektør for IT
I det øjeblik, hvor karantænen fandt sted, og behovet opstod for kraftigt at øge tempoet i onlineudvikling og introducere omnichannel-tjenester, var vi allerede i gang med organisatorisk transformation.
En del af vores struktur blev overført til at arbejde i henhold til principperne og praksisserne for produkttilgangen. Der er dannet teams, som nu er ansvarlige for drift og udvikling af hvert produkt. Medarbejdere i sådanne teams er 100 % involverede og strukturerer deres arbejde ved hjælp af Scrum eller Kanban, afhængigt af hvad der er at foretrække frem for dem, opsætning af en implementeringspipeline, implementering af teknisk praksis, kvalitetssikringspraksis og meget mere.
Heldigvis var størstedelen af vores produktteam inden for online- og omnichannel-tjenester. Dette gjorde det muligt for os at skifte til fjernarbejdstilstand på kortest mulig tid (seriøst, bogstaveligt talt på to dage) uden tab af effektivitet. Den skræddersyede proces gjorde det muligt for os hurtigt at tilpasse os nye arbejdsforhold og opretholde et ret højt tempo i leveringen af ny funktionalitet.
Derudover har vi et behov for at styrke de teams, der er på grænsen til online-forretning. I det øjeblik blev det klart, at vi kun kunne gøre dette med interne ressourcer. Og omkring 50 mennesker på to uger ændrede det område, hvor de arbejdede før, og blev involveret i arbejdet med et produkt, der var nyt for dem.
Dette krævede ikke nogen særlig ledelsesindsats, for sammen med organisering af vores egen proces, teknisk forbedring af produktet og kvalitetssikringspraksis lærer vi vores teams at selvorganisere - at styre deres egen produktionsproces uden at involvere administrative ressourcer.
Vi var i stand til at fokusere vores ledelsesressourcer præcis, hvor det var nødvendigt i det øjeblik - på at koordinere sammen med virksomheden: Hvad er vigtigt for vores klient lige nu, hvilken funktionalitet skal implementeres først, hvad skal der gøres for at øge vores gennemstrømningsevne at levere og behandle ordrer. Alt dette og en klar rollemodel gjorde det muligt i denne periode at belaste vores produktionsværdistrømme med det, der virkelig er vigtigt og nødvendigt.
Det er klart, at med fjernarbejde og et højt forandringstempo, når forretningsindikatorer afhænger af alles deltagelse, kan du ikke kun stole på interne følelser fra serien "Går alt godt med os? Ja, det ser godt ud." Objektive målinger af produktionsprocessen er nødvendige. Vi har disse, de er tilgængelige for alle, der er interesseret i metrics for produktteams. Først og fremmest selve teamet, forretningen, underleverandører og ledelsen.
En gang hver anden uge afholdes en status med hvert team, hvor målinger analyseres i 10 minutter, flaskehalse i produktionsprocessen identificeres, og der udvikles en fælles løsning: hvad kan man gøre for at fjerne disse flaskehalse. Her kan du straks bede om hjælp fra ledelsen, hvis et identificeret problem ligger uden for teamenes indflydelseszone, eller ekspertisen hos kolleger, som måske allerede er stødt på et lignende problem.
Vi forstår dog, at for at accelerere flere gange (og det er præcis det mål, vi sætter os), skal vi stadig lære en masse og implementere det i vores daglige arbejde. Lige nu fortsætter vi med at skalere vores produkttilgang til andre teams og nye produkter. For at gøre dette var vi nødt til at mestre et nyt format for os - en online skole for metodologer.
Metodologer, folk, der hjælper teams med at opbygge en proces, etablere kommunikation og forbedre arbejdseffektiviteten, er i bund og grund forandringsagenter. Lige nu arbejder kandidater fra vores første årgang med teams og hjælper dem med at få succes.
Jeg tror, at den nuværende situation åbner muligheder og perspektiver for os, som vi måske ikke selv er helt klar over endnu. Men den erfaring og praksis, som vi får lige nu, bekræfter, at vi har valgt den rigtige udviklingsvej, vi vil ikke gå glip af disse nye muligheder i fremtiden og vil være i stand til at reagere lige så effektivt på de udfordringer, som Sportmaster vil møde.
Fund
I denne svære tid har vi formuleret de hovedprincipper, som softwareudvikling hviler på, hvilket jeg tror vil være relevant for enhver virksomhed, der beskæftiger sig med dette.
Mennesker. Det er det, alt hviler på. Medarbejderne skal nyde deres arbejde og forstå virksomhedens mål og målene for de produkter, de arbejder med. Og de kunne selvfølgelig udvikle sig fagligt.
Технология. Det er nødvendigt for virksomheden at have en moden tilgang til at arbejde med sin teknologistack og opbygge kompetencer, hvor der virkelig er brug for det. Det lyder meget enkelt og indlysende. Og meget ofte ignoreret.
processer. Det er vigtigt at organisere arbejdet i produktteams og kompetencecentre ordentligt, at etablere interaktion med virksomheden for at kunne arbejde med den som partner.
Generelt er det stort set sådan, vi overlevede. Vor tids hovedtese blev endnu en gang bekræftet med et rungende klik i panden
Selvom du er en enorm offline forretning med mange butikker og en masse byer, hvor du opererer, så udvikle din online forretning. Dette er ikke bare en ekstra salgskanal eller en smuk applikation, hvorigennem du også kan købe noget (og også fordi konkurrenterne også har smukke). Dette er ikke et just-in-case reservedæk, der hjælper dig med at klare stormen.
Dette er en absolut nødvendighed. Som ikke kun dine tekniske evner og infrastruktur skal forberedes, men også dine mennesker og processer. Du kan trods alt hurtigt købe ekstra hukommelse, plads, implementere nye instanser osv. på et par timer. Men det skal mennesker og processer være forberedt på på forhånd.
Kilde: www.habr.com