Sel kevadel olime väga lõbusates tingimustes. Pandeemia tõttu sai selgeks, et meie suvised konverentsid tuleb üle viia veebiversiooni. Ja et neid veebis kvaliteetselt läbi viia, ei sobinud meile valmis tarkvaralahendused, pidime kirjutama oma. Selleks oli meil aega kolm kuud.

On selge, et need olid põnevad kolm kuud. Kuid kõrvalvaatajale ei ole sugugi ilmselge, mis täpselt on veebikonverentside platvorm? Millest see koosneb? Seetõttu küsisin viimase suvise DevOops konverentsi käigus nendelt, kes vastutasid selle ülesande eest:

• Nikolai Moltšanov — JUG Ru Grupi tehniline direktor;
• Vladimir Krasilshchik — pragmaatiline Java programmeerija, kes tegeleb tagaplaaniga (te olete võinud näha tema ettekandeid meie Java konverentsidel);
• Artyom Nikонов — vastutab kogu meie videostreamingu eest.

Muide, sügis-talviste konverentside käigus kasutame parandatud versiooni samast platvormist — nii et paljud Habr kasutajad saavad samuti selle kasutajateks.

Üldine pilt

— Milline oli meeskonna koosseis?

Nikolai Moltšanov: Meil on analüütik, disainer, testija, kolm frontend arendajat ja backend arendaja. Ja muidugi, T-kujuline spetsialist!

— Kuidas nägi protsess üldiselt välja?

Nikolai: Kuni märtsi keskpaigani ei olnud meil veebiversiooni jaoks mitte midagi valmis. Aga 15. märtsil algas kogu tegevus veebis. Meil oli mitu hoidlat, planeerisime, arutasime põhistruktuuri ja tegime kõik kuu ajaga.

See läbis muidugi klassikalised etapid: planeerimine, arhitektuur, omaduste valimine, nende omaduste hääletamine, poliitikate määramine, disain, arendus ja testimine. Lõpuks 6. juunil käivitasime kõik tootesse. TechTrain. Kogu sellele protsessile kulus 90 päeva.

— Kas me saime tehtud selle, millele me end lubasime?

Nikolai: Kuna me osaleme nüüd DevOops konverentsil veebis — siis on see oluline. Ma ise lubasin tuua tellijatele tööriista, millega on võimalik konverentsi veebis korraldada.

Ülesanne oli selline: andke meile tööriist, millega saame oma konverentse piletiholderitele edastada.

Kogu planeerimine jagunes mitmeks etapiks ja kõik omadused (umbes 30 põhijoon) jaotati nelja kategooriasse:

• mida me kindlasti teeme (ilma nendeta ei saa me elada),
• mida me teeme teises järjekorras,
• mida me kunagi ei tee,
• ja mida me kunagi-kunagi ei tee.

Kõik esimese kahe kategooria funktsioonid on meil tehtud.

— Ma tean, et kokku on loodud 600 JIRA-ülesannet. Kolme kuuga olete teinud 13 mikroteenust ja kahtlustan, et need ei ole kirjutatud ainult Java-s. Te kasutasite erinevaid tehnoloogiaid, teil on üles seatud kaks Kubernetes'i klastrit kolmes kättesaadavuse tsoonis ja 5 RTMP-voogu Amazonis.

Vaatame nüüd süsteemi iga komponente eraldi.

Voogedastus

— Alustame sellest, kui meil on juba video pilt ja see edastatakse mingitesse teenustesse. Artyom, räägi, kuidas see voogedastus toimub?

Artyom Nikonov: Meie üldine skeem on järgmine: kaamera pilt -> meie pult -> kohalik RTMP-server -> Amazon -> videopleierer. Täiendavad üksikasjad selle kohta kirjutanud Habr'i juulis.

Üldiselt on kaks peamist teed, kuidas seda teha: kas riistvara või tarkvara lahenduste põhjal. Me valisime tarkvaratee, kuna see on kauguses esinevate esinejate puhul lihtsam. Ei ole alati võimalik tuua esinejale teises riigis riistvara, kuid tarkvara paigaldamine tundub lihtsam ja usaldusväärsem.

Riistvara osas on meil mõned kaamerad (meie stuudiotes ja kauguses esinejate juures) ning ka mõned pultide arvud stuudios, mida tuleb vahel otse eetris laua all parandada.

Nende seadmete signaalid jõuavad arvutitesse, kus on salvestus-, sisendi/väljundi ja helikaardid. Seal signaalid segatakse ja kogutakse ülesseadistusteks:

Näide nelja esinejaga ülesseadmest

Näide nelja esinejaga ülesseadmest

Edasi tagatakse katkematu eetriga kolm arvutit: on üks peamine masin ja paar, mis töötavad vaheldumisi. Esimene arvuti kogub esimese ettekande, teine — pausi, esimene — järgmise ettekande, teine — järgmise pausi ja nii edasi. Peamine masin segab esimest teisega.

Sel viibib mingisugune kolmnurk, ja juhul, kui mõni neist sõlmedest ebaõnnestub, saame kiiresti ja kvaliteeti kaotamata jätkata sisu tarnimist klientidele. Selline olukord juhtus meil. Konverentside esimesel nädalal parandasime ühte masinat, lülitades seda sisse ja välja. Tundub, et inimesed on meie tõrketaluvuse üle rahul.

Seejärel jõuavad voogedastused arvutitest kohalikele serveritele, millel on kaks ülesannet: RTMP-voogude suunamine ja varukoopiate salvestamine. Nii et meil on mitu salvestuspunkti. Seejärel saadetakse videovood osa meie süsteemist, mis on loodud Amazoni SaaS-teenuste peale. Kasutame MediaLive, S3, CloudFront.

Nikolai: Aga mis juhtub enne, kui video jõuab vaatajateni? Kas te ei pea seda lõikama kuidagi?

Artem: Kompresseerime video oma poolt ja saadame selle MediaLive'i. Seal käivitame transkodeerijad. Need kodeerivad video reaalajas mitmesse kvaliteeti, et inimesed saaksid neid vaadata telefonides, halvema internetiühenduse korral suvilas ja nii edasi. Siis jagame need vood chunk'e, nii töötab protokoll HLS. Edastame frontendis esitusloendi, kus on viidatud nendele osadele.

— Kasutame 1080p resolutsiooni?

Artem: Laiuses on meil 1080p video — 1920 pikslit, kõrguses veidi vähem, pilt on piklikum — sellel on omad põhjused.

Mängija

— Artjom kirjeldas, kuidas video jõuab striimidesse, kuidas see jaotatakse erinevatesse mänguvariantidesse erinevate ekraanide resolutsioonide jaoks, lõigatakse juppideks ja jõuab mängijasse. Kolja, räägi nüüd, mis see mängija on, kuidas see striimi tarbib, miks HLS?

Nikolai: Meil on mängija, mida jälgivad kõik konverentsi külastajad.

Sisuliselt on see raamistiku peal, hls.js, mille peal on kirjutatud palju teisi mängijaid. Kuid me vajasime väga spetsiifilist funktsionaalsust: tagasi kerimist ja koha märkimist, kus inimene asub, millist ettekannet ta hetkel vaatab. Samuti olid vajalikud oma layout'id, erinevad logod ja kõik muu, mis meile sobis. Seetõttu otsustasime kirjutada oma raamistiku (HLS'i peal) ja integreerida selle veebisaidile.

See on põhifunktsionaalsus, seega teostati see peaaegu esimesena. Ja selle ümber hakkas kõik muu juba arenema.

Tegemist on sellega, et mängija saavad autentimise kaudu tagasisideplatvormilt mängunimekirja koos linkidega juppidele, mis on seotud aja ja kvaliteediga, laadib vajalikke ja näitab kasutajale, tehes selle käigus teatud 'maagiat'.

Ajajoone näide

— Otseselt mängijasse on sisse ehitatud nupp, mis kuvab kõigi ettekannete ajajoone...

Nikolai: Jah, me lahendasime kasutaja navigeerimise probleemi kohe. Aprilli keskpaiku otsustasime, et ei hakka edastama igat meie konverentsi eraldi saidil, vaid koondame kõik ühte. Nii saavad Full Passi piletite omanikud vabalt vahetada erinevate konverentside vahel: nii otse-eetris kui ka möödunud ettekannete salvestuste vahel.

Ja et kasutajatele oleks lihtsam navigeerida praeguses otseülekandes ja vahetada teede vahel, otsustasime lisada nupu 'Kogu otseülekanne' ja horisontaalsed ettekannete kaardid vahetamiseks teemade ja ettekannete vahel. Seal on klaviatuuriga juhtimine.

— Kas sellel oli mingeid tehnilisi raskusi?

Nikolai: Raskusi oli kerimisribaga, kus on tähistatud erinevate ettekannete alguspunkte.

— Lõpuks реализовали ви отметки на полосе прокрутки раньше, чем YouTube?

Artem: Neil oli see siis beetaversioonis. Tundub, et see on üsna keeruline funktsioon, kuna nad on seda osaliselt testinud kasutajate peal viimase aasta jooksul. Ja nüüd on see lõpuks müügis.

Nikolai: Kuid me saime sellest kiiremini müügiversiooni. Ausalt öeldes, selle lihtsa funktsiooni taga on tohutult palju tagaplaani, esiplaani ja arvutusi ning matemaatikat mängijas.

Frontend

— Uurime, kuidas see sisu, mida me näitame (ettekande kaart, esinejad, veebisait, ajakava), jõuab esiplaani?

Vladimir Krasilshchik: Meil on mitu sisemist IT-süsteemi. On süsteem, kuhu on registreeritud kõik ettekanded ja kõik esinejad. On protsess, kuidas ettekandja konverentsil osaleb. Esineja esitab taotluse, süsteem salvestab selle, ja siis on mingi voosüsteem, mille kaudu ettekande loomine toimub.

Nii näeb esineja voosüsteemi.

See süsteem on meie sisearendus.

Edasi tuleb eraldi ettekannete põhjal koostada ajakava. Nagu teada, on see NP-raskusi tekitav ülesanne, kuid me saame selle kuidagi lahendatud. Selleks käivitame teise komponendi, mis koostab ajakava ja saadab selle kolmandasse osalisse pilveteenusesse Contentful. Seal näeb kõik välja nagu tabel, kus on konverentsi päevad, päevade jooksul ajavahemikud ning ajavahemike sees etteasted, pausid või sponsorite tegevused. Seega sisu, mida me näeme, asub kolmandas osapis. Ja ülesanne on see tuua kodulehele.

Tundub, et veebileht on lihtsalt leht mängijaga, ega midagi keerulist ei ole. Välja arvatud see, et see pole nii. Selle lehe taga olev taustasüsteem läheb Contentful'i, toob sealt välja ajakava, loob mõned objektid ja saadab need esiküljele. Iga meie platvormi klient kasutab veebipõhist soketiühendust, millega me saadame taustast esiküljele ajakava uuenduse.

Tõeline juhtum: esineja vahetas konverentsi ajal töökohta. Peame vahetama tema ettevõtteplaadi. Kuidas see tagaplaanilt toimub? Kõigile klientidele saadetakse uuendus veebipusleti kaudu ja edasi joonistab front-end ajaskaala ise. Kõik see toimub sujuvalt. Pilveteenuse ja meie mitmete komponentide kogum annab meile võimaluse kogu seda sisu luua ja edastada otsefrontile.

Nikolai: Siin on oluline täpsustada, et meie veebisait ei ole klassikaline SPA-rakendus. See on nii vormindatud, renderdatud veebisait kui ka SPA. Tegelikult näeb Google seda saiti kui renderdatud HTML-i. See on hea SEO ja sisu tarnimise jaoks kasutajale. Ta ei pea ootama 1,5 megabaiti JavaScripti laadimist, et seejärel lehte näha; ta näeb kohe juba renderdatud lehte ning te tunnetate seda iga kord, kui konverentsi ettekandeid vahetate. Kõik toimub poole sekundi jooksul, kuna sisu on juba valmis ja paigutatud õigesse kohta.

— Kokkuvõtteks, loetleme tehnoloogiad. Tõema rääkis, et meil on 5 Amazon'i voogu, kuhu edastame video ja heli. Seal on meil bash-skriptid, nende abil käivitame, konfigureerime...

Artem: See toimub AWS API kaudu, seal on veel palju kõrvalt tehnilisi teenuseid. Me jagasime oma ülesandeid nii, et mina edastan {domain} ja es frontend- ja backend-arendajad võtavad sealt. Meil on mõned oma raamistud, et lihtsustada sisu avaldamist, mida me hiljem teeme 4K jne. Kuna tähtaegadega oli väga kitsas, tegime seda peaaegu täielikult AWS-i põhjal. CloudFront, ja sealt saavad frontend- ja backend-arendajad sisu kätte. Meie mängijas on TypeScript, React, Next.JS. Ja meie backendis on mitu teenust C#, Java, Spring Boot ja Node.js. Kõik see on juurutatud Kubernetesega, kasutades Yandex Cloudi infrastruktuuri.

Soovin veel märkida, et kui mul oli vaja platvormiga tutvuda, ei osutunud see keeruliseks: kõik väljaanded on GitLabis, kõik on hästi nimetatud, on kirjutatud testid ja olemas on dokumentatsioon. See tähendab, et isegi kriisiolukordades hooliti sellistest asjadest.

Äri- ja analüüsi piirangud

Ärireeglid ja analüüs

— Meie sihiks oli äritegevuse nõuetele vastamine 10 000 kasutajale. On aeg rääkida äri piirangutest, millega silmitsi seisisime. Me pidime tagama kõrge koormuse ja järgima isikuandmete kaitse seadust. Mis veel?

Nikolai: Esialgu läksime välja videot nõudmistest. Kõige olulisem on jaotatud videote salvestamine üle maailma, et tagada kiire kohaletoimetamine kliendile. Teised nõuded hõlmasid 1080p resolutsiooni ning tagasi kerimise võimalust, mida paljud teised ei ole reaalajas rakendanud. Hiljem lisasime võimaluse aktiveerida 2x kiirus, mis võimaldas "jõuda" otseülekandele ning jätkata konverentsi reaalajas vaatamist. Lisaks tuli kasuks ajajoone märgistamise funktsionaalsus. Samuti pidime olema talitluskindlad ja vastu pidama 10 000 ühenduse koormusele. Tagaplaanil tähendab see umbes 10 000 ühendust, korrutatuna 8 päringuga iga lehe värskenduse kohta. See teeb kokku 80 000 RPS/sekundis. Suhteliselt palju.

— Kas nõudmised "virtuaalse näituse" osas, sealhulgas partnerite veebistendid, olid samuti olemas?

Nikolai: Jah, seda tuli teha üsna kiiresti ja universaalselt. Iga konverentsi jaoks oli meil kuni 10 partnerfirmat, kelle lehti tuli nädala või kahe jooksul vormindada. Samas erineb nende sisu formaadilt veidi. Kuid välja töötati teatud templite genereerija, mis kogus neid lehti reaalajas, praktiliselt arendustegevuses edasise osaluseta.

— Oli ka nõuded reaalajas vaateanalüütikale ja statistikale. Tean, et me kasutame selleks Prometheust, aga räägi lähemalt: milliseid nõudeid me täidame analüütika osas ja kuidas see on ellu viidud?

Nikolai: Alguses on meil turunduslikud nõuded A/B testimise jaoks ja teabe kogumise kohta, et aru saada, kuidas edaspidi klientidele parimat sisu edastada. Samuti on nõuded teatud analüütika kohta partnerite tegevuse ja analüüsi osas, mida te näete (külastuste loendur). Kõik teave kogutakse reaalajas.

Seda teavet saame esitada ka aggregeeritud kujul, isegi esinejatele: kui palju inimesi sind mingil hetkel vaatas. Ühtlasi ei jälgita isiklikku kontot ja isikuandmeid vastavalt 152. seadusele.

Platvormil on juba turunduslikud tööriistad ja meie mõõdikud kasutajate aktiivsuse mõõtmiseks reaalajas (kes vaatas millise sekundi ettekandest), et koostada ettekannete külastamise graafikuid. Nendel andmetel põhinevad uuringud, mis aitavad järgmisi konverentse paremaks muuta.

Pettus

— Kas meil on pettusevastaseid mehhanisme?

Nikolai: Ärivaldkonna range ajaraami tõttu ei olnud algselt eesmärk kohe blokeerida liigseid ühendusi. Kui kaks kasutajat sisenesid sama konto alt, said nad sisu vaadata. Kuid me teame, kui palju sama konto kaudu samal ajal vaatamisi oli. Ja mitmed eriliselt vägivaldsed rikkumised oleme blokeerinud.

Vladimir: Tuleb tõdeda, et üks blokeeritud kasutajatest mõistis, miks see juhtus. Ta tuli, vabandas ja lubas pileti osta.

— Selleks, et kõik see toimuks, peate täielikult jälgima kõiki kasutajaid sisse- ja väljaminekul, alati teadma, mida nad teevad. Kuidas see süsteem töötab?

Vladimir: Soovin rääkida analüütikast ja statistikatest, mida hiljem analüüsime ettekande edukuse hindamiseks või mille võime hiljem partneritele esitada. Kõik kliendid on veebipõhise socket-ühenduse kaudu ühendatud teatud tagaplaani klastriga. Seal on Hazelcast. Iga klient saadab igas ajavahemikus andmeid selle kohta, mida ta teeb ja millist lugu ta vaatab. Edasi kogutakse see teave kiiresti Hazelcast’i töödega ja saadetakse tagasi kõigile, kes neid lugusid vaatavad. Näeme nurgas, kui palju inimesi on praegu koos meiega.

Sama teave koguneb Mongo ja liigub meie andmejärve, mille põhjal saame luua huvitavamaid graafikuid. Küsitakse: kui palju unikaalseid kasutajaid on seda ettekannet vaadanud? Lähme Postgres, seal on kõik inimeste pingid, kes said selle ettekande id kaudu. Oleme kogunud unikaalsed ja nüüd saame aru.

Nikolai: Aga samas saame reaalajas andmeid Prometheuse kaudu. See on suunatud kõigile Kubernetes teenustele ning ka Kubernetesile endale. See kogub absoluutselt kõike, ja Grafana abil saame koostada igasuguseid graafikuid reaalajas.

Vladimir: Ühest küljest laadime selle edasi edasiseks töötlemiseks, näiteks OLAP-i jaoks. OLTP rakendus laadib selle Prometheusse, Grafanasse ning graafikud isegi kattuvad!

— Just see eriline juhtum, kui graafikud kattuvad.

Dünaamilised muutused

— Rääkige, kuidas dünaamilised muutused toimuvad: kui ettekande tegemine tühistatakse 6 minutit enne algust, siis milline on toimingute järjestus? Milline pipeline käivitub?

Vladimir: Pipeline on väga tinglik. On mitu võimalust. Esimene — ajakava koostamise programm töötab ja muudab selle ajakava. Muudetud ajakava laaditakse Contentfuli. Pärast seda backend mõistab, et Contentfulis on selle konverentsi osas muudatused, võtab ja kogub uuesti kokku. Kõik kogutakse ja saadetakse websocketi kaudu.

Teine võimalus, kui kõik toimub meeletus tempos: toimetaja muudab käsitsi Contentfulis teavet (lingid Telegrami, ettekandjate esitused jne) ja käivitub sama loogika nagu esimesel korral.

Nikolai: Kõik toimub ilma lehe värskendamiseta. Kõik muudatused toimuvad kliendi jaoks täiesti sujuvalt. Sama kehtib ka ettekannete vahetamise kohta. Kui aeg peab kätte jõudma, muutub ettekande ja liidese sisu.

Vladimir: Samuti on ajapunktid ettekannete alguseks ajajoonel. Alguses ei ole midagi. Kui kursor punasele ribale viia, ilmuvad mõne hetke pärast tänu ülekanne režissöörile ajapunktid. Režissöör määrab õiged ülekande algused, backend fikseerib selle muudatuse, arvutab vastavalt konverentsi ajakavale ettekannete algus- ja lõpuaja kogu rajale ning saadab selle meie klientidele, mängija joonistab ajapunktid. Nüüd saab kasutaja rahulikult navigeerida ettekande alguse ja lõpu vahel. See oli range äri nõue, väga mugav ja kasulik. Sa ei raiska aega, et leida ettekande tegelikku algusaega. Ja kui me teeme eelvaate, on see üldse suurepärane.

Deployment

— Ma tahaksin küsida deployment'i kohta. Kolja ja meeskond veetsid alguses palju aega, et seadistada kogu infrastruktuur, milles meil kõik töö käib. Räägi, millest see kõik koosneb?

Nikolai: Meil oli algselt tehnilisest vaatenurgast nõue, et toode oleks maksimaalselt sõltumatu mistahes tarnijast. Ei sobinud enda viimine AWS-i ja AWS-i spetsiifiliste Terraform-skriptide, Yandexi või Azure'i kasutamine jne. Me pidime omal ajal kuskile kolima.

Esimese kolme nädala jooksul otsisime pidevalt, kuidas seda kõige paremini teha. Lõpuks jõudsime järeldusele, et Kubernetes on meie puhul ideaalne lahendus, kuna see võimaldab luua automaatselt skaleeritavaid teenuseid, automaatset väljalaskmist ning peaaegu kõiki teenuseid kohe kätte saada. Loomulikult tuli kõiki teenuseid õpetada Kubernetesega, Dockeriga töötama ja ka meeskond pidi selle omandama.

Meil on kaks klastrit: katsetamiseks ja tootmiseks. Need on riistvara ja seadistuste osas täpselt ühesugused. Me rakendame infrastruktuuri koodina. Kõik teenused rakendatakse automaatse pipeline'i kaudu kolmes keskkonnas feature-branch'idest, master-branch'idest ja testimistest GitLabist. See on maksimaalselt integreeritud GitLabi, Elasticu ja Prometheusega.

Saame kiiresti (tagaplaanil 10 minuti, esiplaanil 5 minuti jooksul) rakendusi igas keskkonnas, koos kõigi testide, integratsioonide, funktsionaalsete testide ja integratsioonitestide käivitamisega, ning testime ka koormustestidega testkeskkonnas enam-vähem sama, mida soovime tootmisümbruses saavutada.

Testide kohta

— Te testite peaaegu kõike, raske on uskuda, et olete kõik kirjutanud. Kas saaksite rääkida tagaplaani testide katmisest: kui palju on kaetud, milliseid teste on olemas?

Vladimir: Oleme kirjutanud kahte tüüpi teste. Esimesed on komponenditestid. Testid kõigi Spring-rakenduse ja andmebaasi tasemete kontrollimiseks Testcontainers. See kontrollib kõige kõrgemal tasemel äristsenaariume. Ma ei testita funktsioone. Testime ainult mõningaid suuremaid asju. Näiteks simuleeritakse testis otse kasutaja sisselogimise protsessi, sellele kasutajale piletite taotlemist, kuhu ta võib minna, ning juurdepääsu taotlemist voogu vaatamiseks. Väga arusaadavad kasutajascenaarid.

Umbes sama on rakendatud nn integratsioonitestides, mis tegelikult töötavad keskkonnas. Tegelikult, kui järjekordne rakendus on tootmisse viidud, töötavad seal ka tõelised põhistsenaariumid. Sama sisselogimine, piletite taotlemine, juurdepääsu taotlemine CloudFrontile, kontrollimine, et voog on tõesti seotud minu õigustega, režissööri liidese kontrollimine.

Praegu on mul käigus umbes 70 komponente testi ja umbes 40 integratsioonitestis. Katvus on väga lähedane 95%-le. See on komponentide puhul, integratsiooniliste puhul on see väiksem, seal pole lihtsalt nii palju vaja. Arvestades, et projektis on erinevad koodigeneratsioonid, on see väga hea näitaja. Pole olnud teist võimalust teha seda, mida me kolme kuuga tegime. Sest kui me oleksime käsitsi testinud, andes funktsioone meie testijale, kes oleks leidnud vigu ja tagastanud need meile parandamiseks, oleks see koodide häälestamise ring väga pikk, ja me ei oleks mahtunud mingitesse tähtaegadesse.

Nikolai: Ütleme nii, et kogu platvormi regressioonitestimiseks, kui mõnda funktsiooni muudetakse, peab kaks päeva istuma ja igasse kohta klikkima.

Vladimir: Seetõttu on suur edu, et kui ma funktsiooni hindan, ütlen, et mul on vaja 4 päeva kahe lihtsa käepideme ja 1 websocketi jaoks, Andrei lubab. Ta on juba harjunud, et sellesse 4 päeva on sisse arvestatud 2 tüüpi teste, ja siis, tõenäoliselt, see töötab.

Nikolai: Mul on samuti kirjutatud 140 testi: komponendi + funktsionaalsete testide, mis teevad sama asja. Kõiki samu stsenaariume testitakse nii tootmises, testimisel kui ka arenduses. Samuti on meil hiljuti ilmunud funktsionaalsed põhilised UI-testid. Nii katame kõige põhifunktsioonid, mis võivad kokku kukkuda.

Vladimir: Loomulikult tasub rääkida koormustestidest. Oli vaja kontrollida platvormi koormuse all, mis on lähedane reaalsusele, et mõista, mis toimub Rabbitiga, mis toimub JVM-idega, kui palju tegelikult mälu on vajalik.

— Ma ei tea täpselt, kas me testime midagi voogude küljest, aga mäletan, et meil oli probleeme transkodeerijatega, kui me korraldasime kohtumisi. Kas me testisime vooge?

Artem: Testiti iteratiivselt. Korraldades kohtumisi. Kohtumiste korraldamise käigus tekkis umbes 2300 JIRA-piletit. Need on lihtsalt malli asjad, mida inimesed tegid kohtumiste korraldamiseks. Võtsime platvormi osad eraldi lehe jaoks kohtumistele, millega tegeles Kirill Tolkachev (tolkkv).

Ausalt öeldes ei olnud suuri probleeme. Ainult paar korda tabasime CloudFront'i vahemäluga seotud vigu, lahendasime need üsna kiiresti — lihtsalt seadistasime poliitikad ümber. Vigu oli oluliselt rohkem inimestes, ürituste voogedastussüsteemides.

Konverentside ajal tuli kirjutada veel mitu eksportööri, et katta rohkem seadmeid ja teenuseid. Kohati tuli teha enda lahendusi ainult mõõdikute tõttu. AV (audiovisuaal) riistvara maailm ei ole just roosiline — sul on mingi seadme 'API', millele sa ei saa lihtsalt mõju avaldada. Ja kaugeltki ei ole kindel, et sa saad vajalikku teavet kätte. Riistvaratootjad on tõeliselt aeglased ning nendelt on peaaegu võimatu saavutada soovitud tulemusi. Kokku üle 100 seadme, nad ei anna seda, mida vajad, ja sa kirjutad kummalisi ja liigseid eksportööre, mille kaudu on kuidagi võimalik süsteemi tõrkeid lahendada.

Seadmed

— Mäletan, kuidas enne konverentse täiendasime osaliselt varustust.

Artem: Ostsin arvuteid, sülearvuteid, akublokke. Praegu suudame ilma elektrita elada 40 minutit. Juunis oli Peterburis tugev storms — seega toimus meil selline elektrikatkestus. Samas tulevad meile mitmed teenusepakkujad optiliste linkidega erinevatest kohtadest. See on tõesti 40 minutit hoone seisakut, mille jooksul põleb valgus, töötab heli, kaamerad jne.

— Meil on internetiga sarnane lugu. Kontoris, kus asuvad meie stuudiod, oleme põrandate vahel venitanud tugeva võrgu.

Artem: Meil on 20 GBit optikat põrandate vahel. Edasi on põrandatel optika, mõnes kohas mitte, kuid igal juhul on vähem kui gigabiti kanaleid — edastame nende kaudu konverentside videoid. Üldiselt on väga mugav töötada enda infrastruktuuriga, offline-konverentside korraldamisel saab seda harva teha.

— Juba enne JUG Ru Groupis töötamist nägin, kuidas masinad öö jooksul offline-konverentsidel üles seatakse, kus on suur monitor kõigi metrikatega, mida te Grafanas koostate. Praegu on ka komandokeskus, kus istub arendustiim, kes konverentsi ajal parandab vigu ja arendab funktsioone. Sellel on seire süsteem, mis kuvatakse suurele ekraanile. Artyom, Kolja ja teised poisid istuvad ja jälgivad, et kõik ei kukuks ning töötaks sujuvalt.

Kõrvaltegevused ja probleemid

— Te rääkisite hästi meie Amazoni voogedastusest, veebimängijast, mis on kirjutatud erinevates programmeerimiskeeltes, tagamisel, et tingimused oleksid täidetud, sealhulgas isiklik konto, mis toetab nii juriidilisi kui füüsilisi isikuid, ning saame integreerida kellegagi OAuth 2.0 kaudu, seal on anti-pettuse süsteem ja kasutaja blokeerimine. Saame dünaamiliselt välja anda muudatusi, kuna oleme selle hästi teinud ja see kõik on testitud.

Mind huvitab teada, millised olid kummalised olukorrad seoses millegi käivitamisega. Kas oli kummalisi olukordi, kui töötasite välja tagaplaani, esitlust, ning juhtus, et midagi läks veidralt ja te ei teadnud, mida sellega teha?

Vladimir: Minu arvates oli seda ainult viimased kolm kuud. Igal päeval. Nagu näha on, on kõik mu juuksed välja rebitud.

Vladimir Krasilyshchik kolme kuu pärast, mil juhtus, et midagi läks veidralt ja keegi ei teadnud, mida sellega teha.

Iga päev juhtus midagi sellist, kui tuli hetk, kus sa haarad ja rebid endalt juukseid ära, või mõistad, et kedagi enam pole ja ainult sina saad seda teha. Meie esimene suurem üritus oli TechTrain. 6. juuni kell 2 öösel ei olnud meil ikka veel töökeskkond üles tõstetud, seda tegi Kola. Ja isiklik konto ei töötanud, nagu ka OAuth2.0 autoriseerimiserver. Me muutsime selle OAuth2.0 teenusepakkujaks, et selle kaudu platvormile ühenduda. Ma olin ilmselt juba 18 tundi järjest töötanud, vaatasin arvutisse ja ei näinud midagi, ei saanud aru, miks see ei tööta, ja Kola vaatas mu koodi kaugelt, otsis vead Springi konfiguratsioonist, leidis need ja isiklik konto hakkas tööle, samuti tootmises.

Nikolai: Ja tund enne TechTrain'i ilmumine oli toimunud.

Siin kujunesid paljuski tähed. Meil vedas, sest meil kujunes lihtsalt super meeskond ja kõik olid motiveeritud ideest teha see veebis. Kõik need kolm kuud andis meile energiat, et me „tegime YouTube'i”. Ma ei lasknud endal juukseid rebida, vaid ütlesin kõikidele, et kõik sujub, sest tegelikult oli kõik ammu läbi arvutatud.

Tootlikkusest

— Kas saaksite rääkida, kui palju inimesi oli veebisaidil ühel teel? Kas esines jõudluse probleeme?

Nikolai: Jõudluse probleeme ei esinenud, nagu me juba ütlesime. Üksikutel ettekannetel oli maksimaalselt 1300 inimest, see oli Heisenbugil.

— Kas kohaliku vaatamisega oli probleeme? Ja kas on võimalik tehniline kirjeldus koos skeemidega, kuidas see kõik töötab?

Nikolai: Teeme sellest hiljem artikli.

Kohalikult saab isegi voogedastusi siluda. Kui konverentsid algasid, muutus see isegi lihtsamaks, kuna ilmusid tootmisvoogedastused, mida saame pidevalt jälgida.

Vladimir: Nii nagu ma aru saan, töötasid esiotsa arendajad kohalikult mokeidega, ja kuna voodamine arenduses on samuti lühike (5 minutit), siis sertifikaatide osas probleeme ei esine.

— Kõike testitakse, silutakse, isegi kohalikult. Seega, kirjutame artikli koos kõikide tehniliste detailidega, näitame ja räägime kõigest skeemidega, kuidas see oli.

Vladimir: Saate selle võtta ja korrata.

— 3 kuud.

Kokkuvõte

— Kõik see kokku kõlab ägedalt, arvestades, et see on tehtud väikese meeskonna poolt kolme kuu jooksul.

Nikolai: Suurte tiimide puhul see ei toimi. Aga väiksem grupp inimesi, kes suhtlevad üksteisega tihedalt ja tõhusalt ning saavad kokkuleppele, võiks sellega hakkama saada. Neil ei ole vastumeelsusi, arhitektuur loodi kahe päevaga, viidi lõpule ja ei ole tegelikult muutunud. Ärinõuete karm vältimine ei võimalda funktsionaalsete muutuste ja muudatuste kuhjumist.

— Mis jäi teie järgmiste ülesannete nimekirja, kui suvekohvikud olid juba toimunud?

Nikolai: Näiteks subtiitrid. Videotes liikuvad kirjed, hüpikaknad teatud kohtades sõltuvalt sisu näitamisest. Näiteks, kui esineja soovib küsida publikult, ilmub ekraanile küsitlus, mille tulemused saadetakse tagasi esinejale. Teatud sotsiaalne aktiivsus, nagu meeldimised, südamed, esituse hindamine, et saaks kohe tagasisidet anda ilma hilisemaid tagasiside vorme ootamata. Algne idee oli selline.

Ja veelgi enam, kogu platvormi lisamine, välja arvatud striiming ja konverents, sisaldab ka postkonverentsi olekut. Need on mängud (sealhulgas kasutajate loodud), võimalik sisu varasemate konverentside kohta, integreeritud, märgistatud ja kasutajale kättesaadavad, samuti meie veebisaidil vaatamiseks saadaval.live.jugru.org).

— Aitäh, poisid, vastuste eest!

Kui meie suvekõnede seas on lugejaid, kes osalesid, jagage oma muljeid pleierist ja ülekandest. Mis oli mugav, mis häiris, mida sooviksite tulevikus näha?

Kui platvorm huvitab ja soovite näha seda "töös", siis kasutame seda taas meie sügis-talviste konverentside vältel.. Neid on terve rida, seega on peaaegu kindlasti sobiv teie jaoks.

Allikas: habr.com