Përshëndetje!
Më quajnë Mikhail, jam zëvendësdrejtor i IT në kompaninë «Sportmaster». Dua të ndaj një histori mbi mënyrën se si përballuam sfidat që u shfaqën gjatë pandemisë.
Në ditët e para të realiteteve të reja, formati i zakonshëm offline i tregtisë «Sportmaster» u ngrit, dhe ngarkesa në kanalin tonë online, kryesisht në aspektin e dorëzimeve në adresën e klientëve, u rrit 10 herë. Brenda disa javësh, ne transformuam një biznes offline të madh në online, duke e adaptuar shërbimin sipas nevojave të klientëve tanë.
Në tërësi, ajo që në thelb ishte operacioni ynë dytësor, u bë biznesi ynë kryesor. Rëndësia e çdo porosie online u rrit ekstremisht. Duhej të ruanim çdo lek që klienti sillte në kompani.
Për të reaguar shpejt ndaj kërkesave të klientëve, hapëm një qendër të re kontakti në selinë e kompanisë, dhe tani mund të pranojmë rreth 285,000 telefonata në javë. Në të njëjtën kohë, ne kaluam 270 dyqane në një format të ri pa kontakt dhe të sigurt, çka u mundësoi klientëve të merrnin porositë, ndërsa punonjësit ruajtën vendet e tyre të punës.
Gjatë procesit të transformimit, hasëm dy probleme kryesore. Së pari, ngarkesa në burimet tona online u rrit ndjeshëm (se si e kemi trajtuar këtë, do të tregojë Sergey). Së dyti, fluksi i operacioneve të rralla (para COVID) u rrit shumë, gjë që kërkoi një volum të madh automatizimi të shpejtë. Për të zgjidhur këtë problem, na duhej të transferonim shpejt burimet nga sektorët që ishin më parë kryesorë. Si ia dolëm, do të tregojë Elena.
Funksionimi i shërbimeve online
Kolesnikov Sergey, përgjigjet për funksionimin e dyqanit online dhe mikroshërbimeve
Që nga momenti kur dyqanet tona me pakicë filluan të mbyllen për vizitorët, filluam të regjistronim rritje të metrikeve të tilla si numri i përdoruesve, numri i porosive të bëra në aplikacionin tonë, numri i kërkesave për aplikacionet.
Numri i porosive nga 18 deri më 31 mars
Numri i kërkesave për mikroshërbimet e pagesave online
Numri i porosive të bëra në faqe
Në grafikun e parë shohim se rritja ishte afërsisht 14 herë, ndërsa në të dytin – 4 herë. Metrika më treguese në këtë rast është koha e përgjigjes së aplikacioneve tona.
Në këtë grafik shohim përgjigjet e fronteve dhe aplikacioneve, dhe për vete e kemi përcaktuar se nuk kemi vënë re ndonjë rritje të dukshme.
Kjo është kryesisht e lidhur me faktin se filluam punimet përgatitore në fund të vitit 2019. Tani shërbimet tona janë të rezervuara, është siguruar qëndrueshmëria në nivelin e serverëve fizikë, sistemeve të virtualizimit, dockerëve dhe shërbimeve brenda tyre. Megjithatë, kapacitetet e burimeve tona serverike na lejojnë të përballojmë ngarkesa shumëfish.
Instrumenti kryesor që na ndihmoi në të gjithë këtë histori ishte sistemi ynë i monitorimit. Megjithatë, sapo nuk kishim një sistem të unifikuar i cili do të lejonte mbledhjen e metrikave në të gjitha nivelet, nga niveli i pajisjeve fizike dhe hardware-it deri te metrikat e biznesit.
Formalisht, monitorimi në kompaninë tonë ka ekzistuar, por zakonisht ai ka qenë i shpërndarë dhe nën përgjegjësinë e departamenteve të veçanta. Në fakt, kur ndodhte ndonjë incident, ne kurrë nuk kishim një kuptim të përbashkët për atë që kishte ndodhur, nuk kishte informacion dhe shpeshherë kjo çonte në një cikël të pafund kërkimesh dhe lokalizimi të problemit për zgjidhje të mëvonshme.
Në ndonjë moment ne menduam dhe vendosëm që mjaft është mjaft — na nevojitet një sistem i vetëm për të parë të gjithë pamjen në tërësi. Teknologjitë kryesore që përfshihen në stack-un tonë janë Zabbix si qendra e alarmimit dhe ruajtjes së metrikeve, Prometheus për mbledhjen dhe ruajtjen e metrikeve të aplikacioneve, Stack ELK për regjistrimin dhe ruajtjen e të dhënave të sistemit të monitorimit, si dhe Grafana për vizualizim, Swagger, Docker dhe gjëra të tjera të dobishme e të njohura për ju.
Ne vetëm që përdorim teknologjitë e disponueshme në treg, por gjithashtu zhvillojmë disa gjëra vetë. Për shembull, ne krijojmë shërbime për integrimin e sistemeve me njëri-tjetrin, pra një API për mbledhjen e statistikave. Po ashtu punojmë për sistemet tona të monitorimit — në nivelin e metrikeve të biznesit përdorim teste UI. Gjithashtu, kemi një bot në Telegram për njoftimin e ekipeve.
Në të njëjtën kohë, ne përpiqemi ta bëjmë sistemin e monitorimit të arritshëm për ekipet, në mënyrë që ato të mund të ruajnë vetë statistikat e tyre dhe të punojnë me to, përfshirë konfigurimin e alarmeve në disa metrika të ngushta, që kanë një përdorim jo shumë të gjerë.
Në të gjithë sistemin, ne synojmë proaktivitetin dhe lokalizimin sa më të shpejtë të incidenteve. Për më tepër, numri i mikroshërbimeve dhe sistemeve tona është rritur ndjeshëm kohët e fundit, dhe po ashtu po rritet numri i integrimeve. Në kuadër të optimizimit të procesit të diagnostikimit të incidenteve në nivelin e integrimit, ne po zhvillojmë një sistem që lejon kryerjen e kontrollimeve ndër-sistem dhe nxjerrjen e rezultateve, duke mundësuar gjetjen e problemeve kryesore që lidhen me importet dhe ndërveprimin e sistemeve me njëra-tjetrën.
Natyrisht, ne kemi ende për të ecur përpara dhe zhvilluar në aspektin e operimit të sistemeve, dhe ne po punojmë aktivisht mbi këtë. Më shumë në lidhje me sistemin tonë të monitorimit mund të lexoni .
Operacionet teknike
Sergei Orlov, drejton qendrën e kompetencës për zhvillimin e uebit dhe aplikacioneve mobile
Që nga fillimi i mbylljes së dyqaneve fizike, na është dashur të përballemi me një sërë sfidash nga këndvështrimi i zhvillimit. E para dhe kryesore është rritja e ngarkesës. E qartë është se, nëse nuk merren masat përkatëse, sistemi mund të shndërrohet me një goditje të trishtuar në një kungull, ose të degradojë ndjeshëm në performancë, ose të humbasë plotësisht funksionalitetin e tij.
Aspekti i dytë, pak më pak i dukshëm, është se sistemi nën ngarkesë të lartë duhej të ndryshohej shumë shpejt, duke u përshtatur me ndryshimet e proceseve të biznesit. Ndonjëherë disa herë në ditë. në shumë kompani ka një rregull që, gjatë aktiviteteve të mëdha marketingu, nuk duhen bërë ndryshime në sistem. Asnjë ndryshim, le të funksionojë, pasi funksionon.
Dhe ne, në thelb, kishim një e premte të zezë të pafund, në të cilën duhej të ndryshonim sistemin. Çdo gabim, problem, apo dështim në sistem do të kishte kosto shumë të larta për biznesin.
Duke përpara, dua të them se arritëm të përballojmë këto sfida, të gjitha sistemet përballuan ngarkesën, u shkallëzuan lehtësisht dhe nuk patëm ndonjë prishje teknike globale.
Ekzistojnë katër shtylla mbi të cilat mbështetet kapaciteti i sistemit për të përballuar ngarkesat e larta. Shtylla e parë është monitorimi, për të cilin lexuat pak më lart. Pa një sistem monitorimi të strukturuar, është praktikisht e pamundur të gjejmë vendet e ngushta në sistem. Një sistem i mirë monitorimi është si veshja për shtëpi, duhet të jetë e rehatshme dhe e përshtatur për ju.
Aspekti i dytë është testimi. Ne e marrim këtë çështje shumë seriozisht: shkruajmë teste klasike njësish, integruese, teste ngarkese dhe shumë të tjera për çdo sistem. Gjithashtu, ne shkruajmë një strategji testimi dhe mundohemi ta çojmë nivelin e testimit në një pikë që verifikimet manuale të mos na nevojiten më.
Kiti i tretë është CI/CD Pipeline. Proceset e ndërtimit, testimit dhe distribuimit të aplikacionit duhet të jenë sa më automatizuar, pa ndërhyrje manuale. Tema e CI/CD Pipeline është mjaft e thellë, dhe unë do ta përmend vetëm në përgjithësi. Është e rëndësishme të përmendet se ne kemi një listë kontrolli për CI/CD Pipeline, sipas së cilës kalon çdo ekip produkti me ndihmën e qendrave të kompetencës.
Ja lista e kontrollit
Kështu arrihen shumë qëllime. Kjo është versionimi i API-ve, dhe ndërrimi i veçorive për të shmangur daljen e grumbulluar të lëshimeve, si dhe arritja e mbulimit të testeve në një nivel të tillë që testimi të jetë tërësisht automatizuar, deployt të jenë pa probleme dhe shumë të tjera.
Kiti i katërt janë parimet arkitekturore dhe zgjidhjet teknike. Mund të flasësh shumë dhe gjatë për arkitekturën, por dua të theksoj disa principe mbi të cilat do doja të fokusohem.
Së pari, duhet të zgjedhim mjete të specializuara për detyra të veçanta. Po, duket e qartë, dhe është e kuptueshme që duhet të godisni thikat me një hammer, ndërsa për të shkuar orët dore, duhet të përdorni screwdriver të veçantë. Por në epokën tonë, shumë mjete kërkojnë të bëhen universale, për të kapur sa më shumë përdorues: databaza, cache-t, framework-et dhe të tjera. Për shembull, nëse e marrim databazën MongoDB, ajo punon me transaksione multi-dokumentar, ndërsa databaza Oracle punon me json. Dhe duke e parë kështu, duket se gjithçka mund të përdoret për gjithçka. Por nëse ne mbrojmë performancën, duhet të kuptojmë qartë pikat e forta dhe të dobëta të secilit mjet dhe të përdorim ato që na nevojiten për klasën tonë të detyrave.
Në të dytën, kur projektimi i sistemeve, çdo rritje e kompleksitetit duhet të justifikohet. Duhet ta kemi vazhdimisht në mendje këtë, parimi i low coupling është i njohur për të gjithë. Unë mendoj se duhet ta aplikojmë si në nivelin e shërbimit të veçantë, ashtu edhe në nivelin e gjithë sistemit, dhe në nivelin e peizazhit arkitektonik. Po ashtu, aftësia për të shkallëzuar horizontalisht çdo komponent të sistemit në rast ngarkese është e rëndësishme. Nëse e kemi këtë aftësi, shkallëzimi nuk do të jetë aspak i vështirë.
Në lidhje me zgjidhjet teknike, i kërkuam ekipeve produktore të përgatitin një grup të ri rekomandimesh, ideve dhe zgjidhjeve që ata kanë realizuar gjatë përgatitjes për valën e re të ngarkesës.
Keshat
Është e nevojshme të qasemi me kujdes në zgjedhjen e keshave lokale dhe të shpërndara. Ndonjëherë ka kuptim të përdorim të dyja brenda një sistemi. Për shembull, ne kemi sisteme në të cilat një pjesë e të dhënave në thelb është kesh i vitrinës, domethënë burimi i përditësimeve ndodhet pas vetë sistemit, dhe këto sisteme nuk i ndryshojnë këto të dhëna. Për këtë qasje ne përdorim Caffeine Cache lokal.
Ka janë të dhëna që sistemi i ndryshon aktivisht në procesin e punës, dhe këtu ne zbatojmë një cache të shpërndarë me Hazelcast. Ky qasje na lejon të përdorim përfitimet e cache-it të shpërndarë aty ku ato vërtet nevojiten dhe të minimizojmë shpenzimet e shërbimeve për qarkullimin e të dhënave në klasterin Hazelcast aty ku mund të shmangim këtë. Ne kemi shkruar shumë për cache-t. dhe .
Për më tepër, ndërrimi i serializuesit në Kryo në Hazelcast na dha një rritje të mirë. Kalimi nga ReplicatedMap në IMap + Near Cache në Hazelcast na lejoj të minimizojmë lëvizjen e të dhënave nëpër klaster.
Një këshillë e vogël: kur bëhet një invalizim masiv i cache-it, ndonjëherë taktika e ngrohjes së cache-it të dytë me kalimin e mëpasshëm në të është e aplikueshme. Mund të duket se me këtë qasje do të kemi dyfishim të konsumit të memories, por në praktikë, në sistemet ku diçka e tillë është praktikuar, konsumimi i memories është ulur.
Stoku reaktiv
Ne përdorim një grusht reaktiv në një numër të konsiderueshëm sistemesh. Në rastin tonë, kjo është Webflux ose Kotlin me coroutine. Grushti reaktiv funksionon veçanërisht mirë aty ku presim operacione të ngadalta input-output. Për shembuj, thirrjet ndaj shërbimeve të ngadalta, punimi me sistemin e skedarëve ose sistemet e ruajtjes.
Principi më i rëndësishëm është të shmangni thirrjet bllokuese. Nën kapak, kuptimi i kornizave reaktive funksionon me një numër të vogël të rasteve shërbimi aktive. Nëse me kujdes lejojmë një thirrje të drejtpërdrejtë bllokuese, si p.sh. thirrja e drejtuesit JDBC, sistemi do të ndalojë thjesht.
Përpiquni të ktheni gabimet në përjashtime runtime të duhura. Rrjedha reale e ekzekutimit të programit kalon në kornizat reaktive, ekzekutimi i kodit bëhet jo-linear. Si pasojë, është shumë e vështirë të diagnostikoni problemet përmes stack trace. Një zgjidhje këtu do të ishte krijimi i përjashtimeve runtime objektive të qarta për çdo gabim.
Elasticsearch
Kur përdorni Elasticsearch, mos zgjidhni të dhëna të papërdorura. Kjo është një këshillë shumë e thjeshtë, por shpesh harrohet. Nëse nevojitet të zgjidhen më shumë se 10 mijë të dhëna njëherësh, duhet të përdorni Scroll. Nëse bëni një analogji, kjo është paksi si një kursor në një bazë të dhënash relationale.
Mos përdorni postfilter pa nevojë. Kur keni të dhëna të mëdha në përzgjedhjen kryesore, kjo operacion ngarkon shumë databazën.
Përdorni operacione bulk aty ku është e aplicueshme.
API
Kur projektoni API, parashikoni kërkesat për minimizimin e të dhënave të transmetuara. Kjo është veçanërisht e rëndësishme në lidhje me frontin: pikërisht në këtë pikë, ne dalim jashtë kanaleve të Qendrave tona të Të Dhënave dhe punojmë në kanalin që na lidh me klientin. Nëse ka probleme më të vogla në të, një trafik shumë i lartë shkakton një përvojë negative për përdoruesin.
Dhe, përfundimisht, mos e nxirrni gjithë grumbullin e të dhënave, qasuni me kujdes kontratës midis konsumatorëve dhe ofruesve.
Transformimi organizativ
Eroshkina Elena, zëvendës drejtoresha për IT
Në momentin kur u shpall karantina dhe u shfaq nevoja për të rritur ndjeshëm ritmin e zhvillimit online dhe për të implementuar shërbime omnikanale, ne ishim tashmë në procesin e transformimit organizativ.
Një pjesë e strukturës sonë u kalua në punën sipas parimeve dhe praktikave të qasjes produktive. U formuan skuadra që tani janë përgjegjëse për funksionimin dhe zhvillimin e çdo produkti. Punonjësit në këto skuadra janë angazhuar 100% dhe ndjekin metodologjitë Scrum ose Kanban, në varësi të asaj që preferojnë, duke krijuar linjat e shpërndarjes, duke implementuar praktikat teknike, praktikat e sigurimit të cilësisë dhe shumë të tjera.
Kështu ndodhi që shumica e këtyre skuadrave produktive ishin pikërisht në fushën e shërbimeve online dhe omnikanale. Kjo na lehtësoi të kalonim në një mod të punës nga distanca në një kohë shumë të shkurtër (seriozisht, për dy ditë) pa humbur efikasitetin. Procesi i vendosur na lehtësoi të adaptoheshim shpejt në kushtet e reja të punës dhe të mbajmë një ritëm të lartë të dërgimit të funksionaliteteve të reja.
Përveç kësaj, na u krijua nevoja për të forcuar ekipet që janë në vijën e parë të biznesit online. Në atë moment u kuptua se mund ta bënim këtë vetëm duke përdorur burimet tona të brendshme. Rreth 50 persona brenda dy javësh ndryshuan fushën ku kishin punuar më parë dhe u inkuadruan në punën mbi një produkt të ri për ta.
Për këtë nuk kishte nevojë për ndonjë përpjekje të veçantë menaxheriale, sepse përveç organizimit të procesit tonë, për përmirësimin teknik të produktit, dhe për praktikën e sigurimit të cilësisë, ne i mësojmë ekipet tona të vetëorganizohen — të menaxhojnë procesin e tyre prodhues pa angazhimin e burimeve administrative.
Ne e thjesht një burim menaxhimi që arritëm ta fokusojmë aty ku ishte e nevojshme në atë moment, – në koordinimin me biznesin: Çfarë është e rëndësishme tani për klientin tonë, cila funksionalitet duhet të realizohet si prioritet, çfarë duhet të bëjmë për të rritur kapacitetin tonë të shpërndarjes dhe përpunimit të porosive. Të gjitha këto, së bashku me një model të qartë rolesh, na ndihmuan të ngarkonim proceset tona prodhuese me atë që vërtet është e rëndësishme dhe e nevojshme gjatë kësaj periudhe.
Sigurisht, në punën e largët dhe me një ritëm të lartë ndryshimesh, kur rezultate e biznesit varen nga pjesëmarrja e secilit, nuk mund të mbështetesh vetëm te ndjenjat e brendshme si "A po shkon mirë? Po, duket mirë." Nevojiten metrika objektive të procesit prodhues. Këto i kemi, dhe janë të disponueshme për çdo person që intereson për metrikat e ekipeve të produkteve. Para së gjithash, për ekipin vetë, biznesin, kolegët dhe menaxhimin.
Çdo dy javë, me çdo ekip zhvillohet një status, ku brenda 10 minutave analizohet metrikat, identifikohen ngushticat e procesit të prodhimit dhe krijohet një zgjidhje e përbashkët: çfarë mund të bëjmë për t'i eliminuar ato ngushtica. Aty mund të kërkoni gjithashtu ndihmë nga menaxhimi nëse ndonjë problem i identifikuar është jashtë fuqisë së ekipeve, ose ekspertizës së kolegëve që ndoshta kanë hasur në një problem të ngjashëm.
Megjithatë, ne e kuptojmë se për të arritur një shpejtësi të herëshme (kjo është pikërisht qëllimi ynë), na nevojitet të mësojmë shumë dhe ta implementojmë atë në punën tonë të përditshme. Tani po vazhdojmë të zgjerim qasjen produktore në ekipe të tjera dhe në produkte të reja. Për këtë na duhej të mjeshtronim një format të ri për ne, shkollën online të metodologëve.
Metodologët, njerëzit që ndihmojnë ekipet të ndërtojnë procesin, të përmirësojnë komunikimin, të rrisin efikasitetin e punës, në thelb janë agjentë të ndryshimit. Tani, absolventët e grupit tonë të parë po punojnë me ekipet dhe i ndihmojnë ato të bëhen të suksesshme.
Mendoj se situata aktuale po na ofron mundësi dhe perspektiva të tilla që ndoshta ende nuk i kuptojmë plotësisht. Por përvoja dhe praktika që po marrim tani po konfirmon se kemi zgjedhur rrugën e duhur për zhvillim, dhe nuk do t'i humbasim këto mundësi të reja në të ardhmen, duke qenë në gjendje të përgjigjemi po ashtu në mënyrë efektive ndaj sfidave që do të paraqiten para "Sportmaster".
Përfundimet
Gjatë kësaj periudhe të vështirë, ne formulua parimet kryesore mbi të cilat mbështetet zhvillimi i software-it, të cilat mendoj se do të jenë relevante për çdo kompani që merret me këtë.
Njerëzit. Kjo është ajo mbi të cilën mbështetet gjithçka. Punonjësit duhet të gëzojnë punën, të kuptojnë qëllimet e kompanisë dhe qëllimet e produkteve me të cilat punojnë. Dhe, sigurisht, duhet të kenë mundësi për zhvillim profesional.
Teknologjia. Është e nevojshme që kompania të qaset me maturi ndaj punës me teknologjinë e saj dhe të rrisë kompetencat aty ku është e nevojshme. Duket shumë e thjeshtë dhe e dukshme. Dhe shpesh herë injorohet.
Proceset. Është e rëndësishme të ndërtohet saktë puna e ekipeve produktive dhe qendrat e kompetencës, të krijohet bashkëpunimi me biznesin, që të punosh me të si me një partner.
Në përgjithësi, kështu e kaluam. Tezë kryesore e modernitetit u konfirmua edhe një herë, duke klikuar fort në ballë.
Edhe nëse je një biznes i madh offline me shumë dyqane dhe shumë qytete, zhvillo online-n tënd. Kjo nuk është thjesht një kanal i hapur për shitje ose një aplikacion i bukur përmes të cilit mund të blini diçka (dhe as sepse konkurentët kanë gjithashtu ndonjë gjë të bukur). Kjo nuk është një rezervë për rastet e këqija, që do të ndihmojë për të kaluar stuhinë.
Kjo është një domosdoshmëri e vërtetë. Në të cilën duhet të jenë të gatshëm jo vetëm kapacitetet teknike dhe infrastruktura juaj, por edhe njerëzit dhe proceset. Sepse mund të blihen shpejt kujtesë, hapësirë, të zhvillohen instance të reja dhe gjëra të tjera brenda disa orëve. Por njerëzit dhe proceset duhet të përgatiten për këtë më parë.
Burimi: habr.com
