Det som hjälpte oss att snabbt anpassa oss till onlinehandel under de nya förhållandena

Hälsningar!

Jag heter Mikhail, jag är biträdande IT-direktör på Sportmaster-företaget. Jag vill dela med mig av historien om hur vi hanterade de utmaningar som uppstod under pandemin.

Under de första dagarna av de nya verkligheterna frös det vanliga offlinehandelsformatet för Sportmaster, och belastningen på vår onlinekanal, främst när det gäller leverans till kundens adress, ökade 10 gånger. På bara några veckor förvandlade vi en gigantisk offlineverksamhet till en onlineverksamhet och anpassade tjänsten efter våra kunders behov.

I grund och botten blev det som i huvudsak var vår sidoverksamhet vår kärnverksamhet. Betydelsen av varje onlinebeställning har ökat extremt. Det var nödvändigt att spara varje rubel som kunden tog med till företaget. 

För att snabbt kunna svara på kundförfrågningar öppnade vi ytterligare ett kontaktcenter på företagets huvudkontor och kan nu ta emot cirka 285 tusen samtal per vecka. Samtidigt flyttade vi 270 butiker till ett nytt kontaktlöst och säkert driftformat, vilket gjorde att kunder kunde ta emot beställningar och anställda för att behålla sina jobb.

Under omvandlingsprocessen stötte vi på två huvudproblem. För det första har belastningen på våra onlineresurser ökat avsevärt (Sergey kommer att berätta hur vi hanterade detta). För det andra har flödet av sällsynta (pre-COVID) operationer ökat många gånger, vilket i sin tur krävde en stor mängd snabb automatisering. För att lösa detta problem var vi tvungna att snabbt överföra resurser från områden som tidigare var de huvudsakliga. Elena kommer att berätta hur vi hanterade detta.

Drift av onlinetjänster

Kolesnikov Sergey, ansvarig för driften av nätbutiken och mikrotjänsterna

Från det ögonblick som våra butiker började stänga för besökare, började vi registrera en ökning av mätvärden som antalet användare, antalet beställningar i vår applikation och antalet förfrågningar till applikationer. 

Antal beställningar från 18 mars till 31 marsAntal förfrågningar till betalningsmikrotjänster onlineAntal beställningar som lagts på hemsidan

I den första grafen ser vi att ökningen var cirka 14 gånger, i den andra - 4 gånger. Vi anser att svarstidsmåttet för våra ansökningar är det mest vägledande. 

I den här grafen ser vi responsen från fronter och applikationer, och för oss själva fastställde vi att vi inte märkte någon tillväxt som sådan.

Det beror främst på att vi påbörjade förberedande arbete i slutet av 2019. Nu är våra tjänster reserverade, feltolerans säkerställs på nivån för fysiska servrar, virtualiseringssystem, hamnarbetare och tjänster i dem. Samtidigt tillåter kapaciteten hos våra serverresurser oss att motstå flera belastningar.

Det viktigaste verktyget som hjälpte oss i hela den här historien var vårt övervakningssystem. Det är sant att vi tills helt nyligen inte hade ett enda system som skulle tillåta oss att samla in mått på alla lager, från nivån av fysisk utrustning och hårdvara till nivån på affärsmått. 

Formellt fanns det övervakning i företaget, men som regel var den spridd och låg inom specifika avdelningars ansvarsområde. Faktum är att när en incident inträffade hade vi nästan aldrig en gemensam uppfattning om exakt vad som hände, det fanns ingen kommunikation, och ofta ledde detta till att vi sprang i cirklar för att hitta och isolera problemet så att det kunde åtgärdas.

Vid något tillfälle tänkte vi och bestämde oss för att vi hade nog av att uthärda detta – vi behövde ett enhetligt system för att se hela bilden i sin helhet. De huvudsakliga teknologierna som ingår i vår stack är Zabbix som ett larm- och metriklagringscenter, Prometheus för insamling och lagring av applikationsstatistik, Stack ELK för att logga och lagra data från hela övervakningssystemet, samt Grafana för visualisering, Swagger, Docker och andra användbara och saker som är bekanta för dig.

Samtidigt använder vi inte bara tekniker som finns på marknaden, utan utvecklar också en del av vår egen. Vi gör till exempel tjänster för att integrera system med varandra, det vill säga någon form av API för att samla in mätvärden. Dessutom arbetar vi på våra egna övervakningssystem - på nivån för affärsmått använder vi UI-tester. Och även en bot i Telegram för att meddela team.

Vi försöker också göra övervakningssystemet tillgängligt för team så att de självständigt kan lagra och arbeta med sina mätvärden, inklusive att ställa in varningar för vissa smala mätvärden som inte används i stor utsträckning. 

I hela systemet strävar vi efter proaktivitet och lokalisering av incidenter så snabbt som möjligt. Dessutom har antalet av våra mikrotjänster och system vuxit avsevärt den senaste tiden, och antalet integrationer har därmed vuxit. Och som en del av att optimera processen för att diagnostisera incidenter på integrationsnivå utvecklar vi ett system som gör att du kan utföra systemövergripande kontroller och visa resultatet, vilket gör att du kan hitta huvudproblemen i samband med import och interaktion av system med varandra. 

Självklart har vi fortfarande utrymme att växa och utvecklas vad gäller operativsystem och vi jobbar aktivt med detta. Du kan läsa mer om vårt övervakningssystem här. 

Tekniska tester 

Orlov Sergey, leder kompetenscentret för webb- och mobilutveckling

Sedan de fysiska butiksnedläggningarna började har vi ställts inför olika utmaningar ur ett utvecklingsperspektiv. Först av allt, belastningsökningen som sådan. Det är tydligt att om lämpliga åtgärder inte vidtas, när en hög belastning appliceras på systemet, kan det förvandlas till en pumpa med en sorglig smäll, eller helt försämras i prestanda eller till och med förlora sin funktionalitet.

Den andra aspekten, lite mindre uppenbar, är att systemet under hög belastning måste ändras mycket snabbt och anpassas till förändringar i affärsprocesser. Ibland flera gånger om dagen. Många företag har en regel att om det är mycket marknadsföringsaktivitet så behöver man inte göra några ändringar i systemet. Inga alls, låt det fungera så länge det fungerar.

Och vi hade i princip en oändlig Black Friday, under vilken det var nödvändigt att ändra systemet. Och alla fel, problem eller fel i systemet skulle bli mycket kostsamt för företaget.

Framöver kommer jag att säga att vi klarade av dessa tester, alla system klarade belastningen, var lätta att skala och vi upplevde inga globala tekniska fel.

Det finns fyra pelare på vilka systemets förmåga att motstå höga överspänningsbelastningar vilar. Den första av dem är övervakning, som du läser om precis ovan. Utan ett inbyggt övervakningssystem är det nästan omöjligt att hitta systemflaskhalsar. Ett bra övervakningssystem är som hemkläder, det ska vara bekvämt och skräddarsytt för dig.

Den andra aspekten är testning. Vi tar denna punkt på största allvar: vi skriver klassiska enheter, integrationstester, belastningstester och många andra för varje system. Vi skriver också en teststrategi och försöker samtidigt öka testnivån till den grad att vi inte längre behöver manuella kontroller.

Den tredje pelaren är CI/CD Pipeline. Processerna för att bygga, testa och distribuera en applikation bör automatiseras så mycket som möjligt, det ska inte finnas några manuella ingrepp. Ämnet om CI/CD Pipeline är ganska djupt, och jag kommer bara att beröra det kort. Det är bara värt att nämna att vi har en checklista för CI/CD Pipeline, som varje produktteam går igenom med hjälp av kompetenscenter.

Och här är checklistan

På så sätt uppnås många mål. Detta är API-versionering och funktionsväxling för att undvika release-tåget, och att uppnå täckning av olika tester på en sådan nivå att testning är helt automatiserad, distributioner är sömlösa, och så vidare.

Den fjärde pelaren är arkitektoniska principer och tekniska lösningar. Vi kan prata mycket om arkitektur under lång tid, men jag vill betona ett par principer som jag skulle vilja fokusera på.

Först måste du välja specialiserade verktyg för specifika uppgifter. Ja, det låter självklart, och det är klart att spikar ska slås in med en hammare, och armbandsur ska demonteras med speciella skruvmejslar. Men i vår tid strävar många verktyg efter universalisering för att täcka det maximala segmentet av användare: databaser, cachar, ramverk och resten. Om du till exempel tar MongoDB-databasen fungerar den med transaktioner med flera dokument, och Oracle-databasen fungerar med json. Och det verkar som att allt kan användas till allt. Men om vi står för produktivitet måste vi tydligt förstå styrkorna och svagheterna hos varje verktyg och använda de vi behöver för vår klass av uppgifter. 

För det andra, när man designar system måste varje ökning av komplexiteten motiveras. Vi måste hela tiden ha detta i åtanke, principen om låg koppling är känd för alla. Jag anser att det bör tillämpas på nivån av en specifik tjänst, och på nivån för hela systemet och på nivån av det arkitektoniska landskapet. Möjligheten att horisontellt skala varje systemkomponent längs lastvägen är också viktig. Om du har den här förmågan blir det inte svårt att skala.

På tal om tekniska lösningar bad vi produktteam att förbereda en ny uppsättning rekommendationer, idéer och lösningar, som de implementerade inför nästa våg av arbetsbelastning.

Keshi

Det är nödvändigt att medvetet närma sig valet av lokala och distribuerade cacher. Ibland är det vettigt att använda båda inom samma system. Vi har till exempel system där en del av datan i huvudsak är en showcache, det vill säga källan till uppdateringarna finns bakom själva systemet, och systemen förändras inte. dessa uppgifter. För detta tillvägagångssätt använder vi lokal koffeincache. 

Och det finns data som systemet aktivt ändrar under drift, och här använder vi redan en distribuerad cache med Hazelcast. Detta tillvägagångssätt tillåter oss att använda fördelarna med en distribuerad cache där de verkligen behövs, och minimera servicekostnaderna för att cirkulera Hazelcast-klusterdata där vi kan klara oss utan det. Vi har skrivit mycket om cacher. här и här.

Dessutom gav det ett bra uppsving för oss att ändra serializern till Kryo i Hazelcast. Och övergången från ReplicatedMap till IMap + Near Cache i Hazelcast tillät oss att minimera rörelsen av data över klustret. 

Ett litet råd: i händelse av ogiltigförklaring av masscache, är taktiken att värma upp den andra cachen och sedan byta till den ibland tillämplig. Det verkar som att vi med detta tillvägagångssätt borde få dubbel minnesförbrukning, men i praktiken, i de system där detta praktiserades, minskade minnesförbrukningen.

Reaktiv stack

Vi använder den reaktiva stacken i ett ganska stort antal system. I vårt fall är detta Webflux eller Kotlin med koroutiner. Den reaktiva stacken är särskilt bra där vi förväntar oss långsamma input-output-operationer. Till exempel samtal till långsamma tjänster, arbete med filsystemet eller lagringssystem.

Den viktigaste principen är att undvika att blockera samtal. Reaktiva ramverk har ett litet antal levande servicetrådar som löper under huven. Om vi ​​slarvigt tillåter oss själva att göra ett direkt blockerande samtal, till exempel ett JDBC-föraranrop, kommer systemet helt enkelt att stanna. 

Försök att förvandla fel till ditt eget körtidsundantag. Det faktiska flödet av programexekvering skiftar till reaktiva ramverk, och kodexekveringen blir olinjär. Som ett resultat är det mycket svårt att diagnostisera problem med hjälp av stack traces. Och lösningen här skulle vara att skapa tydliga, objektiva runtime-undantag för varje fel.

Elasticsearch

När du använder Elasticsearch, välj inte oanvänd data. Detta är i princip också väldigt enkla råd, men oftast är det detta som glöms bort. Om du behöver välja mer än 10 tusen poster åt gången måste du använda Scroll. För att använda en analogi så är det lite som en markör i en relationsdatabas. 

Använd inte efterfilter om det inte är nödvändigt. Med stora data i huvudprovet belastar denna operation databasen kraftigt. 

Använd bulkoperationer där så är tillämpligt.

API

När du designar ett API, inkludera krav för att minimera överförda data. Detta gäller särskilt i samband med fronten: det är i denna korsning som vi går bortom kanalerna i våra datacenter och arbetar redan på kanalen som förbinder oss med kunden. Om det har det minsta problem, orsakar för mycket trafik en negativ användarupplevelse.

Och slutligen, kasta inte ut en hel massa data, var tydlig med avtalet mellan konsumenter och leverantörer.

Organisatorisk transformation

Eroshkina Elena, biträdande IT-direktör

I det ögonblick då karantän inträffade och behovet uppstod att kraftigt öka takten i onlineutvecklingen och införa omnikanaltjänster, var vi redan i en process med organisatorisk omvandling. 

En del av vår struktur överfördes till att arbeta enligt principerna och praxisen för produktmetoden. Team har bildats som nu ansvarar för drift och utveckling av varje produkt. Anställda i sådana team är till 100 % involverade och strukturerar sitt arbete med Scrum eller Kanban, beroende på vad som är att föredra framför dem, sätter upp en distributionspipeline, implementerar tekniska rutiner, kvalitetssäkringsrutiner och mycket mer.

Som tur var var huvuddelen av våra produktteam inom området online- och omnikanaltjänster. Detta gjorde det möjligt för oss att byta till fjärrarbetsläge på kortast möjliga tid (på allvar, bokstavligen på två dagar) utan förlust av effektivitet. Den skräddarsydda processen gjorde att vi snabbt kunde anpassa oss till nya arbetsförhållanden och upprätthålla en ganska hög leveranstakt av ny funktionalitet.

Dessutom har vi ett behov av att stärka de team som är på gränsen för online-affärer. I det ögonblicket stod det klart att vi bara kunde göra detta med interna resurser. Och ett 50-tal personer på två veckor bytte område där de arbetade tidigare och engagerade sig i arbetet med en produkt som var ny för dem. 

Detta krävde inga speciella ledningsinsatser, för tillsammans med att organisera vår egen process, tekniska förbättringar av produkten och kvalitetssäkringsmetoder lär vi våra team att självorganisera - att hantera sin egen produktionsprocess utan att involvera administrativa resurser.

Vi kunde fokusera våra ledningsresurser precis där det behövdes just då - på att koordinera tillsammans med verksamheten: Vad är viktigt för vår kund just nu, vilken funktionalitet som ska implementeras först, vad behöver göras för att öka vår genomströmningsförmåga att leverera och behandla beställningar. Allt detta och en tydlig förebild gjorde det möjligt att under denna period ladda våra produktionsvärdeströmmar med det som verkligen är viktigt och nödvändigt. 

Det är tydligt att med distansarbete och hög förändringstakt, när affärsindikatorer beror på allas deltagande, kan du inte bara lita på interna känslor från serien "Går allt bra med oss? Ja, det verkar bra." Objektiva mått på produktionsprocessen behövs. Vi har dessa, de är tillgängliga för alla som är intresserade av måtten för produktteam. Först och främst själva teamet, verksamheten, underleverantörer och ledning.

En gång varannan vecka hålls en status med varje team, där mätvärden analyseras under 10 minuter, flaskhalsar i produktionsprocessen identifieras och en gemensam lösning tas fram: vad kan göras för att eliminera dessa flaskhalsar. Här kan du omedelbart be om hjälp från ledningen om något identifierat problem ligger utanför teamens påverkanszon, eller expertis hos kollegor som kanske redan har stött på ett liknande problem.

Men vi förstår att för att accelerera flera gånger (och det är precis målet vi ställer upp för oss själva), måste vi fortfarande lära oss mycket och implementera det i vårt dagliga arbete. Just nu fortsätter vi att skala vår produktstrategi till andra team och nya produkter. För att göra detta var vi tvungna att bemästra ett nytt format för oss - en onlineskola för metodologer.

Metodologer, människor som hjälper team att bygga en process, etablera kommunikation och förbättra arbetseffektiviteten, är i huvudsak förändringsagenter. Just nu arbetar studenter från vår första kohort med team och hjälper dem att bli framgångsrika. 

Jag tror att den nuvarande situationen öppnar möjligheter och utsikter för oss som vi kanske själva ännu inte är helt medvetna om. Men erfarenheten och praktiken som vi får just nu bekräftar att vi har valt rätt utvecklingsväg, vi kommer inte att missa dessa nya möjligheter i framtiden och kommer att kunna svara lika effektivt på de utmaningar som Sportmaster kommer att möta.

Resultat

Under denna svåra tid har vi formulerat de huvudprinciper som mjukvaruutvecklingen vilar på, vilket jag tror kommer att vara relevant för varje företag som sysslar med detta.

Människor. Detta är vad allt vilar på. Anställda måste trivas med sitt arbete och förstå företagets mål och målen för de produkter de arbetar med. Och naturligtvis kunde de utvecklas professionellt. 

Технология. Det är nödvändigt för företaget att ta ett moget förhållningssätt till att arbeta med sin teknikstack och bygga kompetenser där det verkligen behövs. Det låter väldigt enkelt och självklart. Och väldigt ofta ignoreras.

Processerna. Det är viktigt att ordentligt organisera arbetet i produktteam och kompetenscenter, att etablera interaktion med verksamheten för att kunna arbeta med den som partner.

I allmänhet är det ungefär så vi överlevde. Vår tids huvudtes bekräftades ännu en gång, med ett rungande klick i pannan

Även om du är ett enormt offlineföretag med många butiker och ett gäng städer där du verkar, utveckla din onlineverksamhet. Detta är inte bara en extra försäljningskanal eller en vacker applikation genom vilken du också kan köpa något (och även för att konkurrenterna också har vackra sådana). Detta är inte ett reservdäck för att hjälpa dig att klara stormen.

Detta är en absolut nödvändighet. För vilket inte bara din tekniska förmåga och infrastruktur måste förberedas, utan också dina människor och processer. När allt kommer omkring kan du snabbt köpa extra minne, utrymme, distribuera nya instanser etc. på ett par timmar. Men människor och processer måste vara förberedda på detta i förväg.

Källa: will.com