Letos na jaře jsme se ocitli ve velmi veselých podmínkách. Vzhledem k pandemii bylo jasné, že naše letní konference je třeba přesunout online. A abychom je vedli efektivně online, nevyhovovala nám hotová softwarová řešení, museli jsme napsat vlastní. A měli jsme na to tři měsíce.
Je jasné, že to byly vzrušující tři měsíce. Ale zvenčí to není úplně zřejmé: co je to platforma online konferencí? Z jakých částí se skládá? Proto jsem se na poslední z letních DevOops konferencí zeptal těch, kteří byli za tento úkol zodpovědní:
- Nikolay Molchanov - technický ředitel JUG Ru Group;
- Vladimir Krasilshchik je pragmatický Java programátor pracující na backendu (jeho reportáže jste mohli vidět i na našich Java konferencích);
- Artyom Nikonov je zodpovědný za veškeré naše streamování videa.
Mimochodem, na podzimně-zimních konferencích budeme používat vylepšenou verzi stejné platformy – tolik čtenářů habra bude stále jejími uživateli.
Celkový obraz
— Jaké bylo složení týmu?
Nikolaj Molčanov: Máme analytika, designéra, testera, tři front-endy a back-end. A samozřejmě specialista ve tvaru T!
— Jak celý proces vypadal?
Nikolay: Do půlky března jsme neměli na internetu připraveno vůbec nic. A 15. března se celý online kolotoč roztočil. Založili jsme několik úložišť, naplánovali, prodiskutovali základní architekturu a vše udělali za tři měsíce.
To samozřejmě prošlo klasickými fázemi plánování, architektury, výběru funkcí, hlasování o těch funkcích, politiky pro ty funkce, jejich návrhu, vývoje, testování. Výsledkem bylo, že 6. června jsme vše uvedli do výroby. . Na všechno bylo 90 dní.
— Podařilo se nám splnit to, k čemu jsme se zavázali?
Nikolay: Protože se nyní účastníme konference DevOops online, znamená to, že to fungovalo. Osobně jsem se zavázal k tomu hlavnímu: Přinesu zákazníkům nástroj, se kterým mohou udělat online konferenci.
Výzva byla tato: dejte nám nástroj, pomocí kterého můžeme naše konference přenášet držitelům vstupenek.
Veškeré plánování bylo rozděleno do několika fází a všechny funkce (asi 30 globálních) byly rozděleny do 4 kategorií:
- což určitě uděláme (bez nich nemůžeme žít),
- což uděláme za druhé,
- což nikdy neuděláme,
- a které nikdy, nikdy neuděláme.
Všechny funkce jsme vytvořili z prvních dvou kategorií.
— Vím, že bylo vytvořeno celkem 600 čísel JIRA. Za tři měsíce jsi udělal 13 mikroslužeb a tuším, že byly napsané nejen v Javě. Použili jste různé technologie, máte dva clustery Kubernetes ve třech zónách dostupnosti a 5 streamů RTMP v Amazonu.
Podívejme se nyní na každou součást systému zvlášť.
Streamování
— Začněme tím, když již máme obraz videa a je přenášen do některých služeb. Artyome, řekni nám, jak k tomuto streamování dochází?
Arťom Nikonov: Naše obecné schéma vypadá takto: obraz z kamery -> naše řídicí místnost -> místní server RTMP -> Amazon -> přehrávač videa. Více informací na Habré v červnu.
Obecně existují dva globální způsoby, jak toho dosáhnout: buď na hardwaru, nebo na základě softwarových řešení. Softwarovou cestu jsme zvolili proto, že je v případě vzdálených reproduktorů jednodušší. Není vždy možné přenést hardware do reproduktoru v jiné zemi, ale dodání softwaru do reproduktoru se zdá jednodušší a spolehlivější.
Z hardwarového hlediska máme určitý počet kamer (v našich studiích a u vzdálených reproduktorů), určitý počet dálkových ovladačů ve studiu, které se občas musí během vysílání opravit přímo pod stolem.
Signály z těchto zařízení vstupují do počítačů se snímacími kartami, vstupními/výstupními kartami a zvukovými kartami. Tam jsou signály smíchány a sestaveny do rozložení:
Příklad rozložení pro 4 reproduktory
Příklad rozložení pro 4 reproduktory
Dále je zajištěno nepřetržité vysílání pomocí tří počítačů: jeden hlavní stroj a dvojice pracovních. První počítač shromažďuje první zprávu, druhý - přestávka, první - další zpráva, druhý - další přestávka a tak dále. A hlavní stroj míchá první s druhým.
Vzniká tak jakýsi trojúhelník, a pokud některý z těchto uzlů selže, můžeme rychle a bez ztráty kvality nadále dodávat obsah klientům. Měli jsme takovou situaci. Během prvního týdne konferencí jsme jeden stroj opravili, zapnuli/vypnuli. Zdá se, že lidé jsou spokojeni s naší odolností.
Dále toky z počítačů jdou na místní server, který má dva úkoly: směrovat toky RTMP a nahrávat zálohy. Máme tedy několik záznamových bodů. Videostreamy jsou poté odesílány do části našeho systému postaveného na službách Amazon SaaS. Používáme ,S3,Cloud Front.
Nikolay: Co se tam stane, než se video dostane k publiku? Musíš to nějak ustřihnout, ne?
Artyom: Video z naší strany zkomprimujeme a odešleme do MediaLive. Spouštíme tam transkodéry. Překódují videa v reálném čase do několika rozlišení, aby je lidé mohli sledovat na svých telefonech, přes špatný internet v zemi a tak dále. Poté jsou tyto proudy rozřezány , protokol funguje takto . Do frontendu posíláme seznam skladeb, který obsahuje ukazatele na tyto části.
— Používáme rozlišení 1080p?
Artyom: Šířka našeho videa je stejná jako 1080p - 1920 pixelů a výška je o něco menší, obraz je více protáhlý - existují důvody.
Hráč
— Artyom popsal, jak se video dostává do streamů, jak je distribuováno do různých playlistů pro různá rozlišení obrazovky, rozřezáno na kousky a jak se dostane do přehrávače. Koljo, teď mi řekni, co je to za přehrávač, jak spotřebovává stream, proč HLS?
Nikolay: Máme přehrávač, který mohou sledovat všichni diváci konference.
V podstatě se jedná o obal kolem knihovny , na kterém je napsáno mnoho dalších hráčů. Potřebovali jsme ale velmi specifickou funkcionalitu: přetočit a označit místo, kde se člověk nachází, jakou reportáž právě sleduje. Potřebovali jsme také vlastní layouty, nejrůznější loga a vše ostatní, co bylo zabudováno s námi. Proto jsme se rozhodli napsat vlastní knihovnu (obal přes HLS) a vložit ji na web.
Toto je funkce root, takže byla implementována téměř jako první. A pak kolem toho všechno rostlo.
Ve skutečnosti, prostřednictvím autorizace, hráč obdrží z backendu seznam skladeb s odkazy na kousky korelované s časem a kvalitou, stáhne si ty potřebné a ukáže je uživateli, přičemž na cestě provádí nějaké „kouzlo“.
Příklad časové osy
— Přímo v přehrávači je zabudováno tlačítko pro zobrazení časové osy všech zpráv...
Nikolay: Ano, problém s uživatelskou navigací jsme okamžitě vyřešili. V polovině dubna jsme se rozhodli, že nebudeme každou naši konferenci vysílat na samostatném webu, ale spojíme vše na jednom. Aby uživatelé vstupenek Full Pass mohli volně přepínat mezi různými konferencemi: jak živé vysílání, tak záznamy z minulých.
A abychom uživatelům usnadnili navigaci v aktuálním streamu a přepínání mezi skladbami, rozhodli jsme se vytvořit tlačítko „Celé vysílání“ a horizontální vysvědčení pro přepínání mezi skladbami a reporty. K dispozici je ovládání pomocí klávesnice.
— Byly s tím nějaké technické potíže?
Nikolay: Měly posuvník, na kterém byly vyznačeny výchozí body různých zpráv.
— Nakonec, implementovali jste tyto značky na posuvník, než YouTube udělal něco podobného?
Artyom: Tehdy to měli v beta verzi. Zdá se, že se jedná o poměrně složitou funkci, protože ji v posledním roce částečně testovali s uživateli. A nyní se dostal do prodeje.
Nikolay: Ale ve skutečnosti jsme to dostali do prodeje rychleji. Upřímně řečeno, za touto jednoduchou funkcí se uvnitř přehrávače skrývá obrovské množství backendu, frontendu, výpočtů a matematiky.
Frontend
— Pojďme zjistit, jak se tento obsah, který zobrazujeme (řečový lístek, reproduktory, webové stránky, rozvrh), dostane do frontendu?
Vladimír Krasilshchik: Máme několik interních IT systémů. Existuje systém, do kterého se zadávají všechny reporty a všichni řečníci. Existuje proces, při kterém se řečník účastní konference. Řečník podá žádost, systém ji zachytí, pak existuje určitá pipeline, podle které se sestava vytváří.
Takto vidí řečník potrubí
Tento systém je naším vnitřním vývojem.
Dále je potřeba sestavit plán z jednotlivých přehledů. Jak víte, je to NP-těžký problém, ale nějak ho vyřešíme. K tomu spouštíme další komponentu, která vygeneruje rozvrh a nahraje ho do cloudové služby třetí strany Contentful. Tam vše vypadá jako tabulka, ve které jsou dny konference, ve dnech jsou časové úseky a ve slotech jsou zprávy, přestávky nebo sponzorské aktivity. Obsah, který vidíme, se tedy nachází ve službě třetí strany. A úkolem je zprostředkovat to webu.
Zdálo by se, že web je jen stránka s přehrávačem a není zde nic složitého. Až na to, že není. Backend za touto stránkou přejde do Contentful, získá odtud plán, vygeneruje nějaké objekty a odešle ho do frontendu. Pomocí websocketového připojení, které provádí každý klient naší platformy, mu posíláme aktualizaci harmonogramu z backendu na frontend.
Skutečný případ: řečník změnil práci přímo během konference. Musíme změnit jeho firemní odznak zaměstnavatele. Jak se to stane z backendu? Přes websocket je všem klientům zaslána aktualizace a frontend pak sám překreslí časovou osu. To vše se děje bez problémů. Kombinace cloudové služby a několika našich komponent nám dává příležitost generovat veškerý tento obsah a poskytovat jej dopředu.
Nikolay: Zde je důležité upřesnit, že naše stránky nejsou klasickou SPA aplikací. Jedná se o webovou stránku založenou na rozložení a vykreslení a SPA. Google ve skutečnosti vidí tento web jako vykreslený HTML. To je dobré pro SEO a pro poskytování obsahu uživateli. Před zobrazením stránky nečeká na načtení 1,5 MB JavaScriptu, okamžitě vidí již vykreslenou stránku a cítíte to při každém přepnutí sestavy. Vše se děje během půl sekundy, protože obsah je již připraven a umístěn na správném místě.
— Udělejme čáru za vším výše uvedením technologií. Tyoma řekl, že máme 5 streamů Amazonu a dodáváme tam video a zvuk. Máme tam bash skripty, používáme je ke spouštění a konfiguraci...
Artyom: To se děje přes AWS API, tam je mnohem více technických vedlejších služeb. Rozdělili jsme si povinnosti tak, že doručuji do a vývojáři front-endu a back-endu to přebírají odtud. Máme řadu vlastních vazeb pro zjednodušení rozložení obsahu, který pak děláme ve 4K atp. Vzhledem k tomu, že termíny byly velmi krátké, udělali jsme to téměř výhradně na AWS.
— To vše pak jde do přehrávače pomocí backendového systému. V přehrávači máme TypeScript, React, Next.JS. A na backendu máme několik služeb v C#, Java, Spring Boot a Node.js. To vše je nasazeno pomocí Kubernetes pomocí infrastruktury Yandex.Cloud.
Chci také poznamenat, že když jsem se potřeboval seznámit s platformou, ukázalo se to snadné: všechna úložiště jsou na GitLabu, vše je dobře pojmenováno, testy jsou napsány, existuje dokumentace. Čili i v nouzovém režimu se o takové věci starali.
Obchodní omezení a analytika
— Zaměřili jsme se na 10 000 uživatelů na základě obchodních požadavků. Je čas mluvit o obchodních omezeních, která jsme měli. Museli jsme zajistit vysokou pracovní zátěž, zajistit dodržování zákona o uchovávání osobních údajů. A co ještě?
Nikolay: Zpočátku jsme vycházeli z požadavků na video. Nejdůležitější je distribuované video úložiště po celém světě pro rychlé doručení klientovi. Mezi další patří rozlišení 1080p a také přetáčení, které mnoho jiných v živém režimu neimplementuje. Později jsme přidali možnost povolit 2x rychlost, s její pomocí můžete „dohnat“ živě a pokračovat ve sledování konference v reálném čase. A po cestě se objevila funkce označování časové osy. Navíc jsme museli být odolní vůči chybám a vydržet zátěž 10 000 připojení. Z pohledu backendu je to přibližně 10 000 připojení vynásobených 8 požadavky na každé obnovení stránky. A to už je 80 000 RPS/s. Docela málo.
— Byly nějaké další požadavky na „virtuální výstavu“ s online stánky partnerů?
Nikolay: Ano, to muselo být provedeno poměrně rychle a univerzálně. Na každou konferenci jsme měli až 10 partnerských společností a všechny bylo nutné stihnout za týden až dva. Jejich obsah se však mírně liší ve formátu. Byl však vytvořen určitý šablonový engine, který tyto stránky sestavuje za chodu, prakticky bez další účasti na vývoji.
— Existovaly také požadavky na analýzu zobrazení a statistik v reálném čase. Vím, že k tomu používáme Prometheus, ale řekněte nám podrobněji: jaké požadavky na analýzu splňujeme a jak je to implementováno?
Nikolay: Zpočátku máme marketingové požadavky na shromažďování pro A/B testování a shromažďování informací, abychom pochopili, jak v budoucnu správně dodávat nejlepší obsah klientovi. Existují také požadavky na některé analýzy aktivit partnerů a analýzy, které vidíte (počítadlo návštěv). Všechny informace jsou shromažďovány v reálném čase.
Tyto informace můžeme poskytnout v agregované podobě i mluvčím: kolik lidí vás v určitém okamžiku sledovalo. Zároveň v souladu s federálním zákonem 152 nejsou váš osobní účet a osobní údaje žádným způsobem sledovány.
Platforma již má marketingové nástroje a naše metriky pro měření aktivity uživatelů v reálném čase (kdo sledoval jakou sekundu reportu), abychom mohli sestavit grafy návštěvnosti reportů. Na základě těchto dat se dělá výzkum, který udělá příští konference lepší.
Podvod
— Máme mechanismy proti podvodům?
Nikolay: Vzhledem k napjatému časovému rámci z obchodního hlediska nebyl úkol původně nastaven tak, aby okamžitě zablokoval zbytečná připojení. Pokud se dva uživatelé přihlásili pod stejným účtem, mohli si obsah prohlížet. Ale víme, kolik současných zobrazení bylo z jednoho účtu. A zakázali jsme několik zvláště škodlivých porušovatelů.
Vladimir: Ke cti slouží, že jeden ze zakázaných uživatelů pochopil, proč se tak stalo. Přišel, omluvil se a slíbil, že koupí lístek.
— Aby k tomu všemu došlo, musíte kompletně sledovat všechny uživatele od vstupu až po výstup, vždy vědět, co dělají. Jak tento systém funguje?
Vladimir: Chtěl bych mluvit o analytikách a statistikách, které pak analyzujeme pro úspěšnost zprávy nebo je můžeme poskytnout partnerům. Všichni klienti jsou připojeni přes websocket připojení ke konkrétnímu backend clusteru. Stojí tam . Každý klient v každém časovém období posílá, co dělá a jakou stopu sleduje. Poté jsou tyto informace agregovány pomocí rychlých úloh Hazelcast a odeslány zpět každému, kdo tyto stopy sleduje. V rohu vidíme, kolik lidí je teď s námi.
Stejné informace jsou uloženy v a jde do našeho datového jezera, ze kterého máme možnost sestavit zajímavější graf. Nabízí se otázka: kolik unikátních uživatelů vidělo tento přehled? Jdeme do , jsou pingy všech lidí, kteří přišli s id tohoto přehledu. Shromáždili jsme, agregovali jedinečné, a teď tomu rozumíme.
Nikolay: Zároveň ale také přijímáme data v reálném čase od společnosti Prometheus. Je nastaveno proti všem službám Kubernetes, proti samotnému Kubernetes. Shromažďuje úplně všechno a s Grafanou můžeme vytvářet libovolné grafy v reálném čase.
Vladimir: Na jedné straně to stahujeme pro další zpracování OLAP. A pro OLTP to aplikace stáhne celé do Promethea, Grafany a grafy se dokonce sbíhají!
- To je případ, kdy se grafy sbíhají.
Dynamické změny
— Řekněte nám, jak se zavádějí dynamické změny: pokud byla zpráva zrušena 6 minut před začátkem, jaký je řetězec akcí? Které potrubí funguje?
Vladimir: Potrubí je velmi podmíněné. Možností je několik. První je, že program generování rozvrhu fungoval a rozvrh změnil. Upravený rozvrh je nahrán do Contentful. Poté backend pochopí, že pro tuto konferenci v Contentful došlo ke změnám, vezme ji a přestaví ji. Vše se shromažďuje a odesílá přes websocket.
Druhá možnost, kdy se vše děje závratným tempem: editor ručně změní informace v Contentful (odkaz na telegram, prezentaci řečníka atd.) a funguje stejná logika jako poprvé.
Nikolay: Vše se děje bez obnovení stránky. Všechny změny probíhají pro klienta naprosto hladce. Totéž platí pro přepínání sestav. Až přijde čas, zpráva a rozhraní se změní.
Vladimir: Na časové ose jsou také časové limity pro začátek zpráv. Na samém začátku není nic. A pokud najedete myší na červený pruh, pak se v určitém okamžiku díky režisérovi vysílání objeví ořezy. Režisér nastaví správný začátek vysílání, backend tuto změnu zachytí, vypočítá časy začátku a konce prezentací celé skladby v souladu s harmonogramem konference, pošle to našim klientům a hráč vylosuje cutoffy. Nyní může uživatel snadno přejít na začátek a konec sestavy. Byl to přísný obchodní požadavek, velmi pohodlný a užitečný. Neztrácíte čas hledáním skutečného času zahájení sestavy. A až uděláme preview, bude to naprosto úžasné.
Rozvinutí
— Chtěl bych se zeptat na nasazení. Kolja a tým strávili na začátku hodně času nastavením celé infrastruktury, ve které se nám vše odvíjí. Řekni mi, z čeho to všechno je?
Nikolay: Z technického hlediska jsme zpočátku měli požadavek, aby byl produkt co nejabstraktnější od jakéhokoli dodavatele. Přijďte do AWS a vytvořte skripty Terraform konkrétně z AWS, nebo konkrétně z Yandexu, nebo z Azure atd. se opravdu nehodilo. Jednou jsme se museli někam přestěhovat.
První tři týdny jsme neustále hledali způsob, jak to udělat lépe. V důsledku toho jsme dospěli k závěru, že Kubernetes je v tomto případě naše všechno, protože nám umožňuje vytvářet služby s automatickým škálováním, automatické zavádění a téměř všechny služby ihned po vybalení. Všechny služby musely být přirozeně proškoleny pro práci s Kubernetes, Dockerem a tým se musel také naučit.
Máme dva shluky. Test a výroba. Hardwarově i nastavením jsou naprosto totožné. Infrastrukturu implementujeme jako kód. Všechny služby jsou automaticky zaváděny do tří prostředí z funkčních větví, hlavních větví, testovacích větví a GitLab pomocí automatického kanálu. Toto je maximálně integrováno do GitLab, maximálně integrováno s Elastic, Prometheus.
Získáváme možnost rychle (pro backend do 10 minut, pro frontend do 5 minut) zavést změny do libovolného prostředí se všemi testy, integracemi, spouštěním funkčních testů, integračních testů na prostředí a také testovat pomocí zátěžových testů na testovací prostředí přibližně to samé, co chceme získat ve výrobě.
O testech
— Testuješ skoro všechno, je těžké uvěřit, jak jsi všechno napsal. Můžete nám říci o backendových testech: jak moc je vše pokryto, jaké testy?
Vladimir: Byly napsány dva typy testů. První jsou testy součástek. Zkoušky úrovně zdvihu celé pružinové aplikace a základny . Toto je test obchodních scénářů nejvyšší úrovně. Funkce netestuji. Testujeme jen některé velké věci. Například přímo v testu je emulován proces přihlášení uživatele, požadavek uživatele na vstupenky, kam může jít, a požadavek na přístup ke sledování streamu. Velmi jasné uživatelské scénáře.
Přibližně totéž je implementováno v tzv. integračních testech, které skutečně běží na prostředí. Ve skutečnosti, když je spuštěno další nasazení v produkčním prostředí, běží v produkčním prostředí také skutečné základní scénáře. Stejné přihlášení, vyžádání vstupenek, vyžádání přístupu do CloudFront, kontrola, zda se stream skutečně připojuje k mým oprávněním, kontrola rozhraní ředitele.
V tuto chvíli mám na desce asi 70 testů komponent a asi 40 testů integrace. Pokrytí se velmi blíží 95 %. To je pro komponenty, méně pro ty integrační, prostě toho není tolik potřeba. Vzhledem k tomu, že projekt zahrnuje všechny druhy generování kódu, je to velmi dobrý ukazatel. Neexistoval žádný jiný způsob, jak udělat to, co jsme udělali za tři měsíce. Protože kdybychom testovali ručně, dali funkce našemu testerovi a ona by našla chyby a vrátila nám je k opravě, pak by tato zpáteční cesta k ladění kódu byla velmi dlouhá a nedodrželi bychom žádné termíny.
Nikolay: K provedení regrese na celé platformě při změně některé funkce obvykle musíte dva dny sedět a šťourat všude.
Vladimir: Proto je velkým úspěchem, že když odhadnu nějakou funkci, řeknu, že potřebuji 4 dny na dvě jednoduchá pera a 1 websocket, Kolja to umožňuje. Už je zvyklý, že tyto 4 dny zahrnují 2 typy testů a pak to s největší pravděpodobností půjde.
Nikolay: Dále mám napsaných 140 testů: komponentní + funkční, které dělají to samé. Všechny stejné scénáře jsou testovány v produkci, v testu a ve výrobě. Nově jsme také přidali funkční základní testy uživatelského rozhraní. Tímto způsobem pokryjeme nejzákladnější funkce, které se mohou rozpadnout.
Vladimir: Samozřejmě stojí za to mluvit o zátěžových testech. Bylo nutné otestovat platformu pod zátěží blízkou té skutečné, abychom pochopili, jak to všechno je, co se děje s Rabbitem, co se děje s JVM, kolik paměti je vlastně potřeba.
— Nevím jistě, jestli něco testujeme na straně streamu, ale vzpomínám si, že když jsme dělali setkání, byly problémy s transkodéry. Testovali jsme streamy?
Artyom: Testováno iterativně. Pořádání schůzek. V procesu pořádání meetupů bylo přibližně 2300 vstupenek na JIRA. To jsou jen obecné věci, které lidé dělali, aby se setkali. Části platformy jsme přenesli na samostatnou stránku pro meetupy, kterou provozoval Kirill Tolkachev ().
Abych byl upřímný, žádné velké problémy nebyly. Doslova párkrát jsme na CloudFrontu zachytili caching bugs, vyřešili jsme to celkem rychle – jednoduše jsme překonfigurovali zásady. Podstatně více chyb bylo u lidí, ve streamovacích systémech na webu.
Během konferencí jsem musel napsat několik dalších exportérů, abych pokryl více zařízení a služeb. Na některých místech jsem si musel vyrobit vlastní kola jen kvůli metrikám. Svět AV (audio-video) hardwaru není příliš růžový – máte nějaké „API“ zařízení, které prostě nemůžete ovlivnit. A není zdaleka pravda, že budete schopni získat informace, které potřebujete. Dodavatelé hardwaru jsou opravdu pomalí a je téměř nemožné od nich získat to, co chcete. Celkem jde o více než 100 kusů hardwaru, nevrátí vám to, co potřebujete, a vy píšete podivné a nadbytečné exportéry, díky kterým můžete systém alespoň nějak odladit.
Оборудование
— Pamatuji si, jak jsme před začátkem konferencí částečně dokupovali další vybavení.
Artyom: Nakoupili jsme počítače, notebooky a baterie. V tuto chvíli můžeme žít bez elektřiny 40 minut. V červnu byly v Petrohradu silné bouřky - takže jsme měli takový výpadek proudu. Zároveň k nám přichází několik poskytovatelů s optickými spoji z různých míst. Jedná se skutečně o 40 minut stavební prostoje, během kterých nám budou fungovat světla, zvuk, kamery atd.
— Máme podobný příběh s internetem. V kanceláři, kde sídlí naše ateliéry, jsme táhli mezi patry divokou síť.
Artyom: Mezi patry máme 20 Gbit vlákna. Dále po patrech, někde je optika, někde není optika, ale stále je tam méně kanálů než gigabitových - mezi stopami konference na nich spouštíme video. Obecně je velmi výhodné pracovat na vlastní infrastruktuře, na offline konferencích na stránkách to můžete udělat jen zřídka.
— Než jsem pracoval v JUG Ru Group, viděl jsem, jak se přes noc zřizovaly hardwarové místnosti na offline konferencích, kde byl velký monitor se všemi metrikami, které si v Grafaně postavíte. Nyní je zde také centrála, ve které sedí vývojový tým, který během konference opravuje některé chyby a vyvíjí funkce. Zároveň je zde monitorovací systém, který se zobrazuje na velké obrazovce. Artyom, Kolja a další kluci sedí a dávají pozor, aby to všechno nespadlo a fungovalo krásně.
Kuriozity a problémy
— Dobře jste mluvili o tom, že máme streamování s Amazonem, existuje přehrávač s webem, vše je napsáno v různých programovacích jazycích, je zajištěna odolnost proti chybám a další obchodní požadavky, včetně osobního účtu, který je podporován pro právnické osoby a jednotlivci, a můžeme se integrovat s někým pomocí OAuth 2.0, existuje ochrana proti podvodům a blokování uživatelů. Změny můžeme zavádět dynamicky, protože jsme to udělali dobře a vše je otestováno.
Zajímalo by mě, jaké podivnosti se týkaly zahájení něčeho. Nastaly nějaké zvláštní situace, kdy jste vyvíjeli backend, frontend, stalo se něco šíleného a vy jste nechápali, co s tím?
Vladimir: Zdá se mi, že se to stalo jen poslední tři měsíce. Každý den. Jak vidíte, mám vytrhané všechny vlasy.
Vladimir Krasilshchik po 3 měsících, kdy se objevila nějaká hra a nikdo nechápal, co s tím
Každý den bylo něco takového, kdy nastala taková chvíle, kdy si to vezmete a trháte si vlasy, nebo si uvědomíte, že nikdo jiný není a jen vy to dokážete. Naší první velkou akcí byl TechTrain. 6. června ve 2:2.0 jsme ještě nespustili produkční prostředí, rozjížděl ho Kolja. A osobní účet nefungoval jako autorizační server pomocí OAuth2.0. Udělali jsme z něj poskytovatele OAuth18, abychom k němu připojili platformu. Pracoval jsem asi XNUMX hodin v kuse, podíval jsem se na počítač a nic jsem neviděl, nechápal jsem, proč to nefunguje, a Kolja se na dálku podíval na můj kód, hledal chybu v konfiguraci Spring , našel to a LC fungovalo a také ve výrobě.
Nikolay: A hodinu před TechTrain došlo k vydání.
Bylo zde seřazeno mnoho hvězd. Měli jsme obrovské štěstí, protože jsme měli super tým a všichni byli inspirováni myšlenkou udělat to online. Celé ty tři měsíce nás hnala skutečnost, že jsme „udělali YouTube“. Nedovolil jsem si rvát si vlasy, ale řekl jsem všem, že všechno bude fungovat, protože ve skutečnosti bylo všechno dávno spočítáno.
O výkonu
— Můžete mi říct, kolik lidí bylo na stránce na jedné stopě? Vyskytly se nějaké problémy s výkonem?
Nikolay: Jak jsme již řekli, nebyly žádné problémy s výkonem. Maximální počet lidí, kteří se zúčastnili jedné zprávy, byl 1300 lidí, toto je na Heisenbug.
— Vyskytly se nějaké problémy s místním sledováním? A je možné mít technický popis se schématy, jak to celé funguje?
Nikolay: Později o tom uděláme článek.
Můžete dokonce ladit proudy lokálně. Jakmile konference začaly, bylo to ještě jednodušší, protože se objevily produkční streamy, které můžeme sledovat neustále.
Vladimir: Pokud tomu rozumím, front-endoví vývojáři pracovali lokálně s maketami, a protože čas na zavedení vývojářům vpředu je také krátký (5 minut), nejsou žádné problémy s kontrolou toho, co se s certifikáty děje.
— Vše je testováno a odladěno, dokonce i lokálně. To znamená, že napíšeme článek se všemi technickými funkcemi, ukážeme vám, vše vám povíme s diagramy, jak to bylo.
Vladimir: Můžete to vzít a zopakovat.
- Za 3 měsíce.
Celkový
— Všechno popsané dohromady zní cool, vezmeme-li v úvahu, že to udělal malý tým za tři měsíce.
Nikolay: Velký tým by tohle neudělal. Ale malá skupina lidí, kteří spolu docela úzce a dobře komunikují a dokážou se dohodnout, by mohla. Nemají žádné rozpory, architektura byla vymyšlena za dva dny, byla dokončena a vlastně se nezměnila. Existuje velmi přísné usnadnění příchozích obchodních požadavků, pokud jde o hromadění požadavků na funkce a změn.
— Co bylo na vašem seznamu dalších úkolů, když už proběhly letní konference?
Nikolay: Například kredity. Plíživé čáry ve videu, vyskakovací okna na některých místech ve videu v závislosti na zobrazovaném obsahu. Řečník chce například položit otázku publiku a na obrazovce se objeví hlasování, které se na základě výsledků hlasování vrátí zpět k samotnému řečníkovi. Nějaká společenská aktivita v podobě lajků, srdíček, hodnocení zprávy během samotné prezentace, abyste mohli vyplnit zpětnou vazbu ve správnou chvíli, aniž byste byli později rozptylováni formuláři zpětné vazby. Zpočátku takto.
A také přidání do celé platformy, kromě streamování a konference, také stav po konferenci. Jedná se o seznamy skladeb (včetně seznamů sestavených uživateli), případně obsah z jiných minulých konferencí, integrovaný, označený, přístupný uživateli a také dostupný k prohlížení na našich webových stránkách ().
— Kluci, moc vám děkuji za odpovědi!
Pokud jsou mezi čtenáři tací, kteří se zúčastnili našich letních konferencí, podělte se prosím o své dojmy z přehrávače a vysílání. Co vám vyhovovalo, co vás rozčilovalo, co byste rádi viděli v budoucnu?
Pokud vás platforma zaujala a chcete ji vidět „v bitvě“, používáme ji znovu na naší . Existuje jich celá řada, takže se téměř jistě najde ten, který je pro vás ten pravý.
Zdroj: www.habr.com