Mis aitas meil kiiresti üle minna online-müügile uutes tingimustes

Tere!

Minu nimi on Mihhail, ma olen IT alal asekohtunik ettevõttes „Sportmaster”. Soovin jagada lugu, kuidas me toime tulime raskustega, mis tekkisid pandeemia ajal.

Uute olude esimestel päevadel peatus Sportmasteri traditsiooniline jaemüük, samas kui meie veebikanali koormus, eriti kliendile kohaletoimetamise osas, suurenes 10 korda. Mõne nädalaga muutsime meie tohutu offline-äri online-äri ja kohandasime teenust klientide vajadustega.

Tegelikult see, mis oli meie kõrvaltegevus, muutus peamiseks äritegevuseks. Iga veebitellimuse tähtsus suurenes äärmuslikult. Igast rublast, mille klient firmasse tõi, tuli kinni hoida. 

Klienditaotluste kiireks töötlemiseks avasime ettevõtte peahoones täiendava kontaktkeskuse, mis võimaldab meil vastu võtta umbes 285 000 kõnet nädalas. Samuti muutsime 270 poodi uue kontaktivaba ja ohutu töövormi, mis võimaldas klientidel tellimusi saada ning töötajatel oma töökohti hoida.

Transformatsiooni käigus seisime silmitsi kahe peamise probleemiga. Esiteks, meie veebiteenuste koormus kasvas oluliselt (kuidas me sellega hakkama saime, räägib Sergei). Teiseks, haruldaste (enne COVID-i) tehingute arv kasvas märgatavalt, mis omakorda nõudis kiiret automatiseerimist. Selle probleemi lahendamiseks pidime kiiresti suunama ressursse varasemalt peamistelt suundadelt. Kuidas me sellega toime tulime, räägib Elena.

Veebiteenuste kasutamine

Kolesnikov Sergei, vastutab e-poe ja mikroteenuste haldamise eest

Alates hetkest, mil meie jaemüügipoed suleti külastajatele, hakkasime märkama selliste näitajate kasvu nagu kasutajate arv, meie rakenduses tehtud tellimuste arv ning rakenduste päringute arv. 

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

Esimesel graafikul näeme, et kasv oli umbes 14 korda, teisel — 4 korda. Kõige väljakutsuvamaks peame meie rakenduste vastuse aegade mõõdikut. 

Sellel graafikul näeme frontide ja rakenduste vastuseid, ning oleme järeldanud, et mingit märkimisväärset kasvu me ei märganud.

Esiteks on see seotud sellega, et alustasime eeltöödega 2019. aasta lõpus. Praegu on meie teenused reserveeritud, tagatud on talitluspidevuse taseme saavutamine füüsilistel serveritel, virtualiseerimise süsteemidel, konteineritel ja teenustel nende sees. Samuti võimaldab meie serveriteressursside maht taluda korduvat koormust.

Peamine tööriist, mis aitas meid kogu selle olukorra juures, on meie jälgimissüsteem. Tõsi, veel hiljuti polnud meil ühtset süsteemi, mis võimaldaks koguda mõõdikuid kõigilt kihtidelt, alates füüsilise riistvara ja seadmete tasemest kuni ärimõõdikuteni. 

Formaalselt oli ettevõttes seire olemas, kuid enamasti oli see hajutatud ning kuulus konkreetsete osakondade vastutusele. Tegelikult, kui juhtus mõni intsident, oli meil peaaegu kunagi ühtset arusaama selle kohta, mis täpselt juhtus, ei olnud teavitamist, ning see viis sageli ringi jooksmiseni probleemi leidmiseks ja lokaliseerimiseks selle edasisteks lahendamiseks.

Mõnes etapis mõtlesime, et piisab, ja otsustasime, et vajame ühtset süsteemi, et näha kogu pilti tervikuna. Meie tehnoloogiate peamine killustik sisaldab Zabbixi, mis on alarmide ja mõõdikute salvestamise keskus, Prometheust rakenduste mõõdikute kogumiseks ja salvestamiseks, Stack ELK logimise ja kogu seireandmete salvestamiseks, samuti Grafanat visualiseerimiseks, Swaggerit, Dockerit ja muid kasulikke ning tuttavaid vahendeid.

Kasutame mitte ainult turul olemasolevaid tehnoloogiaid, vaid arendame ka mõned ise. Näiteks loome teenuseid süsteemide omavaheliseks integreerimiseks, see tähendab mingit API-d mõõdikute kogumiseks. Lisaks töötame välja oma jälgimissüsteeme — äri mõõdikute tasandil kasutame UI-testimist. Ja ka Telegramis bot, et meeskondi teavitada.

Ja veel püüame muuta jälgimissüsteemi meeskondadele kergesti kättesaadavaks, et nad saaksid ise oma mõõdikuid salvestada ja nendega töötada, sealhulgas seadistada häireid kitsastes mõõdikutel, millel pole laiemat kasutust. 

Kogu süsteemi piires püüdleme me proaktiivsuse ja võimalikult kiire intsidendi lokaliseerimise poole. Lisaks on meie mikroteenuste ja süsteemide arv viimastel aegadel oluliselt kasvanud, mistõttu suureneb ka integratsioonide hulk. Intsidendi diagnostika protsessi optimeerimise raames arendame süsteemi, mis võimaldab teha rist-süsteemseid kontrollimisi ja esitada tulemusi, aidates leida peamised probleemid, mis on seotud impordiga ja süsteemide omavahelise interaktsiooniga. 

Muidugi on meil veel palju arenguruumi süsteemide ekspluateerimise valdkonnas, ja me töötame selle nimel aktiivselt. Rohkem teavet meie jälgimissüsteemi kohta leiate siit. 

Tehnilised katsed 

Sergei Orlov, juhib veeb- ja mobiiliarenduse kompetentsikeskust

Alates füüsiliste kaupluste sulgemisest oleme pidanud silmitsi seisma erinevate arenduslikke proovikivide ja raskustega. Esiteks, koormuse tõus kui selline. On selge, et kui ei võeta tarvitusele meetmeid, võib süsteem suurt koormust taluda püüdes kurva plahvatusega kõrvitsaks muutuda, kas täielikult jõudluse kaotada või isegi täiesti töövõimetuks muutuda.

Teine aspekt, mis on veidi vähem ilmne, seisneb selles, et kõrge koormusega süsteemi tuli väga kiiresti muuta, kohanedes äriprotsesside muutustega. Mõnikord mitu korda päevas. paljudes ettevõtetes on reegel, et suurte turundustegevuste ajal ei tohiks süsteemi mingeid muudatusi teha. Üldse mitte, las see töötab, kui see töötab.

Meil oli aga sisuliselt lõputu must reede, mille käigus tuli süsteemi muuta. Ja iga viga, probleem või süsteemi tõrge oleks äridele väga kulukas.

Koheselt ütlen, et me suutsime nende katsumustega toime tulla, kõik süsteemid talusid koormust, skaleerusid hõlpsasti ning tõsiseid tehnilisi tõrkeid meil ei olnud.

On neli peamist alust, millele toetub süsteemi võime taluda kõrgeid järske koormusi. Esimene neist on jälgimine, millest olete varem lugenud. Ilma korraliku jälgimissüsteemita on süsteemi kitsaskohtade leidmine pea võimatu. Hea jälgimissüsteem on nagu kodu riided — see peab olema mugav ja teile sobiv.

Teine aspekt on testimine. Me võtame seda teemat väga tõsiselt: kirjutame klassikalisi üksuste, integratsiooni ja koormusteste ning palju muud igas süsteemis. Me koostame ka testimisstrateegia ja püüame viia testimise taseme selliseks, et me ei peaks enam käsitsi kontrollimisi tegema.

Kolmas vaal on CI/CD Pipeline. Rakenduse saate-, testimis- ja juurutamisprotsessid peavad olema võimalikult automatiseeritud, käsitsi sekkumisi ei tohi olla. CI/CD Pipeline teema on piisavalt sügav ja ma puudutan seda vaid kergelt. Tuleb mainida, et meil on CI/CD Pipeline'i kontrollnimekiri, mille alusel läbib iga toote meeskond kompetentsikeskuste abiga.

Siin on kontrollnimekiri

Nii saavutatakse palju eesmärke. See hõlmab API versioneerimist ja funktsioonide lülitamist, et vältida versioonide ‘rongi’, samuti erinevate testide katmise saavutamist sellisel tasemel, et testimine oleks täielikult automatiseeritud, juurutamine oleks sujuv jne.

Neljas vaal on arhitektuuri põhimõtted ja tehnilised lahendused. Arhitektuurist saab rääkida palju ja pikka aega, kuid soovin rõhutada paari põhimõtet, millele soovin tähelepanu juhtida.

Esiteks tuleb valida spetsialiseeritud tööriistad konkreetsete ülesannete jaoks. Jah, see kõlab iseenesestmõistetavalt, ja on selge, et naela tuleks taguda haamriga, samas kui käekellade demonteerimiseks tuleks kasutada spetsiaalseid kruvikeerajaid. Kuid meie ajastul püüavad paljud tööriistad universaliseeruda, et katta maksimaalne kasutajasegment: andmebaasid, vahemälud, raamistikud ja muu. Näiteks, kui võtta andmebaas MongoDB, siis see toetab mitmeid dokumentide tehinguid, samas kui andmebaas Oracle toetab JSON-e. Ja näiliselt võiks öelda, et kõike võib kasutada igaks otstarbeks. Kuid kui me räägime efektiivsusest, peame selgelt mõistma iga tööriista tugevusi ja nõrkusi ning kasutama neid vastavalt meie ülesannetele. 

Teiseks, süsteemide projekteerimisel peab iga keerukuse tõus olema põhjendatud. Me peame seda pidevalt meeles pidama, madala seotuse põhimõte on kõigile teada. Ma arvan, et seda tuleks kasutada nii konkreetse teenuse tasandil kui ka kogu süsteemi ja arhitektuuri maastiku tasandil. Samuti on oluline, et iga süsteemi komponent suudaks koormuse korral horisontaalselt skaleeruda. Kui see võime on olemas, ei ole skaleerimine mingisugune probleem.

Kui rääkida tehnilistest lahendustest, palusime tootegruppidel valmistada ette värskendatud soovituste, ideede ja lahenduste kogum, mida nad on ellu viinud ettevalmistustes järgmise koormuse laineks.

Vahemälud

Kohalike ja jaotatud vahemälude valikusse tuleb läheneda teadlikult. Mõnikord on mõistlik kasutada nii ühte kui teist süsteemi raames. Näiteks on meil süsteeme, kus osa andmeid on sisuliselt vitriinivahemälu, st uuenduste allikas asub süsteemi taga ning süsteem ei muuda neid andmeid. Selle lähenemise jaoks kasutame kohalikku Caffeine Cache'i. 

Ja on andmeid, mida süsteem aktiivselt muudetakse tööprotsessis, ja siin rakendame me jaotatud vahemälu Hazelcastiga. Selline lähenemine võimaldab meil kasutada jaotatud vahemälu eeliseid seal, kus need on tõeliselt vajalikud, ja minimeerida teenuste kulu Hazelcasti klastrite andmete ringlusele seal, kus me saame ilma selleta hakkama. Oleme vahemäludest palju kirjutanud. siit ja siit.

Lisaks andis Hazelcasti serialiseerija vahetamine Kryole meile üsna hea kasvu. Ja üleminek ReplicatedMapilt IMapile koos Near Cache'iga Hazelcastis võimaldas meil minimeerida andmete liikumist klastris. 

Väike nõuanne: massilise vahemälu tühistamise korral on mõnikord rakendatav taktika teise vahemälu soojendamisega ning sellele üleminekuga. Tundub, et sel juhul peaksime saama topeltmälu kasutuse, kuid praktikas nende süsteemide puhul, kus sarnast on praktiseeritud, vähenes mälu kasutamine.

Reaktiivne korrus

Kasutame reaktiivset tehnoloogiat juba piisavalt paljudes süsteemides. Meie puhul on need Webflux või Kotlin koos korutaatidega. Erakordselt hästi sobib reaktiivne tehnoloogia kohtadesse, kus ootame aeglaseid sisend-väljund operatsioone. Näiteks aeglaste teenuste kõned, failisüsteemiga töötamine või andmesalvestussüsteemide kasutamine.

Kõige olulisem põhimõte on vältida blokeerivaid kõnesid. Reaktiivsete raamistikude taga töötab väikestes kogustes elavaid teenusevooge. Kui me ettevaatlikult ei käitu ja teeme otsese blokeeriva kõne, nagu näiteks JDBC-draiveri kõne, siis süsteem lihtsalt peatub. 

Püüdke muuta vead oma omadeks runtime exception’iteks. Tõeline programmi täitmisvoog läheb reaktiivsetesse raamistikesse, koodi täitmine muutub mittelineaarseks. Seetõttu on probleeme steki jälgede kaudu väga keeruline diagnoosida. Lahenduseks on selgete, objektiivsete runtime exception’ite loomine iga vea jaoks.

Elasticsearch

Elasticsearchi kasutamisel vältige kasutamata andmete valimist. See on, põhimõtteliselt, väga lihtne nõuanne, kuid sageli unustatakse seda. Kui tuleb korraga valida rohkem kui 10 000 kirjet, tuleks kasutada Scrolli. Kui tuua paralleel, sarnaneb see veidi relatsioonilise andmebaasi kursori kasutamisega. 

Ärge kasutage postfilteri ilma vajaduseta. Suurte andmehulkade korral peamise valiku puhul koormab see operatsioon andmebaasi väga tugevalt. 

Kasutage seal, kus see on kohane, bulk-operatsioone.

API

API projekteerimisel arvestage nõudmisi edastatavate andmete minimeerimise osas. See on eriti oluline front-endiga seondumisel: just sellel ristmikul liigume välja meie andmekeskuste kanalitest ja töötame juba kanalil, mis seob meid kliendiga. Kui seal esinevad isegi kõige väiksemad probleemid, põhjustab liiga kõrge liiklus negatiivset kasutajakogemust.

Ja lõpuks, ärge visake kogu andmehulk välja, olge täpsed lepingus tarbijate ja pakkujate vahel.

Organisatsiooniline transformatsioon

Elenna Eroshkina, IT asedirektor

Quarantine took place, and the need to rapidly increase the pace of online development and implement omnichannel services arose, our organizational transformation was already underway. 

Part of our structure was transitioned to operate based on product management principles and practices. Teams were formed that are now responsible for the functioning and development of each product. Employees in these teams are fully engaged and organize their work using Scrum or Kanban, depending on what works best for them, set up deployment pipelines, implement technical practices, quality assurance practices, and much more.

By a happy coincidence, the majority of these product teams were already focused on online and omnichannel services. This allowed us to transition to remote work mode in a very short time (seriously, literally within two days) without losing efficiency. The established process enabled quick adaptation to new working conditions while maintaining a high pace of delivering new functionality.

Lisaks on meil olnud vajadus tugevdada neid meeskondi, mis on online-äritegevuse eesliinil. Sel hetkel sai selgeks, et saame seda teha ainult sisemiste ressursside arvelt. Ligikaudu 50 inimest vahetas kahe nädala jooksul oma senist töövaldkonda ja astus uue, neile seni tundmatu toote arendusse. 

Selleks ei olnud vaja mingeid erik tehtud juhtimisjõupingutusi, kuna oma protsessi korraldamise, toote tehnilise täiustamise ja kvaliteedikindluse praktikaga koos õpetame oma meeskondi eneseorganiseerimisele — juhendame neid oma tootmisprotsessi juhtima ilma administratiivsete ressursside kaasamiseta.

Meie juhtimisressursid suudame suunata just sinna, kus see hetkel vajalik on, — koostöös äri ja teiste partneritega: Mis on hetkel meie kliendi jaoks oluline, milline funktsionaliteet peaks esmajärjekorras rakenduma, mida on vaja teha, et suurendada meie tellimuste täitmise ja töötlemise suutlikkust. Kõik see ja selge rollimudel lubasid meil sel perioodil koormata meie väärtuse loomise tootmisvooge sellega, mis tõeliselt oluline ja vajalik on. 

Selge on see, et kaugtöös ja kiirete muutuste tempos, kus igaühe panus mõjutab äritulemusi, ei saa toetuda ainult sisetunde põhjalikele küsimustele, nagu 'Kas me kõik teeme hästi? Jah, nagu tundub, on kõik korras.' On vajalikud objektiivsed mõõdikud tootmisprotsessist. Need on meil olemas ja kergesti kättesaadavad kõigile, kes huvituvad tooteteamade mõõdikutest. Esiteks meeskonnale endale, äriühingule, kaasosalistele ja juhtkonnale.

Iga kahe nädala tagant toimub iga meeskonna koosolek, kus 10 minuti jooksul analüüsitakse näitajaid, tuvastatakse tootmisprotsessi kitsaskohad ja leitakse ühiselt lahendusi, et neid kitsaskohti kõrvaldada. Siinkohal on võimalik otse paluda juhtkonna abi, kui mõni tuvastatud probleem jääb meeskondade mõjupiirist välja või vajab kolleegide spetsiifilist teadmiste abi, kes on võib-olla juba sarnaste probleemidega kokku puutunud.

Küll aga mõistame, et meie eesmärgi, nimelt kiiruselt mitmekordistumise saavutamiseks, peame me õppima ja rakendama palju uusi teadmisi igapäevases töös. Just praegu laiendame toote lähenemist teistele meeskondadele ja uutele toodetele. Selleks oleme pidanud õppima uut, meile seni tundmatut online-koolitajate formaati.

Koolitajad, kes aitavad meeskondadel protsesse üles ehitada, suhtlemist korraldada ja tööhõivet tõsta, on sisuliselt muutuste agendid. Just praegu töötavad meie esimese lennu lõpetajad meeskondadega, aidates neil edukaks saada. 

Ma arvan, et praegune olukord avab meile võimalusi ja perspektiive, millest me võib-olla veel täielikult aru ei saa. Kuid see kogemus ja praktika, mida me praegu omandame, kinnitavad, et oleme valinud õige arengu suuna, et saaksime tulevikus kasutada neid uusi võimalusi ning tõhusalt vastata ootustele, mis «Sportmasteri» ees seisavad.

Järeldused

Selle keerulise aja jooksul oleme sõnastanud peamised printsiibid, millel põhineb tarkvara arendamine, mis, nagu ma usun, on asjakohased igasugusele ettevõttele, mis sellega tegeleb.

InimesedSee on see, mille peal kõik põhineb. Töötajad peavad saama oma tööst rõõmu tunda, mõistma ettevõtte eesmärke ja tooteid, millega nad tegelevad. Ja loomulikult peaksid nad saama ka professionaalselt areneda. 

TehnoloogiaOn vajalik, et ettevõte läheneks oma tehnoloogia virnale küpselt ja kasvataks oskusi seal, kus see tõeliselt vajalik on. See kõlab väga lihtsalt ja tõeliselt ilmse asjana. Ja seda ignoreeritakse väga sageli.

Protsessid. Oluline on õigesti korraldada toote meeskondade ja ekspertkeskuste tööd ning luua koostöö äriga, et suhelda nendega kui partneritega.

Üldiselt saime kuidagi hakkama. Tänapäeva peamine tees kinnitust leidis veel korra, vali kõlksatus peas.

Isegi kui oled tohutu offline-äri, millel on palju poode ja hulk linnu, kus tegevust tähistad, arenda oma online kohalolekut. See pole vaid lisamüügikanal ega ilus rakendus, mille kaudu midagi osta (ja ka seetõttu, et konkurentidel on samuti ilus). See ei ole varuvariant, mis aitab tormi üle elada.

See on täiesti vajalik. Selleks peavad olema valmis mitte ainult teie tehnilised ressursid ja infrastruktuur, vaid ka inimesed ja protsessid. Lõppude lõpuks on kiiresti lisada mäluruumi, ruumi, avada uusi instantsse ja muud lihtsalt. Kuid inimesi ja protsesse tuleb selliseks ette valmistada eelnevalt.

Allikas: habr.com