Hey there!
Mijn naam is Mikhail, ik ben adjunct-directeur IT bij het bedrijf Sportmaster. Ik wil het verhaal delen over hoe we zijn omgegaan met de uitdagingen die tijdens de pandemie zijn ontstaan.
In de eerste dagen van de nieuwe realiteit bevroor het gebruikelijke offline handelsformaat van Sportmaster en nam de belasting van ons online kanaal, voornamelijk in termen van bezorging op het adres van de klant, tien keer toe. In slechts enkele weken tijd hebben we een gigantisch offline bedrijf omgevormd tot een online bedrijf en de dienstverlening aangepast aan de behoeften van onze klanten.
Kortom, wat in wezen onze nevenactiviteit was, werd onze kernactiviteit. Het belang van elke online bestelling is enorm toegenomen. Het was noodzakelijk om elke roebel die de klant naar het bedrijf bracht, te sparen.
Om snel te kunnen reageren op verzoeken van klanten hebben we een extra contactcenter geopend op het hoofdkantoor van het bedrijf. We kunnen nu ongeveer 285 telefoontjes per week ontvangen. Tegelijkertijd verhuisden we 270 winkels naar een nieuwe contactloze en veilige bedrijfsformule, waardoor klanten bestellingen konden ontvangen en medewerkers hun baan konden behouden.
Tijdens het transformatieproces kwamen we twee belangrijke problemen tegen. Ten eerste is de belasting van onze online bronnen aanzienlijk toegenomen (Sergey zal u vertellen hoe we hiermee zijn omgegaan). Ten tweede is de stroom van zeldzame (pre-COVID) operaties vele malen groter geworden, wat op zijn beurt een grote mate van snelle automatisering vereiste. Om dit probleem op te lossen moesten we snel middelen overbrengen uit gebieden die voorheen de belangrijkste waren. Elena vertelt je hoe we dit hebben aangepakt.
Exploitatie van onlinediensten
Kolesnikov Sergey, verantwoordelijk voor de werking van de online winkel en microservices
Vanaf het moment dat onze winkels voor bezoekers begonnen te sluiten, begonnen we een toename in statistieken te registreren, zoals het aantal gebruikers, het aantal bestellingen dat in onze applicatie werd geplaatst en het aantal aanvragen voor applicaties.
Aantal bestellingen van 18 maart tot 31 maartAantal verzoeken aan online betalingsmicroservicesAantal bestellingen geplaatst op de website
In de eerste grafiek zien we dat de toename ongeveer 14 keer was, in de tweede - 4 keer. Wij beschouwen de responstijdmetriek van onze applicaties als het meest indicatief.
In deze grafiek zien we de respons van fronten en toepassingen, en voor onszelf hebben we vastgesteld dat we als zodanig geen groei hebben opgemerkt.
Dit komt vooral doordat we eind 2019 zijn begonnen met de voorbereidende werkzaamheden. Nu onze services gereserveerd zijn, is fouttolerantie gegarandeerd op het niveau van fysieke servers, virtualisatiesystemen, dockers en services daarin. Tegelijkertijd stelt de capaciteit van onze serverbronnen ons in staat meerdere belastingen te weerstaan.
Het belangrijkste instrument dat ons in dit hele verhaal heeft geholpen, was ons monitoringsysteem. Toegegeven, tot voor kort hadden we geen enkel systeem waarmee we statistieken op alle lagen konden verzamelen, van het niveau van fysieke apparatuur en hardware tot het niveau van zakelijke statistieken.
Formeel was er sprake van toezicht binnen het bedrijf, maar in de regel was dit verspreid en viel het onder de verantwoordelijkheid van specifieke afdelingen. Als er zich een incident voordeed, hadden we bijna nooit een gezamenlijk begrip van wat er precies was gebeurd, was er geen communicatie en leidde dit er vaak toe dat we in cirkels rondliepen om het probleem te vinden en te isoleren, zodat het kon worden opgelost.
Op een gegeven moment dachten en besloten we dat we er genoeg van hadden dit te moeten doorstaan; we hadden een uniform systeem nodig om het hele plaatje volledig te kunnen zien. De belangrijkste technologieën die in onze stack zijn opgenomen zijn Zabbix als opslagcentrum voor waarschuwingen en statistieken, Prometheus voor het verzamelen en opslaan van applicatiestatistieken, Stack ELK voor het loggen en opslaan van gegevens uit het gehele monitoringsysteem, evenals Grafana voor visualisatie, Swagger, Docker en andere nuttige en dingen die u bekend voorkomen.
Tegelijkertijd gebruiken we niet alleen technologieën die op de markt beschikbaar zijn, maar ontwikkelen we ook enkele van onze eigen technologieën. We maken bijvoorbeeld diensten voor het met elkaar integreren van systemen, dat wil zeggen een soort API voor het verzamelen van statistieken. Bovendien werken we aan onze eigen monitoringsystemen - op het niveau van bedrijfsstatistieken gebruiken we UI-tests. En ook een bot in Telegram om teams op de hoogte te stellen.
We proberen het monitoringsysteem ook toegankelijk te maken voor teams, zodat ze hun meetgegevens onafhankelijk kunnen opslaan en ermee kunnen werken, inclusief het instellen van waarschuwingen voor een aantal specifieke meetgegevens die niet veel worden gebruikt.
Door het hele systeem heen streven wij naar proactiviteit en het zo snel mogelijk lokaliseren van incidenten. Bovendien is het aantal van onze microservices en systemen de laatste tijd aanzienlijk gegroeid en is het aantal integraties dienovereenkomstig gegroeid. En als onderdeel van het optimaliseren van het proces van het diagnosticeren van incidenten op integratieniveau, ontwikkelen we een systeem waarmee u systeemoverschrijdende controles kunt uitvoeren en het resultaat kunt weergeven, waardoor u de belangrijkste problemen kunt vinden die verband houden met de import en interactie van systemen met elkaar.
Uiteraard hebben we nog ruimte om te groeien en ontwikkelen op het gebied van besturingssystemen en daar zijn we actief mee bezig. U kunt meer lezen over ons monitoringsysteem .
Technische testen
Orlov Sergey, hoofd van het competentiecentrum voor web- en mobiele ontwikkeling
Sinds het begin van de fysieke winkelsluitingen zijn we vanuit ontwikkelingsperspectief met verschillende uitdagingen geconfronteerd. Allereerst de belastingsstoot als zodanig. Het is duidelijk dat als er geen passende maatregelen worden genomen, het systeem bij hoge belasting met een trieste knal in een pompoen kan veranderen, of de prestaties volledig kan verslechteren, of zelfs zijn functionaliteit kan verliezen.
Het tweede aspect, iets minder voor de hand liggend, is dat het systeem onder hoge belasting zeer snel moest worden gewijzigd om zich aan te passen aan veranderingen in bedrijfsprocessen. Soms meerdere keren per dag. Veel bedrijven hebben de regel dat als er veel marketingactiviteit is, het niet nodig is om wijzigingen in het systeem aan te brengen. Helemaal geen, laat het werken zolang het werkt.
En we hadden in wezen een eindeloze Black Friday, waarin het nodig was om het systeem te veranderen. En elke fout, probleem of storing in het systeem zou zeer kostbaar zijn voor het bedrijf.
Vooruitkijkend zal ik zeggen dat we deze tests hebben doorstaan, dat alle systemen de belasting hebben doorstaan, gemakkelijk kunnen worden geschaald en dat we geen wereldwijde technische storingen hebben ondervonden.
Er zijn vier pijlers waarop het vermogen van het systeem om hoge piekbelastingen te weerstaan, berust. De eerste daarvan is monitoring, waarover je hierboven hebt gelezen. Zonder een ingebouwd monitoringsysteem is het vrijwel onmogelijk om systeemknelpunten te vinden. Een goed monitoringsysteem is als huiskleding; het moet comfortabel zijn en op maat gemaakt.
Het tweede aspect is testen. We nemen dit punt zeer serieus: we schrijven klassieke eenheden, integratietests, belastingstests en vele andere voor elk systeem. We schrijven ook een teststrategie en proberen tegelijkertijd het testniveau te verhogen tot het punt dat we geen handmatige controles meer nodig hebben.
De derde pijler is CI/CD Pipeline. De processen voor het bouwen, testen en implementeren van een applicatie moeten zoveel mogelijk worden geautomatiseerd; er mag geen handmatige tussenkomst zijn. Het onderwerp CI/CD Pipeline gaat behoorlijk diep en ik zal er slechts kort op ingaan. Het is alleen de moeite waard te vermelden dat we een CI/CD Pipeline-checklist hebben, die elk productteam doorloopt met de hulp van competentiecentra.
En hier is de checklist
Op deze manier worden veel doelen bereikt. Dit is API-versiebeheer en het wisselen van functies om de release-trein te vermijden en de dekking van verschillende tests op een zodanig niveau te bereiken dat het testen volledig geautomatiseerd is, implementaties naadloos zijn, enzovoort.
De vierde pijler zijn architectonische principes en technische oplossingen. We kunnen nog heel lang over architectuur praten, maar ik wil een aantal principes benadrukken waar ik me graag op wil concentreren.
Eerst moet u gespecialiseerde hulpmiddelen kiezen voor specifieke taken. Ja, het klinkt voor de hand liggend, en het is duidelijk dat spijkers met een hamer moeten worden ingeslagen en dat polshorloges moeten worden gedemonteerd met speciale schroevendraaiers. Maar in onze tijd streven veel tools naar universalisering om het maximale gebruikerssegment te bestrijken: databases, caches, frameworks en de rest. Als u bijvoorbeeld de MongoDB-database neemt, werkt deze met transacties met meerdere documenten, en de Oracle-database werkt met json. En het lijkt erop dat alles voor alles kan worden gebruikt. Maar als we voor productiviteit staan, moeten we de sterke en zwakke punten van elke tool duidelijk begrijpen en de tools gebruiken die we nodig hebben voor ons soort taken.
Ten tweede moet bij het ontwerpen van systemen elke toename in complexiteit gerechtvaardigd worden. Dit moeten we voortdurend in gedachten houden; het principe van low-koppeling is bij iedereen bekend. Ik ben van mening dat het moet worden toegepast op het niveau van een specifieke dienst, en op het niveau van het hele systeem, en op het niveau van het architecturale landschap. De mogelijkheid om elk systeemonderdeel horizontaal langs het belastingspad te schalen is ook belangrijk. Als je dit vermogen hebt, zal opschalen niet moeilijk zijn.
Over technische oplossingen gesproken: we hebben productteams gevraagd een nieuwe reeks aanbevelingen, ideeën en oplossingen voor te bereiden, die ze vervolgens implementeerden ter voorbereiding op de volgende golf van werkdruk.
Keshi
Het is noodzakelijk om de keuze voor lokale en gedistribueerde caches bewust te benaderen. Soms is het zinvol om beide binnen hetzelfde systeem te gebruiken. We hebben bijvoorbeeld systemen waarin sommige gegevens in wezen een showcase-cache zijn, dat wil zeggen dat de bron van updates zich achter het systeem zelf bevindt en dat de systemen niet veranderen. Deze data. Voor deze aanpak gebruiken we lokale cafeïnecache.
En er zijn gegevens die het systeem actief verandert tijdens het gebruik, en hier gebruiken we al een gedistribueerde cache met Hazelcast. Deze aanpak stelt ons in staat de voordelen van een gedistribueerde cache te gebruiken waar ze echt nodig zijn, en de servicekosten van het circuleren van Hazelcast-clustergegevens te minimaliseren waar we het zonder kunnen. We hebben veel over caches geschreven. и .
Bovendien gaf het veranderen van de serializer naar Kryo in Hazelcast ons een goede boost. En dankzij de overgang van ReplicatedMap naar IMap + Near Cache in Hazelcast konden we de verplaatsing van gegevens binnen het cluster minimaliseren.
Een klein advies: in het geval van massale ongeldigverklaring van de cache is de tactiek van het opwarmen van de tweede cache en het vervolgens overschakelen ernaar soms van toepassing. Het lijkt erop dat we met deze aanpak een dubbel geheugenverbruik zouden moeten bereiken, maar in de praktijk daalde het geheugenverbruik in de systemen waar dit werd toegepast.
Reactieve stapel
We gebruiken de reactieve stapel in een vrij groot aantal systemen. In ons geval is dit Webflux of Kotlin met coroutines. De reactieve stapel is vooral goed wanneer we langzame invoer-uitvoerbewerkingen verwachten. Bijvoorbeeld oproepen naar langzame services, werken met het bestandssysteem of opslagsystemen.
Het belangrijkste principe is om te voorkomen dat oproepen worden geblokkeerd. Reactieve raamwerken hebben een klein aantal live servicethreads onder de motorkap. Als we onszelf achteloos toestaan een directe blokkeringsoproep te doen, zoals een JDBC-stuurprogrammaoproep, komt het systeem eenvoudigweg tot stilstand.
Probeer fouten om te zetten in uw eigen runtime-uitzondering. De feitelijke stroom van programma-uitvoering verschuift naar reactieve raamwerken, en code-uitvoering wordt niet-lineair. Als gevolg hiervan is het erg moeilijk om problemen te diagnosticeren met behulp van stacktraces. En de oplossing hier zou zijn om voor elke fout duidelijke, objectieve runtime-uitzonderingen te creëren.
Elasticsearch
Wanneer u Elasticsearch gebruikt, selecteer dan geen ongebruikte gegevens. Dit is in principe ook een heel eenvoudig advies, maar meestal wordt dit vergeten. Als u meer dan 10 records tegelijk moet selecteren, moet u Scroll gebruiken. Om een analogie te gebruiken: het lijkt een beetje op een cursor in een relationele database.
Gebruik geen postfilter tenzij dit noodzakelijk is. Met grote gegevens in het hoofdvoorbeeld wordt de database door deze bewerking enorm belast.
Gebruik waar van toepassing bulkbewerkingen.
API
Neem bij het ontwerpen van een API eisen op voor het minimaliseren van verzonden gegevens. Dit geldt vooral in verband met de voorkant: op dit kruispunt gaan we verder dan de kanalen van onze datacenters en werken we al aan het kanaal dat ons met de klant verbindt. Als er ook maar het minste probleem is, veroorzaakt te veel verkeer een negatieve gebruikerservaring.
En tot slot: gooi geen hele hoop data weg, maar wees duidelijk over het contract tussen consumenten en leveranciers.
Organisatorische transformatie
Eroshkina Elena, adjunct-directeur IT
Op het moment dat quarantaine plaatsvond en de noodzaak ontstond om het tempo van de online ontwikkeling sterk te verhogen en omnichanneldiensten te introduceren, bevonden we ons al in het proces van organisatorische transformatie.
Een deel van onze structuur werd overgebracht naar het werken volgens de principes en praktijken van de productaanpak. Er zijn teams gevormd die nu verantwoordelijk zijn voor de werking en ontwikkeling van elk product. Medewerkers in dergelijke teams zijn 100% betrokken en structureren hun werk met behulp van Scrum of Kanban, afhankelijk van wat voor hen de voorkeur heeft, het opzetten van een implementatiepijplijn, het implementeren van technische praktijken, kwaliteitsborgingspraktijken en nog veel meer.
Gelukkig bevond het grootste deel van onze productteams zich op het gebied van online en omnichannel dienstverlening. Hierdoor konden we in de kortst mogelijke tijd (serieus, letterlijk in twee dagen) overschakelen naar de modus voor werken op afstand, zonder verlies van efficiëntie. Dankzij het op maat gemaakte proces konden we ons snel aanpassen aan nieuwe werkomstandigheden en een vrij hoog tempo van levering van nieuwe functionaliteit handhaven.
Bovendien moeten we de teams versterken die zich op de grens van online zakendoen bevinden. Op dat moment werd duidelijk dat we dit alleen met interne middelen konden doen. En ongeveer 50 mensen veranderden in twee weken tijd het gebied waar ze voorheen werkten en raakten betrokken bij het werken aan een product dat nieuw voor hen was.
Hiervoor waren geen speciale managementinspanningen nodig, omdat we, naast het organiseren van ons eigen proces, de technische verbetering van het product en de kwaliteitsborgingspraktijken, onze teams leren om zichzelf te organiseren - om hun eigen productieproces te beheren zonder dat daar administratieve middelen bij betrokken zijn.
We konden onze managementmiddelen precies daar inzetten waar het op dat moment nodig was: op de afstemming met de business: wat is op dit moment belangrijk voor onze klant, welke functionaliteit moet eerst worden geïmplementeerd, wat moet er gebeuren om onze doorvoercapaciteit te vergroten Bestellingen bezorgen en verwerken. Dit alles en een duidelijk rolmodel hebben het in deze periode mogelijk gemaakt om onze productiewaardestromen te laden met wat echt belangrijk en noodzakelijk is.
Het is duidelijk dat met werken op afstand en een hoog tempo van veranderingen, wanneer bedrijfsindicatoren afhankelijk zijn van ieders deelname, je niet alleen kunt vertrouwen op interne gevoelens uit de serie ‘Gaat alles goed met ons? Ja, het lijkt goed.” Er zijn objectieve maatstaven van het productieproces nodig. We hebben deze, ze zijn beschikbaar voor iedereen die geïnteresseerd is in de statistieken van productteams. Allereerst het team zelf, het bedrijf, de onderaannemers en het management.
Eens in de twee weken wordt met elk team een status bijgehouden, waarbij gedurende 10 minuten metrics worden geanalyseerd, knelpunten in het productieproces worden geïdentificeerd en een gezamenlijke oplossing wordt ontwikkeld: wat kan er gedaan worden om deze knelpunten weg te nemen. Hier kunt u direct de hulp van het management inroepen als een geïdentificeerd probleem buiten de invloedssfeer van de teams ligt, of de expertise van collega's die mogelijk al met een soortgelijk probleem zijn geconfronteerd.
We begrijpen echter dat we, om meerdere keren te kunnen accelereren (en dit is precies het doel dat we onszelf hebben gesteld), nog veel moeten leren en implementeren in ons dagelijks werk. Op dit moment blijven we onze productaanpak uitbreiden naar andere teams en nieuwe producten. Om dit te doen, moesten we een nieuw format voor ons onder de knie krijgen: een online school van methodologen.
Methodologen, mensen die teams helpen een proces op te bouwen, communicatie tot stand te brengen en de werkefficiëntie te verbeteren, zijn in essentie agenten van verandering. Op dit moment werken afgestudeerden van ons eerste cohort met teams en helpen ze succesvol te worden.
Ik denk dat de huidige situatie kansen en perspectieven voor ons opent waar we ons misschien nog niet volledig van bewust zijn. Maar de ervaring en praktijk die we nu opdoen bevestigt dat we de juiste ontwikkelingsweg hebben gekozen, dat we deze nieuwe kansen in de toekomst niet zullen missen en net zo effectief zullen kunnen reageren op de uitdagingen waarmee Sportmaster te maken krijgt.
Bevindingen
In deze moeilijke tijd hebben we de belangrijkste principes geformuleerd waarop softwareontwikkeling rust, die volgens mij relevant zullen zijn voor elk bedrijf dat hiermee te maken heeft.
Mensen. Dit is waar alles op berust. Werknemers moeten plezier hebben in hun werk en de doelstellingen van het bedrijf en de doelstellingen van de producten waaraan ze werken begrijpen. En natuurlijk konden ze zich professioneel ontwikkelen.
Технология. Het is noodzakelijk dat het bedrijf een volwassen benadering hanteert bij het werken met zijn technologische stack en competenties opbouwt waar dat echt nodig is. Het klinkt heel simpel en voor de hand liggend. En heel vaak genegeerd.
processen. Het is belangrijk om het werk van productteams en competentiecentra goed te organiseren, interactie met het bedrijf tot stand te brengen en er als partner mee samen te werken.
Over het algemeen hebben we zo ongeveer overleefd. De belangrijkste stelling van onze tijd werd opnieuw bevestigd, met een daverende klik op het voorhoofd
Zelfs als u een enorm offline bedrijf bent met veel winkels en een aantal steden waar u actief bent, kunt u uw online bedrijf ontwikkelen. Dit is niet alleen een extra verkoopkanaal of een mooie applicatie waarmee je ook iets kunt kopen (en ook omdat concurrenten ook mooie hebben). Dit is geen reservewiel dat je zomaar kunt gebruiken om de storm te doorstaan.
Dit is een absolute noodzaak. Waarop niet alleen uw technische mogelijkheden en infrastructuur voorbereid moeten zijn, maar ook uw mensen en processen. U kunt immers binnen een paar uur snel extra geheugen en ruimte kopen, nieuwe instances implementeren, enz. Maar mensen en processen moeten daar vooraf op voorbereid zijn.
Bron: www.habr.com