Këtë pranverë ishim në kushte shumë të këndshme. Për shkak të pandemisë, u bë e qartë se konferencat tona të verës duhet t'i kalonim online. Dhe për ta zhvilluar ato në mënyrë cilësore, zgjidhjet e gatshme nuk ishin të mjaftueshme; duhej ndërtuar një platformë të vetme. Dhe për këtë kishim tre muaj.
E qartë, ishin tri muaj emocionues. Por nga jasht duket se nuk është shumë e qartë: çfarë përbën një platformë për konferenca online? Nga cilat pjesë përbëhet ajo? Prandaj, gjatë konferencës së fundit të verës DevOops, pyeta ata që ishin përgjegjës për këtë detyrë:
- Nikolaj Molçanov — drejtori teknik i JUG Ru Group;
- Vladimir Krasilshchik — një programues pragmatik Java, i angazhuar në backend (mund të keni parë gjithashtu paraqitjet e tij në konferencat tona Java);
- Artyom Nikонов — përgjegjës për tërë transmetimin tonë video.
Përveç kësaj, në konferencat e vjeshtës dhe dimrit do të përdorim një version të përmirësuar të të njëjtës platformë — kështu që shumë përdorues të Habr do të jenë gjithashtu përdorues të saj.
Pamja e përgjithshme
— Si ishte përbërja e ekipit?
Nikolaj Molçanov: У нас есть аналитик, дизайнер, тестировщик, три фронтендера, бэкендер. И, конечно, T-shaped специалист!
— Как в целом выглядел процесс?
Николай: До середины марта у нас к онлайну не было готово вообще ничего. А 15 марта завертелась вся карусель с онлайном. Мы завели несколько репозиториев, спланировали, обсудили базовую архитектуру и сделали всё за три месяца.
Это, конечно, прошло классические этапы планирования, архитектуры, выбора фич, голосование за эти фичи, политики этих фич, их дизайна, разработки, тестирования. В итоге 6 июня мы выкатили всё в прод на . На всё про всё было 90 дней.
— Получилось ли успеть то, на что мы коммитились?
Николай: Раз мы сейчас участвуем в конференции DevOops в онлайне — значит, получилось. Я лично закоммитился на главную вещь: принесу заказчикам инструмент, при помощи которого можно будет сделать конференцию в онлайне.
Задача стояла так: дайте нам инструмент, с помощью которого мы сможем транслировать наши конференции обладателям билетов.
Все планирование было разбито на несколько этапов, и все фичи (около 30 глобальных), были поделены на 4 категории:
- të cilat ne patjetër do t'i bëjmë (pa to nuk mund të jetojmë),
- të cilat do t'i bëjmë në radhën e dytë,
- të cilat ne kurrë nuk do t'i bëjmë,
- dhe ato që kurrë-jo-kurrë nuk do t'i bëjmë.
Të gjitha veçoritë nga dy kategoritë e para i kemi bërë.
— E di që janë regjistruar në total 600 detyra në JIRA. Për tridhjetë muaj, ju keni bërë 13 mikrosherbime dhe dyshoj se ato janë shkruar jo vetëm në Java. Keni përdorur teknologji të ndryshme, keni ngritur dy klasterë Kubernetes në tre zona disponibiliteti dhe 5 RTMP stream-e në Amazon.
Tani le të shqyrtojmë çdo komponent të sistemit veç e veç.
Streaming
— Të fillojmë me atë, kur ne tashmë kemi një pamje video dhe ajo po dërgohet në disa shërbime. Artyom, na trego si ndodh ky streaming?
Artyom Nikонов: Schemi ynë duket kështu: imazhi nga kamera -> pultin tonë -> serveri lokal RTMP -> Amazon -> playeri video. Më shumë në Habra në qershor.
Në përgjithësi, ka dy mënyra globale për ta bërë këtë: ose në harduer, ose duke përdorur zgjidhje software. Ne zgjodhëm rrugën e softit, sepse është më e lehtë në rastin e folësve të largët. Nuk është gjithmonë e mundur të sjellësh harduer për një folës në një tjetër vend, ndërsa instalimi i një programi duket më i lehtë dhe më i sigurt për folësin.
Sa i përket harduerit, ne kemi një numër kamerash (në studiot tona dhe te folësit e largët), disa pult në studio, të cilat ndonjëherë duhet të riparohen përpara në udhëzim gjatë transmetimit.
Sinjalet nga këto pajisje hyjnë në kompjuterë me bordet e kapjes, hyrjes/daljes dhe kartat audio. Atje sinjalet përzihen dhe mblidhen në layout-e:
Shembulli i një laye të 4 folësve
Shembulli i një laye të 4 folësve
Më pas, transmetimi vazhdon pa ndërprerje me ndihmën e tre kompjuterëve: ka një makinë kryesore dhe dy që punojnë me radhë. Kompjuteri i parë mbledh prezantimin e parë, i dyti — pushimin, i pari — prezantimin tjetër, i dyti — pushimin tjetër dhe kështu me radhë. Ndërsa makina kryesore përzjen të parin me të dytin.
Në këtë mënyrë formohet një trekëndësh, dhe në rast të rënies së ndonjëra nga këto nyje, ne mund të vazhdojmë të dërgojmë përmbajtje klientëve shpejt dhe pa humbur cilësi. Një situatë e tillë ndodhi. Në javën e parë të konferencave, ne riparojmë një makinë, e ndezim/e fikim. Duket se njerëzit janë të kënaqur me qëndrueshmërinë tonë.
Më pas, rrjedhat nga kompjuterët shkojnë në serverin lokal, i cili ka dy detyra: të rruajë rrjedhat RTMP dhe të regjistron një kopje rezervë. Kështu, ne kemi disa pikë regjistrimi. Më vonë, rrjedhat e videos dërgohen në një pjesë të sistemit tonë, e ndërtuar mbi shërbimet SaaS të Amazon. Përdorim , S3, CloudFront.
Николай: Dhe çfarë ndodh atje para se videoja të arrijë tek shikuesit? A nuk duhet ta prishni ndonjëherë?
Artyom: Ne ngushtojmë videon nga ana jonë, e dërgojmë në MediaLive. Atje, aktivizojmë transcoder-at. Ata ricodojnë videon në kohë reale në disa rezolucione që njerëzit të mund ta shikojnë atë në telefonat e tyre, përmes internetit të dobët në vilë dhe kështu me radhë. Më pas, këto transmetime preken në , kështu funksionon protokolli . Ne i japim frontend-it një playlist, në të cilën janë treguesit për këto copa.
— A përdorim rezolucionin 1080p?
Artyom: Gjerësia është si video 1080p — 1920 piksel, ndërsa lartësia është pak më e vogël, figura është më e zgjatur — kjo ka shkaqet e veta.
Lojtari
— Artiom e përshkroi se si videoja përfundon në transmetime, si ndahen në lista të ndryshme për rezolucione të ndryshme ekranesh, shkurtohet në fragmente dhe hyn në lojtar. Kolja, tregoi tani, çfarë është ky lojtar, si konsumon transmetimin, përse HLS?
Николай: Kemi një lojtar që e ndjekin të gjithë shikuesit e konferencës.
Në thelb, kjo është një mbështjellës mbi bibliotekën , mbi të cilën janë shkruar shumë lojtarë të tjerë. Por na nevojitej një funksionalitet shumë specifik: rikthim prapa dhe shënim në vendin ku ndodhet personi, cili prezantim po e shikon tani. Po ashtu, na duhen dizajne të posaçme, logo dhe çdo gjë tjetër që është integruar me ne. Kështu që vendosëm të shkruajmë një bibliotekë të vetme (mbështjellës mbi HLS) dhe ta integrojmë në faqe.
Kjo është funksionaliteti kryesor, kështu që u realizua thuajse e para. Më pas, përreth kësaj gjithçka filloi të rritet.
Në fakt, player-i merr nga backend-i një listë me lidhje për chunks, të lidhura me kohën dhe cilësinë, dhe i shkarkon ato të nevojshme në mënyrë që t'i tregojë përdoruesit, duke kryer në këtë proces njëfarë 'magjie'.
Shembulli i kohës
— Direkt në player është e integruar një buton për të shfaqur kohën e të gjitha prezantimeve...
Николай: Po, ne menjëherë zgjidhëm problemin e navigimit të përdoruesit. Në mes të prillit vendosëm të mos transmetonim çdo konferencë në një faqe të veçantë, por t'i bashkonim të gjitha në një. Kështu, përdoruesit me biletë Full Pass mund të kalojnë lirisht midis konferencave të ndryshme: si transmetimi direkt ashtu edhe regjistrimet e kaluara.
Dhe për të lehtësuar përdoruesit në lëvizjen e tyre në transmetimin aktual dhe kalimin midis temave, vendosëm të krijojmë një buton 'I gjithë transmetimi' dhe karta horizontale për prezantimet për kalimin mes temave dhe prezantimeve. Aty ka kontroll nga tastiera.
— A kishte ndonjë vështirësi teknike me këtë?
Николай: Ishte me shiritin e rrotullimit, ku shënohen pikat e fillimit të prezantimeve të ndryshme.
— Në fund, a e realizuat këto shënime në shiritin e rrotullimit më herët se YouTube?
Artyom: Ata e kishin atëherë në beta. Duket se është një veçori mjaft e komplikuar, pasi ata e kanë provuar pjesërisht me përdoruesit gjatë vitit të kaluar. Dhe tani, përfundimisht, ka arritur në shitje.
Николай: Por ne e kemi çuar në shitje më shpejt. E vërteta është që pas kësaj veçorie të thjeshtë fshihet një sasi e madhe të backend-it, frontend-it dhe llogaritjeve dhe matematikës brenda lojtarit.
Frontend
— Le të kuptojmë si del ky përmbajtje që ne e tregojmë (kartela e prezantimit, folësit, faqja, orari) në frontend?
Vladimir Krasilshchik: Kemi disa sisteme të brendshme IT. Ka një sistem ku janë regjistruar të gjitha prezantimet dhe të gjithë folësit. Ka një proces me të cilin folësi merr pjesë në konferencë. Folësi aplikon, sistemi e kap atë, më pas ka një pipeline të caktuar nga i cili krijohet prezantimi.
Kështu folësi sheh pipeline-in
Ky sistem është zhvillim i brendshëm për ne.
Më vonë, nga raportet e veçanta duhet të ndërtojmë një planifikim. Siç dihet, kjo është një detyrë NP-e komplikuar, por ne e zgjidhim në një farë mënyre. Për këtë, aktivizojmë një komponent tjetër që formon orarin dhe e dërgon atë në shërbimin e jashtëm të Cloud-it, Contentful. Atje, gjithçka duket si një tabelë, ku ka ditët e konferencës, në ditë - kohë të caktuara, dhe në të - prezantime, pushime ose aktivitete sponsoruese. Pra, përmbajtja që ne shohim ndodhet në një shërbim të jashtëm. Dhe qëllimi është të arrijmë tek faqja.
Duket se faqja është thjesht një faqe me një lojtar, dhe nuk ka asgjë të komplikuar këtu. Përveç faktit që nuk është kështu. Backend-i që qëndron pas kësaj faqeje shkon në Contentful, merr orarin nga aty, formon disa objekte dhe i dërgon në frontend. Me ndihmën e një lidhjeje të websockets, e cila bëhet nga çdo klient i platformës sonë, ne dërgojmë një përditësim të orarit nga backend në frontend.
Një rast real: një folës ndryshoi punë pikërisht gjatë konferencës. Duhet ta ndryshojmë pllakën e kompanisë që e punëson. Si ndodh kjo nga backend? Një azhurnim i dërgohet të gjithë klientëve përmes WebSocket-it, dhe më pas frontend-i e ribëhet vetë timeline-in. Të gjitha këto ndodhin në mënyrë të pandërprerë. Kombinimi i shërbimit në njohje dhe disa nga komponentët tanë na jep mundësinë të formojmë gjithë këtë përmbajtje dhe ta ofrojmë përpara.
Николай: Këtu është e rëndësishme të sqarojmë se faqja jonë nuk është një aplikacion klasik SPA. Kjo është si një faqe e ndërtuar, e renderuar, ashtu edhe një SPA. Në të vërtetë, Google e sheh këtë faqe si HTML të renderuar. Kjo është mirë për SEO dhe për shpërndarjen e përmbajtjes tek përdoruesi. Ai nuk pret ngarkimin e 1.5 megabajto JavaScript për të parë faqen, ai e sheh menjëherë faqen e renderuar, dhe ju e ndjeni këtë çdo herë kur kaloni tek një prezantim. Gjithçka ndodh për një gjysmë sekonde, pasi përmbajtja është tashmë gati dhe e vendosur në vendin e duhur.
— Le të përmblidhim gjithçka të thënë më parë, duke enumeruar teknologjitë. Të Ma ka treguar se kemi 5 Amazon-stream, aty dërgojmë video dhe tinguj. Atje kemi skript bash, me ndihmën e të cilëve e fillojmë, e konfigurojmë...
Artyom: Kjo ndodh përmes API AWS, ka shumë shërbime teknike të tjera përkrahëse. Ne e ndamë detyrat tona në mënyrë që unë të dërgoj në , ndërsa zhvilluesit e frontend-it dhe backend-it marrin prej aty. Ne kemi një numër të caktuar të mbështetjeve tona për të thjeshtuar publikimin e përmbajtjes, që më pas e bëjmë në 4K etj. Duke qenë se afatet ishin shumë të shkurtra, ne praktikisht e bëmë këtë të gjithë mbi bazën e AWS.
— Më pas gjithçka shkon në lojtar, duke përdorur backend-in e sistemit. Ne kemi në lojtar TypeScript, React, Next.JS. Dhe në backend kemi disa shërbime në C#, Java, Spring Boot dhe Node.js. Të gjitha këto zhvillohen me Kubernetes, duke përdorur infrastrukturën e Yandex.Cloud.
Gjithashtu dëshiroj të theksoj se kur më duhej të njihesha me platformën, nuk ishte e vështirë: të gjitha depozitë janë në GitLab, gjithçka është mirë e emëruar, janë shkruar teste, ka dokumentacion. Kështu që edhe në situata urgjente, u kujdesën për këto gjëra.
Kufizimet biznesore dhe analiza
— Ne kemi targetuar kërkesat e biznesit për 10,000 përdorues. Koha është për të folur për kufizimet e biznesit që kishim. Na duhej të siguroni një ngarkesë të lartë, të respektojmë ligjin për ruajtjen e të dhënave personale. Çfarë tjetër?
Николай: Fillimisht ne u orientuam nga kërkesat për videon. E rëndësishmja — ruajtja e shpërndarë e videove në të gjithë botën për një shpërndarje të shpejtë për klientët. Nga kërkesat e tjera — zgjidhja 1080p, si dhe mundësia për të rikthyer përpara, që shumë të tjerë nuk e realizojnë në kohë reale. Më vonë shtuam mundësinë për të aktivizuar shpejtësinë 2x, me të cilën mund të "kapësh" transmetimin dhe më pas të vazhdosh të shikosh konferencën në kohë reale. Gjithashtu, ndodhi që të zhvillohet funksionaliteti i shënjimit të timeline. Përveç kësaj, ne duhej të ishim të papenguar dhe të përballonim një ngarkesë prej 10,000 lidhjesh. Nga pikëpamja e backend-it, kjo do të thotë rreth 10,000 lidhje të shumëzuara me 8 kërkesa për çdo rifreskim të faqes. Dhe kjo është tashmë 80,000 RPS/s. Mjaft shumë.
— A kishin gjithashtu kërkesa për "ekspozitën virtuale" me stendet e partnerëve online?
Николай: Po, kjo duhej bërë mjaft shpejt dhe në mënyrë universale. Kishim deri në 10 kompani partnere për çdo konferencë, dhe të gjitha faqet e tyre duhej të ishin ndërtuar brenda një ose dy javësh. Për më tepër, përmbajtja e tyre ndryshonte pak në format. Megjithatë, u bë një caktues i caktuar që mbledh këto faqe në fluks, praktikisht pa pjesëmarrje të mëtejshme nga zhvillimi.
— Kishte gjithashtu kërkesa për analizën e shikimeve në kohë reale dhe statistikat. E di që ne përdorim për këtë Prometheus, por tregoni më shumë: çfarë kërkesash përmbushim për analizën, dhe si realizohet kjo?
Николай: Fillimisht kemi kërkesa marketingu për mbledhjen për A/B-testimin dhe për mbledhjen e informacionit për të kuptuar si t'i ofrojmë përmbajtjen më të mirë klientit në të ardhmen. Ka gjithashtu kërkesa për ndonjë analizë mbi aktivitetet partnere dhe analizën që ju shihni (numërimin e vizitave). Të gjitha informacionet mblidhen në kohë reale.
Ne mund të ofrojmë këtë informacion në një formë të agreguar edhe për folësit: sa njerëz të kanë parë në një moment të caktuar. Gjithashtu, në përputhje me ligjin 152 FZ, llogaria personale dhe të dhënat personale nuk gjurmohen në fare.
Platforma ka tashmë mjete marketingu dhe metrika tona për matjen e aktivizmit të përdoruesve pikërisht në kohë reale (kush ka parë çdo sekondë të prezantimit), për të ndërtuar grafikun e vizitave të prezantimeve. Në bazë të këtyre të dhënave kryhen hulumtime që do të lejojnë konferencat e ardhshme të jenë më të mira.
Fraudë
A kemi mekanizma anti-fraudë?
Николай: Për shkak të kufijve të rreptë temporal nga pikëpamja e biznesit, fillimisht nuk ishte përcaktuar qëllimi për të bllokuar menjëherë lidhjet e tepërta. Nëse dy përdorues hynin me të njëjtin llogari, ata mund të shihnin përmbajtjen. Por dimë se sa shikime të njëkohshme ka pasur nga një llogari. Dhe disa violatorë të veçantë kanë qenë të bllokuar.
Vladimir: Duhet t'i jepet merita, një nga përdoruesit e bllokuar e kuptoi pse ndodhi kjo. Erdhi, kërkoi falje dhe premtoi se do të blinte biletë.
— Për të gjitha këto të ndodhin, duhet të ndjekim të gjithë përdoruesit nga hyrja deri në dalje, gjithmonë duke ditur se çfarë po bëjnë. Si funksionon ky sistem?
Vladimir: Do doja të flisja për analitikën dhe statistikën, të cilat ne më pas i analizojmë për suksesin e ligjëratës ose mund t'i ofrojmë më vonë partnerëve. Të gjithë klientët janë të lidhur përmes një lidhjeje WebSocket me një grup të caktuar backend. Atje është . Secili klient në çdo periudhë kohe dërgon informacion për atë që bën dhe cilin track po e shikon. Më pas, kjo informatë përpunohet shpejt nga jobs të Hazelcast-it dhe kthehet te të gjithë ata që po shikojnë këto tracks. Ne shohim në kënd, sa njerëz janë tani me ne.
Kjo e njëjta informatë ruhet në dhe dërgohet në liqenin tonë të të dhënave, nëpërmjet të cilit kemi mundësinë të ndërtojmë një grafik më interesant. Vjen pyetja: sa përdorues unikë kanë parë këtë ligjëratë? Ne shkojmë në , atje janë ping-et e gjithë njerëzve që erdhën përmes id të kësaj ligjërate. I mblodhëm, i agreguam unikët, dhe tani mund ta kuptojmë.
Николай: Por këtë arsye, ne marrim gjithashtu të dhëna në kohë reale nga Prometheus. Ai është i orientuar ndaj të gjitha shërbimeve Kubernetes, ndaj Kubernetes vetë. Grumbullon gjithçka, dhe me Grafana mund të ndërtojmë çdo grafik në kohë reale.
Vladimir: Nga njëra anë, ne e nxjerrim këtë për përpunim të mëtejshëm të tipit OLAP. Ndërsa për aplikacionin OLTP, të gjitha këto dërgohen në Prometheus, Grafana dhe grafiket madje përputhen!
— Ky është rasti kur grafiket përputhen.
Ndryshimet dinamike
— Na thoni, si realizohen ndryshimet dinamike: nëse raporti anulohet 6 minuta para fillimit, cila është zinxhirin e veprimit? Cili është pipeline që aktivizohet?
Vladimir: Pipeline është shumë kushtor. Ka disa mundësi. E para — programi që krijon orarin ka funksionuar dhe e ka ndryshuar këtë orar. Orari i ndryshuar shpërndahet në Contentful. Pas kësaj, backend-i kupton se ka ndryshime për këtë konferencë në Contentful, merr dhe ri-ndërton. Gjithçka grumbullohet dhe dërgohet përmes websocket.
Mundësia e dytë, kur gjithçka ndodh me një ritëm të çmendur: redaktori ndryshon informacionin në Contentful me duar (linkun në Telegram, prezantimin e referuesit, etj.) dhe aktivizohet e njëjta logjikë si herën e parë.
Николай: Все происходит без рефреша страницы. Все изменения происходят абсолютно бесшовно для клиента. Также и с переключением докладов. Когда подходит время, меняется доклад и интерфейс.
Vladimir: Также и временные отсечки начала докладов в таймлайне. В самом начале ничего нет. А если навести мышку на красную полоску, то в какой-то момент, благодаря режиссеру трансляции, появятся отсечки. Режиссер ставит правильное начало трансляции, бэкенд это изменение схватывает, рассчитывает соответственно расписанию конференции время начала и окончания докладов всего трека, отправляет нашим клиентам, плеер рисует отсечки. Теперь пользователь может спокойно навигироваться в начало и конец доклада. Это было жесткое бизнес-требование, очень удобное и полезное. Ты не тратишь время, чтобы найти настоящее время начала доклада. А когда мы сделаем превью, будет вообще замечательно.
Деплоймент
— Я бы хотел спросить про деплоймент. Коля и команда в начале убили много времени, чтобы настроить всю инфраструктуру, в которой у нас всё разворачивается. Расскажи, из чего это всё?
Николай: Në fillim patëm një kërkesë nga ana teknike për produktin që të ishte sa më shumë i abstrahuar nga ndonjë ofrues. Të shkonim në AWS për të bërë skriptet Terraform specifike për AWS, ose specifike për Yandex, ose për Azure etj., nuk ishte shumë e përshtatshme. Kemi pasur nevojë të zhvendosemi diku.
Të parat tri javët vazhdimisht po kërkonim mënyrën se si ta bëjmë këtë më mirë. Në fund arritëm në përfundimin se Kubernetes në këtë rast është gjithçka për ne, sepse lejon krijimin e shërbimeve automatikisht të shkallëzueshme, ndërrimin automatik dhe merrni nga kutia pothuajse të gjitha shërbimet. Sigurisht, duhej të trajnonim të gjithë shërbimet për të punuar me Kubernetes, Docker, dhe ekipi gjithashtu duhej të mësonte.
Kemi dy klastera. Një testues dhe një prodhues. Ata janë absolutisht identikë nga pikëpamja e harduerit dhe konfiguriacioneve. Po implementojmë infrastrukturën si kod. Të gjitha shërbimet shpërndahen me pipeline automatik në tre ambiente nga degët e tipareve, nga degët kryesore, nga ato testuese, nga GitLab. Kjo është maksimalisht e integruar në GitLab, maksimalisht e integruar me Elastic, Prometheus.
Ne jemi në gjendje të lançojmë shpejt (për backend gjatë 10 minutave, për frontend gjatë 5 minutave) ndryshime në çdo ambient me të gjitha testet, integrimet, ekzekutimin e testeve funksionale, testeve integruese në ambient, dhe gjithashtu të testojmë me teste ngarkese në ambientin testues për të marrë rreth të njëjtës gjë që duam të arrijmë në prodhim.
Për testet
— G hampir cdo gjë e testoni, është e vështirë të besosh se si e keni shkruar. Mund të flasësh për testet e backend-it: sa është i mbuluar gjithçka, cilat teste?
Vladimir: Janë shkruar dy lloje testesh. Të parat janë testet komponentale. Testet e nivelit të ngjitjes së gjithë aplikacionit spring dhe bazës në . Kjo është një kontroll i skenarëve të biznesit më të lartë. Nuk po testoj funksionet. Ne testojmë vetëm disa gjëra të mëdha. Për shembull, direkt në test simulon procesin e kyçjes së përdoruesit, kërkesën nga ky përdorues për biletat, ose aksesin për të parë një stream. Scenarët e përdoruesit janë shumë të qartë.
Përgjithësisht e njëjta gjë është realizuar në atë që quhet teste integruese, të cilat realisht funksionojnë në mjedis. Në fakt, kur një tjetër shpërndarje në prodhim bëhet, skenarët bazë të vërtetë gjithashtu funksionojnë në prodhim. E njëjta lidhje, kërkesa për bileta, kërkesa për akses në CloudFront, kontrolli për të siguruar që stream-i zgjidhet me lejet e mia, kontrolli i ndërfaqes së regjisorëve.
Aktualisht kam rreth 70 teste komponenti dhe rreth 40 teste integruese. Pokrimi është shumë afër 95%. Kjo për testet komponenti, për ato integruese janë pak më pak, sepse nuk ka nevojë për aq shumë. Duke marrë parasysh që projekti ka gjithëfarë gjenerimeve të kodit, ky është një tregues shumë i mirë. Nuk kishte asnjë mënyrë tjetër për të bërë atë që kemi bërë për tre muaj. Sepse nëse do të testonim në mënyrë manuale, duke i dhënë funksionalitetet testuesit tonë, dhe ajo do të gjejë gabime dhe do t'i kthejë për rregullim, atëherë ky proces i ndihmës së kodit do të ishte shumë i gjatë, dhe ne nuk do të arrinim në asnjë afat.
Николай: Kushtimisht, për të kryer një rregresion në të gjithë platformën kur ndonjë funksion ndryshohet, duhen dy ditë duke punuar dhe klikuar kudo.
Vladimir: Prandaj, është një sukses i madh që, kur unë estimoj një veçori, them se më nevojiten 4 ditë për dy thjeshtësi dhe 1 websocket, Kolya lejon. Ai tashmë është mësuar që në këto 4 ditë janë të përfshira 2 lloje testesh, dhe më pas, ka të ngjarë që gjithçka do të funksionojë.
Николай: Edhe unë kam shkruar 140 teste: komponente + funksionale, të cilat bëjnë të njëjtën gjë. Të njëjtat skenarë testohen dhe në prodhim, në test dhe në zhvillim. Gjithashtu, kohët e fundit kemi filluar të kemi teste funksionale bazike UI. Kështu ne mbulojmë funksionalitetet më të bazuara që mund të dështojnë.
Vladimir: Sigurisht, është e nevojshme të flasim për testet e ngarkesës. Duhej të kontrollonim platformën nën një ngarkesë që i afrohej realitetit, për të kuptuar se çfarë ndodh me Rabbit, çfarë ndodh me JVM-të, sa realisht nevojitet memorie.
— Nuk e di saktësisht nëse po testojmë ndonjë gjë në anën e transmetimeve, por e mbaj mend se kishte probleme me transkoderët kur bëmë mitapet. A kemi testuar transmetimet?
Artyom: I kemi testuar iterativ. Po organizonim takime. Në procesin e organizimit të takimeve kishim rreth 2300 tiketa JIRA. Këto ishin thjesht gjëra standarde që njerëzit bënin për të organizuar takimet. Merrnim pjesë të platformës në një faqe të veçantë për takimet, të cilën e menaxhonte Kirill Tolkachev ().
Sinqerisht, nuk kishte probleme të mëdha. Vetëm disa herë hasëm defekte për shkak të caches në CloudFront, i zgjidhëm mjaft shpejt — thjesht rikonfiguruam politikat. Kishte shumë më tepër defekte te njerëzit, në sistemet e transmetimit në vend.
Gjatë konferencave na duhej të shkruanim disa eksportues të tjerë për të mbuluar më shumë pajisje dhe shërbime. Në disa raste, na duhej të krijonim bicicleta të veta vetëm për metrika. Bota e AV (audio-video) nuk është shumë e ndritshme - ke një "API" pajisjeje, mbi të cilin thjesht nuk ke ndikim. Dhe nuk është aspak e garantuar që mund të marrësh informacionin që të nevojitet. Furnizuesit e pajisjeve janë me të vërtetë të ngadalshëm dhe është pothuajse e pamundur të arrish atë që dëshiron. Në total, më shumë se 100 pajisje, ato japin gjënë që nuk ka nevojë, dhe ti shkruan eksportues të çuditshëm dhe të tepërt, përmes të cilëve mund të debagohet sistemi në njëfarë mënyre.
Pajisjet
— E mbaj mend si, para fillimit të konferencave, ne pjesërisht blenim pajisje.
Artyom: Blemë kompjuterë, laptopë, bllok baterish. Në këtë moment, mund të jetojmë pa energji elektrike për 40 minuta. Në qershor, në Shën Petersburg pati stuhi të forta — kështu që kemi përjetuar një ndërprerje të tillë. Megjithatë, disa ofrues vijnë me fibra optike nga pika të ndryshme. Kjo në të vërtetë është 40 minuta ndërprerjeje për ndërtesën, gjatë të cilave do të kemi dritë, funksionimin e zërit, kamerat etj.
— Me historia është e ngjashme me internetin. Në zyrën ku ndodhen studiot tona, ne kaluam një rrjet të shkëlqyer mes katërra.
Artyom: Kemi 20 GBit fiber optik mes katërra. Më tej në katëra ndodhet fibra, ndonjëherë jo, por gjithsesi ka më pak se kanale gigabit — ne i nxjerrim mes videove të konferencave. Në fakt, është shumë e lehtë të punosh me infrastrukturën tonë, pasi në konferencat offline rrallë gjejmë mundësi të bëjmë këtë.
— Edhe para se të punoja në JUG Ru Group, kisha parë si vendosen pajisjet për një natë në konferencat offline, ku ndodhet një monitor i madh me të gjitha metrikat që ndërtoni në Grafana. Tani gjithashtu ekziston një sallë-shtab, ku qëndron ekipi i zhvillimit, i cili gjatë konferencës rregullon ndonjë defekt dhe zhvillon karakteristika. Gjithashtu ka një sistem monitorimi që shfaqet në një ekran të madh. Artyom, Kolya dhe djemtë e tjerë qëndrojnë dhe shikojnë që gjithçka të mos bjerë dhe të punojë bukur.
Kuriozitete dhe probleme
— Flisni për shkurt mbi atë që ofrojmë, siç janë transmetimet me Amazon, një player me web, të gjitha janë shkruar në gjuhë të ndryshme programimi, ofrohet qëndrueshmëri dhe kërkesa të tjera biznesi, përfshirë një llogari të personalizuar e cila mbështetet për persona juridikë dhe fizikë, dhe ne mund të integrohemi me dikë përmes OAuth 2.0, ka mbrojtje ndaj mashtrimit, bllokim përdoruesi. Ne mund të zbatojmë ndryshime dinamikisht, sepse e kemi bërë mirë këtë, dhe gjithashtu, gjithçka testohet.
Më intereson të di në lidhje me ndodhitë qesharake që ndodhën gjatë lansimit të diçkaje. A kishte situata të çuditshme gjatë zhvillimit të backend-it dhe frontend-it, ku ndodhte diçka e pazakontë dhe nuk e dinit se si të vepronit?
Vladimir: Më duket se kjo ka ndodhur vetëm tre muajt e fundit. Çdo ditë. Siç mund ta shihni, të gjithë flokët e mi janë të shqyer.
Vladimir Krasilshchik pas 3 muajsh, kur ndodhte diçka e pazakontë dhe askush nuk e dinte se çfarë të bënte me këtë.
Çdo ditë kishte diçka të tillë, kur ndodhte një moment, kur merr dhe tërheq flokët, ose kupton që nuk ka askënd tjetër, dhe vetëm ti mund ta bësh këtë. Ngjarja e parë e madhe për ne ishte TechTrain. Më 6 qershor në orën 2 të mëngjesit akoma nuk kishim zbatuar mjedisin e prodhimit, që e zbatoi Kola. Dhe dhoma personale nuk funksiononte, as si server autorizimi me OAuth2.0. Ne e shndërruam në një ofrues OAuth2.0 për ta lidhur me platformën. Kam punuar ndoshta tashmë 18 orë rresht, shikoja në kompjuter dhe nuk shikoja asgjë, nuk kuptoja pse nuk punonte, dhe Kola shikonte kodin tim nga larg, kërkonte një bug në konfigurimin e Spring, e gjeti, dhe dhoma personale filloi të punonte, edhe në prodhim.
Николай: Dhe një orë para TechTrain u bë publikimi.
Këtu u krijuan shumë yje. Na ka pasur fat i madh, sepse kemi krijuar një super ekip, dhe të gjithë u frymëzuam nga ideja për ta bërë online. Të gjitha këto tri muaj na frymëzoi fakti që ne ishim "duke bërë YouTube". Nuk e lejoja veten të tërhiqja flokët, por u thashë të gjithëve se do të dalë, sepse në të vërtetë gjithçka ishte llogaritur prej kohësh.
Për performancën
— A mund të tregoni se sa njerëz maksimalisht ishin në një pasqyrë? A pati probleme me performancën?
Николай: Nuk kishte probleme me performancën, siç e thamë më parë. Numri maksimal i njerëzve që ishin në një raport ishte 1300, kjo ndodhi në Heisenbug.
— A pati probleme me shikimin lokal? Dhe është e mundur një përshkrim teknik me skema se si funksionon gjithçka?
Николай: Do ta bëjmë një artikull për këtë më vonë.
Lokalisht mund të debbugohet edhe strimi. Pasi filluan konferencat, kjo u bë edhe më e lehtë, sepse u shfaqën strimet prodhuese që mund t'i shohim vazhdimisht.
Vladimir: Sa e kuptoj, zhvilluesit frontend lokal punonin me mocke, dhe më pas, pasi koha e lëshimit në dev për frontend është gjithashtu e vogël (5 minuta), duket se nuk ka probleme me certifikatat.
— Çdo gjë testihet, debbugohet, madje edhe lokal. Pra, do të shkruajmë një artikull me të gjitha veçoritë teknike, do të tregojmë gjithçka me skemat, siç u bë.
Vladimir: Mund ta merrni dhe ta përsërisni.
— Për 3 muaj.
Përfundimi
— Të gjitha ato që janë përshkruar së bashku duken të mrekullueshme duke marrë parasysh se është bërë nga një ekip i vogël brenda tre muajve.
Николай: Një ekip i madh nuk do ta bënte këtë. Por një grup i vogël njerëzish, të cilët komunikojnë ngusht dhe mirë me njëri-tjetrin dhe mund të bien dakord, do ta bënte. Ata nuk kanë ndonjë kundërshtim, arkitektura u ideua brenda dy ditëve, u finalizua dhe faktikisht nuk ndryshoi. Ka një fasilitim shumë të fortë të kërkesave biznesore që hyjnë në lidhje me mbingarkesën e kërkesave për veçori dhe ndryshime.
— Çfarë doli në listën tuaj të detyrave të ardhshme, kur konferencat verore tashmë u mbajtën?
Николай: Për shembull, tituj. Dritare që lëvizin në video, skenat që shfaqen në disa vende të videos në varësi të shfaqjes së përmbajtjes. Për shembull, folësi dëshiron të bëjë një pyetje në audiencë, dhe në ekran shfaqet një ankëtim që rikthehet në sistem pas rezultateve të votimit te folësi vetë. Një aktivitet social në formën e pëlqimeve, zemrave, vlerësimeve të prezantimit gjatë prezantimit, në mënyrë që të mund të plotësohet feedback-u në momentin e duhur, pa u shpërqendruar më vonë në formularët e feedback-ut. Kështu fillimisht.
Dhe gjithashtu shtimi i gjithë platformës, përveç transmetimeve dhe konferencave, gjithashtu gjendja paskonferencale. Këto janë playliste (përfshirë ato të krijuara nga përdoruesit), mundësisht përmbajtje nga konferenca të kaluara, të integruara, të markuara, të disponueshme për përdoruesin, dhe gjithashtu të aksesueshme për shikim në faqen tonë ().
— Djem, faleminderit shumë për përgjigjet!
Nëse mes lexuesve ka ata që ishin në konferencat tona verore — ndahuni me mendimet tuaja për playerin dhe transmetimin. Çfarë ishte e përshtatshme, çfarë ishte irrituese, çfarë dëshiron të shohësh në të ardhmen?
Nëse platforma ju ka interesuar dhe dëshironi ta shihni atë "në luftë" — ne do ta përdorim përsëri në konferencat tona . Ka një sërë të tërë, kështu që pothuajse me siguri ka një të përshtatshme për ju.
Burimi: habr.com
