Mis aitas meil kiiresti uutes tingimustes online-kaubandusele üle minna

Tere!

Minu nimi on Mihhail, olen IT-direktori asetäitja ettevõttes „Sportmaster”. Soovin jagada lugu sellest, kuidas me toime tulime koroonapandeemia ajal tekkinud väljakutsedega.

Uute reaalsuste esimeses päeva meie tavapärane offline-müügiformaat „Sportmasteris” seiskus, ja koormus meie veebikanalile, eelkõige kohaletoimetamise osas, suurenes kümme korda. Paari nädala jooksul muutsime tohutu mahu offline-äri veebiks, kohandades teenuseid meie klientide vajadustega.

Kokkuvõttes muutus see, mis oli meie kõrvaltoiming, meie põhitegevuseks. Iga interneti tellimuse tähtsus suurenes äärmiselt. Oli vajalik säilitada iga rubla, mille klient ettevõttesse tõi. 

Kliendipäringutele kiire vastamise tagamiseks avasime peakorteris lisakontaktikeskuse, ja nüüd suudame vastu võtta umbes 285 tuhat kõnet nädalas. Samal ajal muutsime 270 poodi uue kontaktivaba ja ohutu töö formati, mis võimaldas klientidel tellimusi vastu võtta ja töötajatel töökohti säilitada.

Töötamise käigus tundsime kahte peamist probleemi. Esiteks, meie veebiresursside koormus suurenes järsult (kuidas me sellega toime tulime, räägib Sergei). Teiseks, COVID-eelset haruldaste operatsioonide voog kasvas mitmekordselt, mis omakorda nõudis suurt hulka kiiret automatiseerimist. Selle probleemi lahendamiseks pidime kiiresti suunama ressursse sektoritest, mis olid varem peamised. Kuidas me sellega hakkama saime - räägib Elena.

Veebiteenuste kasutamine

Koliesnikov Sergei, vastutab veebipoe ja mikroteenuste kasutamise eest

Sellest hetkest, kui meie jaekauplused hakkasid külastajatele sulguma, oleme hakanud fikseerima kasvu sellistes näitajates nagu kasutajate arv, tellimuste arv, mis meie rakenduses vormistatakse, rakendustele saadetavate päringute arv. 

Tellimuste arv 18. kuni 31. märtsiniPäringute arv veebimaksete mikroteenusteleVeebilehel vormistatud tellimuste arv

Esimesel graafikul näeme, et kasvõi suurus on ligikaudu 14 korda, teisel - 4 korda. Meie arvates on kõige silmapaistvam selle juures meie rakenduste vastuse aeg. 

Sellel graafikul näeme, et nii front-end kui rakenduste vastused ei ole märgatavat kasvu toonud.

See on peamiselt tingitud sellest, et alustasime ettevalmistustöid 2019. aasta lõpus. Praegu on meie teenused reserveeritud ning tagatud on füüsiliste serverite, virtualiseerimissüsteemide ja konteinerite tasemel tõrketaluvus. Samuti suudavad meie serverivõimsused taluda korduvaid koormusi.

Peamine tööriist, mis aitas meid kogu selle protsessi käigus, oli meie jälgimissüsteem. Tõsi, veel hiljuti puudus meil ühtne süsteem, mis võimaldaks koguda mõõdikuid kõigil tasanditel, alates füüsilise varustuse ja riistvara tasemest kuni äri mõõdikute tasemeni. 

Kuigi ettevõttes oli formaalselt jälgimine olemas, oli see reeglina hajutatud ja vastutuseks olid konkreetsed osakonnad. Tegelikult, kui juhtus mõni intsident, ei olnud meil peaaegu kunagi ühtset arusaama sellest, mis täpselt juhtus, ei olnud teavitamist ning see viis sageli ringikõndimisele probleemi paikamiseks ja lahendamiseks.

Mõnes mõttes jõudsime järeldusele, et on aeg lõpetada see talumine – meil on vaja ühtset süsteemi, et näha kogu pilti. Meie tehnoloogiakuhjas on peamised tehnoloogiad Zabbix, mis on alarmeerimise ja mõõdikute hoiustamise keskus, Prometheus rakenduste mõõdikute kogumiseks ja hoidmiseks, Stack ELK logimise ja kogu jälgimissüsteemi andmete hoidmiseks ning Grafana visualiseerimiseks, samuti Swagger, Docker ja teised tuttavad ja kasulikud vahendid.

Kasutame mitte ainult turul olevaid tehnoloogiaid, vaid arendame ka mõningaid asju ise. Näiteks loome teenuseid süsteemide omavaheliseks integreerimiseks, see tähendab teatud API-d mõõdikute kogumiseks. Lisaks töötame oma jälgimissüsteemide kallal – äri mõõdikute tasemel kasutame UI-teste. Samuti oleme loonud Telegrami boti meeskondade teavitamiseks.

Püüdleme ka selle poole, et jälgimissüsteem oleks meeskondadele kergesti kättesaadav, et nad saaksid iseseisvalt oma mõõdikuid hoida ja nendega töötada, sealhulgas seadistada teatud kitsastes mõõdikutest alarme, millel ei ole ulatuslikku rakendust. 

Kogu süsteemi raames püüdleme proaktiivsuse ja kiireima võimaliku intsidentide lokaliseerimise poole. Samuti on meie mikroteenuste ja süsteemide arv viimase aja jooksul oluliselt kasvanud, seega suureneb ka integratsioonide arv. Protsesside diagnostika optimeerimise raames arendame süsteemi, mis võimaldab teostada rist-süsteemseid kontrolle ja kuvada tulemusi, mis aitavad leida põhiprobleeme, mis on seotud impordiga ja süsteemidevahelise koostööga. 

Muidugi on meil veel ruumi kasvada ja areneda süsteemide haldamises ning me teeme selle nimel aktiivselt tööd. Lisainfot meie jälgimissüsteemi kohta saab lugeda siin. 

Tehnilised katsed 

Sergei Orlov, juhib veeb- ja mobiiliarenduse kompetentsikeskust

Alates füüsiliste poodide sulgemisest oleme pidanud silmitsi seisma erinevate väljakutsetega arenduse vaatenurgast. Esiteks koormuse järsk tõus. On selge, et kui ei tehta vastavaid meetmeid, siis võib süsteem kõrge koormuse korral kurva plahvatusega kõrvitsaks muutuda, kas täielikult degradeeruda tootlikkuses või hoopis oma töövõimet kaotada.

Teine aspekt, veidi vähem ilmne, seisneb selles, et kõrge koormusega süsteemi tuli väga kiiresti muuta, kohandades seda ärihoogude muutustega. Mõnikord mitu korda päevas. Paljudes ettevõtetes kehtib reegel, et suurtel turundustegevustel ei tohiks süsteemis mingeid muudatusi teha. Üldse mitte, las töötab, kui töötab.

Meil oli põhimõtteliselt lõputu must reede, mille käigus tuli süsteemi muuta. Ja iga viga, probleem või tõrge süsteemis maksaks äri kalliks.

Eelnevalt öeldes, saame kinnitada, et meil õnnestus nendel katsetel toime tulla, kõik süsteemid talusid koormust, kohandusid kergesti ja suuri tehnilisi tõrkeid meil ei olnud.

On systeemi suutlikkuse suurte pingete kestmiseks toetuvad neli peamist pillarohtu. Esimene neist on monitooring, millest olete natuke varem lugenud. Ilma korralikult üles ehitatud monitooringusüsteemita on peaaegu võimatu leida süsteemi kitsaskohti. Hea monitooringusüsteem on nagu mugavad koduriided, see peab olema mugav ja teie vajadustele kohandatud.

Teine aspekt on testimine. Me võtame seda väga tõsiselt: kirjutame klassikalisi ühik- ja integreerimisteste, koormusteste ja palju muud iga süsteemi jaoks. Samuti koostame testimistrategia ja püüdleme selle poole, et viia testimise tase selleni, et me enam ei vajaks käsitsi kontrolle.

Kolmas pillihoidja on CI/CD torujuhe. Rakenduse ehitamise, testimise ja juurutamise protsessid peavad olema maksimaalselt automatiseeritud, seal ei tohiks olla käsitsi sekkumisi. CI/CD torujuhe on piisavalt sügav teema ning ma käsitlen seda vaid pinnapealselt. Tuleb vaid mainida, et meil on CI/CD torujuhi kontrollnimekiri, mille abil toimub iga toote meeskonna läbivaatamine kompetentsikeskustes.

Ja siin on kontrollnimekiri

Sellega saavutatakse väga palju eesmärke. See on API versioonimine, funktsioonide lülitamine, et vältida ülekoormatud väljalaskepäevi ja erinevate testide katte saavutamine sellisel tasemel, et testimine oleks täielikult automatiseeritud, juurutamised oleks sujuvad jne.

Neljas pillihoidja on arhitektuuripõhimõtted ja tehnilised lahendused. Arhitektuurist võiks pikalt ja laialdaselt rääkida, kuid soovin rõhutada mõningaid põhimõtteid, millele tahaksin tähelepanu juhtida.

Esiteks tuleb valida spetsialiseeritud tööriistad konkreetsete ülesannete jaoks. Jah, see kõlab ilmse tõena, ja on selge, et naelu tuleb lüüa haamriga, samas kui kellade lahtivõtmiseks on vaja spetsiaalseid kruvikeerajaid. Kuid meie ajastul pürgivad paljud tööriistad universaalsuse poole, et katta võimalikult suur kasutajate segment: andmebaasid, vahemäolid, raamistike ja muu puhul. Näiteks, kui võtta andmebaas MongoDB, siis see töötab mitme dokumendi tehingutega, samas kui andmebaas Oracle töötab json failidega. Ja tundub, et kõike saab kasutada igasugusteks otstarveteks. Kuid kui me hoolime sooritusest, peame selgelt mõistma iga tööriista tugevusi ja nõrkusi ning kasutama just neid, mis sobivad meie ülesande klassile. 

Teiseks, süsteemide projekteerimisel peab iga keerukuse tõus olema põhjendatud. Me peame seda pidevalt meeles pidama, madala sidususe põhimõte on kõigile teada. Ma usun, et seda tuleb rakendada nii konkreetse teenuse tasemel, kogu süsteemi tasemel kui ka arhitektuurilises maastikus. Samuti on oluline iga süsteemi komponendi horisontaalse skaleerimise võime koormuse ajal. Kui omada seda võimet, ei valmista skaleerimine mingit raskust.

Kui rääkida tehnilistest lahendustest, palusime tootmisrühmadel valmistada ette värske soovituste, ideede ja lahenduste kogum, mida nad on ellu viinud järgmise koormuslaine ettevalmistamise käigus.

Vahemälud

Tuleb teadlikult läheneda kohapealsete ja jaotatud vahemälte valikule. Mõnikord on mõistlik kasutada mõlemat ühe süsteemi raames. Näiteks meil on süsteeme, kus osa andmeid on sisuliselt vitriinja paigaldatav vahemälu, see tähendab, et uuenduste allikas asub süsteemi taga ja need süsteemid neid andmeid ei muuda. Sellise lähenemise jaoks kasutame kohalikku Caffeine Cache-i. 

Aga on ka andmeid, mida süsteem aktiivselt töötamise ajal muudab, ja siin rakendame jaotatud vahemälu Hazelcastiga. Selline lähenemine võimaldab meil kasutada jaotatud vahemälu eeliseid seal, kus need tõeliselt vajalikud on, ja minimeerida teeninduskulusid andmete ringluses Hazelcasti klastris seal, kus me saame ilma selleta hakkama. Oleme vahemälude kohta palju kirjutanud. siin ja siin.

Lisaks andis Hazelcasti serialiseerija vahetus Kryole meile märkimisväärse kasvu. Samuti võimaldas Hazelcasti üleminek ReplicatedMapilt IMapile + Near Cachel andmete liikumise minimeerimist klastris. 

Väike nõuanne: massilise vahemälu tühjendamise korral võib mõnikord rakendada teise vahemälu soojendamise takti, millele järgneb sellele üleminek. Tundub, et selle lähenemise korral peaksime saama topeltmälu tarbimise, kuid praktikas, nendes süsteemides, kus seda on praktiseeritud, vähenes mälutarbimine.

Reaktiivne kiht

Kasutame reaktiivset kihti juba piisavalt suurel hulgal süsteemides. Meie puhul on see Webflux või Kotlin koorusidega. Eriti hästi sobib reaktiivne kiht seal, kus ootame aeglaseid sisend-väljundoperatsioone. Näiteks aeglaste teenuste kutsumine, failisüsteemist või salvestussüsteemidest töötamine.

Kõige olulisem põhimõte on vältida blokeerivaid kutseid. Reaktiivsete raamistikud all töötavad vähesed elavad teenuse niidid. Kui lubame endale ettevaatamatult teha otsese blokeeriva kutse, nagu näiteks JDBC-draiveri kutse, peatub süsteem lihtsalt. 

Püüdke muuta vead oma käivitusaja eranditeks. Tõeline programmi teostamine läheb reaktiivsetesse raamistikudesse, koodi teostamine muutub mittelineaarseks. Selle tagajärjel on väga keeruline diagnoosida probleeme virnastamiste kaudu. Lahendus on iga vea jaoks arusaadavate objektiivsete käitusaegsete erandite loomine.

Elasticsearch

Elasticsearchi kasutamisel ärge valige kasutamata andmeid. See on põhimõtteliselt ka väga lihtne nõuanne, kuid enamus inimesi unustab selle. Kui tuleb valida korraga rohkem kui 10 000 kirjet, tuleb kasutada Rullimist. Kui teha analoogia, on see veidi sarnane rikka andmebaasi kursoriga. 

Ärge kasutage postfilterit ilma vajaduseta. Suurte andmete puhul põhivalikus koormab see operatsioon andmebaasi väga tugevalt. 

Kasutage bulk-operatsioone seal, kus see on kohaldatav.

API

API projekteerimisel kaaluge nõudeid edastatavate andmete minimoimiseks. See on eriti oluline front-endiga seondumisel: just seal, kus me ületame meie andmekeskuste kanalid ja töötame juba kanali kaudu, mis ühendab meid kliendiga. Kui sellel on kõige väiksemad probleemid, põhjustab liiga kõrge liiklus negatiivset kasutajakogemust.

Ja lõpuks, ärge laske kogu andmemassi voolata, vaid lähenemise lepingule tarbijate ja tarnijate vahel peaks olema selge.

Organisatsiooniline transformatsioon

Elena Eroškina, IT-direktori asetäitja

Hetkel, mil karantiin toimus ja vajadus kiiruselt suurendada online-teenuste arendust ning rakendada omnichannel teenuseid, olime juba organisatsioonilise transformatsiooni protsessis. 

Osa meie struktuurist viidi üle töötama toote lähenemise põhimõtete ja praktikate kohaselt. Moodustati meeskonnad, mis nüüd vastutavad iga toote toimimise ja arengu eest. Nendes meeskondades on töötajad 100% hõivatud ja korraldavad oma tööd scrumi või kanbani järgi, sõltuvalt sellest, mis neile sobib, seadistavad juurutamise protsessi, rakendavad tehnilisi praktikaid, kvaliteedihaldust ja palju muud.

Kuna suur osa neist tootemeeskondadest asus meil just online- ja omnichannel-teenuste valdkonnas, võimaldas see meil lühikese ajaga (ausalt öeldes, vaid kahe päevaga) üle minna kaug töötamise režiimile ilma efektiivsuse kaotuseta. Hästi seadistatud protsess võimaldas kiiresti uute töötingimustega kohaneda ja hoida kõrget uusi funktsionaalsuse pakkumise tempo.

Lisaks tekkis meil vajadus tugevdada neid meeskondi, mis asuda online-äri esirinnas. Sel hetkel sai selgeks, et saame seda teha ainult sisemiste ressursside arvelt. Umbes 50 inimest kahe nädalaga vahetasid ala, kus nad varem töötasid, ja integreerusid uue toote kallal töötamisse. 

Selleks ei olnud vaja mingeid erilisi juhtimispingutusi, kuna koos enda protsessi korraldamise, toote tehnilise täiustamise ja kvaliteedihalduse praktikatega õpetame oma meeskondi iseorienteeruma — juhtima oma tootmisprotsessi ilma administratiivsete ressurssideta.

Juhtimisressursi oleme suutnud suunata just sinna, kus see hetkel vajalik oli – koostöös ärihuvidega: Mis on hetkel meie kliendi jaoks oluline, millised funktsioonid peavad esimesena ellu viidud olema, mida tuleb teha, et suurendada meie võimet tellimuste kohaletoimetamiseks ja töötlemiseks. Kõik see ning selge rollimudel võimaldas meil sel perioodil koormata meie väärtuse loomise tootmisvooge sellega, mis on tõeliselt oluline ja vajalik. 

Selge on see, et kaugelt töötades ja kiirete muudatustega, kui igaühe osalus mõjutab ettevõtte tulemusi, ei saa tugineda pelgalt sisetunde jälgimisele, näiteks „Kas meil kõik sujub? Tundub, et päris hästi.” Vajame objektiivseid tootmisprotsessi mõõdikuid. Meil on need olemas, need on kergesti kätte saadavad kõigile, kes huvituvad tootmeeskondade mõõdikest. Ennekõike nendele, kes kuuluvad meeskonda, ärile, osakondadele ja juhtkonnale.

Iga kahe nädala tagant toimub koosolek igas meeskonnas, kus 10 minut jooksul analüüsitakse mõõdikuid, tuvastatakse tootmisprotsessi kitsaskohad ja töötatakse välja ühiselt lahendused: mida saame teha, et need kitsaskohad kõrvaldada. Sellega koos on võimalik kohe küsida abi juhtkonnalt, kui mõni tuvastatud probleem jääb meeskondadeulatusest välja, või kolleegide ekspertiisilt, kes on võib-olla sarnaste probleemidega juba kokku puutunud.

Kuid samas mõistame, et meie eesmärkide, millest me lähtume, kiireks saavutamiseks peame me veel palju õppima ja rakendama seda igapäevases töös. Just praegu jätkame toote lähenemise laienemist teistele meeskondadele ja uutele toodetele. Selleks oleme pidanud õppima uut online-koolituse formaati metodoloogide jaoks.

Metodoloogid, kes aitavad meeskondadel protsesse üles ehitada, suhtlemist korraldada ja töö efektiivsust tõsta, on tegelikult muutuste agendid. Just praegu töötavad meie esimese kursuse lõpetanud meeskondadega ja aitavad neil edukaks saada. 

Ma arvan, et olukord, milles me praegu oleme, avab meile sellised võimalused ja perspektiivid, mida me võib-olla veel täielikult ei teadvusta. Kuid see kogemus ja praktika, mida me hetkel saame, tõestab, et oleme valinud õige arengu tee, ei jäta tulevikus neid uusi võimalusi kasutamata ning suudame tõhusalt vastata nendele väljakutsetele, mis seisavad «Sportmasteri» ees.

Järeldused

Selle keerulise aja jooksul oleme formuleerinud peamised põhimõtted, millele tuginevad tarkvaraarendused ja mis, arvan, kehtivad iga ettevõtte jaoks, mis sellega tegeleb.

Inimesed. See on see, mille ümber kõik pöörleb. Töötajad peavad oma tööst rõõmu tundma, mõistma ettevõtte ja nende toodete eesmärke, millega nad tegelevad. Ja loomulikult saavad nad professionaalselt areneda. 

Tehnoloogia. Oluline on, et ettevõte läheneks küpselt oma teknoloogilistele vahenditele ja kasvataks oma oskusi seal, kus see tõeliselt vajalik on. See kõlab väga lihtsalt ja iseenesestmõistetavalt. Ja väga tihti jääb tähelepanuta.

Protsessid. Oluline on õigesti korraldada tootegruppide ja oskuskeskuste tööd, et luua sujuv koostöö äriettevõttega, töötades selle eest partnerina.

Üldiselt on me sellega enam-vähem ellu jäänud. Kaasaegne teesi on taas kord kinnitust leidnud, teravalt pihta lüües.

Isegi kui oled tohutu jaekett, millel on palju poode ja hulgaliselt kohalike linnade, arenda oma veebi. See ei ole lihtsalt täiendav müügikanal või ilus rakendus, mille kaudu saab midagi osta (ja veel sellepärast, et konkurentidel on ka ilus). See ei ole lihtsalt varuvõimalus, mis aitab tormi üle elada.

See on hädavajalik. Milles peavad olema valmis mitte ainult teie tehnilised vahendid ja infrastruktuur, vaid ka inimesed ja protsessid. Kiiresti mälu ja ruumi juurde ostmine, uute instantside käivitamine ja muu sarnane on võimalik mõne tunni jooksul. Kuid inimesi ja protsesse tuleb selleks eelnevalt ette valmistada.

Allikas: habr.com