Túto jar sme sa ocitli vo veľmi veselých podmienkach. Kvôli pandémii sa ukázalo, že naše letné konferencie je potrebné presunúť online. A aby sme ich mohli efektívne vykonávať online, hotové softvérové riešenia pre nás neboli vhodné, museli sme si napísať vlastné. A mali sme na to tri mesiace.
Je jasné, že to boli vzrušujúce tri mesiace. Ale zvonku to nie je úplne zrejmé: čo je platforma online konferencií? Z akých častí sa skladá? Preto som sa na poslednej z letných konferencií DevOops spýtal tých, ktorí boli za túto úlohu zodpovední:
- Nikolay Molchanov - technický riaditeľ skupiny JUG Ru;
- Vladimir Krasilshchik je pragmatický Java programátor pracujúci na backende (jeho správy ste mohli vidieť aj na našich Java konferenciách);
- Artyom Nikonov je zodpovedný za všetky naše streamovanie videa.
Mimochodom, na jesenno-zimných konferenciách budeme používať vylepšenú verziu tej istej platformy – toľko čitateľov habra bude stále jej používateľmi.
Celkový obraz
— Aké bolo zloženie mužstva?
Nikolaj Molčanov: Máme analytika, dizajnéra, testera, troch front-endov a back-end. A, samozrejme, špecialista v tvare T!
— Ako vyzeral proces vo všeobecnosti?
nikolai: Do polovice marca sme nemali na internete pripravené vôbec nič. A 15. marca sa rozkrútil celý online kolotoč. Založili sme niekoľko úložísk, naplánovali, prediskutovali základnú architektúru a všetko sme spravili za tri mesiace.
Toto, samozrejme, prešlo klasickými fázami plánovania, architektúry, výberu funkcií, hlasovania za tie funkcie, politiky pre tieto funkcie, ich dizajnu, vývoja, testovania. Výsledkom bolo, že 6. júna sme všetko spustili do výroby. . Na všetko bolo 90 dní.
— Podarilo sa nám splniť to, k čomu sme sa zaviazali?
nikolai: Keďže sa teraz zúčastňujeme online konferencie DevOops, znamená to, že to fungovalo. Osobne som sa zaviazal k tomu hlavnému: Prinesiem zákazníkom nástroj, s ktorým môžu urobiť online konferenciu.
Výzva znela takto: dajte nám nástroj, pomocou ktorého môžeme vysielať naše konferencie majiteľom vstupeniek.
Celé plánovanie bolo rozdelené do niekoľkých etáp a všetky funkcie (približne 30 globálnych) boli rozdelené do 4 kategórií:
- čo určite urobíme (bez nich nemôžeme žiť),
- čo urobíme ako druhé,
- čo nikdy neurobíme,
- a čo nikdy, nikdy neurobíme.
Všetky funkcie sme vytvorili z prvých dvoch kategórií.
— Viem, že celkovo bolo vytvorených 600 čísel JIRA. Za tri mesiace ste urobili 13 mikroslužieb a tuším, že boli napísané nielen v Jave. Použili ste rôzne technológie, máte dva klastre Kubernetes v troch zónach dostupnosti a 5 streamov RTMP v Amazone.
Pozrime sa teraz na každý komponent systému samostatne.
Streaming
— Začnime tým, keď už máme obraz videa a prenáša sa do niektorých služieb. Artyom, povedz nám, ako prebieha toto streamovanie?
Arťom Nikonov: Naša všeobecná schéma vyzerá takto: obrázok z kamery -> naša riadiaca miestnosť -> lokálny server RTMP -> Amazon -> prehrávač videa. Viac informácií na Habré v júni.
Vo všeobecnosti existujú dva globálne spôsoby, ako to urobiť: buď na hardvéri alebo na základe softvérových riešení. Softvérovú cestu sme zvolili preto, lebo je jednoduchšia v prípade vzdialených reproduktorov. Nie je vždy možné priniesť hardvér do reproduktora v inej krajine, ale dodanie softvéru do reproduktora sa zdá jednoduchšie a spoľahlivejšie.
Z hardvérového hľadiska máme určitý počet kamier (v našich štúdiách a pri vzdialených reproduktoroch), určitý počet diaľkových ovládačov v štúdiu, ktoré sa občas musia počas vysielania opraviť priamo pod stolom.
Signály z týchto zariadení vstupujú do počítačov so zachytávacími kartami, vstupnými/výstupnými kartami a zvukovými kartami. Tam sú signály zmiešané a zostavené do rozložení:
Príklad rozloženia pre 4 reproduktory
Príklad rozloženia pre 4 reproduktory
Nepretržité vysielanie ďalej zabezpečujú tri počítače: jeden hlavný stroj a dva pracovné. Prvý počítač zhromažďuje prvú správu, druhý - prestávku, prvý - ďalšiu správu, druhý - ďalšiu prestávku atď. A hlavný stroj zmieša prvé s druhým.
Vzniká tak akýsi trojuholník a ak niektorý z týchto uzlov zlyhá, môžeme rýchlo a bez straty kvality pokračovať v doručovaní obsahu klientom. Mali sme takú situáciu. Počas prvého týždňa konferencií sme jeden stroj opravili, zapli/vypli. Zdá sa, že ľudia sú spokojní s našou odolnosťou.
Ďalej prúdy z počítačov smerujú na lokálny server, ktorý má dve úlohy: smerovať toky RTMP a zaznamenávať zálohy. Máme teda viacero záznamových bodov. Videostreamy sa potom odosielajú do časti nášho systému postaveného na službách Amazon SaaS. Používame ,S3,Cloud Front.
nikolai: Čo sa tam stane, kým sa video dostane k publiku? Musíš to nejako orezať, nie?
Artyom: Video z našej strany skomprimujeme a odošleme do MediaLive. Tam spúšťame transkodéry. Videá prekódujú v reálnom čase do niekoľkých rozlíšení, aby ich ľudia mohli sledovať na svojich telefónoch, cez slabý internet v krajine atď. Potom sa tieto prúdy rozrežú , takto funguje protokol . Do frontendu posielame zoznam skladieb, ktorý obsahuje ukazovatele na tieto časti.
— Používame rozlíšenie 1080p?
Artyom: Šírka nášho videa je rovnaká ako 1080p - 1920 pixelov a výška je o niečo menšia, obraz je pretiahnutý - existujú dôvody.
Prehrávač
— Artyom opísal, ako sa video dostáva do streamov, ako sa distribuuje do rôznych zoznamov skladieb pre rôzne rozlíšenia obrazovky, rozdeľuje sa na kúsky a dostáva sa do prehrávača. Kolja, teraz mi povedz, čo je to za prehrávač, ako spotrebúva stream, prečo HLS?
nikolai: Máme prehrávač, ktorý môžu sledovať všetci diváci konferencie.
V podstate ide o obal okolo knižnice , na ktorom je napísaných mnoho ďalších hráčov. Potrebovali sme však veľmi špecifickú funkcionalitu: pretáčanie a označenie miesta, kde sa človek nachádza, akú reportáž práve sleduje. Potrebovali sme aj vlastné layouty, všemožné logá a všetko ostatné, čo bolo s nami zabudované. Preto sme sa rozhodli napísať vlastnú knižnicu (obal nad HLS) a vložiť ju na stránku.
Toto je koreňová funkcia, takže bola implementovaná takmer ako prvá. A potom okolo toho všetko rástlo.
V skutočnosti, prostredníctvom autorizácie, hráč dostane z backendu zoznam skladieb s odkazmi na kúsky korelujúce s časom a kvalitou, stiahne potrebné a ukáže ich používateľovi, pričom na ceste vykoná nejaké „kúzlo“.
Príklad časovej osi
— Priamo v prehrávači je zabudované tlačidlo na zobrazenie časovej osi všetkých správ...
nikolai: Áno, problém používateľskej navigácie sme okamžite vyriešili. V polovici apríla sme sa rozhodli, že nebudeme každú našu konferenciu vysielať na samostatnom webe, ale spojíme všetko na jednej. Aby používatelia lístkov Full Pass mohli voľne prepínať medzi rôznymi konferenciami: živé vysielanie aj záznamy z minulých.
A aby sme používateľom uľahčili navigáciu v aktuálnom streame a prepínanie medzi skladbami, rozhodli sme sa vytvoriť tlačidlo „Celé vysielanie“ a horizontálne hlásenia na prepínanie medzi skladbami a hláseniami. K dispozícii je ovládanie pomocou klávesnice.
— Boli s tým nejaké technické problémy?
nikolai: Mali rolovaciu lištu, na ktorej boli vyznačené východiská rôznych správ.
— Nakoniec, implementovali ste tieto značky na posuvnú lištu predtým, ako YouTube urobil niečo podobné?
Artyom: Vtedy to mali v beta verzii. Zdá sa, že ide o dosť zložitú funkciu, pretože ju za posledný rok čiastočne testovali s používateľmi. A teraz sa dostal do predaja.
nikolai: V skutočnosti sme ho však dostali do predaja rýchlejšie. Úprimne povedané, za touto jednoduchou funkciou sa skrýva obrovské množstvo backendu, frontendu, výpočtov a matematiky vo vnútri prehrávača.
Frontend
— Poďme zistiť, ako sa tento obsah, ktorý zobrazujeme (prejavy, reproduktory, webová stránka, rozvrh), dostane do frontendu?
Vladimír Krasilshchik: Máme niekoľko interných IT systémov. Existuje systém, do ktorého sa zadávajú všetky správy a všetci rečníci. Existuje proces, pri ktorom sa rečník zúčastňuje konferencie. Hovorca podá žiadosť, systém ju zachytí, potom existuje určitá pipeta, podľa ktorej sa zostava vytvorí.
Rečník takto vidí potrubie
Tento systém je naším vnútorným vývojom.
Ďalej je potrebné zostaviť plán z jednotlivých prehľadov. Ako viete, toto je NP-ťažký problém, ale nejako ho vyriešime. Za týmto účelom spúšťame ďalší komponent, ktorý vygeneruje plán a nahrá ho do cloudovej služby tretej strany Contentful. Všetko tam vyzerá ako tabuľka, v ktorej sú dni konferencie, v dňoch sú časové úseky a v úsekoch sú správy, prestávky či sponzorské aktivity. Obsah, ktorý vidíme, sa teda nachádza v službe tretej strany. A úlohou je preniesť to na stránku.
Zdalo by sa, že stránka je len stránka s prehrávačom a nie je tu nič zložité. Ibaže nie je. Backend za touto stránkou prejde do Contentful, získa odtiaľ plán, vygeneruje nejaké objekty a odošle ho do frontendu. Pomocou websocket pripojenia, ktoré robí každý klient našej platformy, mu posielame aktualizáciu harmonogramu z backendu na frontend.
Skutočný prípad: rečník zmenil prácu priamo počas konferencie. Musíme mu zmeniť odznak zamestnávateľskej spoločnosti. Ako sa to deje z backendu? Aktualizácia sa odošle všetkým klientom cez websocket a potom samotný frontend prekreslí časovú os. To všetko sa deje bez problémov. Kombinácia cloudovej služby a niekoľkých našich komponentov nám dáva možnosť generovať všetok tento obsah a poskytovať ho dopredu.
nikolai: Tu je dôležité objasniť, že naša stránka nie je klasickou SPA aplikáciou. Ide o vykreslenú webovú stránku založenú na rozložení a SPA. Google v skutočnosti vidí túto stránku ako vykreslený kód HTML. To je dobré pre SEO a pre poskytovanie obsahu používateľovi. Pred zobrazením stránky nečaká na načítanie 1,5 megabajtu JavaScriptu, okamžite vidí už vykreslenú stránku a cítite to pri každom prepnutí zostavy. Všetko sa deje za pol sekundy, pretože obsah je už pripravený a uverejnený na správnom mieste.
— Urobme čiaru za všetkým vyššie uvedeným zoznamom technológií. Tyoma povedal, že máme 5 streamov Amazonu a tam dodávame video a zvuk. Máme tam bash skripty, používame ich na spúšťanie a konfiguráciu...
Artyom: Deje sa to cez AWS API, tam je oveľa viac technických bočných služieb. Rozdelili sme si povinnosti tak, že doručujem do a vývojári front-endu a back-endu to preberajú odtiaľ. Máme množstvo vlastných väzieb na zjednodušenie rozloženia obsahu, ktorý potom robíme v 4K atď. Keďže termíny boli veľmi krátke, urobili sme to takmer celé na AWS.
— Potom to všetko ide do prehrávača pomocou backendového systému. V prehrávači máme TypeScript, React, Next.JS. A na backende máme niekoľko služieb v C#, Java, Spring Boot a Node.js. To všetko je nasadené pomocou Kubernetes pomocou infraštruktúry Yandex.Cloud.
Chcem tiež poznamenať, že keď som sa potreboval zoznámiť s platformou, ukázalo sa, že je to jednoduché: všetky úložiská sú na GitLab, všetko je dobre pomenované, testy sú napísané, existuje dokumentácia. Teda aj v núdzovom režime sa o takéto veci starali.
Obchodné obmedzenia a analytika
— Zamerali sme sa na 10 000 používateľov na základe obchodných požiadaviek. Je čas hovoriť o obchodných obmedzeniach, ktoré sme mali. Museli sme zabezpečiť vysoké pracovné nasadenie, zabezpečiť dodržiavanie zákona o uchovaní osobných údajov. A čo ešte?
nikolai: Spočiatku sme vychádzali z požiadaviek na video. Najdôležitejšou vecou je distribuované video úložisko po celom svete pre rýchle doručenie klientovi. Medzi ďalšie patrí rozlíšenie 1080p, ako aj pretáčanie dozadu, ktoré mnohí iní neimplementujú v živom režime. Neskôr sme pridali možnosť povoliť 2x rýchlosť, s jej pomocou môžete „dobehnúť“ naživo a pokračovať v sledovaní konferencie v reálnom čase. A popri tom sa objavila funkcia označovania časovej osi. Navyše sme museli byť odolní voči chybám a vydržať záťaž 10 000 spojení. Z pohľadu backendu je to približne 10 000 spojení vynásobených 8 požiadavkami na každé obnovenie stránky. A to je už 80 000 RPS/s. Pomerne málo.
— Boli nejaké ďalšie požiadavky na „virtuálnu výstavu“ s online stánkami partnerov?
nikolai: Áno, toto sa muselo urobiť pomerne rýchlo a univerzálne. Na každú konferenciu sme mali až 10 partnerských spoločností a všetky sme museli stihnúť za týždeň alebo dva. Ich obsah sa však mierne líši formátom. Bol však vytvorený určitý nástroj šablón, ktorý tieto stránky zostavuje za chodu, prakticky bez ďalšej účasti na vývoji.
— Požiadavky boli aj na analýzu zobrazení a štatistík v reálnom čase. Viem, že na to používame Prometheus, ale povedzte nám podrobnejšie: aké požiadavky na analýzu spĺňame a ako sa to implementuje?
nikolai: Na začiatku máme marketingové požiadavky na zhromažďovanie pre A/B testovanie a zhromažďovanie informácií, aby sme pochopili, ako správne doručiť klientovi ten najlepší obsah v budúcnosti. Existujú aj požiadavky na niektoré analýzy partnerských aktivít a analýzy, ktoré vidíte (počítadlo návštev). Všetky informácie sa zhromažďujú v reálnom čase.
Tieto informácie môžeme poskytnúť v súhrnnej forme aj prednášajúcim: koľko ľudí vás v určitom čase sledovalo. Zároveň sa v súlade s federálnym zákonom 152 váš osobný účet a osobné údaje žiadnym spôsobom nesledujú.
Platforma už má marketingové nástroje a naše metriky na meranie aktivity používateľov v reálnom čase (kto sledoval akú sekundu správy), aby sme mohli zostaviť grafy návštevnosti na správach. Na základe týchto údajov sa robí výskum, ktorý skvalitní nasledujúce konferencie.
Podvod
— Máme mechanizmy na boj proti podvodom?
nikolai: Vzhľadom na tesný časový rámec z obchodného hľadiska nebola úloha pôvodne nastavená na okamžité blokovanie nepotrebných spojení. Ak sa dvaja používatelia prihlásili pod rovnakým účtom, mohli si zobraziť obsah. Vieme však, koľko simultánnych zobrazení bolo z jedného účtu. A zakázali sme niekoľko obzvlášť zlomyseľných porušovateľov.
vladimir: Ku cti treba povedať, že jeden zo zakázaných používateľov pochopil, prečo sa tak stalo. Prišiel, ospravedlnil sa a sľúbil, že si kúpi lístok.
— Aby sa to všetko stalo, musíte úplne sledovať všetkých používateľov od vstupu až po výstup, vždy vedieť, čo robia. Ako tento systém funguje?
vladimir: Chcel by som hovoriť o analytikách a štatistikách, ktoré potom analyzujeme pre úspešnosť správy alebo ich môžeme poskytnúť partnerom. Všetci klienti sú pripojení cez websocket pripojenie k špecifickému backendovému klastru. Stojí tam . Každý klient v každom časovom období posiela, čo robí a akú stopu sleduje. Potom sú tieto informácie agregované pomocou rýchlych úloh Hazelcast a odoslané späť každému, kto sleduje tieto stopy. V rohu vidíme, koľko ľudí je teraz s nami.
Rovnaké informácie sú uložené v a ide do nášho dátového jazera, z ktorého máme možnosť zostaviť zaujímavejší graf. Vynára sa otázka: koľko jedinečných používateľov si prezrelo tento prehľad? Ideme , sú pingy všetkých ľudí, ktorí prišli s ID tohto prehľadu. Zhromaždili sme, agregovali jedinečné a teraz tomu rozumieme.
nikolai: Zároveň však od spoločnosti Prometheus dostávame aj údaje v reálnom čase. Je nastavený proti všetkým službám Kubernetes, proti samotnému Kubernetes. Zhromažďuje úplne všetko a s Grafanou môžeme zostaviť akékoľvek grafy v reálnom čase.
vladimir: Na jednej strane to stiahneme na ďalšie spracovanie OLAP. A pre OLTP aplikácia stiahne celé do Prometheus, Grafana a grafy sa dokonca zbiehajú!
- To je prípad, keď sa grafy zbiehajú.
Dynamické zmeny
— Povedzte nám, ako sa zavádzajú dynamické zmeny: ak bola správa zrušená 6 minút pred začiatkom, aký je reťazec akcií? Ktoré potrubie funguje?
vladimir: Potrubie je veľmi podmienené. Možností je viacero. Prvým je, že program generovania rozvrhu fungoval a zmenil rozvrh. Upravený rozvrh sa nahrá do Contentful. Potom backend pochopí, že pre túto konferenciu v Contentful nastali zmeny, vezme ju a prestaví ju. Všetko sa zhromažďuje a odosiela cez websocket.
Druhá možnosť, keď sa všetko deje závratným tempom: editor manuálne zmení informácie v Contentful (odkaz na telegram, prezentáciu rečníka atď.) a funguje rovnaká logika ako prvýkrát.
nikolai: Všetko sa deje bez obnovenia stránky. Všetky zmeny prebiehajú pre klienta úplne hladko. To isté platí pre prepínanie správ. Keď príde čas, správa a rozhranie sa zmenia.
vladimir: Na časovej osi sú tiež časové limity pre začiatok prehľadov. Na samom začiatku nie je nič. A ak prejdete myšou na červený pruh, v určitom okamihu sa vďaka režisérovi vysielania objavia prerušenia. Režisér nastaví správny začiatok vysielania, backend zachytí túto zmenu, vypočíta čas začiatku a konca prezentácií celej skladby v súlade s harmonogramom konferencie, pošle to našim klientom a hráč vyžrebuje cutoffy. Teraz môže používateľ jednoducho prejsť na začiatok a koniec zostavy. Bola to prísna obchodná požiadavka, veľmi pohodlná a užitočná. Nestrácate čas hľadaním skutočného času začiatku prehľadu. A keď urobíme ukážku, bude to úplne úžasné.
Nasadenie
— Chcel by som sa opýtať na nasadenie. Kolja a tím venovali na začiatku veľa času nastaveniu celej infraštruktúry, v ktorej sa nám všetko odvíja. Povedz mi, z čoho to všetko je?
nikolai: Z technického hľadiska sme mali spočiatku požiadavku, aby bol produkt čo najabstraktnejší od akéhokoľvek predajcu. Príďte do AWS a vytvorte skripty Terraform konkrétne z AWS alebo konkrétne z Yandexu alebo z Azure atď. naozaj nesedel. Raz sme sa museli niekam posunúť.
Prvé tri týždne sme neustále hľadali spôsob, ako to urobiť lepšie. V dôsledku toho sme dospeli k záveru, že Kubernetes je v tomto prípade naše všetko, pretože nám umožňuje vytvárať služby s automatickým škálovaním, automatické zavádzanie a takmer všetky služby hneď po vybalení. Prirodzene, všetky služby museli byť vyškolené na prácu s Kubernetes, Docker a tím sa musel tiež naučiť.
Máme dva klastre. Test a výroba. Hardvérom a nastavením sú úplne totožné. Infraštruktúru implementujeme ako kód. Všetky služby sa automaticky zavádzajú do troch prostredí z funkčných vetiev, hlavných vetiev, testovacích vetiev a GitLab pomocou automatického potrubia. Toto je maximálne integrované do GitLab, maximálne integrované s Elastic, Prometheus.
Máme možnosť rýchlo (pre backend do 10 minút, pre frontend do 5 minút) zaviesť zmeny do akéhokoľvek prostredia so všetkými testami, integráciami, spustením funkčných testov, integračnými testami na prostredí a tiež testovaním záťažovými testami na testovacie prostredie približne to isté, čo chceme získať vo výrobe.
O testoch
— Testuješ takmer všetko, je ťažké uveriť, ako si všetko napísal. Môžete nám povedať o backendových testoch: koľko je všetko pokryté, aké testy?
vladimir: Boli napísané dva typy testov. Prvým sú testy komponentov. Testy úrovne zdvihu celej aplikácie pružiny a základne . Toto je test obchodných scenárov najvyššej úrovne. Funkcie netestujem. Testujeme len niektoré veľké veci. Napríklad priamo v teste je emulovaný proces prihlásenia používateľa, žiadosť používateľa o lístky, kam môže ísť, a žiadosť o prístup na sledovanie streamu. Veľmi jasné používateľské scenáre.
Približne to isté je implementované v takzvaných integračných testoch, ktoré reálne bežia na prostredí. V skutočnosti, keď sa spustí ďalšie nasadenie v produkcii, reálne základné scenáre bežia aj v produkcii. Rovnaké prihlásenie, vyžiadanie lístkov, vyžiadanie prístupu do CloudFront, kontrola, či sa stream skutočne spája s mojimi povoleniami, kontrola rozhrania režiséra.
Momentálne mám na palube asi 70 testov komponentov a asi 40 testov integrácie. Pokrytie je veľmi blízko 95 %. Toto je pre komponenty, menej pre integračné, jednoducho toho nie je toľko potrebné. Vzhľadom na to, že projekt zahŕňa všetky druhy generovania kódu, je to veľmi dobrý ukazovateľ. Neexistoval žiadny iný spôsob, ako urobiť to, čo sme urobili za tri mesiace. Pretože ak by sme testovali manuálne, dali funkcie nášmu testerovi a ona by našla chyby a vrátila by nám ich na opravu, potom by táto spiatočná cesta na ladenie kódu bola veľmi dlhá a nedodržali by sme žiadne termíny.
nikolai: Na vykonanie regresie na celej platforme pri zmene niektorej funkcie zvyčajne musíte dva dni sedieť a hrabať sa všade.
vladimir: Preto je veľkým úspechom, že keď odhadnem nejakú funkciu, poviem, že potrebujem 4 dni na dve jednoduché perá a 1 websocket, Kolja to umožňuje. Už je zvyknutý, že tieto 4 dni zahŕňajú 2 typy testov a potom to s najväčšou pravdepodobnosťou bude fungovať.
nikolai: Tiež mám napísaných 140 testov: komponent + funkčný, ktoré robia to isté. Všetky rovnaké scenáre sa testujú vo výrobe, v teste a vo výrobe. Nedávno sme pridali aj funkčné základné testy používateľského rozhrania. Týmto spôsobom pokrývame najzákladnejšie funkcie, ktoré sa môžu rozpadnúť.
vladimir: Samozrejme, stojí za to hovoriť o záťažových testoch. Platformu bolo potrebné otestovať pod záťažou blízkou tej skutočnej, aby sme pochopili, ako sa všetko deje, čo sa deje s Rabbitom, čo sa deje s JVM, koľko pamäte je vlastne potrebné.
— Neviem s istotou, či niečo testujeme na strane streamu, ale pamätám si, že keď sme robili stretnutia, vyskytli sa problémy s transkodérmi. Testovali sme streamy?
Artyom: Testované iteratívne. Organizovanie stretnutí. V procese organizovania meetupov bolo približne 2300 vstupeniek na JIRA. Toto sú len všeobecné veci, ktoré ľudia robili, aby sa stretli. Časti platformy sme preniesli na samostatnú stránku pre stretnutia, ktorú viedol Kirill Tolkachev ().
Úprimne povedané, neboli žiadne veľké problémy. Doslova párkrát sme na CloudFronte zachytili chyby ukladania do vyrovnávacej pamäte, vyriešili sme to pomerne rýchlo – jednoducho sme prekonfigurovali politiky. Podstatne viac chýb bolo u ľudí, v streamovacích systémoch na stránke.
Počas konferencií som musel napísať niekoľko ďalších exportérov, aby som pokryl viac zariadení a služieb. Na niektorých miestach som si musel vyrobiť vlastné bicykle len kvôli metrike. Svet AV (audio-video) hardvéru nie je veľmi ružový – máte nejaké „API“ zariadenia, ktoré jednoducho nemôžete ovplyvniť. A zďaleka nie je pravda, že budete môcť získať informácie, ktoré potrebujete. Dodávatelia hardvéru sú naozaj pomalí a je takmer nemožné získať od nich to, čo chcete. Celkovo ide o viac ako 100 kusov hardvéru, nevrátia vám to, čo potrebujete, a píšete podivné a nadbytočné exportéry, vďaka ktorým môžete aspoň nejako odladiť systém.
Оборудование
— Pamätám si, ako sme pred začiatkom konferencií čiastočne dokúpili ďalšie vybavenie.
Artyom: Kúpili sme počítače, notebooky a batérie. Momentálne dokážeme žiť bez elektriny 40 minút. V júni boli v Petrohrade silné búrky - takže sme mali taký výpadok prúdu. Zároveň k nám prichádza viacero poskytovateľov s optickými linkami z rôznych miest. To je naozaj 40 minút odstávky budovy, počas ktorej nám budú fungovať svetlá, zvuk, kamery atď.
— Máme podobný príbeh s internetom. V kancelárii, kde sa nachádzajú naše ateliéry, sme medzi poschodiami ťahali tvrdú sieť.
Artyom: Medzi poschodiami máme 20 Gbit vlákna. Ďalej po poschodiach, niekde je optika, niekde nie je optika, ale stále je tam menej kanálov ako gigabitových - spúšťame na nich video medzi skladbami konferencie. Vo všeobecnosti je veľmi výhodné pracovať na vlastnej infraštruktúre, na offline konferenciách na stránkach to môžete urobiť len zriedka.
— Predtým, ako som pracoval v JUG Ru Group, som videl, ako sa cez noc zriaďovali hardvérové miestnosti na offline konferenciách, kde bol veľký monitor so všetkými metrikami, ktoré si vytvoríte v Grafane. Teraz je tu aj centrála, v ktorej sedí vývojový tím, ktorý počas konferencie opravuje niektoré chyby a vyvíja funkcie. Zároveň je tu monitorovací systém, ktorý sa zobrazuje na veľkej obrazovke. Artyom, Kolya a ďalší chlapci sedia a starajú sa, aby to všetko nespadlo a fungovalo nádherne.
Kuriozity a problémy
— Dobre ste hovorili o tom, že máme streamovanie s Amazonom, existuje prehrávač s webom, všetko je napísané v rôznych programovacích jazykoch, je zabezpečená odolnosť proti chybám a ďalšie obchodné požiadavky, vrátane osobného účtu, ktorý je podporovaný pre právnické osoby a jednotlivcov a môžeme sa s niekým integrovať pomocou protokolu OAuth 2.0, existuje ochrana proti podvodom a blokovanie používateľov. Zmeny môžeme zavádzať dynamicky, pretože sme to urobili dobre a všetko je otestované.
Zaujímalo by ma, aké zvláštnosti boli zahrnuté v tom, aby sa niečo začalo. Nastali nejaké zvláštne situácie, keď ste vyvíjali backend, frontend, stalo sa niečo šialené a vy ste nechápali, čo s tým?
vladimir: Zdá sa mi, že sa to deje len posledné tri mesiace. Každý deň. Ako vidíte, všetky vlasy mám vytrhané.
Vladimir Krasilshchik po 3 mesiacoch, keď sa objavila nejaká hra a nikto nechápal, čo s tým robiť
Každý deň bolo niečo také, keď nastala taká chvíľa, kedy si to vezmeš a trháš si vlasy, alebo si uvedomíš, že nikto iný nie je a len ty to dokážeš. Našou prvou veľkou akciou bol TechTrain. 6. júna o 2:2.0 sme ešte nespustili produkčné prostredie, rozbiehal ho Kolja. A osobný účet nefungoval ako autorizačný server pomocou protokolu OAuth2.0. Premenili sme ho na poskytovateľa OAuth18, aby sme k nemu pripojili platformu. Pracoval som asi XNUMX hodín v kuse, pozrel som sa do počítača a nič som nevidel, nechápal som, prečo to nefunguje, a Kolja sa na diaľku pozrel na môj kód, hľadal chybu v konfigurácii Spring , našiel to a LC fungovalo aj vo výrobe.
nikolai: A hodinu pred TechTrain sa vydanie uskutočnilo.
Bolo tu zoradených veľa hviezd. Mali sme obrovské šťastie, pretože sme mali super tím a každý bol inšpirovaný myšlienkou urobiť to online. Všetky tieto tri mesiace nás poháňala skutočnosť, že sme „vytvorili YouTube“. Nedovolil som si trhať si vlasy, ale všetkým som povedal, že všetko bude fungovať, pretože v skutočnosti bolo všetko už dávno vypočítané.
O výkone
— Môžete mi povedať, koľko ľudí bolo na stránke na jednej trati? Vyskytli sa nejaké problémy s výkonom?
nikolai: Ako sme už povedali, neboli žiadne problémy s výkonom. Maximálny počet ľudí, ktorí sa zúčastnili jednej správy, bol 1300 ľudí, toto je na Heisenbug.
— Vyskytli sa nejaké problémy s miestnym sledovaním? A je možné mať technický popis so schémami, ako to celé funguje?
nikolai: O tom urobíme článok neskôr.
Môžete dokonca lokálne ladiť streamy. Po začatí konferencií to bolo ešte jednoduchšie, pretože sa objavili produkčné streamy, ktoré môžeme sledovať stále.
vladimir: Chápem to tak, že front-end vývojári pracovali lokálne s maketami a potom, keďže čas na zavedenie vývojárom vpredu je tiež krátky (5 minút), nie sú problémy s kontrolou toho, čo sa deje s certifikátmi.
— Všetko je testované a odladené, dokonca aj lokálne. To znamená, že napíšeme článok so všetkými technickými funkciami, ukážeme vám, povieme vám všetko pomocou diagramov, ako to bolo.
vladimir: Môžete si to vziať a zopakovať.
- Za 3 mesiace.
Celkový
— Všetko, čo je spolu opísané, znie cool, keď vezmeme do úvahy, že to urobil malý tím za tri mesiace.
nikolai: Veľký tím by to neurobil. Ale malá skupina ľudí, ktorí spolu celkom úzko a dobre komunikujú a vedia sa dohodnúť, by mohla. Nemajú žiadne rozpory, architektúra bola vynájdená za dva dni, bola dokončená a vlastne sa nezmenila. Existuje veľmi prísne uľahčenie prichádzajúcich obchodných požiadaviek, pokiaľ ide o hromadenie požiadaviek na funkcie a zmien.
— Čo bolo na vašom zozname ďalších úloh, keď sa už konali letné konferencie?
nikolai: Napríklad kredity. Plíživé čiary vo videu, vyskakovacie okná na niektorých miestach vo videu v závislosti od zobrazeného obsahu. Napríklad rečník chce položiť otázku publiku a na obrazovke sa objaví hlasovanie, ktoré sa vráti dozadu na základe výsledkov hlasovania samotnému rečníkovi. Nejaký druh spoločenskej aktivity v podobe lajkov, srdiečok, hodnotení správy počas samotnej prezentácie, aby ste mohli v správnom momente vyplniť spätnú väzbu bez toho, aby vás neskôr rozptyľovali formuláre spätnej väzby. Spočiatku takto.
A tiež pridanie do celej platformy, okrem streamovania a konferencie, aj stav po konferencii. Ide o zoznamy skladieb (vrátane zoznamov zostavených používateľmi), prípadne obsah z iných minulých konferencií, integrovaný, označený, prístupný používateľovi a dostupný aj na prezeranie na našej webovej stránke ().
— Chlapci, veľmi pekne vám ďakujem za odpovede!
Ak sú medzi čitateľmi takí, ktorí sa zúčastnili našich letných konferencií, podeľte sa o svoje dojmy z prehrávača a vysielania. Čo vám vyhovovalo, čo vás rozčuľovalo, čo by ste chceli vidieť v budúcnosti?
Ak vás platforma zaujala a chcete ju vidieť „v boji“, opäť ju používame na našej . Existuje ich celá škála, takže takmer určite existuje ten, ktorý je pre vás ten pravý.
Zdroj: hab.com