Testimi në Prod: Vendosja e Kanareve

Kanarina është një zog i vogël që këndon vazhdimisht. Këta zogj janë të ndjeshëm ndaj metanit dhe monoksidit të karbonit. Edhe përqendrimet e vogla të këtyre gazrave në ajër mund t'i bëjnë ata të humbasin ndjenjat ose të vdesin. Shpëtuesit e arit dhe minatorët i merrnin këta zogj me vete kur punonin në miniera: ndërsa kanarinat këndonin, ato mund të punonin; nëse ndalonin së kënduari, kishte gaz në minierë dhe ishte koha për t'u larguar. Minatorët sakrifikonin zogun e vogël për të shpëtuar gjallë.

Një praktikë e ngjashme ka gjetur rrugën e saj në IT. Për shembull, në detyrën standarde të vendosjes së një versioni të ri të një shërbimi ose aplikacioni në prodhim me testime paraprake. Një mjedis testimi mund të jetë shumë i kushtueshëm, testet e automatizuara nuk mbulojnë gjithçka që do të dëshironit, dhe mostestimi dhe sakrifikimi i cilësisë është i rrezikshëm. Në raste të tilla, qasja e Vendosjes Canary është e dobishme, ku një sasi e vogël e trafikut të prodhimit real vendoset në versionin e ri. Kjo qasje ndihmon. me siguri kontrolloni versionin e ri për prodhim, sakrifikimi i gjërave të vogla për një qëllim më të madh. Mësoni më shumë rreth asaj se si funksionon kjo qasje, përfitimet e saj dhe si ta zbatoni atë. Andrey Markelov (Andrey_V_Markelov), bazuar në shembullin e zbatimit në kompaninë Infobip.

Andrey Markelov — Inxhinier Kryesor i Softuerëve në Infobip, me 11 vjet përvojë në zhvillimin e aplikacioneve Java në financë dhe telekomunikacion. Ai zhvillon produkte me burim të hapur, merr pjesë aktive në Komunitetin Atlassian dhe shkruan plugin-e për produktet Atlassian. Ai është gjithashtu një ungjilltar për Prometheus, Docker dhe Redis.

Rreth Infobip

Është një platformë globale telekomunikacioni që u lejon bankave, shitësve me pakicë, dyqaneve online dhe kompanive të transportit detar të komunikojnë me klientët e tyre nëpërmjet SMS-ve, njoftimeve push, email-eve dhe mesazheve zanore. Në biznese të tilla, stabiliteti dhe besueshmëria janë thelbësore për të siguruar që klientët të marrin mesazhet në kohë.

Infrastruktura IT e Infobip në shifra:

• 15 qendra të dhënash në të gjithë botën;
• 500 shërbime unike në veprim;
• 2500 instanca shërbimi, që është shumë më tepër sesa komanda;
• 4,5 TB trafik mujor;
• 4,5 miliardë numra telefoni;

Biznesi po rritet, dhe bashkë me të edhe numri i publikimeve. Ne po kryejmë 60 publikime në ditë, sepse klientët duan më shumë veçori dhe kapacitet. Por është e vështirë—ka shumë shërbime dhe pak ekipe. Duhet të shkruash shpejt kod që funksionon pa probleme në prodhim.

Liron

Një version tipik për ne është kështu. Për shembull, kemi shërbimet A, B, C, D dhe E, secila e zhvilluar nga një ekip i veçantë.

Në një moment të caktuar, ekipi në shërbimin A vendos të vendosë një version të ri, por ekipet në shërbimet B, C, D dhe E nuk janë në dijeni të kësaj. Ekipi në shërbimin A mund të ndërmarrë dy veprime.

Do të drejtojë lirim gradual: së pari zëvendësoni një version, dhe pastaj të dytin.

Por ekziston një mundësi e dytë: ekipi do të gjejë kapacitet dhe makineri shtesë, vendosni versionin e ri dhe pastaj ndërroni routerin, dhe versioni do të fillojë të funksionojë në prodhim.

Në çdo skenar vendosjeje, pothuajse gjithmonë lindin probleme, edhe nëse versioni është testuar. Pavarësisht nëse e testoni manualisht, automatikisht apo aspak, problemet do të lindin. Mënyra më e lehtë dhe më efektive për t'i zgjidhur ato është të riktheheni në një version funksional. Vetëm atëherë mund ta adresoni dëmin, të identifikoni shkaqet dhe t'i rregulloni ato.

Pra, çfarë duam ne?

Nuk kemi nevojë për probleme. Nëse klientët i zbulojnë ato para nesh, kjo do të dëmtojë reputacionin tonë. Kjo është arsyeja pse ne duhet i gjejnë problemet më shpejt se klientëtDuke punuar në mënyrë proaktive, ne minimizojmë dëmet.

Në të njëjtën kohë, ne dëshirojmë përshpejtoni vendosjen, në mënyrë që kjo të ndodhë shpejt, lehtë, natyrshëm dhe pa stres për ekipin. Inxhinierët, inxhinierët DevOps dhe programuesit duhet të mbrohen - publikimi i një versioni të ri është stresues. Ekipi nuk është i pashfrytëzueshëm; ne përpiqemi të përdorin burimet njerëzore në mënyrë racionale.

Probleme me vendosjen

Trafiku i klientëve është i paparashikueshëmËshtë e pamundur të parashikohet se kur trafiku i klientëve do të jetë në nivelin më të ulët. Nuk e dimë se ku dhe kur klientët do të nisin fushatat e tyre - mund të jetë sonte në Indi dhe nesër në Hong Kong. Duke pasur parasysh ndryshimin e madh kohor, vendosja në përdorim edhe në orën 2 të mëngjesit nuk garanton kënaqësinë e klientëve.

Probleme me ofruesinMessenger-at dhe ofruesit janë partnerët tanë. Ndonjëherë ata hasin probleme që shkaktojnë gabime gjatë vendosjes së versioneve të reja.

Ekipet e shpërndaraEkipet që zhvillojnë klientin dhe backend-in ndodhen në zona të ndryshme kohore. Për shkak të kësaj, ato shpesh dështojnë të komunikojnë.

Qendrat e të dhënave nuk mund të replikohen në skenëNjë qendër e vetme të dhënash ka 200 rafte—është e pamundur ta replikosh këtë edhe nga distanca në një sandbox.

Kohëzgjatja e ndërprerjes së punësjanë të papranueshme! Ne kemi një nivel të pranueshëm disponueshmërie (Buxheti i Gabimeve), ku operojmë 99,99% të kohës, për shembull, dhe përqindja e mbetur konsiderohet "marzh për gabim". Arritja e besueshmërisë 100% është e pamundur, por është e rëndësishme të monitorohen vazhdimisht ndërprerjet dhe kohët e ndërprerjes së funksionimit.

Zgjidhje klasike

Shkruaj kod pa gabimeKur isha një zhvillues i ri, menaxherët më kërkonin ta publikoja pa gabime, por kjo nuk është gjithmonë e mundur.

Shkruaj testeTestet funksionojnë, por ndonjëherë jo në mënyrën që dëshiron biznesi. Qëllimi i testeve nuk është të fitosh para.

Test në skenëNë 3,5 vitet e mia në Infobip, nuk e kam parë kurrë skenën të përputhet qoftë edhe pjesërisht me gjendjen e produksionit.

Madje u përpoqëm ta zhvillonim më tej këtë ide: fillimisht patëm një skenë, pastaj para-prodhim dhe më pas para-prodhim të para-prodhimit. Por as kjo nuk ndihmoi—nuk ishin të krahasueshme as në fuqi. Me një skenë, mund të garantojmë funksionalitetin bazë, por nuk e dimë se si do të funksionojë nën ngarkesë.

Lëshimi bëhet nga ai që e zhvilloi atë. Është një praktikë e mirë të shtoni menjëherë një koment në prodhim, edhe nëse titullohet ndryshe. Kjo ndihmon në nxitjen e llogaridhënies dhe siguron që ndryshimet të mbahen mend.

Ka edhe ndërlikime të tjera. Është stresuese për një zhvillues të shpenzojë shumë kohë duke kontrolluar gjithçka manualisht.

Publikime të koordinuaraKy opsion zakonisht sugjerohet nga menaxhmenti: "Le të biem dakord të testojmë dhe shtojmë versione të reja çdo ditë." Kjo nuk funksionon: gjithmonë ka një ekip që pret të gjithë të tjerët, ose anasjelltas.

Testet e tymit

Një mënyrë tjetër për të zgjidhur problemet tona të vendosjes. Le të shohim se si funksionojnë testet e tymit duke përdorur shembullin e mëparshëm, kur Ekipi A dëshiron të vendosë një version të ri.

Së pari, ekipi vendos një instancë në prodhim. Mesazhe për instancën nga modelet. trafiku i vërtetë është i simuluarpër t'u përputhur me trafikun normal ditor. Nëse gjithçka shkon mirë, ekipi e kalon versionin e ri në trafikun e përdoruesve.

Opsioni i dytë është vendosja me hekur shtesë. Ekipi e teston atë në prodhim, pastaj e ndërron dhe gjithçka funksionon.

Disavantazhet e testeve të tymit:

• Testet nuk mund të zihen besë. Ku mund ta merrni të njëjtin trafik si prodhimi? Mund të përdorni të dhënat e djeshme ose të një jave, por nuk përputhet gjithmonë me ato aktuale.
• Është e vështirë për t’u mirëmbajtur. Do të duhet të mirëmbani llogaritë e testimit dhe t’i rivendosni ato vazhdimisht para çdo vendosjeje kur të dhënat aktive dërgohen në depo. Kjo është më e vështirë sesa të shkruani një test në sandbox-in tuaj.

Bonusi i vetëm këtu është mund ta kontrolloni performancën.

Publikimet e Canary

Për shkak të mangësive të testeve të tymit, filluam të përdorim lëshime nga kanarina.

Një praktikë e ngjashme me mënyrën se si minatorët përdornin kanarinë për të treguar nivelet e gazit ka gjetur rrugën e saj në IT. Ne po lançojmë disa trafik të vërtetë prodhimi për versionin e ri, ndërkohë që përpiqemi t'i përmbahemi Marrëveshjes së Nivelit të Shërbimit (SLA). SLA është "e drejta jonë për të bërë gabime", të cilën mund ta ushtrojmë një herë në vit (ose në çdo periudhë tjetër kohore). Nëse gjithçka shkon mirë, do të shtojmë më shumë trafik. Nëse jo, do të anulojmë versionet e mëparshme.

Zbatimi dhe nuancat

Si i zbatuam lëshimet e Canary? Për shembull, një grup klientësh dërgojnë mesazhe përmes shërbimit tonë.

Vendosja shkon kështu: ne heqim një nyje nga balancuesi (1), ndryshojmë versionin (2) dhe veçmas lëshojmë pak trafik (3).

Në përgjithësi, të gjithë në grup do të jenë të kënaqur, edhe nëse një përdorues është i pakënaqur. Nëse gjithçka është në rregull, ne i ndryshojmë të gjitha versionet.

Do t'ju tregoj një diagram se si duket kjo për mikroserviset në shumicën e rasteve.

Ekziston Zbulimi i Shërbimit dhe dy shërbime të tjera: S1N1 dhe S2. Shërbimi i parë (S1N1) njofton Zbulimin e Shërbimit kur fillon, dhe Zbulimi i Shërbimit e mban mend atë. Shërbimi i dytë, me dy nyje (S2N1 dhe S2N2), gjithashtu njofton Zbulimin e Shërbimit kur fillon.

Shërbimi i dytë vepron si server për të parin. Shërbimi i parë kërkon informacion në lidhje me serverat e tij nga Service Discovery dhe, kur e merr atë, i kërkon dhe i kontrollon ata ("kontrollet e shëndetit"). Pasi verifikohet, u dërgon mesazhe.

Kur dikush dëshiron të vendosë një version të ri të shërbimit të dytë, ai i tregon Service Discovery se nyja e dytë do të jetë një nyje kanarie: më pak trafik do t'i dërgohet asaj sepse vendosja është gati të ndodhë. Ne e heqim nyjen kanarie nga balancuesi i ngarkesës dhe shërbimi i parë ndalon së dërguari trafik tek ajo.

Ne e ndryshojmë versionin dhe Service Discovery e di që nyja e dytë tani është kanarinë—mund t’i japim një ngarkesë të reduktuar (5%). Nëse gjithçka shkon mirë, ne e ndryshojmë versionin, e rivendosim ngarkesën dhe vazhdojmë punën.

Për të zbatuar të gjitha këto, na duhen:

• balancimi;
• monitorimi, pasi është e rëndësishme të dimë se çfarë pret secili përdorues dhe si funksionojnë shërbimet tona në detaje;
• analiza e versionitpër të kuptuar se sa mirë do të funksionojë versioni i ri në prodhim;
• automatizim — ne shkruajmë sekuencën e vendosjes (tubacioni i vendosjes).

balancimi

Kjo është gjëja e parë për të cilën duhet të mendojmë. Ekzistojnë dy strategji balancuese.

Opsioni më i thjeshtë është kur një nyje është gjithmonë kanarinëKjo nyje merr gjithmonë më pak trafik, kështu që ne e fillojmë vendosjen nga aty. Nëse ka ndonjë problem, ne do të krahasojmë performancën e saj para dhe gjatë vendosjes. Për shembull, nëse numri i gabimeve dyfishohet, atëherë dëmi është dyfishuar.

Nyja Canary vendoset gjatë procesit të vendosjes.Pasi të përfundojë vendosja dhe ta heqim nga statusi i nyjes canary, balanca e trafikut do të rivendoset. Me më pak makina, do të arrijmë një shpërndarje të drejtë.

Monitorimi

Gurthemeli i publikimeve të Canary: duhet të kuptojmë qartë pse po e bëjmë dhe çfarë metrikash duam të mbledhim.

Shembuj të metrikave që mbledhim nga shërbimet tona.

• Numri i gabimeve, të cilat shkruhen në regjistra. Ky është një tregues i qartë se gjithçka po funksionon siç duhet. Në përgjithësi, kjo është një metrikë e mirë.
• Koha e ekzekutimit të pyetjes (latencë). Të gjithë e monitorojnë këtë metrikë sepse të gjithë duan të punojnë shpejt.
• Madhësia e radhës (prodhueshmëri).
• Numri i përgjigjeve të suksesshme për sekondë.
• Koha e ekzekutimit për 95% të të gjitha kërkesave.
• Metrikat e biznesit: Sa para fiton një biznes gjatë një periudhe të caktuar kohore ose largimit të përdoruesve. Këto metrika mund të jenë më të rëndësishme për versionin tonë të ri sesa ato të shtuara nga inxhinierët.

Shembuj të metrikave në shumicën e sistemeve të monitorimit të njohura.

Numërues. Kjo është një vlerë në rritje, për shembull, numri i gabimeve. Kjo metrikë është e lehtë për t'u interpoluar dhe për të studiuar grafikun: dje kishte 2 gabime, dhe sot ka 500, që do të thotë se diçka shkoi keq.

Numri i gabimeve për minutë ose për sekondë është një metrikë kyçe që mund të llogaritet duke përdorur Counter. Këto të dhëna japin një pamje të qartë të performancës së sistemit me kalimin e kohës. Le të shohim një grafik shembull të numrit të gabimeve për sekondë për dy versione të një sistemi prodhimi.

Versioni i parë kishte disa gabime dhe ndoshta auditimi nuk po funksiononte. Versioni i dytë është shumë më i keq. Mund të themi me siguri se ka probleme, kështu që duhet ta anulojmë atë version.

Matës. Metrikat janë të ngjashme me Counter, por ne regjistrojmë vlera që mund të rriten ose ulen, siç është koha e ekzekutimit të kërkesës ose madhësia e radhës.

Grafiku tregon një shembull të kohës së përgjigjes (latencës). Nga grafiku është e qartë se versionet janë të ngjashme dhe të realizueshme. Por nëse shikoni nga afër, do të vini re se si ndryshojnë vlerat. Nëse koha e ekzekutimit të pyetjes rritet ndërsa shtohen përdorues, është menjëherë e qartë se ka probleme - ky nuk ishte rasti më parë.

Përmbledhje. Një nga metrikat më të rëndësishme për biznesin janë përqindjet. Metrika tregon se në 95% të rasteve Sistemi ynë funksionon ashtu siç duam ne. Mund t’i pranojmë problemet diku sepse e kuptojmë trendin e përgjithshëm, sa të mira ose të këqija janë gjërat.

Mjete

ELK StackMund ta implementoni canary duke përdorur Elasticsearch—ne i regjistrojmë gabimet aty ndërsa ndodhin ngjarje. Një thirrje e thjeshtë API ju lejon të merrni numrin e gabimeve në çdo kohë të caktuar dhe t'i krahasoni ato me periudhat e mëparshme: GET /applg/_cunt?q=level:errr.

Prometeu. Pati performancë të mirë në Infobip. Lejon zbatimin e metrikave shumëdimensionale sepse përdor etiketa.

Ne mund të përdorim level, instance, service, kombinojini ato në një sistem. Me ndihmën e offset Mund të shihni, për shembull, vlerën e një sasie një javë më parë me vetëm një komandë GET /api/v1/query?query={query}Ku {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Analiza e versionit

Ekzistojnë disa strategji për analizën e versioneve.

Shikoni metrikat vetëm për nyjet canary. Një nga opsionet më të thjeshta: instaloni versionin e ri dhe thjesht studioni se si funksionon. Por nëse një inxhinier fillon të studiojë regjistrat ndërsa e bën këtë, duke rifreskuar vazhdimisht faqet me nxitim, atëherë kjo zgjidhje nuk është ndryshe nga të tjerat.

Nyja Kanarie krahasohet me çdo nyje tjetërKy është një krahasim me instanca të tjera që funksionojnë me trafik të plotë. Për shembull, nëse gjërat janë më keq ose nuk janë më mirë me trafik të ulët sesa në instancat reale, atëherë diçka nuk shkon.

Nyja kanarine krahasohet me veten e saj të kaluar. Nyjet e alokuara për canary mund të krahasohen me të dhënat historike. Për shembull, nëse gjithçka ishte në rregull një javë më parë, ne mund t'i përdorim këto të dhëna për të kuptuar situatën aktuale.

automatizim

Ne duam t'i çlirojmë inxhinierët nga krahasimet manuale, prandaj është e rëndësishme të zbatohet automatizimi. Procesi i implementimit zakonisht duket kështu:

• le të fillojmë;
• hiqni nyjen nga poshtë balancuesit;
• ne instalojmë një nyje kanarike;
• Ne e aktivizojmë balancuesin me një sasi të kufizuar trafiku;
• le të krahasojmë.

Në këtë fazë ne zbatojmë krahasim automatikLe të shohim një shembull nga Jenkins për të parë se si mund të duket kjo dhe pse është më mirë sesa një kontroll pas vendosjes.

Ky është një tubacion për në Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Këtu në ciklin e punës, ne specifikojmë që do ta krahasojmë nyjen e re brenda një ore. Nëse procesi canary nuk ka përfunduar ende, ne e thërrasim funksionin. Ai raporton nëse gjithçka është në rregull apo jo: def isOk = compare(srv, canary, time, base, offset, metrics).

Nëse gjithçka është mirë - sleep DEFAULT SLEEP, për shembull, për një sekondë dhe vazhdoni. Nëse jo, dilni - vendosja dështoi.

Përshkrimi i metrikës. Le të shohim se si mund të duket funksioni compare duke përdorur DSL si shembull.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Le të themi se po krahasojmë numrin e gabimeve dhe duam të dimë numrin e gabimeve për sekondë gjatë 5 minutave të fundit.

Kemi dy vlera: vlerën bazë dhe vlerën e nyjës kanarie. Vlera e nyjës kanarie është vlera aktuale. Vlera bazë është baseValue — kjo është vlera e çdo nyje tjetër jo-kanarie. Ne i krahasojmë vlerat duke përdorur një formulë që e vendosim bazuar në përvojën dhe vëzhgimet tona. Nëse vlera canaryValue keq, atëherë vendosja dështoi dhe ne rikthehemi prapa.

Pse është e nevojshme e gjithë kjo?

Një person nuk mund të kontrollojë qindra e mijëra metrika, veçanërisht për ta bërë shpejt. Krahasimi automatik ndihmon në kontrollin e të gjitha metrikave dhe ju njofton shpejt për problemet. Koha e njoftimit është kritike: nëse diçka ka ndodhur në dy sekondat e fundit, dëmi nuk do të jetë aq i madh sa nëse do të kishte ndodhur 15 minuta më parë. Derisa dikush ta vërejë problemin, të kontaktojë mbështetjen dhe të duhet mbështetje për ta zgjidhur problemin, mund të humbisni klientë.

Nëse procesi është i suksesshëm, ne i vendosim automatikisht të gjitha nyjet e mbetura. Gjatë kësaj kohe, inxhinierët nuk bëjnë asgjë. Vetëm kur e lançojnë programin canary, ata vendosin se cilat metrika të përdorin, sa kohë të kryejnë krahasimin dhe cilën strategji të përdorin.

Nëse lindin probleme, ne e çaktivizojmë automatikisht nyjen canary, e ekzekutojmë në versionet e mëparshme dhe rregullojmë çdo gabim që gjejmë. Metrikat e bëjnë të lehtë identifikimin e tyre dhe të shohin ndikimin e versionit të ri.

Pengesat

Sigurisht, kjo nuk është e lehtë për t’u zbatuar. Para së gjithash, na duhet sistemi i përgjithshëm i monitorimitInxhinierët kanë metrikat e tyre, mbështetja dhe analistët kanë të tjera, dhe biznesi ka një të tretë. Një sistem i përbashkët është një gjuhë e përbashkët midis biznesit dhe zhvillimit.

Duhet të testohet në praktikë stabiliteti i metrikave. Testi ndihmon për të kuptuar, Cili është grupi minimal i metrikave të nevojshme për të siguruar cilësinë?.

Si të arrihet kjo? Përdor shërbimin Canary jo në kohën e vendosjesPo i shtojmë një shërbim versionit të vjetër që mund të marrë përsipër çdo nyje të dedikuar në çdo kohë, duke zvogëluar trafikun pa u vendosur. Pastaj krahasojmë: studiojmë gabimet dhe gjejmë pragun ku arrijmë cilësinë.

Çfarë përfitimesh kemi përfituar nga lëshimet e kanarinëve?

Minimizoi përqindjen e dëmit të shkaktuar nga insektet. Shumica e gabimeve të vendosjes ndodhin për shkak të mospërputhjeve të të dhënave ose të përparësive. Këto gabime janë bërë shumë më pak të zakonshme sepse mund ta zgjidhim problemin brenda sekondave.

Ne optimizuam punën e ekipeve. Të sapoardhurit kanë "të drejtën për të bërë gabime": ata mund të fillojnë prodhimin pa pasur frikë se do të bëjnë gabime, gjë që u jep atyre iniciativë dhe nxitje shtesë për të punuar. Nëse prishin diçka, kjo nuk do të jetë kritike dhe personi që bën gabimin nuk do të pushohet nga puna.

Vendosja e automatizuarKy nuk është më një proces manual, siç ishte dikur, por një proces vërtet i automatizuar. Por kërkon më shumë kohë.

Metrika të rëndësishme të theksuaraE gjithë kompania, nga biznesi te inxhinieria, e kupton se çfarë është vërtet e rëndësishme në produktin tonë, duke përfshirë metrika si largimi dhe blerja e përdoruesve. Ne monitorojmë procesin: testojmë metrika, prezantojmë të reja dhe monitorojmë se si performojnë ato të vjetrat, të gjitha për të ndërtuar një sistem që do të gjenerojë të ardhura në mënyrë më efikase.

Ne kemi shumë praktika dhe sisteme të shkëlqyera që na ndihmojnë. Pavarësisht kësaj, ne përpiqemi të jemi profesionistë dhe ta bëjmë punën tonë mirë, pavarësisht nëse kemi një sistem që na ndihmon apo jo.

Qasjet dhe praktikat inxhinierike - fokusi kryesor i konferencës TechLead ConfNëse keni bërë përparim në rrugën tuaj drejt përsosmërisë teknike dhe jeni të gatshëm të ndani se çfarë ju ndihmoi ta arrini atë, paraqisni një kërkesë për raportim.

Ne planifikojmë të mbajmë Konferenca e TechLead 8 qershor. E kuptojmë që është e vështirë të vendosësh nëse do të marrësh pjesë në konferencë tani. Por në të njëjtën kohë, besojmë se karantina nuk është arsye për të ndaluar krijimin e rrjeteve dhe zhvillimin profesional. Prandaj, patjetër që do të gjejmë një mënyrë për të diskutuar sfidat e liderëve të teknologjisë dhe qasjet për zgjidhjen e tyre - nëse është e nevojshme, madje do të lidhemi online dhe do të krijojmë rrjete atje!

Burimi: www.habr.com