Привет!
My naam is Mikhail, ek is die Adjunk-direkteur van IT by die Sportmaster-maatskappy. Ek wil die storie deel van hoe ons die uitdagings wat tydens die pandemie ontstaan het, hanteer het.
In die eerste dae van die nuwe realiteite het die gewone aflyn-handelsformaat van Sportmaster gevries, en die las op ons aanlyn kanaal, hoofsaaklik in terme van aflewering aan die kliënt se adres, het 10 keer toegeneem. In net 'n paar weke het ons 'n reusagtige vanlyn besigheid in 'n aanlyn een omskep en die diens by die behoeftes van ons kliënte aangepas.
Basies, wat in wese ons sy-operasie was, het ons kernbesigheid geword. Die belangrikheid van elke aanlyn bestelling het uiters toegeneem. Dit was nodig om elke roebel te spaar wat die kliënt na die maatskappy gebring het.
Om vinnig op klantversoeke te reageer, het ons 'n bykomende kontaksentrum by die maatskappy se hoofkantoor geopen, en kan nou sowat 285 duisend oproepe per week ontvang. Terselfdertyd het ons 270 winkels na 'n nuwe kontaklose en veilige bedryfsformaat geskuif, wat kliënte in staat gestel het om bestellings te ontvang en werknemers om hul werk te behou.
Tydens die transformasieproses het ons twee hoofprobleme teëgekom. Eerstens het die las op ons aanlyn hulpbronne aansienlik toegeneem (Sergey sal jou vertel hoe ons dit hanteer het). Tweedens het die vloei van seldsame (voor-COVID) bedrywighede baie keer toegeneem, wat op sy beurt 'n groot hoeveelheid vinnige outomatisering vereis het. Om hierdie probleem op te los, moes ons vinnig hulpbronne oordra van gebiede wat voorheen die belangrikste was. Elena sal jou vertel hoe ons dit hanteer het.
Bedryf van aanlyn dienste
Kolesnikov Sergey, verantwoordelik vir die bedryf van die aanlynwinkel en mikrodienste
Vanaf die oomblik dat ons kleinhandelwinkels vir besoekers begin toemaak het, het ons 'n toename in maatstawwe begin aanteken soos die aantal gebruikers, die aantal bestellings wat in ons toepassing geplaas is en die aantal versoeke aan toepassings.
Aantal bestellings vanaf 18 Maart tot 31 MaartAantal versoeke aan aanlynbetalingsmikrodiensteAantal bestellings wat op die webwerf geplaas is
In die eerste grafiek sien ons dat die toename ongeveer 14 keer was, in die tweede - 4 keer. Ons beskou die reaksietyd-metriek van ons aansoeke as die mees aanduidend.
In hierdie grafiek sien ons die reaksie van fronte en toepassings, en vir onsself het ons vasgestel dat ons geen groei as sodanig opgemerk het nie.
Dit is hoofsaaklik te wyte aan die feit dat ons aan die einde van 2019 met voorbereidingswerk begin het. Nou is ons dienste gereserveer, foutverdraagsaamheid word verseker op die vlak van fisiese bedieners, virtualisasiestelsels, dokkers en dienste daarin. Terselfdertyd stel die kapasiteit van ons bedienerhulpbronne ons in staat om veelvuldige vragte te weerstaan.
Die belangrikste hulpmiddel wat ons in hierdie hele storie gehelp het, was ons moniteringstelsel. Dit is waar, tot redelik onlangs het ons nie 'n enkele stelsel gehad wat ons in staat sou stel om metrieke op alle lae te versamel nie, van die vlak van fisiese toerusting en hardeware tot die vlak van besigheidsmetrieke.
Formeel was daar monitering in die maatskappy, maar dit was in die reël versprei en was op die verantwoordelikheidsgebied van spesifieke departemente. Trouens, wanneer 'n voorval plaasgevind het, het ons amper nooit 'n gemeenskaplike begrip gehad van wat presies gebeur het nie, daar was geen kommunikasie nie, en dit het dikwels daartoe gelei dat dit in sirkels gehardloop het om die probleem te vind en te isoleer sodat dit reggestel kon word.
Op 'n stadium het ons gedink en besluit dat ons genoeg het om dit te verduur - ons het 'n verenigde stelsel nodig om die hele prentjie volledig te sien. Die belangrikste tegnologieë wat by ons stapel ingesluit is, is Zabbix as 'n waarskuwing- en statistiekbergingsentrum, Prometheus vir die insameling en berging van toepassingsstatistieke, Stack ELK vir die aanteken en berging van data van die hele moniteringstelsel, asook Grafana vir visualisering, Swagger, Docker en ander nuttige en dinge wat aan jou bekend is.
Terselfdertyd gebruik ons nie net tegnologieë wat op die mark beskikbaar is nie, maar ontwikkel ook van ons eie. Ons maak byvoorbeeld dienste vir die integrasie van stelsels met mekaar, dit wil sê, 'n soort API vir die insameling van metrieke. Boonop werk ons aan ons eie moniteringstelsels – op die vlak van besigheidsmaatstawwe gebruik ons UI-toetse. En ook 'n bot in Telegram om spanne in kennis te stel.
Ons probeer ook om die moniteringstelsel vir spanne toeganklik te maak sodat hulle onafhanklik hul maatstawwe kan stoor en daarmee kan werk, insluitend die opstel van waarskuwings vir 'n paar nou maatstawwe wat nie wyd gebruik word nie.
Dwarsdeur die stelsel streef ons na proaktiwiteit en lokalisering van insidente so vinnig as moontlik. Daarbenewens het die aantal van ons mikrodienste en stelsels die afgelope tyd aansienlik gegroei, en die aantal integrasies het dienooreenkomstig gegroei. En as deel van die optimalisering van die proses om insidente op integrasievlak te diagnoseer, ontwikkel ons 'n stelsel wat u toelaat om kruisstelselkontroles uit te voer en die resultaat te vertoon, wat u in staat stel om die hoofprobleme te vind wat verband hou met invoere en interaksie van stelsels met mekaar.
Ons het natuurlik nog ruimte om te groei en te ontwikkel wat bedryfstelsels betref, en ons werk aktief hieraan. Jy kan meer lees oor ons moniteringstelsel .
Tegniese toetse
Orlov Sergey, hoof van die bevoegdheidsentrum vir web- en mobiele ontwikkeling
Sedert die sluiting van die fisieke winkels begin het, het ons verskeie uitdagings vanuit 'n ontwikkelingsperspektief in die gesig gestaar. Eerstens, die lastoename as sodanig. Dit is duidelik dat as gepaste maatreëls nie getref word nie, wanneer 'n hoë las op die stelsel toegepas word, dit in 'n pampoen met 'n hartseer knal kan verander, of heeltemal afneem in prestasie, of selfs sy funksionaliteit verloor.
Die tweede aspek, 'n bietjie minder voor die hand liggend, is dat die stelsel onder hoë las baie vinnig verander moes word, aanpas by veranderinge in besigheidsprosesse. Soms 'n paar keer per dag. Baie maatskappye het 'n reël dat as daar baie bemarkingsaktiwiteite is, dit nie nodig is om enige veranderinge aan die stelsel aan te bring nie. Glad nie, laat dit werk solank dit werk.
En ons het in wese 'n eindelose Swart Vrydag gehad, waartydens dit nodig was om die stelsel te verander. En enige fout, probleem of mislukking in die stelsel sal baie duur vir die besigheid wees.
As ek vorentoe kyk, sal ek sê dat ons dit reggekry het om hierdie toetse te hanteer, alle stelsels het die las weerstaan, maklik afgeskaal is, en ons het geen wêreldwye tegniese foute ervaar nie.
Daar is vier pilare waarop die stelsel se vermoë om hoë oplewingslae te weerstaan rus. Die eerste daarvan is monitering, waarvan jy net hierbo gelees het. Sonder 'n ingeboude moniteringstelsel is dit byna onmoontlik om stelselbottelnekke te vind. ’n Goeie moniteringstelsel is soos huisklere dit moet gemaklik en pasgemaak wees vir jou.
Die tweede aspek is toetsing. Ons neem hierdie punt baie ernstig op: ons skryf klassieke eenhede, integrasietoetse, lastoetse en vele ander vir elke stelsel. Ons skryf ook 'n toetsstrategie, en probeer terselfdertyd die vlak van toetsing verhoog tot die punt dat ons nie meer handkontroles nodig het nie.
Die derde pilaar is CI/CD Pipeline. Die prosesse van die bou, toets en ontplooiing van 'n toepassing moet so veel as moontlik geoutomatiseer word daar moet geen handmatige ingryping wees nie. Die onderwerp van CI/CD Pipeline is redelik diep, en ek sal dit net kortliks aanraak. Dit is net die moeite werd om te noem dat ons 'n CI/CD Pipeline kontrolelys het, waardeur elke produkspan met behulp van bevoegdheidsentrums gaan.
En hier is die kontrolelys
Op hierdie manier word baie doelwitte bereik. Dit is API-weergawe en kenmerkwisseling om die vrystellingstrein te vermy, en om dekking van verskeie toetse op so 'n vlak te bereik dat toetsing ten volle geoutomatiseer is, ontplooiings naatloos is, ensovoorts.
Die vierde pilaar is argitektoniese beginsels en tegniese oplossings. Ons kan lank baie oor argitektuur praat, maar ek wil 'n paar beginsels beklemtoon waarop ek graag wil fokus.
Eerstens moet jy gespesialiseerde gereedskap vir spesifieke take kies. Ja, dit klink vanselfsprekend, en dit is duidelik dat spykers met 'n hamer ingeslaan moet word, en polshorlosies moet met spesiale skroewedraaiers uitmekaar gehaal word. Maar in ons tyd streef baie instrumente na universalisering om die maksimum segment gebruikers te dek: databasisse, kas, raamwerke en die res. Byvoorbeeld, as jy die MongoDB-databasis neem, werk dit met multi-dokument-transaksies, en die Oracle-databasis werk met json. En dit wil voorkom asof alles vir alles gebruik kan word. Maar as ons vir produktiwiteit staan, moet ons die sterk- en swakpunte van elke instrument duidelik verstaan en die wat ons nodig het vir ons klas take gebruik.
Tweedens, wanneer stelsels ontwerp word, moet elke toename in kompleksiteit geregverdig word. Ons moet dit voortdurend in gedagte hou die beginsel van lae koppeling is aan almal bekend. Ek glo dat dit toegepas moet word op die vlak van 'n spesifieke diens, en op die vlak van die hele stelsel, en op die vlak van die argitektoniese landskap. Die vermoë om elke stelselkomponent langs die laspad horisontaal te skaal, is ook belangrik. As jy hierdie vermoë het, sal skaal nie moeilik wees nie.
Van tegniese oplossings gepraat, ons het produkspanne gevra om 'n nuwe stel aanbevelings, idees en oplossings voor te berei, wat hulle geïmplementeer het ter voorbereiding van die volgende golf van werklading.
Keshi
Dit is nodig om bewustelik die keuse van plaaslike en verspreide kas te benader. Soms maak dit sin om beide binne dieselfde stelsel te gebruik. Ons het byvoorbeeld stelsels waarin sommige van die data in wese 'n vertoonkaskas is, dit wil sê die bron van opdaterings is agter die stelsel self geleë, en die stelsels verander nie. hierdie data. Vir hierdie benadering gebruik ons plaaslike kafeïenkas.
En daar is data wat die stelsel aktief verander tydens werking, en hier gebruik ons reeds 'n verspreide kas met Hazelcast. Hierdie benadering stel ons in staat om die voordele van 'n verspreide kas te gebruik waar dit regtig nodig is, en die dienskoste van die sirkulasie van Hazelcast-groepdata te verminder waar ons daarsonder kan klaarkom. Ons het baie oor caches geskryf. и .
Daarbenewens het die verandering van die serializer na Kryo in Hazelcast ons 'n goeie hupstoot gegee. En die oorgang van ReplicatedMap na IMap + Near Cache in Hazelcast het ons toegelaat om die beweging van data oor die groep te verminder.
'n Bietjie raad: in die geval van ongeldigmaking van massakas, is die taktiek om die tweede kas op te warm en dan daarna oor te skakel soms van toepassing. Dit wil voorkom asof ons met hierdie benadering dubbele geheueverbruik moet kry, maar in die praktyk, in daardie stelsels waar dit beoefen is, het geheueverbruik afgeneem.
Reaktiewe stapel
Ons gebruik die reaktiewe stapel in 'n redelike groot aantal stelsels. In ons geval is dit Webflux of Kotlin met koroutines. Die reaktiewe stapel is veral goed waar ons stadige inset-uitset-bewerkings verwag. Byvoorbeeld, oproepe na stadige dienste, werk met die lêerstelsel of bergingstelsels.
Die belangrikste beginsel is om te verhoed dat oproepe geblokkeer word. Reaktiewe raamwerke het 'n klein aantal lewendige diensdrade wat onder die enjinkap loop. As ons onsself onverskillig toelaat om 'n direkte blokkeeroproep te maak, soos 'n JDBC-bestuurderoproep, sal die stelsel eenvoudig tot stilstand kom.
Probeer om foute in jou eie runtime-uitsondering te verander. Die werklike vloei van programuitvoering verskuif na reaktiewe raamwerke, en kode-uitvoering word nie-lineêr. As gevolg hiervan is dit baie moeilik om probleme met behulp van stapelspore te diagnoseer. En die oplossing hier sou wees om duidelike, objektiewe runtime-uitsonderings vir elke fout te skep.
Elasticsearch
Wanneer jy Elasticsearch gebruik, moenie ongebruikte data kies nie. Dit is in beginsel ook baie eenvoudige raad, maar meestal is dit wat vergeet word. As jy meer as 10 duisend rekords op 'n slag moet kies, moet jy Scroll gebruik. Om 'n analogie te gebruik, is dit 'n bietjie soos 'n wyser in 'n relasionele databasis.
Moenie nafilter gebruik nie, tensy dit nodig is. Met groot data in die hoofmonster, laai hierdie bewerking die databasis baie.
Gebruik grootmaatbewerkings waar van toepassing.
API
Wanneer 'n API ontwerp word, sluit vereistes in vir die minimalisering van oorgedrade data. Dit is veral waar in verband met die front: dit is by hierdie aansluiting dat ons verder gaan as die kanale van ons datasentrums en reeds besig is met die kanaal wat ons met die kliënt verbind. As dit die geringste probleem het, veroorsaak te veel verkeer 'n negatiewe gebruikerservaring.
En laastens, moenie 'n hele klomp data uitgooi nie, wees duidelik oor die kontrak tussen verbruikers en verskaffers.
Organisatoriese transformasie
Eroshkina Elena, adjunkdirekteur vir IT
Op die oomblik toe kwarantyn plaasgevind het, en die behoefte ontstaan het om die tempo van aanlynontwikkeling skerp te verhoog en omnichannel-dienste in te stel, was ons reeds in die proses van organisatoriese transformasie.
'n Deel van ons struktuur is oorgedra om volgens die beginsels en praktyke van die produkbenadering te werk. Spanne is gevorm wat nou verantwoordelik is vir die werking en ontwikkeling van elke produk. Werknemers in sulke spanne is 100% betrokke en struktureer hul werk met behulp van Scrum of Kanban, afhangende van wat verkieslik vir hulle is, die opstel van 'n ontplooiingspyplyn, implementering van tegniese praktyke, gehalteversekeringspraktyke, en nog baie meer.
Met geluk was die grootste deel van ons produkspanne op die gebied van aanlyn- en omnichannel-dienste. Dit het ons in staat gestel om in die kortste moontlike tyd (ernstig, letterlik binne twee dae) na afgeleë werkmodus oor te skakel sonder om doeltreffendheid te verloor. Die pasgemaakte proses het ons in staat gestel om vinnig by nuwe werksomstandighede aan te pas en 'n redelik hoë pas van lewering van nuwe funksionaliteit te handhaaf.
Daarbenewens het ons 'n behoefte om daardie spanne te versterk wat op die grens van aanlyn besigheid is. Op daardie oomblik het dit duidelik geword dat ons dit net met interne hulpbronne kan doen. En sowat 50 mense het in twee weke die area waar hulle voorheen gewerk het, verander en betrokke geraak by die werk aan 'n produk wat vir hulle nuut was.
Dit het geen spesiale bestuurspogings geverg nie, want saam met die organisering van ons eie proses, tegniese verbetering van die produk, en gehalteversekeringspraktyke, leer ons ons spanne om self te organiseer – om hul eie produksieproses te bestuur sonder om administratiewe hulpbronne te betrek.
Ons kon ons bestuurshulpbronne fokus presies waar dit op daardie oomblik nodig was - op koördinering saam met die besigheid: Wat is op die oomblik belangrik vir ons kliënt, watter funksionaliteit moet eerste geïmplementeer word, wat moet gedoen word om ons deurvloeivermoë te verhoog om bestellings af te lewer en te verwerk. Dit alles en 'n duidelike rolmodel het dit gedurende hierdie tydperk moontlik gemaak om ons produksiewaardestrome te laai met dit wat werklik belangrik en nodig is.
Dit is duidelik dat met afgeleë werk en 'n hoë tempo van verandering, wanneer besigheidsaanwysers afhang van almal se deelname, jy nie net kan staatmaak op interne gevoelens van die reeks "Gaan alles goed met ons? Ja, dit lyk goed.” Objektiewe maatstawwe van die produksieproses is nodig. Ons het hierdie, hulle is beskikbaar vir almal wat belangstel in die maatstawwe van produkspanne. Eerstens, die span self, die besigheid, subkontrakteurs en bestuur.
Een keer elke twee weke word 'n status met elke span gehou, waar metrieke vir 10 minute ontleed word, knelpunte in die produksieproses geïdentifiseer word, en 'n gesamentlike oplossing ontwikkel word: wat kan gedoen word om hierdie knelpunte uit te skakel. Hier kan jy dadelik vir hulp van die bestuur vra indien enige geïdentifiseerde probleem buite die invloedsone van die spanne is, of die kundigheid van kollegas wat dalk reeds 'n soortgelyke probleem teëgekom het.
Ons verstaan egter dat om verskeie kere te versnel (en dit is presies die doelwit wat ons vir onsself gestel het), ons nog baie moet leer en dit in ons daaglikse werk implementeer. Op die oomblik gaan ons voort om ons produkbenadering na ander spanne en nuwe produkte te skaal. Om dit te doen, moes ons 'n nuwe formaat vir ons bemeester - 'n aanlyn skool van metodoloë.
Metodoloë, mense wat spanne help om 'n proses te bou, kommunikasie te vestig en werkdoeltreffendheid te verbeter, is in wese agente van verandering. Op die oomblik werk gegradueerdes van ons eerste kohort met spanne en help hulle om suksesvol te word.
Ek dink dat die huidige situasie vir ons geleenthede en vooruitsigte oopmaak waarvan ons dalk self nog nie ten volle bewus is nie. Maar die ervaring en oefening wat ons nou opdoen bevestig dat ons die regte pad van ontwikkeling gekies het, ons sal nie hierdie nuwe geleenthede in die toekoms mis nie en sal net so effektief kan reageer op die uitdagings wat Sportmaster in die gesig staar.
Bevindinge
Gedurende hierdie moeilike tyd het ons die hoofbeginsels geformuleer waarop sagteware-ontwikkeling berus, wat, dink ek, relevant sal wees vir elke maatskappy wat hiermee te doen het.
Mense. Dit is waarop alles berus. Werknemers moet hul werk geniet en die maatskappy se doelwitte en die doelwitte van die produkte waaraan hulle werk, verstaan. En natuurlik kan hulle professioneel ontwikkel.
Технология. Dit is nodig dat die maatskappy 'n volwasse benadering volg om met sy tegnologiestapel te werk en vaardighede op te bou waar dit werklik nodig is. Dit klink baie eenvoudig en voor die hand liggend. En baie dikwels geïgnoreer.
prosesse. Dit is belangrik om die werk van produkspanne en bevoegdheidsentrums behoorlik te organiseer, om interaksie met die onderneming te bewerkstellig om as vennoot daarmee saam te werk.
Oor die algemeen is dit omtrent hoe ons oorleef het. Die hooftesis van ons tyd is weereens bevestig, met 'n dawerende klik op die voorkop
Selfs al is jy 'n groot vanlyn besigheid met baie winkels en 'n klomp stede waar jy werk, ontwikkel jou aanlyn besigheid. Dit is nie net 'n bykomende verkoopskanaal of 'n pragtige toepassing waardeur jy ook iets kan koop nie (en ook omdat mededingers ook pragtiges het). Dit is nie 'n net-in-geval spaarband om jou te help om die storm te weerstaan nie.
Dit is 'n absolute noodsaaklikheid. Waarvoor nie net jou tegniese vermoëns en infrastruktuur voorberei moet word nie, maar ook jou mense en prosesse. U kan immers binne 'n paar uur vinnig ekstra geheue, spasie koop, nuwe gevalle, ens. Maar mense en prosesse moet vooraf hierop voorberei word.
Bron: will.com