I våras befann vi oss i mycket glada förhållanden. På grund av pandemin blev det klart att våra sommarkonferenser behövde flyttas online. Och för att kunna genomföra dem online på ett effektivt sätt var färdiga mjukvarulösningar inte lämpliga för oss, vi behövde skriva våra egna. Och vi hade tre månader på oss att göra det här.

Det är klart att det har varit tre spännande månader. Men utifrån är det inte helt självklart: vad är en onlinekonferensplattform? Vilka delar består den av? Därför frågade jag vid den sista av sommarens DevOops-konferenser de som var ansvariga för denna uppgift:

• Nikolay Molchanov - teknisk chef för JUG Ru Group;
• Vladimir Krasilshchik är en pragmatisk Java-programmerare som arbetar på backend (du kan också se hans rapporter på våra Java-konferenser);
• Artyom Nikonov är ansvarig för all vår videoströmning.

Förresten, på höst-vinterkonferenserna kommer vi att använda en förbättrad version av samma plattform - så många habra-läsare kommer fortfarande att vara dess användare.

Hela bilden

— Hur var lagets sammansättning?

Nikolay Molchanov: Vi har en analytiker, en designer, en testare, tre frontendare och en back-end. Och, naturligtvis, en T-formad specialist!

— Hur såg processen ut generellt?

Nikolai: Fram till mitten av mars hade vi ingenting klart för online alls. Och den 15 mars började hela onlinekarusellen snurra. Vi satte upp flera förvar, planerade, diskuterade grundarkitekturen och gjorde allt på tre månader.

Detta gick naturligtvis igenom de klassiska stadierna av planering, arkitektur, funktionsval, röstning för dessa funktioner, policy för dessa funktioner, deras design, utveckling, testning. Som ett resultat rullade vi ut allt till produktion den 6 juni. TechTrain. Det fanns 90 dagar för allt.

— Lyckades vi genomföra det vi åtagit oss?

Nikolai: Eftersom vi nu deltar i DevOops-konferensen online betyder det att det fungerade. Jag har personligen engagerat mig i huvudsaken: Jag kommer att ge kunderna ett verktyg som de kan göra en onlinekonferens med.

Utmaningen var denna: ge oss ett verktyg med vilket vi kan sända våra konferenser till biljettinnehavare.

All planering var uppdelad i flera steg, och alla funktioner (cirka 30 globala) delades in i fyra kategorier:

• vilket vi definitivt kommer att göra (vi kan inte leva utan dem),
• vilket vi kommer att göra för det andra,
• vilket vi aldrig kommer att göra,
• och som vi aldrig någonsin kommer att göra.

Vi gjorde alla funktioner från de två första kategorierna.

— Jag vet att totalt 600 JIRA-nummer skapades. På tre månader skapade du 13 mikrotjänster, och jag misstänker att de inte bara skrevs i Java. Du använde olika tekniker, du har två Kubernetes-kluster i tre tillgänglighetszoner och 5 RTMP-strömmar i Amazon.

Låt oss nu titta på varje komponent i systemet separat.

Strömning

— Låt oss börja med när vi redan har en videobild, och den överförs till vissa tjänster. Artyom, berätta hur den här streamingen går till?

Artyom Nikonov: Vårt allmänna schema ser ut så här: bild från kameran -> vårt kontrollrum -> lokal RTMP-server -> Amazon -> videospelare. Fler detaljer skrev om det på Habré i juni.

I allmänhet finns det två globala sätt att göra detta: antingen på hårdvara eller baserade på mjukvarulösningar. Vi valde mjukvaruvägen eftersom det är lättare när det gäller fjärrhögtalare. Det är inte alltid möjligt att ta med hårdvara till en högtalare i ett annat land, men att leverera mjukvara till högtalaren verkar enklare och mer tillförlitligt.

Ur hårdvarusynpunkt har vi ett visst antal kameror (i våra studior och vid fjärrhögtalare), ett visst antal fjärrkontroller i studion, som ibland måste repareras precis under bordet under sändningen.

Signaler från dessa enheter kommer in i datorer med inspelningskort, in-/utgångskort och ljudkort. Där blandas signalerna och sätts ihop till layouter:

Exempel på layout för 4 högtalare

Exempel på layout för 4 högtalare

Vidare tillhandahålls kontinuerlig sändning med hjälp av tre datorer: det finns en huvudmaskin och ett par fungerande i tur och ordning. Den första datorn samlar in den första rapporten, den andra - pausen, den första - nästa rapport, den andra - nästa paus och så vidare. Och huvudmaskinen blandar den första med den andra.

Detta skapar en sorts triangel, och om någon av dessa noder misslyckas kan vi snabbt och utan kvalitetsförlust fortsätta att leverera innehåll till kunderna. Vi hade en sådan situation. Under den första konferensveckan fixade vi en maskin, slog på/av den. Folk verkar vara nöjda med vår motståndskraft.

Därefter går strömmarna från datorerna till en lokal server, som har två uppgifter: dirigera RTMP-strömmar och spela in säkerhetskopior. Så vi har flera inspelningspunkter. Videoströmmarna skickas sedan till den del av vårt system som bygger på Amazon SaaS-tjänster. Vi använder MediaLive:,S3, CloudFront.

Nikolai: Vad händer där innan videon når publiken? Du måste klippa den på något sätt, eller hur?

Artyom: Vi komprimerar videon från vår sida och skickar den till MediaLive. Vi lanserar omkodare där. De omkodar videor i realtid till flera upplösningar så att folk kan titta på dem på sina telefoner, via dåligt internet i landet och så vidare. Sedan skärs dessa bäckar i bitar, så här fungerar protokollet HLS. Vi skickar en spellista till frontend som innehåller pekare till dessa bitar.

— Använder vi 1080p-upplösning?

Artyom: Bredden på vår video är densamma som 1080p - 1920 pixlar, och höjden är lite mindre, bilden är mer långsträckt - det finns anledningar till detta.

Spelare

— Artyom beskrev hur videon kommer in i streams, hur den distribueras i olika spellistor för olika skärmupplösningar, skärs i bitar och kommer in i spelaren. Kolya, berätta nu för mig vilken typ av spelare det här är, hur den förbrukar strömmen, varför HLS?

Nikolai: Vi har en spelare som alla konferenstittare kan titta på.

I huvudsak är detta ett omslag runt biblioteket hls.js, som många andra spelare är skrivna på. Men vi behövde mycket specifik funktionalitet: spola tillbaka och markera platsen där personen är, vilken rapport han tittar på just nu. Vi behövde även egna layouter, alla möjliga logotyper och allt annat som byggdes in hos oss. Därför bestämde vi oss för att skriva vårt eget bibliotek (ett omslag över HLS) och bädda in det på sajten.

Detta är rotfunktionen, så den implementerades nästan först. Och sedan växte allt runt det.

Faktum är att genom auktorisering får spelaren från backend en spellista med länkar till bitar som är korrelerade med tid och kvalitet, laddar ner de nödvändiga och visar dem för användaren och utför lite "magi" längs vägen.

Exempel på tidslinje

— En knapp är inbyggd direkt i spelaren för att visa en tidslinje över alla rapporter...

Nikolai: Ja, vi löste omedelbart problemet med användarnavigering. I mitten av april beslutade vi att vi inte skulle sända var och en av våra konferenser på en separat webbplats, utan skulle kombinera allt på en. Så att användare av Full Pass-biljett fritt kan växla mellan olika konferenser: både livesändningar och inspelningar av tidigare.

Och för att göra det enklare för användare att navigera i den aktuella strömmen och växla mellan spår, bestämde vi oss för att skapa en "Hel sändning"-knapp och horisontella rapportkort för att växla mellan spår och rapporter. Det finns tangentbordskontroll.

— Fanns det några tekniska problem med detta?

Nikolai: De hade en rullningslist där startpunkterna för olika rapporter var markerade.

— Till slut, implementerade du dessa märken på rullningslisten innan YouTube gjorde något liknande?

Artyom: De hade den i beta då. Det verkar som att det här är en ganska komplex funktion eftersom de delvis har testat det med användare under det senaste året. Och nu har den nått försäljning.

Nikolai: Men vi fick den till försäljning snabbare. Ärligt talat, bakom denna enkla funktion finns det en enorm mängd backend, frontend, beräkningar och matematik inuti spelaren.

Frontend

— Låt oss ta reda på hur det här innehållet som vi visar (talkort, talare, webbplats, schema) kommer till fronten?

Vladimir Krasilshchik: Vi har flera interna IT-system. Det finns ett system där alla rapporter och alla talare läggs in. Det finns en process genom vilken en talare deltar i en konferens. Talaren skickar in en ansökan, systemet fångar upp den, sedan finns det en viss pipeline enligt vilken rapporten skapas.

Det är så talaren ser rörledningen

Detta system är vår interna utveckling.

Därefter måste du bygga ett schema från individuella rapporter. Som ni vet är detta ett NP-hårt problem, men vi löser det på något sätt. För att göra detta lanserar vi ytterligare en komponent som genererar ett schema och laddar upp det till tredjepartsmolntjänsten Contentful. Där ser allt ut som ett bord där det finns konferensdagar, på dagarna finns det tidluckor och i luckorna finns rapporter, pauser eller sponsringsaktiviteter. Så innehållet vi ser finns i en tredjepartstjänst. Och uppgiften är att förmedla det till sajten.

Det verkar som att sidan bara är en sida med en spelare, och det är inget komplicerat här. Förutom att det inte är det. Backend bakom denna sida går till Contentful, hämtar schemat därifrån, genererar några objekt och skickar det till frontend. Med hjälp av en websocket-anslutning, som varje klient på vår plattform gör, skickar vi honom en uppdatering av schemat från backend till frontend.

Verkligt fall: talaren bytte jobb direkt under konferensen. Vi måste byta hans arbetsgivarföretagsmärke. Hur sker detta från backend? En uppdatering skickas till alla klienter via websocket, och sedan ritar frontend själv om tidslinjen. Allt detta sker sömlöst. Kombinationen av molntjänsten och flera av våra komponenter ger oss möjlighet att generera allt detta innehåll och tillhandahålla det till fronten.

Nikolai: Det är viktigt att förtydliga här att vår sida inte är en klassisk SPA-applikation. Detta är både en layoutbaserad, renderad webbplats och ett SPA. Google ser faktiskt den här webbplatsen som renderad HTML. Detta är bra för SEO och för att leverera innehåll till användaren. Den väntar inte på att 1,5 megabyte JavaScript ska laddas innan den ser sidan, den ser omedelbart den redan renderade sidan, och du känner det varje gång du byter rapport. Allt händer på en halv sekund, eftersom innehållet redan är klart och publicerat på rätt plats.

— Låt oss dra en linje under allt ovan genom att lista teknikerna. Tyoma sa att vi har 5 Amazon-strömmar och vi levererar video och ljud där. Vi har bash-skript där, vi använder dem för att starta och konfigurera...

Artyom: Detta sker genom AWS API, det finns många fler tekniska sidotjänster där. Vi delade upp vårt ansvar så att jag levererar till Cloudfront, och front-end- och back-end-utvecklare tar det därifrån. Vi har ett antal egna bindningar för att förenkla layouten av innehåll som vi sedan gör i 4K osv. Eftersom tidsfristerna var väldigt snäva gjorde vi det nästan helt på AWS.

— Sedan går allt detta in i spelaren med hjälp av backend-systemet. Vi har TypeScript, React, Next.JS i vår spelare. Och på backend har vi flera tjänster i C#, Java, Spring Boot och Node.js. Allt detta distribueras med Kubernetes med Yandex.Cloud-infrastrukturen.

Jag vill också notera att när jag behövde bekanta mig med plattformen visade det sig vara lätt: alla förråd finns på GitLab, allt är väl namngivet, tester är skrivna, det finns dokumentation. Det vill säga att även i akutläge tog man hand om sådant.

Affärsbegränsningar och analys

— Vi riktade in oss på 10 000 användare baserat på affärskrav. Det är dags att prata om affärsrestriktioner som vi hade. Vi var tvungna att säkerställa en hög arbetsbelastning, säkerställa efterlevnad av lagen om bevarande av personuppgifter. Och vad mer?

Nikolai: Till en början utgick vi från videokrav. Det viktigaste är distribuerad videolagring runt om i världen för snabb leverans till klienten. Andra inkluderar 1080p-upplösning, samt spola tillbaka, som många andra inte implementerar i live-läge. Senare lade vi till möjligheten att aktivera 2x hastighet, med dess hjälp kan du "komma ikapp" med live och fortsätta att titta på konferensen i realtid. Och längs vägen dök funktionalitet för tidslinjemarkering upp. Dessutom var vi tvungna att vara feltoleranta och tåla belastningen av 10 000 anslutningar. Ur backend-synpunkt är detta cirka 10 000 anslutningar multiplicerat med 8 förfrågningar för varje siduppdatering. Och detta är redan 80 000 RPS/sek. Ganska lite av.

— Fanns det några andra krav på en "virtuell utställning" med partnermontrar online?

Nikolai: Ja, detta måste göras ganska snabbt och allmänt. Vi hade upp till 10 partnerföretag för varje konferens, och alla måste genomföras på en eller två veckor. Deras innehåll skiljer sig dock något åt ​​i format. Men en viss mallmotor gjordes som sätter ihop dessa sidor i farten, med praktiskt taget inget vidare utvecklingsdeltagande.

— Det fanns också krav på analyser av realtidsvyer och statistik. Jag vet att vi använder Prometheus för detta, men berätta mer detaljerat: vilka krav uppfyller vi för analys och hur implementeras detta?

Nikolai: Inledningsvis har vi marknadsföringskrav för att samla in för A/B-tester och samla in information för att förstå hur man korrekt levererar det bästa innehållet till kunden i framtiden. Det finns också krav på vissa analyser på partneraktiviteter och de analyser som du ser (besöksdisk). All information samlas in i realtid.

Vi kan tillhandahålla denna information i aggregerad form även till talare: hur många personer som tittade på dig vid en viss tidpunkt. Samtidigt, för att följa federal lag 152, spåras inte ditt personliga konto och dina personuppgifter på något sätt.

Plattformen har redan marknadsföringsverktyg och våra mätvärden för att mäta användaraktivitet i realtid (vem såg vilken sekund av rapporten) för att kunna bygga grafer över närvaro vid rapporterna. Baserat på dessa data pågår forskning som kommer att göra kommande konferenser bättre.

Bedrägeri

— Har vi bedrägeribekämpningsmekanismer?

Nikolai: På grund av den snäva tidsramen ur affärssynpunkt var uppgiften initialt inte inställd på att omedelbart blockera onödiga anslutningar. Om två användare loggade in under samma konto kunde de se innehållet. Men vi vet hur många visningar det var samtidigt från ett konto. Och vi förbjöd flera särskilt illvilliga överträdare.

Vladimir: Till dess förtjänst förstod en av de förbjudna användarna varför detta hände. Han kom, bad om ursäkt och lovade att köpa en biljett.

— För att allt detta ska hända måste du helt spåra alla användare från ingång till utgång, alltid veta vad de gör. Hur fungerar detta system?

Vladimir: Jag skulle vilja prata om analyser och statistik, som vi sedan analyserar för rapportens framgång eller sedan kan tillhandahålla partners. Alla klienter är anslutna via en websocket-anslutning till ett specifikt backend-kluster. Den står där Hasselcast. Varje klient vid varje tidsperiod skickar vad han gör och vilket spår han tittar på. Sedan sammanställs denna information med hjälp av snabba Hazelcast-jobb och skickas tillbaka till alla som tittar på dessa spår. Vi ser i hörnet hur många som nu är med oss.

Samma information lagras i mongo och går till vår datasjö, från vilken vi har möjlighet att bygga en mer intressant graf. Frågan uppstår: hur många unika användare såg den här rapporten? Vi går till postgres, det finns pingar från alla personer som kom med id:t för denna rapport. Vi samlade in unika, och nu kan vi förstå.

Nikolai: Men samtidigt får vi även realtidsdata från Prometheus. Den ställs mot alla Kubernetes-tjänster, mot Kubernetes själv. Den samlar in absolut allt, och med Grafana kan vi bygga vilka grafer som helst i realtid.

Vladimir: Å ena sidan laddar vi ner detta för vidare OLAP-bearbetning. Och för OLTP laddar applikationen ner det hela till Prometheus, Grafana och graferna konvergerar till och med!

– Så är fallet när graferna konvergerar.

Dynamiska förändringar

— Berätta för oss hur dynamiska förändringar rullas ut: om rapporten avbröts 6 minuter före start, vad är kedjan av åtgärder? Vilken pipeline fungerar?

Vladimir: Rörledningen är mycket villkorad. Det finns flera möjligheter. Den första är att schemagenereringsprogrammet fungerade och ändrade schemat. Det ändrade schemat laddas upp till Contentful. Därefter förstår backend att det finns förändringar för denna konferens i Contentful, tar den och bygger om den. Allt samlas in och skickas via websocket.

Den andra möjligheten, när allt händer i en rasande takt: redaktören ändrar informationen manuellt i Contentful (länk till Telegram, talarens presentation, etc.) och samma logik fungerar som första gången.

Nikolai: Allt sker utan att sidan uppdateras. Alla förändringar sker helt sömlöst för kunden. Detsamma gäller för att byta rapporter. När det är dags ändras rapporten och gränssnittet.

Vladimir: Det finns också tidsgränser för starten av rapporter i tidslinjen. I början finns det ingenting. Och om du för musen över den röda randen, kommer vid något tillfälle, tack vare sändningsdirektören, cutoffs att dyka upp. Regissören ställer in rätt start på sändningen, backend tar upp denna förändring, beräknar start- och sluttider för hela spårets presentationer i enlighet med konferensschemat, skickar det till våra kunder och spelaren drar cutoffs. Nu kan användaren enkelt navigera till början och slutet av rapporten. Det var ett strikt affärskrav, mycket bekvämt och användbart. Du slösar inte tid på att hitta den faktiska starttiden för rapporten. Och när vi gör en förhandsvisning blir det helt underbart.

Spridning

— Jag skulle vilja fråga om utplacering. Kolya och teamet tillbringade mycket tid i början på att sätta upp hela infrastrukturen där allt utvecklas för oss. Säg mig, vad är allt gjort av?

Nikolai: Ur teknisk synvinkel hade vi initialt ett krav på att produkten skulle vara så abstrakt som möjligt från vilken leverantör som helst. Kom till AWS för att skapa Terraform-skript specifikt från AWS, eller specifikt från Yandex, eller från Azure, etc. passade inte riktigt. Vi var tvungna att flytta någonstans någon gång.

Under de första tre veckorna letade vi ständigt efter ett sätt att göra detta bättre. Som ett resultat kom vi till slutsatsen att Kubernetes i det här fallet är vårt allt, eftersom det tillåter oss att skapa automatiskt skalningstjänster, automatisk utrullning och få nästan alla tjänster ur lådan. Naturligtvis måste alla tjänster tränas för att fungera med Kubernetes, Docker, och teamet måste också lära sig.

Vi har två kluster. Test och produktion. De är helt identiska vad gäller hårdvara och inställningar. Vi implementerar infrastruktur som kod. Alla tjänster rullas automatiskt ut i tre miljöer från funktionsgrenar, mastergrenar, testgrenar och GitLab med hjälp av en automatisk pipeline. Detta är maximalt integrerat i GitLab, maximalt integrerat med Elastic, Prometheus.

Vi får möjlighet att snabbt (för backend inom 10 minuter, för frontend inom 5 minuter) rulla ut ändringar till valfri miljö med alla tester, integrationer, köra funktionstester, integrationstester på miljön, och även testa med belastningstester på en testmiljö ungefär samma sak som vi vill få i produktion.

Om tester

— Du testar nästan allt, det är svårt att tro hur du skrev allt. Kan du berätta om backend-testerna: hur mycket allt täcks, vilka tester?

Vladimir: Två typer av prov har skrivits. Det första är komponenttester. Lyftnivåtest av hela fjäderapplikationen och bas in Testbehållare. Detta är ett test av affärsscenarier på högsta nivå. Jag testar inte funktioner. Vi testar bara några stora saker. Till exempel, direkt i testet, emuleras processen att logga in på en användare, användarens begäran om biljetter dit han kan åka och en begäran om åtkomst att titta på streamen. Mycket tydliga användarscenarier.

Ungefär samma sak implementeras i de så kallade integrationstesterna, som faktiskt körs på miljön. Faktum är att när nästa driftsättning i produktionen rullas ut, körs också riktiga grundscenarier i produktionen. Samma inloggning, begära biljetter, begära åtkomst till CloudFront, kontrollera att strömmen verkligen ansluter till mina behörigheter, kontrollera regissörens gränssnitt.

För tillfället har jag ett 70-tal komponenttester och ett 40-tal integrationstester ombord. Täckningen är mycket nära 95 %. Det här är för komponenter, mindre för integration, det behövs helt enkelt inte så mycket. Med tanke på att projektet involverar alla typer av kodgenerering är detta en mycket bra indikator. Det fanns inget annat sätt att göra det vi gjorde på tre månader. För om vi testade manuellt, gav funktioner till vår testare, och hon skulle hitta buggar och skicka tillbaka dem till oss för korrigeringar, då skulle denna rundresa för att felsöka koden bli väldigt lång och vi skulle inte hålla några deadlines.

Nikolai: Konventionellt, för att utföra en regression på hela plattformen när du byter någon funktion, måste du sitta och peta överallt i två dagar.

Vladimir: Därför är det en stor framgång att när jag uppskattar en funktion säger jag att jag behöver 4 dagar för två enkla pennor och 1 websocket, Kolya tillåter det. Han är redan van vid det faktum att dessa 4 dagar inkluderar 2 typer av tester, och då kommer det troligen att fungera.

Nikolai: Jag har också skrivit 140 test: komponent + funktionell, som gör samma sak. Alla samma scenarier testas i produktion, i test och i produktion. Vi har också nyligen lagt till funktionella grundläggande UI-tester. På så sätt täcker vi den mest grundläggande funktionaliteten som kan falla isär.

Vladimir: Naturligtvis är det värt att prata om belastningstester. Det var nödvändigt att testa plattformen under en belastning nära den verkliga för att förstå hur allt är, vad som händer med Rabbit, vad som händer med JVM:erna, hur mycket minne som faktiskt behövs.

— Jag vet inte säkert om vi testar något på streamsidan, men jag minns att det var problem med omkodare när vi gjorde meetups. Har vi testat strömmarna?

Artyom: Testade iterativt. Organisera möten. I processen med att organisera möten fanns det cirka 2300 XNUMX JIRA-biljetter. Det här är bara generiska saker som folk gjorde för att träffas. Vi tog delar av plattformen till en separat sida för möten, som drevs av Kirill Tolkachev (talkkv).

För att vara ärlig så var det inga stora problem. Bokstavligen ett par gånger fångade vi cachingbuggar på CloudFront, vi löste det ganska snabbt - vi konfigurerade helt enkelt om policyerna. Det fanns betydligt fler buggar hos människor, i streamingsystemen på sajten.

Under konferenserna var jag tvungen att skriva flera exportörer för att täcka mer utrustning och tjänster. På vissa ställen var jag tvungen att tillverka mina egna cyklar bara för måttens skull. Världen av AV (audio-video) hårdvara är inte särskilt rosa - du har någon form av "API" av utrustning som du helt enkelt inte kan påverka. Och det är långt ifrån ett faktum att du kommer att kunna få den information du behöver. Hårdvaruleverantörer är väldigt långsamma och det är nästan omöjligt att få det du vill ha från dem. Totalt finns det mer än 100 hårdvara, de ger inte tillbaka det du behöver, och du skriver konstiga och överflödiga exportörer, tack vare vilka du åtminstone på något sätt kan felsöka systemet.

Оборудование

— Jag minns hur vi inför konferensstarten delvis köpte ytterligare utrustning.

Artyom: Vi köpte datorer, bärbara datorer och batteripaket. För tillfället kan vi leva utan el i 40 minuter. I juni var det kraftiga åskväder i St Petersburg - så vi hade ett sådant blackout. Samtidigt kommer flera leverantörer till oss med optiska länkar från olika håll. Det här är verkligen 40 minuters driftstopp, under vilken vi kommer att ha ljus, ljud, kameror etc. som fungerar.

— Vi har en liknande historia med Internet. På kontoret där våra ateljéer ligger släpade vi ett häftigt nät mellan våningarna.

Artyom: Vi har 20 Gbit fiber mellan våningarna. Längre längs våningarna, någonstans finns det optik, någonstans finns det ingen optik, men ändå finns det färre kanaler än gigabit-kanaler - vi kör video på dem mellan spåren av konferensen. I allmänhet är det väldigt bekvämt att arbeta med din egen infrastruktur, du kan sällan göra detta vid offlinekonferenser på webbplatser.

— Innan jag jobbade på JUG Ru Group såg jag hur hårdvarurum vid offlinekonferenser sattes upp över en natt, där det fanns en stor bildskärm med alla mätvärden som man bygger i Grafana. Nu finns det även ett huvudkontorsrum där utvecklingsteamet sitter, som under konferensen fixar en del buggar och utvecklar funktioner. Samtidigt finns ett övervakningssystem som visas på en stor skärm. Artyom, Kolya och andra killar sitter och ser till att allt inte faller och fungerar vackert.

Kuriosa och problem

— Du pratade väl om att vi har streaming med Amazon, det finns en spelare med webben, allt är skrivet på olika programmeringsspråk, feltolerans och andra affärskrav tillhandahålls, inklusive ett personligt konto som stöds för juridiska personer och individer, och vi kan integrera med någon som använder OAuth 2.0, finns det anti-bedrägeri, användarblockering. Vi kan rulla ut förändringar dynamiskt eftersom vi gjorde det bra, och allt är testat.

Jag är intresserad av att veta vilka konstigheter som var inblandade i att få igång något. Har det varit några konstiga situationer när du utvecklade en backend, frontend, något galet visade sig och du inte förstod vad du skulle göra med det?

Vladimir: Det verkar för mig att detta bara har hänt de senaste tre månaderna. Varje dag. Som ni ser har allt mitt hår dragits ut.

Vladimir Krasilshchik efter 3 månader, när något slags spel visade sig och ingen förstod vad han skulle göra med det

Varje dag var det något sånt här, när det fanns ett sådant ögonblick när du tar det och sliter av dig håret, eller inser att det inte finns någon annan, och bara du kan göra det. Vårt första stora event var TechTrain. Den 6 juni klockan 2:2.0 hade vi ännu inte rullat ut produktionsmiljön, Kolya rullade ut den. Och det personliga kontot fungerade inte som en auktoriseringsserver med OAuth2.0. Vi förvandlade den till en OAuth18-leverantör för att ansluta plattformen till den. Jag hade jobbat i säkert XNUMX timmar i sträck, jag tittade på datorn och såg ingenting, jag förstod inte varför den inte fungerade, och Kolya tittade på min kod på distans, letade efter en bugg i vårkonfigurationen , hittade den, och LC fungerade, och i produktion också.

Nikolai: Och en timme innan TechTrain släpptes.

Många stjärnor var i linje här. Vi hade oerhört tur eftersom vi hade ett superteam och alla blev inspirerade av idén att göra det online. Alla dessa tre månader drevs vi av det faktum att vi "gjorde YouTube". Jag tillät mig inte slita mig i håret utan sa till alla att allt skulle ordna sig, för i själva verket hade allt beräknats för länge sedan.

Om prestanda

— Kan du berätta för mig hur många personer som var på platsen på ett spår? Fanns det några prestandaproblem?

Nikolai: Det var inga prestandaproblem, som vi redan sa. Det maximala antalet personer som deltog i en rapport var 1300 personer, detta finns på Heisenbug.

— Fanns det några problem med lokal visning? Och är det möjligt att ha en teknisk beskrivning med diagram över hur det hela fungerar?

Nikolai: Vi kommer att göra en artikel om detta senare.

Du kan till och med felsöka strömmar lokalt. När konferenserna väl startade blev det ännu enklare, eftersom det dök upp produktionsströmmar som vi kan titta på hela tiden.

Vladimir: Som jag förstår det arbetade front-end-utvecklare lokalt med mockar, och sedan, eftersom tiden att rulla ut till utvecklarna i fronten också är kort (5 minuter), finns det inga problem med att kontrollera vad som händer med certifikaten.

— Allt testas och felsöks, även lokalt. Det betyder att vi kommer att skriva en artikel med alla tekniska funktioner, visa dig, berätta allt med diagram, hur det var.

Vladimir: Du kan ta det och upprepa det.

- Om 3 månader.

Totalt

— Allt som beskrivs tillsammans låter coolt med tanke på att det gjordes av ett litet team på tre månader.

Nikolai: Ett stort lag skulle inte göra det här. Men en liten grupp människor som kommunicerar ganska nära och bra med varandra och kan komma överens skulle kunna. De har inga motsägelser, arkitekturen uppfanns på två dagar, färdigställdes och har faktiskt inte förändrats. Det finns en mycket strikt förenkling av inkommande affärskrav när det gäller att samla upp funktionsförfrågningar och ändringar.

— Vad stod på din lista över ytterligare uppgifter när sommarkonferenserna redan hade ägt rum?

Nikolai: Till exempel krediter. Krypande linjer på videon, popup-fönster på vissa ställen i videon beroende på innehållet som visas. Till exempel vill talaren ställa en fråga till publiken, och en röst dyker upp på skärmen, som går tillbaka till baksidan baserat på röstningsresultatet till talaren själv. Någon form av social aktivitet i form av likes, hjärtan, betyg av rapporten under själva presentationen, så att du kan fylla i feedback i rätt ögonblick utan att bli distraherad senare av feedbackformulär. Till en början så här.

Och lägga till hela plattformen, förutom streaming och konferens, även ett tillstånd efter konferensen. Dessa är spellistor (inklusive de som sammanställts av användare), eventuellt innehåll från andra tidigare konferenser, integrerade, märkta, tillgängliga för användaren och även tillgängliga för visning på vår webbplats (live.jugru.org).

– Killar, tack så mycket för era svar!

Om det bland läsarna finns de som deltog i våra sommarkonferenser, dela gärna dina intryck av spelaren och sändningen. Vad var bekvämt, vad irriterade dig, vad skulle du vilja se i framtiden?

Om du är intresserad av plattformen och vill se den "i strid" använder vi den igen på vår höst-vinterkonferenser. Det finns en hel rad av dem, så det finns nästan säkert en som är rätt för dig.

Källa: will.com