Këtë pranverë u gjendëm në kushte shumë gazmore. Për shkak të pandemisë, u bë e qartë se konferencat tona verore duhej të zhvendoseshin në internet. Dhe për t'i kryer ato në internet në mënyrë efikase, zgjidhjet e gatshme softuerike nuk ishin të përshtatshme për ne; duhej të shkruanim tona. Dhe ne kishim tre muaj për ta bërë këtë.
Është e qartë se kanë qenë tre muaj emocionues. Por nga jashtë nuk është plotësisht e qartë: çfarë është një platformë konferencash në internet? Nga cilat pjesë përbëhet? Prandaj, në konferencat e fundit të verës DevOops, pyeta ata që ishin përgjegjës për këtë detyrë:
- Nikolay Molchanov - drejtor teknik i JUG Ru Group;
- Vladimir Krasilshchik është një programues pragmatik Java që punon në backend (mund të shihni gjithashtu raportet e tij në konferencat tona Java);
- Artyom Nikonov është përgjegjës për të gjithë transmetimin tonë të videos.
Nga rruga, në konferencat vjeshtë-dimër ne do të përdorim një version të përmirësuar të së njëjtës platformë - kështu që shumë lexues habra do të jenë ende përdoruesit e saj.
Pasqyra e madhe
– Cila ishte përbërja e ekipit?
Nikolay Molchanov: Ne kemi një analist, një projektues, një testues, tre panele të përparme dhe një fundore. Dhe, sigurisht, një specialist në formë T-je!
— Si dukej procesi në përgjithësi?
Nikolai: Deri në mes të marsit, nuk kishim asgjë gati për online. Dhe më 15 mars, i gjithë karuseli në internet filloi të rrotullohej. Ne ngritëm disa depo, planifikuam, diskutuam arkitekturën bazë dhe bëmë gjithçka në tre muaj.
Kjo, natyrisht, kaloi nëpër fazat klasike të planifikimit, arkitekturës, përzgjedhjes së veçorive, votimit për ato veçori, politikës për ato veçori, projektimit, zhvillimit, testimit të tyre. Si rezultat, më 6 qershor, ne lëshuam gjithçka në prodhim. . Kishte 90 ditë për gjithçka.
— A ia dolëm të realizonim atë që u angazhuam?
Nikolai: Meqenëse tani po marrim pjesë në konferencën e DevOops në internet, do të thotë se funksionoi. Unë personalisht u angazhova për gjënë kryesore: do t'u sjell klientëve një mjet me të cilin ata mund të bëjnë një konferencë online.
Sfida ishte kjo: na jepni një mjet me të cilin mund të transmetojmë konferencat tona te mbajtësit e biletave.
I gjithë planifikimi u nda në disa faza, dhe të gjitha tiparet (rreth 30 globale) u ndanë në 4 kategori:
- që ne patjetër do ta bëjmë (nuk mund të jetojmë pa to),
- të cilën do ta bëjmë së dyti,
- që nuk do ta bëjmë kurrë,
- dhe që nuk do ta bëjmë kurrë, kurrë.
Kemi bërë të gjitha tiparet nga dy kategoritë e para.
— E di që janë krijuar gjithsej 600 çështje JIRA. Në tre muaj keni bërë 13 mikroshërbime dhe dyshoj se ato janë shkruar jo vetëm në Java. Ju keni përdorur teknologji të ndryshme, keni dy grupime Kubernetes në tre zona disponueshmërie dhe 5 transmetime RTMP në Amazon.
Tani le të shohim secilin komponent të sistemit veç e veç.
Transmetim
— Le të fillojmë kur tashmë kemi një imazh video, dhe ai transmetohet në disa shërbime. Artyom, na trego si ndodh ky transmetim?
Artyom Nikonov: Skema jonë e përgjithshme duket kështu: imazhi nga kamera -> dhoma jonë e kontrollit -> serveri lokal RTMP -> Amazon -> luajtësi i videos. Më shumë detaje në Habré në qershor.
Në përgjithësi, ekzistojnë dy mënyra globale për ta bërë këtë: ose në harduer ose bazuar në zgjidhje softuerike. Ne zgjodhëm rrugën e softuerit sepse është më e lehtë në rastin e altoparlantëve në distancë. Nuk është gjithmonë e mundur të sillni pajisje në një altoparlant në një vend tjetër, por dërgimi i softuerit tek altoparlanti duket më i lehtë dhe më i besueshëm.
Nga pikëpamja harduerike, ne kemi një numër të caktuar kamerash (në studiot tona dhe në altoparlantët në distancë), një numër të caktuar telekomandash në studio, të cilat ndonjëherë duhet të riparohen pikërisht nën tavolinë gjatë transmetimit.
Sinjalet nga këto pajisje hyjnë në kompjuterë me karta kapëse, karta hyrëse/dalëse dhe karta zanore. Atje sinjalet përzihen dhe grumbullohen në paraqitje:
Shembull i një paraqitjeje për 4 altoparlantë
Shembull i një paraqitjeje për 4 altoparlantë
Më tej, transmetimi i vazhdueshëm sigurohet me ndihmën e tre kompjuterëve: ka një makinë kryesore dhe një palë të punës me radhë. Kompjuteri i parë mbledh raportin e parë, i dyti - pushimi, i pari - raporti tjetër, i dyti - pushimi tjetër, e kështu me radhë. Dhe makina kryesore përzien të parën me të dytën.
Kjo krijon një lloj trekëndëshi dhe nëse ndonjë prej këtyre nyjeve dështon, ne mund të vazhdojmë me shpejtësi dhe pa humbje të cilësisë të ofrojmë përmbajtje tek klientët. Kishim një situatë të tillë. Gjatë javës së parë të konferencave, ne rregulluam një makinë, e ndezëm/fikëm. Njerëzit duket se janë të kënaqur me qëndrueshmërinë tonë.
Më pas, transmetimet nga kompjuterët shkojnë në një server lokal, i cili ka dy detyra: të drejtojë transmetimet RTMP dhe të regjistrojë kopje rezervë. Pra, ne kemi pika të shumta regjistrimi. Transmetimet e videos më pas dërgohen në pjesën e sistemit tonë të ndërtuar në shërbimet e Amazon SaaS. Ne përdorim ,S3,CloudFront.
Nikolai: Çfarë ndodh atje përpara se videoja të arrijë tek audienca? Duhet ta shkurtosh disi, apo jo?
Artyom: Ne e kompresojmë videon nga ana jonë dhe e dërgojmë në MediaLive. Ne lëshojmë transkoderë atje. Ata transkodojnë videot në kohë reale në disa rezolucione në mënyrë që njerëzit t'i shikojnë ato në telefonat e tyre, përmes internetit të dobët në vend, etj. Pastaj këto rrjedha priten në , kështu funksionon protokolli . Ne dërgojmë një listë luajtjeje në pjesën e përparme që përmban tregues për këto pjesë.
— A po përdorim rezolucionin 1080p?
Artyom: Gjerësia e videos sonë është e njëjtë me 1080p - 1920 piksele, dhe lartësia është pak më e vogël, fotografia është më e zgjatur - ka arsye për këtë.
Lojtar
— Artyom përshkroi se si video hyn në transmetime, si shpërndahet në lista të ndryshme luajtjeje për rezolucione të ndryshme të ekranit, pritet në copa dhe futet në luajtës. Kolya, më thuaj tani çfarë lloj lojtari është ky, si e konsumon transmetimin, pse HLS?
Nikolai: Ne kemi një lojtar që të gjithë shikuesit e konferencës mund ta shikojnë.
Në thelb, ky është një mbështjellës rreth bibliotekës , mbi të cilin janë shkruar shumë lojtarë të tjerë. Por ne kishim nevojë për një funksionalitet shumë specifik: kthimin dhe shënimin e vendit ku ndodhet personi, çfarë raporti po shikon aktualisht. Ne gjithashtu kishim nevojë për paraqitjet tona, të gjitha llojet e logove dhe gjithçka tjetër që ishte ndërtuar me ne. Prandaj, vendosëm të shkruajmë bibliotekën tonë (një mbështjellës mbi HLS) dhe ta vendosim atë në sit.
Ky është funksionaliteti rrënjësor, kështu që u zbatua pothuajse i pari. Dhe pastaj gjithçka u rrit rreth saj.
Në fakt, përmes autorizimit, lojtari merr nga pjesa e pasme një listë dëgjimi me lidhje me pjesë të lidhura me kohën dhe cilësinë, shkarkon ato të nevojshme dhe ia tregon përdoruesit, duke kryer disa "magji" gjatë rrugës.
Shembull i afatit kohor
- Një buton është ndërtuar direkt në luajtës për të shfaqur një afat kohor të të gjitha raporteve...
Nikolai: Po, ne e zgjidhëm menjëherë problemin e navigimit të përdoruesit. Në mes të prillit, vendosëm që të mos transmetonim secilën nga konferencat tona në një faqe interneti të veçantë, por të kombinonim gjithçka në një. Kështu që përdoruesit e biletave Full Pass mund të kalojnë lirisht midis konferencave të ndryshme: si transmetime të drejtpërdrejta ashtu edhe regjistrime të atyre të kaluara.
Dhe për ta bërë më të lehtë për përdoruesit të lundrojnë në transmetimin aktual dhe të kalojnë mes titujve, vendosëm të krijojmë një buton "Transmetimi i plotë" dhe kartat horizontale të raportit për kalimin midis pjesëve dhe raporteve. Ka kontroll të tastierës.
— A kishte ndonjë vështirësi teknike me këtë?
Nikolai: Ata kishin një shirit rrotullimi në të cilin shënoheshin pikat e fillimit të raporteve të ndryshme.
— Në fund, a i keni zbatuar këto shenja në shiritin e lëvizjes përpara se YouTube të bënte diçka të ngjashme?
Artyom: Ata e kishin atë në beta atëherë. Duket sikur kjo është një veçori mjaft komplekse sepse ata e kanë testuar pjesërisht me përdoruesit gjatë vitit të kaluar. Dhe tani ka arritur në shitje.
Nikolai: Por ne në fakt e arritëm në shitje më shpejt. Sinqerisht, pas kësaj veçorie të thjeshtë ka një sasi të madhe prapavijë, front, llogaritje dhe matematikë brenda lojtarit.
Frontend
— Le të kuptojmë se si kjo përmbajtje që shfaqim (karta e të folurit, folësit, uebsajti, orari) arrin në pjesën e përparme?
Vladimir Krasilshchik: Ne kemi disa sisteme të brendshme IT. Ekziston një sistem në të cilin futen të gjitha raportet dhe të gjithë folësit. Ekziston një proces me anë të të cilit një folës merr pjesë në një konferencë. Folësi paraqet një aplikim, sistemi e kap atë, pastaj ekziston një tubacion i caktuar sipas të cilit krijohet raporti.
Kështu e sheh folësi tubacionin
Ky sistem është zhvillimi ynë i brendshëm.
Tjetra, duhet të ndërtoni një orar nga raportet individuale. Siç e dini, ky është një problem i vështirë NP, por ne disi e zgjidhim atë. Për ta bërë këtë, ne lëshojmë një komponent tjetër që gjeneron një orar dhe e ngarkon atë në shërbimin cloud të palëve të treta Contentful. Aty çdo gjë duket si një tavolinë në të cilën ka ditë të konferencës, në ditë ka periudha kohore dhe në slota ka raporte, pushime ose aktivitete sponsorizimi. Pra, përmbajtja që shohim ndodhet në një shërbim të palës së tretë. Dhe detyra është ta përcillni atë në sit.
Duket se faqja është vetëm një faqe me një lojtar, dhe nuk ka asgjë të komplikuar këtu. Përveçse nuk është. Backend-i pas kësaj faqe shkon te Contentful, merr orarin prej andej, gjeneron disa objekte dhe e dërgon atë në front. Duke përdorur një lidhje websocket, të cilën çdo klient i platformës sonë e bën, ne i dërgojmë atij një përditësim të orarit nga pjesa e pasme në pjesën e përparme.
Rasti i vërtetë: folësi ndërroi punë pikërisht gjatë konferencës. Duhet të ndryshojmë distinktivin e kompanisë së tij të punëdhënësit. Si ndodh kjo nga prapavija? Një përditësim u dërgohet të gjithë klientëve nëpërmjet uebsocket-it dhe më pas vetë frontend rivizaton afatin kohor. E gjithë kjo ndodh pa probleme. Kombinimi i shërbimit cloud dhe disa prej komponentëve tanë na jep mundësinë që të gjenerojmë të gjithë këtë përmbajtje dhe ta ofrojmë atë përpara.
Nikolai: Është e rëndësishme të sqarojmë këtu se faqja jonë nuk është një aplikacion klasik SPA. Kjo është edhe një faqe interneti e bazuar në paraqitje, e paraqitur dhe një SPA. Google në fakt e sheh këtë faqe si HTML të dhënë. Kjo është e mirë për SEO dhe për dërgimin e përmbajtjes tek përdoruesi. Nuk pret që 1,5 megabajt JavaScript të ngarkohet përpara se të shohë faqen, ai menjëherë sheh faqen e renderuar tashmë dhe ju e ndjeni atë sa herë që ndërroni raportin. Gjithçka ndodh në gjysmë sekonde, pasi përmbajtja tashmë është gati dhe e postuar në vendin e duhur.
— Le të bëjmë një vijë nën të gjitha sa më sipër duke renditur teknologjitë. Tyoma tha se ne kemi 5 transmetime në Amazon dhe ne ofrojmë video dhe zë atje. Ne kemi skriptet bash atje, ne i përdorim ato për të nisur dhe konfiguruar ...
Artyom: Kjo ndodh përmes API AWS, ka shumë shërbime të tjera anësore teknike atje. Ne kemi ndarë përgjegjësitë tona në mënyrë që unë t'i dorëzoj , dhe zhvilluesit e përparme dhe të pasme e marrin atë nga atje. Ne kemi një numër lidhjesh tona për të thjeshtuar paraqitjen e përmbajtjes, të cilat më pas i bëjmë në 4K, etj. Meqenëse afatet ishin shumë të ngushta, ne e bëmë atë pothuajse tërësisht në AWS.
— Pastaj e gjithë kjo shkon në luajtës duke përdorur sistemin e backend. Ne kemi TypeScript, React, Next.JS në luajtësin tonë. Dhe në backend kemi disa shërbime në C#, Java, Spring Boot dhe Node.js. E gjithë kjo vendoset duke përdorur Kubernetes duke përdorur infrastrukturën Yandex.Cloud.
Dua të vërej gjithashtu se kur më duhej të njihesha me platformën, doli të ishte e lehtë: të gjitha depot janë në GitLab, gjithçka është e emërtuar mirë, testet janë shkruar, ka dokumentacion. Domethënë, edhe në gjendje emergjente, ata kujdeseshin për gjëra të tilla.
Kufizimet e biznesit dhe analizat
— Ne synuam 10 përdorues bazuar në kërkesat e biznesit. Është koha të flasim për kufizimet e biznesit që kishim. Ne duhej të siguronim një ngarkesë të lartë pune, të siguronim respektimin e ligjit për ruajtjen e të dhënave personale. Dhe cfare tjeter?
Nikolai: Fillimisht u nisëm nga kërkesat për video. Gjëja më e rëndësishme është ruajtja e videove të shpërndara në të gjithë botën për dërgim të shpejtë te klienti. Të tjera përfshijnë rezolucionin 1080p, si dhe rikthimin, të cilin shumë të tjerë nuk e zbatojnë në modalitetin live. Më vonë shtuam aftësinë për të aktivizuar shpejtësinë 2x, me ndihmën e saj ju mund të "kapni hapin" me live dhe të vazhdoni ta shikoni konferencën në kohë reale. Dhe gjatë rrugës, u shfaq funksionaliteti i shënimit të afatit kohor. Plus, duhej të ishim tolerantë ndaj gabimeve dhe të përballonim ngarkesën prej 10 lidhjesh. Nga pikëpamja e backend-it, kjo është afërsisht 000 lidhje shumëzuar me 10 kërkesa për çdo rifreskim të faqes. Dhe kjo është tashmë 000 RPS/sek. Mjaft pak.
— A kishte kërkesa të tjera për një “ekspozitë virtuale” me stendat online të partnerëve?
Nikolai: Po, kjo duhej bërë mjaft shpejt dhe në mënyrë universale. Ne kishim deri në 10 kompani partnere për çdo konferencë dhe të gjitha duhej të përfundonin brenda një ose dy javësh. Megjithatë, përmbajtja e tyre ndryshon pak në format. Por u krijua një motor i caktuar shabllon që i mbledh këto faqe në fluturim, praktikisht pa pjesëmarrje të mëtejshme në zhvillim.
— Kishte gjithashtu kërkesa për analitikë të pamjeve dhe statistikave në kohë reale. E di që ne përdorim Prometheun për këtë, por na tregoni më në detaje: çfarë kërkesash plotësojmë për analitikë dhe si zbatohet kjo?
Nikolai: Fillimisht, ne kemi kërkesa marketingu për mbledhjen për testimin e A/B dhe mbledhjen e informacionit, në mënyrë që të kuptojmë se si t'i dorëzojmë siç duhet përmbajtjen më të mirë klientit në të ardhmen. Ekzistojnë gjithashtu kërkesa për disa analiza mbi aktivitetet e partnerëve dhe analitikën që shihni (banaku i vizitave). Të gjitha informacionet mblidhen në kohë reale.
Ne mund ta ofrojmë këtë informacion në formë të përmbledhur edhe për folësit: sa njerëz po ju shikonin në një moment të caktuar kohor. Në të njëjtën kohë, në përputhje me Ligjin Federal 152, llogaria juaj personale dhe të dhënat personale nuk gjurmohen në asnjë mënyrë.
Platforma tashmë ka mjetet e marketingut dhe metrikat tona për matjen e aktivitetit të përdoruesve në kohë reale (të cilët kanë parë çfarë sekonde të raportit) në mënyrë që të ndërtojnë grafikët e pjesëmarrjes në raporte. Në bazë të këtyre të dhënave po bëhen kërkime që do t'i bëjnë më të mira konferencat e ardhshme.
Mashtrim
— A kemi mekanizma kundër mashtrimit?
Nikolai: Për shkak të kornizës së ngushtë kohore nga pikëpamja e biznesit, detyra nuk ishte vendosur fillimisht për të bllokuar menjëherë lidhjet e panevojshme. Nëse dy përdorues janë identifikuar në të njëjtën llogari, ata mund të shikojnë përmbajtjen. Por ne e dimë se sa shikime të njëkohshme ka pasur nga një llogari. Dhe ne ndaluam disa shkelës veçanërisht keqdashës.
Vladimir: Për meritë të tij, një nga përdoruesit e ndaluar e kuptoi pse ndodhi kjo. Ai erdhi, kërkoi falje dhe premtoi se do të blinte një biletë.
— Që të ndodhë e gjithë kjo, duhet të gjurmoni plotësisht të gjithë përdoruesit nga hyrja në dalje, gjithmonë të dini se çfarë po bëjnë. Si funksionon ky sistem?
Vladimir: Do të doja të flisja për analitikën dhe statistikat, të cilat më pas i analizojmë për suksesin e raportit ose më pas mund t'ua ofrojmë partnerëve. Të gjithë klientët janë të lidhur nëpërmjet një lidhjeje websocket me një grup specifik backend. Ajo qëndron atje . Çdo klient në çdo periudhë kohore dërgon atë që po bën dhe çfarë piste po shikon. Më pas, ky informacion grumbullohet duke përdorur punë të shpejta Hazelcast dhe u dërgohet të gjithëve që i shikon këto pjesë. Ne shohim në qoshe se sa njerëz janë tani me ne.
I njëjti informacion ruhet në dhe shkon në liqenin tonë të të dhënave, nga i cili kemi mundësinë të ndërtojmë një grafik më interesant. Shtrohet pyetja: sa përdorues unikë e kanë parë këtë raport? Shkojmë në , ka ping të të gjithë personave që kanë ardhur nga id i këtij raporti. Ne mblodhëm, grumbulluam ato unike dhe tani mund t'i kuptojmë.
Nikolai: Por në të njëjtën kohë, ne marrim edhe të dhëna në kohë reale nga Prometheus. Është vendosur kundër të gjitha shërbimeve Kubernetes, kundër vetë Kubernetes. Ai mbledh absolutisht gjithçka, dhe me Grafana mund të ndërtojmë çdo grafik në kohë reale.
Vladimir: Nga njëra anë, ne e shkarkojmë këtë për përpunim të mëtejshëm OLAP. Dhe për OLTP, aplikacioni shkarkon të gjithë në Prometheus, Grafana dhe grafikët madje konvergojnë!
- Ky është rasti kur grafikët konvergjojnë.
Ndryshimet dinamike
— Na tregoni se si zhvillohen ndryshimet dinamike: nëse raporti u anulua 6 minuta para fillimit, cili është zinxhiri i veprimeve? Cili tubacion funksionon?
Vladimir: Tubacioni është shumë i kushtëzuar. Ka disa mundësi. E para është se programi i gjenerimit të orarit funksionoi dhe ndryshoi orarin. Orari i modifikuar ngarkohet te Contentful. Pas së cilës backend kupton se ka ndryshime për këtë konferencë në Contentful, e merr atë dhe e rindërton. Gjithçka mblidhet dhe dërgohet përmes websocket.
Mundësia e dytë, kur gjithçka ndodh me një ritëm marramendës: redaktori ndryshon manualisht informacionin në Contentful (lidhja me Telegram, prezantimi i folësit, etj.) dhe e njëjta logjikë funksionon si herën e parë.
Nikolai: Gjithçka ndodh pa rifreskuar faqen. Të gjitha ndryshimet ndodhin absolutisht pa probleme për klientin. E njëjta gjë vlen edhe për ndërrimin e raporteve. Kur të vijë koha, raporti dhe ndërfaqja ndryshojnë.
Vladimir: Gjithashtu, ka ndërprerje kohore për fillimin e raporteve në afatin kohor. Në fillim nuk ka asgjë. Dhe nëse rri pezull miun mbi shiritin e kuq, atëherë në një moment, falë drejtorit të transmetimit, do të shfaqen ndërprerje. Regjisori cakton fillimin e saktë të transmetimit, backend-i e merr këtë ndryshim, llogarit kohën e fillimit dhe mbarimit të të gjithë prezantimeve të këngës në përputhje me orarin e konferencës, ia dërgon atë klientëve tanë dhe lojtari tërheq kufijtë. Tani përdoruesi mund të lundrojë lehtësisht në fillim dhe në fund të raportit. Ishte një kërkesë e rreptë biznesi, shumë e përshtatshme dhe e dobishme. Ju nuk humbni kohë duke gjetur kohën aktuale të fillimit të raportit. Dhe kur të bëjmë një pamje paraprake, do të jetë absolutisht e mrekullueshme.
Vendosja
— Do të doja të pyesja për vendosjen. Kolya dhe ekipi shpenzuan shumë kohë në fillim për të ngritur të gjithë infrastrukturën në të cilën shpaloset gjithçka për ne. Më thuaj, nga çfarë përbëhet?
Nikolai: Nga pikëpamja teknike, fillimisht kishim një kërkesë që produkti të ishte sa më abstrakt nga çdo shitës. Ejani në AWS për të bërë skriptet Terraform posaçërisht nga AWS, ose specifikisht nga Yandex, ose nga Azure, etj. nuk përshtatej vërtet. Na u desh të lëviznim diku në një moment.
Për tre javët e para ne po kërkonim vazhdimisht një mënyrë për ta bërë këtë më mirë. Si rezultat, arritëm në përfundimin se Kubernetes në këtë rast është gjithçka jonë, sepse na lejon të krijojmë shërbime me shkallëzim automatik, lëshim automatik dhe të nxjerrim pothuajse të gjitha shërbimet jashtë kutisë. Natyrisht, të gjitha shërbimet duhej të trajnoheshin për të punuar me Kubernetes, Docker dhe ekipi duhej të mësonte gjithashtu.
Kemi dy grupime. Testimi dhe prodhimi. Ato janë absolutisht identike për sa i përket harduerit dhe cilësimeve. Ne implementojmë infrastrukturën si kod. Të gjitha shërbimet shpërndahen automatikisht në tre mjedise nga degët e veçorive, degët kryesore, degët testuese dhe GitLab duke përdorur një tubacion automatik. Kjo është e integruar maksimalisht në GitLab, e integruar maksimalisht me Elastic, Prometheus.
Ne kemi mundësinë që shpejt (për pjesën e përparme brenda 10 minutash, për pjesën e përparme brenda 5 minutash) të bëjmë ndryshime në çdo mjedis me të gjitha testet, integrimet, ekzekutimin e testeve funksionale, testet e integrimit në mjedis dhe gjithashtu testimin me testet e ngarkesës në një mjedis testimi përafërsisht të njëjtën gjë që ne duam të marrim në prodhim.
Rreth testeve
— Ti teston pothuajse gjithçka, është e vështirë të besosh se si ke shkruar gjithçka. Mund të na thoni për testet e backend: sa është e mbuluar gjithçka, çfarë testesh?
Vladimir: Janë shkruar dy lloje testesh. E para janë testet e komponentëve. Testet e nivelit të ngritjes së të gjithë aplikimit të pranverës dhe bazës brenda . Ky është një test i skenarëve të biznesit të nivelit më të lartë. Unë nuk i testoj funksionet. Ne testojmë vetëm disa gjëra të mëdha. Për shembull, pikërisht në test, procesi i hyrjes në një përdorues imitohet, kërkesa e përdoruesit për bileta ku mund të shkojë dhe një kërkesë për qasje për të parë transmetimin. Skenarë shumë të qartë të përdoruesit.
Përafërsisht e njëjta gjë zbatohet në të ashtuquajturat teste të integrimit, të cilat në fakt ekzekutohen në mjedis. Në fakt, kur vendosja e radhës në prodhim është e mbështjellë, skenarët e vërtetë bazë janë gjithashtu në prodhim. I njëjti hyrje, duke kërkuar bileta, duke kërkuar qasje në CloudFront, duke kontrolluar që transmetimi lidhet vërtet me lejet e mia, duke kontrolluar ndërfaqen e drejtorit.
Për momentin kam rreth 70 teste të komponentëve dhe rreth 40 teste integrimi në bord. Mbulimi është shumë afër 95%. Kjo është për ato komponente, më pak për ato të integrimit, thjesht nuk ka aq shumë nevojë. Duke marrë parasysh që projekti përfshin të gjitha llojet e gjenerimit të kodit, ky është një tregues shumë i mirë. Nuk kishte rrugë tjetër për të bërë atë që bëmë në tre muaj. Sepse nëse do të testonim manualisht, duke i dhënë veçori testerit tonë, dhe ajo do të gjente gabime dhe do t'i kthente tek ne për rregullime, atëherë ky udhëtim vajtje-ardhje për të korrigjuar kodin do të ishte shumë i gjatë dhe ne nuk do të përmbushnim asnjë afat.
Nikolai: Në mënyrë konvencionale, për të kryer një regresion në të gjithë platformën kur ndryshoni disa funksione, duhet të uleni dhe të goditni kudo për dy ditë.
Vladimir: Prandaj, është një sukses i madh që kur vlerësoj një veçori, them se më duhen 4 ditë për dy stilolapsa të thjeshtë dhe 1 fole ueb, Kolya e lejon. Ai tashmë është mësuar me faktin që këto 4 ditë përfshijnë 2 lloje testesh, dhe më pas, me shumë mundësi, do të funksionojë.
Nikolai: Kam shkruar edhe 140 teste: komponent + funksional, të cilat bëjnë të njëjtën gjë. Të gjithë skenarët e njëjtë testohen në prodhim, në provë dhe në prodhim. Kohët e fundit kemi shtuar gjithashtu teste funksionale bazë të ndërfaqes së përdoruesit. Në këtë mënyrë ne mbulojmë funksionalitetin më themelor që mund të shpërbëhet.
Vladimir: Sigurisht, ia vlen të flasim për testet e ngarkesës. Ishte e nevojshme të testohej platforma nën një ngarkesë afër asaj reale për të kuptuar se si është gjithçka, çfarë po ndodh me Rabbit, çfarë po ndodh me JVM-të, sa memorie nevojitet në të vërtetë.
— Nuk e di me siguri nëse po testojmë ndonjë gjë në anën e rrjedhës, por mbaj mend që kishte probleme me transkoderat kur bëmë takime. A i kemi testuar rrjedhat?
Artyom: Testuar në mënyrë të përsëritur. Organizimi i takimeve. Në procesin e organizimit të takimeve, ishin rreth 2300 bileta JIRA. Këto janë thjesht gjëra të përgjithshme që njerëzit bënë për të bërë takime. Ne morëm pjesë të platformës në një faqe të veçantë për takime, e cila u drejtua nga Kirill Tolkachev ().
Për të qenë i sinqertë, nuk kishte probleme të mëdha. Fjalë për fjalë disa herë ne kapëm defekte në memorie në CloudFront, e zgjidhëm mjaft shpejt - thjesht rikonfiguruam politikat. Kishte dukshëm më shumë gabime te njerëzit, në sistemet e transmetimit në faqe.
Gjatë konferencave, më duhej të shkruaja disa eksportues të tjerë në mënyrë që të mbuloja më shumë pajisje dhe shërbime. Në disa vende më duhej të bëja biçikletat e mia vetëm për hir të metrikës. Bota e pajisjeve AV (audio-video) nuk është shumë rozë - ju keni një lloj "API" pajisjesh që thjesht nuk mund të ndikoni. Dhe është larg nga fakti që ju do të jeni në gjendje të merrni informacionin që ju nevojitet. Shitësit e pajisjeve janë vërtet të ngadaltë dhe është pothuajse e pamundur të merrni atë që dëshironi prej tyre. Në total, ka më shumë se 100 pjesë të pajisjeve, ato nuk ju kthejnë atë që ju nevojitet, dhe ju shkruani eksportues të çuditshëm dhe të tepërt, falë të cilëve të paktën mund të korrigjoni disi sistemin.
Оборудование
— Më kujtohet se si para fillimit të konferencave kemi blerë pjesërisht pajisje shtesë.
Artyom: Ne blemë kompjuterë, laptopë dhe paketa baterish. Për momentin mund të jetojmë pa energji elektrike për 40 minuta. Në qershor pati stuhi të forta në Shën Petersburg - kështu që patëm një ndërprerje të tillë. Në të njëjtën kohë, disa ofrues na vijnë me lidhje optike nga pika të ndryshme. Kjo është me të vërtetë 40 minuta kohë joproduktive të ndërtesës, gjatë së cilës do të kemi ndezur dritat, zërin, kamerat, etj.
— Ne kemi një histori të ngjashme me internetin. Në zyrën ku ndodhen studiot tona, tërhoqëm një rrjetë të ashpër midis kateve.
Artyom: Ne kemi 20 Gbit fibër midis kateve. Më tej përgjatë kateve, diku ka optikë, diku nuk ka optikë, por gjithsesi ka më pak kanale se ato gigabit - ne shfaqim video në to midis këngëve të konferencës. Në përgjithësi, është shumë i përshtatshëm të punosh në infrastrukturën tënde; rrallë mund ta bësh këtë në konferenca offline në sajte.
— Përpara se të punoja në JUG Ru Group, pashë sesi dhomat e harduerit në konferencat offline u krijuan brenda natës, ku kishte një monitor të madh me të gjitha metrikat që ndërtoni në Grafana. Tani ka edhe një dhomë qendrore në të cilën ulet ekipi i zhvillimit, i cili gjatë konferencës rregullon disa gabime dhe zhvillon veçori. Në të njëjtën kohë, ekziston një sistem monitorimi që shfaqet në një ekran të madh. Artyom, Kolya dhe djem të tjerë ulen dhe sigurohen që gjithçka të mos bjerë dhe të funksionojë bukur.
Kuriozitete dhe probleme
— Ju folët mirë për faktin që ne kemi transmetim me Amazon, ka një lojtar me ueb, gjithçka është e shkruar në gjuhë të ndryshme programimi, ofrohet toleranca ndaj gabimeve dhe kërkesa të tjera biznesi, duke përfshirë një llogari personale që mbështetet për personat juridikë dhe individë, dhe ne mund të integrohemi me dikë që përdor OAuth 2.0, ka anti-mashtrim, bllokim të përdoruesit. Ne mund t'i hapim ndryshimet në mënyrë dinamike sepse e bëmë mirë, dhe gjithçka është e testuar.
Unë jam i interesuar të di se çfarë të çuditshme ishin përfshirë në fillimin e diçkaje. A ka pasur ndonjë situatë të çuditshme kur po zhvillonit një backend, frontend, doli diçka e çmendur dhe nuk e kuptonit se çfarë të bëni me të?
Vladimir: Më duket se kjo ka ndodhur vetëm tre muajt e fundit. Çdo ditë. Siç mund ta shihni, të gjitha flokët më janë shkulur.
Vladimir Krasilshchik pas 3 muajsh, kur doli një lloj loje dhe askush nuk e kuptoi se çfarë të bënte me të
Çdo ditë ka pasur diçka të tillë, kur ka pasur një moment të tillë kur e merr dhe i heq flokët, ose e kupton se nuk ka njeri tjetër dhe vetëm ti mund ta bësh. Ngjarja jonë e parë e madhe ishte TechTrain. Më 6 qershor në orën 2 të mëngjesit ne ende nuk e kishim hapur mjedisin e prodhimit, Kolya po e nxirrte atë. Dhe llogaria personale nuk funksionoi si një server autorizimi duke përdorur OAuth2.0. Ne e kthyem atë në një ofrues OAuth2.0 për të lidhur platformën me të. Unë kisha punuar për ndoshta 18 orë rresht, shikova kompjuterin dhe nuk pashë asgjë, nuk e kuptoja pse nuk po funksiononte dhe Kolya shikoi kodin tim nga distanca, kërkoi një gabim në konfigurimin Spring , e gjeti, dhe LC funksionoi, dhe në prodhim gjithashtu.
Nikolai: Dhe një orë para TechTrain u bë lëshimi.
Shumë yje u rreshtuan këtu. Ishim jashtëzakonisht me fat sepse kishim një super ekip dhe të gjithë u frymëzuan nga ideja për ta bërë atë online. Të gjithë këta tre muaj ne u nxitëm nga fakti që ne "krijuam YouTube". Nuk e lejova veten të shkulja flokët, por u thashë të gjithëve se gjithçka do të funksiononte, sepse në fakt, gjithçka ishte llogaritur shumë kohë më parë.
Rreth performancës
— A mund të më thoni sa njerëz ishin në sit në një pistë? A kishte probleme me performancën?
Nikolai: Nuk kishte probleme me performancën, siç thamë tashmë. Numri maksimal i njerëzve që morën pjesë në një raport ishte 1300 persona, ky është në Heisenbug.
— A kishte ndonjë problem me shikimin lokal? Dhe a është e mundur të kemi një përshkrim teknik me diagrame se si funksionon gjithçka?
Nikolai: Ne do të bëjmë një artikull për këtë më vonë.
Ju madje mund të korrigjoni transmetimet në nivel lokal. Me fillimin e konferencave, u bë edhe më e lehtë, sepse u shfaqën rryma prodhimi që mund t'i shikojmë gjatë gjithë kohës.
Vladimir: Siç e kuptoj unë, zhvilluesit e nivelit të përparmë kanë punuar në nivel lokal me tallje, dhe më pas, meqenëse koha për t'u futur te zhvilluesit në pjesën e përparme është gjithashtu e shkurtër (5 minuta), nuk ka probleme për të kontrolluar se çfarë po ndodh me certifikatat.
— Gjithçka testohet dhe korrigjohet, madje edhe në nivel lokal. Kjo do të thotë që ne do të shkruajmë një artikull me të gjitha karakteristikat teknike, do t'ju tregojmë, do t'ju tregojmë gjithçka me diagrame, si ishte.
Vladimir: Mund ta merrni dhe ta përsërisni.
- Në 3 muaj.
Total
— Gjithçka e përshkruar së bashku tingëllon e lezetshme, duke pasur parasysh se është bërë nga një ekip i vogël në tre muaj.
Nikolai: Një ekip i madh nuk do ta bënte këtë. Por një grup i vogël njerëzish që komunikojnë mjaft ngushtë dhe mirë me njëri-tjetrin dhe mund të arrijnë një marrëveshje mund. Nuk kanë asnjë kontradiktë, arkitektura u shpik për dy ditë, u finalizua dhe në fakt nuk ka ndryshuar. Ekziston një lehtësim shumë i rreptë i kërkesave të biznesit në hyrje në drejtim të grumbullimit të kërkesave dhe ndryshimeve për veçori.
— Çfarë ishte në listën tuaj të detyrave të mëtejshme kur tashmë ishin zhvilluar konferencat verore?
Nikolai: Për shembull, kreditë. Vija rrëshqitëse në video, shfaqen në disa vende në video në varësi të përmbajtjes që shfaqet. Për shembull, folësi dëshiron t'i bëjë një pyetje audiencës dhe një votim shfaqet në ekran, i cili kthehet prapa në bazë të rezultateve të votimit për vetë folësin. Një lloj aktiviteti shoqëror në formën e pëlqimeve, zemrave, vlerësimeve të raportit gjatë vetë prezantimit, në mënyrë që të plotësoni reagimet në momentin e duhur pa u shpërqendruar më vonë nga formularët e komenteve. Fillimisht kështu.
Dhe gjithashtu duke shtuar në të gjithë platformën, përveç transmetimit dhe konferencës, gjithashtu një gjendje pas konferencës. Këto janë lista për luajtje (duke përfshirë ato të përpiluara nga përdoruesit), ndoshta përmbajtje nga konferenca të tjera të kaluara, të integruara, të etiketuara, të aksesueshme për përdoruesin dhe gjithashtu të disponueshme për t'u parë në faqen tonë të internetit ().
- Djema, ju faleminderit shumë për përgjigjet tuaja!
Nëse mes lexuesve ka nga ata që morën pjesë në konferencat tona verore, ju lutemi ndani përshtypjet tuaja për lojtarin dhe transmetimin. Çfarë ishte e përshtatshme, çfarë ju acaroi, çfarë do të dëshironit të shihnit në të ardhmen?
Nëse jeni të interesuar për platformën dhe dëshironi ta shihni atë "në betejë", ne e përdorim përsëri në faqen tonë . Ka një gamë të tërë të tyre, kështu që ka pothuajse me siguri një që është i duhuri për ju.
Burimi: www.habr.com