Привет!
Unë quhem Mikhail, jam Zëvendës Drejtor i IT në kompaninë Sportmaster. Dua të ndaj historinë se si u përballëm me sfidat që u shfaqën gjatë pandemisë.
Në ditët e para të realiteteve të reja, formati i zakonshëm i tregtimit offline i Sportmaster ngriu dhe ngarkesa në kanalin tonë në internet, kryesisht për sa i përket dërgesës në adresën e klientit, u rrit 10 herë. Në vetëm pak javë, ne transformuam një biznes gjigant offline në një biznes online dhe e përshtatëm shërbimin me nevojat e klientëve tanë.
Në thelb, ajo që ishte në thelb operacioni ynë anësor u bë biznesi ynë kryesor. Rëndësia e çdo porosie online është rritur jashtëzakonisht shumë. Ishte e nevojshme të kursehej çdo rubla që klienti solli në kompani.
Për t'iu përgjigjur shpejt kërkesave të klientëve, ne hapëm një qendër shtesë kontakti në zyrën kryesore të kompanisë dhe tani mund të marrim rreth 285 mijë telefonata në javë. Në të njëjtën kohë, ne zhvendosëm 270 dyqane në një format të ri funksionimi pa kontakt dhe të sigurt, i cili lejoi klientët të merrnin porosi dhe punonjësit të ruanin punën e tyre.
Gjatë procesit të transformimit kemi hasur në dy probleme kryesore. Së pari, ngarkesa në burimet tona në internet është rritur ndjeshëm (Sergey do t'ju tregojë se si e trajtuam këtë). Së dyti, fluksi i operacioneve të rralla (para-COVID) është rritur shumë herë, gjë që kërkonte një sasi të madhe automatizimi të shpejtë. Për të zgjidhur këtë problem, na u desh të transferonim shpejt burimet nga zonat që më parë ishin ato kryesore. Elena do t'ju tregojë se si e trajtuam këtë.
Funksionimi i shërbimeve online
Kolesnikov Sergey, përgjegjës për funksionimin e dyqanit online dhe mikroshërbimeve
Që nga momenti që dyqanet tona të shitjes me pakicë filluan të mbylleshin për vizitorët, ne filluam të regjistronim një rritje të treguesve të tillë si numri i përdoruesve, numri i porosive të bëra në aplikacionin tonë dhe numri i kërkesave për aplikacione.
Numri i porosive nga data 18 mars deri më 31 marsNumri i kërkesave për mikroshërbimet e pagesave në internetNumri i porosive të vendosura në faqen e internetit
Në grafikun e parë shohim se rritja ishte afërsisht 14 herë, në të dytin - 4 herë. Ne e konsiderojmë metrikën e kohës së përgjigjes së aplikacioneve tona si më treguesin.
Në këtë grafik shohim reagimin e fronteve dhe aplikimeve, dhe për veten tonë kemi vendosur që nuk kemi vërejtur ndonjë rritje si të tillë.
Kjo kryesisht për faktin se ne filluam punën përgatitore në fund të vitit 2019. Tani shërbimet tona janë të rezervuara, toleranca ndaj gabimeve sigurohet në nivelin e serverëve fizikë, sistemeve të virtualizimit, dokerëve dhe shërbimeve në to. Në të njëjtën kohë, kapaciteti i burimeve të serverit tonë na lejon të përballojmë ngarkesa të shumta.
Mjeti kryesor që na ndihmoi në gjithë këtë histori ishte sistemi ynë i monitorimit. Vërtetë, deri vonë nuk kishim një sistem të vetëm që do të na lejonte të mblidhnim metrikë në të gjitha shtresat, nga niveli i pajisjeve fizike dhe harduerit deri në nivelin e matjeve të biznesit.
Formalisht, në kompani kishte monitorim, por si rregull ishte i shpërndarë dhe ishte në fushën e përgjegjësisë së departamenteve të veçanta. Në fakt, kur ndodhte një incident, pothuajse kurrë nuk kishim një kuptim të përbashkët të asaj që ndodhi saktësisht, nuk kishte asnjë komunikim dhe shpesh kjo çonte në vrapim në qarqe për të gjetur dhe izoluar problemin në mënyrë që të mund të rregullohej.
Në një moment, ne menduam dhe vendosëm se na mjaftonte duke duruar këtë - na duhej një sistem i unifikuar për të parë të gjithë pamjen në tërësi. Teknologjitë kryesore që përfshihen në stivën tonë janë Zabbix si një qendër alarmi dhe ruajtjeje metrike, Prometheus për mbledhjen dhe ruajtjen e metrikave të aplikacionit, Stack ELK për regjistrimin dhe ruajtjen e të dhënave nga i gjithë sistemi i monitorimit, si dhe Grafana për vizualizim, Swagger, Docker. dhe gjëra të tjera të dobishme dhe të njohura për ju.
Në të njëjtën kohë, ne përdorim jo vetëm teknologjitë e disponueshme në treg, por gjithashtu zhvillojmë disa nga tonat. Për shembull, ne bëjmë shërbime për integrimin e sistemeve me njëri-tjetrin, domethënë një lloj API për mbledhjen e metrikës. Plus, ne jemi duke punuar në sistemet tona të monitorimit - në nivelin e matjeve të biznesit ne përdorim teste UI. Dhe gjithashtu një bot në Telegram për të njoftuar ekipet.
Ne po përpiqemi gjithashtu ta bëjmë sistemin e monitorimit të aksesueshëm për ekipet në mënyrë që ata të mund të ruajnë dhe të punojnë në mënyrë të pavarur metrikat e tyre, duke përfshirë vendosjen e sinjalizimeve për disa metrika të ngushta që nuk përdoren gjerësisht.
Në të gjithë sistemin, ne përpiqemi për proaktivitet dhe lokalizim të incidenteve sa më shpejt të jetë e mundur. Përveç kësaj, numri i mikroshërbimeve dhe sistemeve tona është rritur ndjeshëm kohët e fundit, dhe numri i integrimeve është rritur në përputhje me rrethanat. Dhe si pjesë e optimizimit të procesit të diagnostikimit të incidenteve në nivelin e integrimit, ne po zhvillojmë një sistem që ju lejon të kryeni kontrolle ndër-sistemesh dhe të shfaqni rezultatin, i cili ju lejon të gjeni problemet kryesore që lidhen me importet dhe ndërveprimin e sistemeve me njëri tjetrin.
Natyrisht, ne kemi ende hapësirë për t'u rritur dhe zhvilluar për sa i përket sistemeve operative, dhe ne jemi duke punuar në mënyrë aktive për këtë. Mund të lexoni më shumë rreth sistemit tonë të monitorimit .
Testet teknike
Orlov Sergey, drejton qendrën e kompetencës për zhvillimin e uebit dhe celularit
Që nga fillimi i mbylljes së dyqaneve fizike, ne jemi përballur me sfida të ndryshme nga këndvështrimi i zhvillimit. Para së gjithash, rritja e ngarkesës si e tillë. Është e qartë se nëse nuk merren masat e duhura, atëherë kur një ngarkesë e lartë aplikohet në sistem, ai mund të shndërrohet në një kungull me një zhurmë të trishtuar, ose të degradojë plotësisht në performancë, ose madje të humbasë 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 iu përshtatur ndryshimeve në proceset e biznesit. Ndonjëherë disa herë në ditë. Shumë kompani kanë një rregull që nëse ka shumë aktivitet marketingu, nuk ka nevojë të bëhen ndryshime në sistem. Asnjë, le të funksionojë për aq kohë sa funksionon.
Dhe ne në thelb patëm një të Premte të Zezë të pafund, gjatë së cilës ishte e nevojshme të ndryshonim sistemin. Dhe çdo gabim, problem ose dështim në sistem do të ishte shumë i kushtueshëm për biznesin.
Duke parë përpara, do të them se ne arritëm të përballonim këto prova, të gjitha sistemet i rezistuan ngarkesës, u shkallëzuan lehtësisht dhe nuk pësuam asnjë dështim teknik global.
Ka katër shtylla mbi të cilat mbështetet aftësia e sistemit për t'i bërë ballë ngarkesave të larta. E para prej tyre është monitorimi, për të cilin keni lexuar pak më lart. Pa një sistem monitorimi të integruar, është pothuajse e pamundur të gjesh pengesat e sistemit. Një sistem i mirë monitorimi është si rrobat e shtëpisë; ai duhet të jetë i rehatshëm dhe i përshtatur për ju.
Aspekti i dytë është testimi. Ne e marrim këtë pikë shumë seriozisht: ne shkruajmë njësi klasike, teste integrimi, teste të ngarkesës dhe shumë të tjera për çdo sistem. Ne po shkruajmë gjithashtu një strategji testimi, dhe në të njëjtën kohë po përpiqemi të rrisim nivelin e testimit deri në atë pikë sa të mos kemi më nevojë për kontrolle manuale.
Shtylla e tretë është tubacioni CI/CD. Proceset e ndërtimit, testimit dhe vendosjes së një aplikacioni duhet të automatizohen sa më shumë që të jetë e mundur; nuk duhet të ketë ndërhyrje manuale. Tema e tubacionit CI/CD është mjaft e thellë dhe do ta prek vetëm shkurtimisht. Vlen të përmendet vetëm se ne kemi një listë kontrolli të tubacionit CI/CD, të cilën çdo ekip produkti e kalon me ndihmën e qendrave të kompetencës.
Dhe këtu është lista e kontrollit
Në këtë mënyrë arrihen shumë qëllime. Ky është versionimi i API-së dhe ndërrimi i veçorive për të shmangur trenin e lëshimit dhe arritjen e mbulimit të testeve të ndryshme në një nivel të tillë që testimi të jetë plotësisht i automatizuar, vendosjet të jenë pa probleme, etj.
Shtylla e katërt janë parimet arkitekturore dhe zgjidhjet teknike. Mund të flasim shumë për arkitekturën për një kohë të gjatë, por dua të theksoj disa parime në të cilat do të doja të fokusohesha.
Së pari, ju duhet të zgjidhni mjete të specializuara për detyra specifike. Po, tingëllon e qartë, dhe është e qartë se gozhdat duhet të futen me çekiç dhe orët e dorës duhet të çmontohen me kaçavida speciale. Por në epokën tonë, shumë mjete përpiqen për universalizim në mënyrë që të mbulojnë segmentin maksimal të përdoruesve: bazat e të dhënave, cache, kornizat dhe të tjerat. Për shembull, nëse merrni bazën e të dhënave MongoDB, ajo funksionon me transaksione me shumë dokumente dhe baza e të dhënave Oracle punon me json. Dhe duket se gjithçka mund të përdoret për gjithçka. Por nëse mbrojmë produktivitetin, atëherë duhet të kuptojmë qartë anët e forta dhe të dobëta të secilit mjet dhe të përdorim ato që na duhen për klasën tonë të detyrave.
Së dyti, gjatë projektimit të sistemeve, çdo rritje e kompleksitetit duhet të justifikohet. Duhet ta mbajmë vazhdimisht parasysh këtë; parimi i lidhjes së ulët është i njohur për të gjithë. Unë besoj se duhet të zbatohet në nivelin e një shërbimi specifik dhe në nivelin e të gjithë sistemit dhe në nivelin e peizazhit arkitektonik. Aftësia për të shkallëzuar horizontalisht çdo komponent të sistemit përgjatë rrugës së ngarkesës është gjithashtu e rëndësishme. Nëse e keni këtë aftësi, shkallëzimi nuk do të jetë i vështirë.
Duke folur për zgjidhjet teknike, ne i kërkuam ekipeve të produkteve të përgatisin një grup të ri rekomandimesh, idesh dhe zgjidhjesh, të cilat i zbatuan në përgatitje për valën e ardhshme të ngarkesës.
Keshi
Është e nevojshme t'i qasemi me vetëdije zgjedhjes së cache lokale dhe të shpërndara. Ndonjëherë ka kuptim që të përdoren të dyja brenda të njëjtit sistem. Për shembull, ne kemi sisteme në të cilat disa nga të dhënat janë në thelb një cache vitrinë, domethënë burimi i përditësimeve ndodhet prapa vetë sistemit dhe sistemet nuk ndryshojnë këto të dhëna. Për këtë qasje ne përdorim cache lokale të kafeinës.
Dhe ka të dhëna që sistemi ndryshon në mënyrë aktive gjatë funksionimit, dhe këtu ne tashmë po përdorim një cache të shpërndarë me Hazelcast. Kjo qasje na lejon të përdorim përfitimet e një cache të shpërndarë aty ku ato janë vërtet të nevojshme, dhe të minimizojmë kostot e shërbimit të qarkullimit të të dhënave të grupit Hazelcast ku mund të bëjmë pa të. Ne kemi shkruar shumë për cache. и .
Për më tepër, ndryshimi i serializuesit në Kryo në Hazelcast na dha një shtysë të mirë. Dhe kalimi nga ReplicatedMap në IMap + Near Cache në Hazelcast na lejoi të minimizonim lëvizjen e të dhënave nëpër grup.
Një këshillë e vogël: në rast të zhvlerësimit masiv të cache-it, ndonjëherë është e zbatueshme taktika e ngrohjes së cache-it të dytë dhe më pas kalimit në të. Duket se me këtë qasje duhet të kemi konsum të dyfishtë të memories, por në praktikë, në ato sisteme ku praktikohej kjo, konsumi i kujtesës u ul.
Rafte reaktive
Ne përdorim rafte reaktive në një numër mjaft të madh sistemesh. Në rastin tonë, ky është Webflux ose Kotlin me korutina. Stacki reaktiv është veçanërisht i mirë aty ku presim operacione të ngadalta hyrje-dalje. Për shembull, thirrjet drejt shërbimeve të ngadalta, duke punuar me sistemin e skedarëve ose sistemet e ruajtjes.
Parimi më i rëndësishëm është shmangia e bllokimit të telefonatave. Kornizat reaktive kanë një numër të vogël të lidhjeve të drejtpërdrejta të shërbimit që funksionojnë nën kapuç. Nëse e lejojmë veten në mënyrë të pakujdesshme të bëjmë një telefonatë të drejtpërdrejtë bllokuese, si p.sh. një telefonatë drejtuesi JDBC, sistemi thjesht do të ndalet.
Mundohuni t'i ktheni gabimet në përjashtimin tuaj të kohës së ekzekutimit. Rrjedha aktuale e ekzekutimit të programit kalon në korniza reaktive dhe ekzekutimi i kodit bëhet jolinear. Si rezultat, është shumë e vështirë të diagnostikosh problemet duke përdorur gjurmët e stivës. Dhe zgjidhja këtu do të ishte krijimi i përjashtimeve të qarta, objektive të kohës së ekzekutimit për çdo gabim.
Elasticsearch
Kur përdorni Elasticsearch, mos zgjidhni të dhëna të papërdorura. Kjo, në parim, është gjithashtu një këshillë shumë e thjeshtë, por më shpesh kjo është ajo që harrohet. Nëse keni nevojë të zgjidhni më shumë se 10 mijë regjistrime në të njëjtën kohë, duhet të përdorni Scroll. Për të përdorur një analogji, është paksa si një kursor në një bazë të dhënash relacionale.
Mos përdorni postfilter nëse nuk është e nevojshme. Me të dhëna të mëdha në kampionin kryesor, ky operacion ngarkon shumë bazën e të dhënave.
Përdorni operacione me shumicë aty ku është e mundur.
API
Kur hartoni një API, përfshini kërkesat për minimizimin e të dhënave të transmetuara. Kjo është veçanërisht e vërtetë në lidhje me pjesën e përparme: është në këtë kryqëzim që ne shkojmë përtej kanaleve të qendrave tona të të dhënave dhe tashmë po punojmë në kanalin që na lidh me klientin. Nëse ka problemin më të vogël, trafiku i tepërt shkakton një përvojë negative të përdoruesit.
Dhe së fundi, mos hidhni një mori të dhënash, jini të qartë për kontratën midis konsumatorëve dhe furnitorëve.
Transformimi organizativ
Eroshkina Elena, Zëvendës Drejtoreshë për IT
Në momentin kur ndodhi karantina dhe lindi nevoja për të rritur ndjeshëm ritmin e zhvillimit në internet dhe futjen e shërbimeve omnichannel, ne ishim tashmë në procesin e transformimit organizativ.
Një pjesë e strukturës sonë u transferua në punë sipas parimeve dhe praktikave të qasjes së produktit. Janë formuar ekipe që tani janë përgjegjëse për funksionimin dhe zhvillimin e secilit produkt. Punonjësit në ekipe të tilla janë 100% të përfshirë dhe strukturojnë punën e tyre duke përdorur Scrum ose Kanban, në varësi të asaj që është e preferueshme për ta, duke vendosur një tubacion vendosjeje, duke zbatuar praktika teknike, praktika të sigurimit të cilësisë dhe shumë më tepër.
Për fat, pjesa më e madhe e ekipeve tona të produkteve ishin në fushën e shërbimeve online dhe të gjithanshme. Kjo na lejoi të kalonim në modalitetin e punës në distancë në kohën më të shkurtër të mundshme (seriozisht, fjalë për fjalë në dy ditë) pa humbje të efikasitetit. Procesi i personalizuar na lejoi të përshtatemi shpejt me kushtet e reja të punës dhe të mbajmë një ritëm mjaft të lartë të ofrimit të funksionalitetit të ri.
Përveç kësaj, ne kemi nevojë për të forcuar ato ekipe që janë në kufirin e biznesit online. Në atë moment u bë e qartë se ne mund ta bënim këtë vetëm duke përdorur burime të brendshme. Dhe rreth 50 njerëz në dy javë ndryshuan zonën ku ata punonin më parë dhe u përfshinë në punën për një produkt që ishte i ri për ta.
Kjo nuk kërkon ndonjë përpjekje të veçantë menaxheriale, sepse së bashku me organizimin e procesit tonë, përmirësimin teknik të produktit dhe praktikat e sigurimit të cilësisë, ne i mësojmë ekipet tona të vetëorganizohen - të menaxhojnë procesin e tyre të prodhimit pa përfshirë burimet administrative.
Ne ishim në gjendje t'i fokusonim burimet tona të menaxhimit pikërisht aty ku ishte e nevojshme në atë moment - në koordinimin së bashku me biznesin: Çfarë është e rëndësishme për klientin tonë tani, çfarë funksioni duhet të zbatohet së pari, çfarë duhet bërë për të rritur aftësinë tonë të xhiros për të dorëzuar dhe përpunuar porositë. E gjithë kjo dhe një model i qartë bëri të mundur që gjatë kësaj periudhe të ngarkojmë rrjedhat tona të vlerës së prodhimit me atë që është vërtet e rëndësishme dhe e nevojshme.
Është e qartë se me punën në distancë dhe një ritëm të lartë ndryshimi, kur treguesit e biznesit varen nga pjesëmarrja e të gjithëve, nuk mund të mbështeteni vetëm në ndjenjat e brendshme nga seria "A po shkon gjithçka mirë me ne? Po, duket mirë”. Nevojiten metrika objektive të procesit të prodhimit. Ne i kemi këto, ato janë të disponueshme për këdo që është i interesuar në matjet e ekipeve të produkteve. Para së gjithash, vetë ekipi, biznesi, nënkontraktorët dhe menaxhmenti.
Një herë në dy javë, mbahet një status me secilin ekip, ku analizohen metrikat për 10 minuta, identifikohen pengesat në procesin e prodhimit dhe zhvillohet një zgjidhje e përbashkët: çfarë mund të bëhet për të eliminuar këto pengesa. Këtu mund të kërkoni menjëherë ndihmë nga menaxhmenti nëse ndonjë problem i identifikuar është jashtë zonës së ndikimit të ekipeve, ose ekspertizës së kolegëve që mund të kenë hasur tashmë një problem të ngjashëm.
Megjithatë, ne e kuptojmë se për të përshpejtuar disa herë (dhe pikërisht ky është qëllimi që i kemi vendosur vetes), ne ende duhet të mësojmë shumë dhe ta zbatojmë atë në punën tonë të përditshme. Tani për tani ne po vazhdojmë të shkallëzojmë qasjen tonë të produktit në ekipe të tjera dhe produkte të reja. Për ta bërë këtë, ne duhej të zotëronim një format të ri për ne - një shkollë në internet të metodologëve.
Metodologët, njerëzit që ndihmojnë ekipet të ndërtojnë një proces, të krijojnë komunikime dhe të përmirësojnë efikasitetin e punës, janë në thelb agjentë të ndryshimit. Tani për tani, të diplomuarit e grupit tonë të parë po punojnë me ekipe dhe po i ndihmojnë ata të bëhen të suksesshëm.
Mendoj se situata aktuale na hap mundësi dhe perspektiva për të cilat ndoshta ne vetë nuk jemi ende plotësisht të vetëdijshëm. Por përvoja dhe praktika që po fitojmë tani konfirmon se kemi zgjedhur rrugën e duhur të zhvillimit, nuk do të humbasim këto mundësi të reja në të ardhmen dhe do të jemi në gjendje t'i përgjigjemi po aq efektivisht sfidave me të cilat do të përballet Sportmaster.
Gjetjet
Gjatë kësaj kohe të vështirë, ne kemi formuluar parimet kryesore mbi të cilat mbështetet zhvillimi i softuerit, të cilat, mendoj se do të jenë të rëndësishme për çdo kompani që merret me këtë.
Njerëz. Kjo është ajo ku gjithçka mbështetet. Punonjësit duhet të kënaqen me punën e tyre dhe të kuptojnë qëllimet e kompanisë dhe qëllimet e produkteve në të cilat punojnë. Dhe, sigurisht, ata mund të zhvillohen profesionalisht.
Технология. Është e nevojshme që kompania të marrë një qasje të pjekur për të punuar me grupin e saj të teknologjisë dhe të ndërtojë kompetenca aty ku është vërtet e nevojshme. Tingëllon shumë e thjeshtë dhe e qartë. Dhe shumë shpesh injorohet.
proceset. Është e rëndësishme të organizohet siç duhet puna e ekipeve të produkteve dhe qendrave të kompetencës, të vendoset ndërveprimi me biznesin në mënyrë që të punohet me të si partner.
Në përgjithësi, kështu mbijetuam. Teza kryesore e kohës sonë u vërtetua edhe një herë, me një klikim kumbues në ballë
Edhe nëse jeni një biznes i madh offline me shumë dyqane dhe një mori qytetesh ku veproni, zhvilloni biznesin tuaj online. Ky nuk është vetëm një kanal shtesë shitjesh ose një aplikacion i bukur përmes të cilit gjithashtu mund të blini diçka (dhe gjithashtu sepse konkurrentët kanë gjithashtu të bukur). Kjo nuk është një gomë rezervë për çdo rast për t'ju ndihmuar të përballoni stuhinë.
Kjo është një domosdoshmëri absolute. Për të cilat duhet të përgatiten jo vetëm aftësitë tuaja teknike dhe infrastruktura, por edhe njerëzit dhe proceset tuaja. Në fund të fundit, mund të blini shpejt memorie shtesë, hapësirë, të vendosni instanca të reja, etj. brenda disa orësh. Por njerëzit dhe proceset duhet të përgatiten paraprakisht për këtë.
Burimi: www.habr.com