Denne våren befant vi oss i svært muntre forhold. På grunn av pandemien ble det klart at sommerkonferansene våre måtte flyttes online. Og for å gjennomføre dem på nettet effektivt, var ikke ferdige programvareløsninger egnet for oss, vi måtte skrive våre egne. Og vi hadde tre måneder på oss til å gjøre dette.
Det er tydelig at det har vært tre spennende måneder. Men fra utsiden er det ikke helt åpenbart: hva er en nettkonferanseplattform? Hvilke deler består den av? På den siste av sommerens DevOops-konferanser spurte jeg derfor de som var ansvarlige for denne oppgaven:
- Nikolay Molchanov - teknisk direktør for JUG Ru Group;
- Vladimir Krasilshchik er en pragmatisk Java-programmerer som jobber med backend (du kan også se rapportene hans på våre Java-konferanser);
- Artyom Nikonov er ansvarlig for all vår videostrømming.
Forresten, på høst-vinterkonferansene vil vi bruke en forbedret versjon av samme plattform - så mange habra-lesere vil fortsatt være dens brukere.
Det store bildet
— Hvordan var sammensetningen av laget?
Nikolay Molchanov: Vi har en analytiker, en designer, en tester, tre front-endere og en back-end. Og selvfølgelig en T-formet spesialist!
— Hvordan så prosessen ut generelt?
Nikolay: Fram til midten av mars hadde vi ingenting klart for online i det hele tatt. Og 15. mars begynte hele nettkarusellen å snurre. Vi satte opp flere depoter, planla, diskuterte den grunnleggende arkitekturen og gjorde alt på tre måneder.
Dette gikk selvfølgelig gjennom de klassiske stadiene av planlegging, arkitektur, funksjonsvalg, stemmegivning for disse funksjonene, policy for disse funksjonene, deres design, utvikling, testing. Det førte til at vi 6. juni rullet ut alt til produksjon. . Det var 90 dager for alt.
— Klarte vi å gjennomføre det vi forpliktet oss til?
Nikolay: Siden vi nå deltar på DevOops-konferansen online, betyr det at det fungerte. Jeg personlig forpliktet meg til det viktigste: Jeg vil gi kundene et verktøy som de kan lage en nettkonferanse med.
Utfordringen var denne: gi oss et verktøy som vi kan kringkaste konferansene våre med til billettinnehavere.
All planlegging ble delt inn i flere stadier, og alle funksjoner (ca. 30 globale) ble delt inn i 4 kategorier:
- som vi definitivt vil gjøre (vi kan ikke leve uten dem),
- som vi vil gjøre for det andre,
- som vi aldri vil gjøre,
- og som vi aldri, aldri vil gjøre.
Vi har laget alle funksjonene fra de to første kategoriene.
— Jeg vet at det ble opprettet totalt 600 JIRA-utgaver. På tre måneder laget du 13 mikrotjenester, og jeg mistenker at de ikke bare ble skrevet i Java. Du brukte forskjellige teknologier, du har to Kubernetes-klynger i tre tilgjengelighetssoner og 5 RTMP-strømmer i Amazon.
La oss nå se på hver komponent i systemet separat.
Streaming
— La oss begynne med når vi allerede har et videobilde, og det overføres til noen tjenester. Artyom, fortell oss hvordan denne streamingen skjer?
Artyom Nikonov: Vårt generelle opplegg ser slik ut: bilde fra kameraet -> kontrollrommet vårt -> lokal RTMP-server -> Amazon -> videospiller. Mer informasjon på Habré i juni.
Generelt er det to globale måter å gjøre dette på: enten på maskinvare eller basert på programvareløsninger. Vi valgte programvareruten fordi den er enklere når det gjelder eksterne høyttalere. Det er ikke alltid mulig å bringe maskinvare til en høyttaler i et annet land, men å levere programvare til høyttaleren virker enklere og mer pålitelig.
Fra et maskinvaresynspunkt har vi et visst antall kameraer (i studioene våre og ved fjernhøyttalere), et visst antall fjernkontroller i studioet, som noen ganger må repareres rett under bordet under sendingen.
Signaler fra disse enhetene går inn i datamaskiner med opptakskort, inngangs-/utdatakort og lydkort. Der blandes signalene og settes sammen til oppsett:
Eksempel på layout for 4 høyttalere
Eksempel på layout for 4 høyttalere
Videre gis kontinuerlig kringkasting ved hjelp av tre datamaskiner: det er én hovedmaskin og et par fungerende etter tur. Den første datamaskinen samler inn den første rapporten, den andre - pausen, den første - den neste rapporten, den andre - den neste pausen, og så videre. Og hovedmaskinen blander den første med den andre.
Dette skaper en slags trekant, og hvis noen av disse nodene svikter, kan vi raskt og uten tap av kvalitet fortsette å levere innhold til kundene. Vi hadde en slik situasjon. I løpet av den første uken med konferanser fikset vi en maskin, skrudde den på/av. Folk ser ut til å være fornøyde med vår robusthet.
Deretter går strømmene fra datamaskinene til en lokal server, som har to oppgaver: rute RTMP-strømmer og ta opp sikkerhetskopier. Så vi har flere opptakspunkter. Videostrømmene sendes deretter til den delen av systemet vårt som er bygget på Amazon SaaS-tjenester. Vi bruker ,S3,CloudFront.
Nikolay: Hva skjer der før videoen når publikum? Du må kutte den på en eller annen måte, ikke sant?
Artyom: Vi komprimerer videoen fra vår side og sender den til MediaLive. Vi lanserer transkodere der. De koder videoer i sanntid til flere oppløsninger slik at folk kan se dem på telefonene sine, gjennom dårlig internett i landet, og så videre. Deretter kuttes disse bekkene i , dette er hvordan protokollen fungerer . Vi sender en spilleliste til frontend som inneholder pekere til disse delene.
— Bruker vi 1080p-oppløsning?
Artyom: Bredden på videoen vår er den samme som 1080p - 1920 piksler, og høyden er litt mindre, bildet er mer langstrakt - det er grunner til dette.
Spiller
— Artyom beskrev hvordan videoen kommer inn i strømmer, hvordan den distribueres i forskjellige spillelister for forskjellige skjermoppløsninger, kuttes i biter og kommer inn i spilleren. Kolya, fortell meg nå hva slags spiller dette er, hvordan den forbruker strømmen, hvorfor HLS?
Nikolay: Vi har en spiller som alle konferanseseere kan se.
I hovedsak er dette en innpakning rundt biblioteket , som mange andre spillere er skrevet på. Men vi trengte veldig spesifikk funksjonalitet: spole tilbake og markere stedet der personen er, hvilken rapport han ser på for øyeblikket. Vi trengte også egne layouter, alle mulige logoer og alt annet som var innebygd hos oss. Derfor bestemte vi oss for å skrive vårt eget bibliotek (en wrapper over HLS) og legge det inn på siden.
Dette er rotfunksjonaliteten, så den ble implementert nesten først. Og så vokste alt rundt det.
Faktisk, gjennom autorisasjon, mottar spilleren fra backend en spilleliste med lenker til biter korrelert med tid og kvalitet, laster ned de nødvendige og viser dem til brukeren, og utfører litt "magi" underveis.
Eksempel på tidslinje
— En knapp er innebygd rett i spilleren for å vise en tidslinje over alle rapporter...
Nikolay: Ja, vi løste umiddelbart problemet med brukernavigasjon. I midten av april bestemte vi oss for at vi ikke skulle sende hver av våre konferanser på en egen nettside, men kombinere alt på én. Slik at Full Pass-billettbrukere fritt kan bytte mellom ulike konferanser: både direktesendinger og opptak av tidligere.
Og for å gjøre det enklere for brukere å navigere i gjeldende strøm og bytte mellom spor, bestemte vi oss for å lage en "Hele kringkasting"-knapp og horisontale rapportkort for å bytte mellom spor og rapporter. Det er tastaturkontroll.
— Var det noen tekniske problemer med dette?
Nikolay: De hadde en rullefelt der startpunktene til ulike rapporter ble markert.
— Til slutt, implementerte du disse merkene på rullefeltet før YouTube gjorde noe lignende?
Artyom: De hadde det i beta da. Det virker som om dette er en ganske kompleks funksjon fordi de har delvis testet den med brukere det siste året. Og nå er den kommet i salg.
Nikolay: Men vi fikk den faktisk raskere i salg. Ærlig talt, bak denne enkle funksjonen er det en enorm mengde backend, frontend, beregninger og matematikk inne i spilleren.
Frontend
— La oss finne ut hvordan dette innholdet som vi viser (talekort, høyttalere, nettside, tidsplan) kommer til frontend?
Vladimir Krasilshchik: Vi har flere interne IT-systemer. Det er et system der alle rapporter og alle foredragsholdere legges inn. Det er en prosess der en foredragsholder deltar i en konferanse. Foredragsholderen sender inn en søknad, systemet fanger den opp, så er det en viss pipeline som rapporten opprettes i henhold til.
Slik ser taleren rørledningen
Dette systemet er vår interne utvikling.
Deretter må du bygge en tidsplan fra individuelle rapporter. Som du vet er dette et NP-hardt problem, men vi løser det på en eller annen måte. For å gjøre dette lanserer vi en annen komponent som genererer en tidsplan og laster den opp til tredjeparts skytjeneste Contentful. Der ser alt allerede ut som et bord der det er konferansedager, i dagene er det tidsluker, og i lukene er det rapporter, pauser eller sponsoraktiviteter. Så innholdet vi ser er plassert i en tredjepartstjeneste. Og oppgaven er å formidle det til nettstedet.
Det ser ut til at nettstedet bare er en side med en spiller, og det er ikke noe komplisert her. Bortsett fra at det ikke er det. Backend bak denne siden går til Contentful, henter timeplanen derfra, genererer noen objekter og sender den til frontend. Ved å bruke en websocket-tilkobling, som hver klient på plattformen vår oppretter, sender vi ham en oppdatering til tidsplanen fra backend til frontend.
Virkelig tilfelle: foredragsholderen byttet jobb rett under konferansen. Vi må endre arbeidsgiverbedriftsmerket hans. Hvordan skjer dette fra backend? En oppdatering sendes til alle klienter via websocket, og deretter tegner frontend selv tidslinjen på nytt. Alt dette skjer sømløst. Kombinasjonen av skytjenesten og flere av komponentene våre gir oss muligheten til å generere alt dette innholdet og levere det til fronten.
Nikolay: Det er viktig å presisere her at siden vår ikke er en klassisk SPA-applikasjon. Dette er både et layoutbasert, gjengitt nettsted og et SPA. Google ser faktisk på dette nettstedet som gjengitt HTML. Dette er bra for SEO og for å levere innhold til brukeren. Den venter ikke på at 1,5 megabyte JavaScript skal lastes før den ser siden, den ser umiddelbart den allerede gjengitte siden, og du føler det hver gang du bytter rapport. Alt skjer på et halvt sekund, siden innholdet allerede er klart og lagt ut på rett sted.
— La oss trekke en linje under alt det ovennevnte ved å liste opp teknologiene. Tyoma sa at vi har 5 Amazon-strømmer, og vi leverer video og lyd der. Vi har bash-skript der, vi bruker dem til å starte og konfigurere...
Artyom: Dette skjer gjennom AWS API, det er mange flere tekniske sidetjenester der. Vi delte ansvar slik at jeg leverer til , og front-end og back-end utviklere tar det derfra. Vi har en del egne bindinger for å forenkle oppsettet av innhold, som vi så lager i 4K osv. Siden tidsfristene var veldig stramme, gjorde vi det nesten utelukkende på AWS.
— Så går alt dette inn i spilleren ved hjelp av backend-systemet. Vi har TypeScript, React, Next.JS i spilleren vår. Og på backend har vi flere tjenester i C#, Java, Spring Boot og Node.js. Alt dette er distribuert ved hjelp av Kubernetes ved hjelp av Yandex.Cloud-infrastrukturen.
Jeg vil også merke meg at når jeg trengte å bli kjent med plattformen, viste det seg å være enkelt: alle depotene er på GitLab, alt er godt navngitt, tester er skrevet, det er dokumentasjon. Det vil si at selv i nødmodus tok de seg av slike ting.
Forretningsbegrensninger og analyse
— Vi målrettet 10 000 brukere basert på forretningskrav. Det er på tide å snakke om forretningsbegrensningene vi hadde. Vi måtte sørge for høy arbeidsbelastning, sikre overholdelse av lov om bevaring av personopplysninger. Og hva annet?
Nikolay: I utgangspunktet tok vi utgangspunkt i videokrav. Det viktigste er distribuert videolagring over hele verden for rask levering til klienten. Andre inkluderer 1080p-oppløsning, samt spole tilbake, som mange andre ikke implementerer i live-modus. Senere la vi til muligheten til å aktivere 2x hastighet, med dens hjelp kan du "ta igjen" live og fortsette å se konferansen i sanntid. Og underveis dukket det opp funksjonalitet for tidslinjemarkering. I tillegg måtte vi være feiltolerante og tåle belastningen på 10 000 tilkoblinger. Fra et backend-synspunkt er dette omtrent 10 000 tilkoblinger multiplisert med 8 forespørsler for hver sideoppdatering. Og dette er allerede 80 000 RPS/sek. Ganske mye av.
— Var det andre krav til en «virtuell utstilling» med nettstander til partnere?
Nikolay: Ja, dette måtte gjøres ganske raskt og universelt. Vi hadde opptil 10 partnerbedrifter for hver konferanse, og alle måtte gjennomføres i løpet av en uke eller to. Innholdet deres varierer imidlertid litt i format. Men det ble laget en viss malmotor som setter sammen disse sidene i farten, praktisk talt uten videreutviklingsdeltakelse.
— Det ble også stilt krav til analyser av sanntidsvisninger og statistikk. Jeg vet at vi bruker Prometheus til dette, men fortell oss mer detaljert: hvilke krav møter vi til analyser, og hvordan implementeres dette?
Nikolay: I utgangspunktet har vi markedsføringskrav for innsamling for A/B-testing og innsamling av informasjon for å forstå hvordan vi kan levere det beste innholdet til kunden i fremtiden. Det stilles også krav til noen analyser på partneraktiviteter og analysene du ser (besøkskranke). All informasjon samles inn i sanntid.
Vi kan gi denne informasjonen i aggregert form selv til høyttalere: hvor mange som så på deg på et bestemt tidspunkt. Samtidig, for å overholde føderal lov 152, spores ikke din personlige konto og personlige data på noen måte.
Plattformen har allerede markedsføringsverktøy og våre beregninger for å måle brukeraktivitet i sanntid (hvem så hvilken sekund av rapporten) for å bygge grafer over oppmøte på rapportene. Basert på disse dataene gjøres det forskning som vil gjøre de neste konferansene bedre.
Bedrageri
— Har vi anti-svindelmekanismer?
Nikolay: På grunn av den stramme tidsrammen fra et forretningsmessig synspunkt, var oppgaven i utgangspunktet ikke satt til å umiddelbart blokkere unødvendige forbindelser. Hvis to brukere logget på med samme konto, kunne de se innholdet. Men vi vet hvor mange samtidige visninger det var fra én konto. Og vi forbød flere spesielt ondsinnede overtredere.
Vladimir: Til æren forsto en av de utestengte brukerne hvorfor dette skjedde. Han kom, ba om unnskyldning og lovet å kjøpe billett.
— For at alt dette skal skje, må du spore alle brukere fullstendig fra inngang til utgang, alltid vite hva de gjør. Hvordan fungerer dette systemet?
Vladimir: Jeg vil gjerne snakke om analyser og statistikk, som vi deretter analyserer for å lykkes med rapporten eller så kan gi til partnere. Alle klienter er koblet via en websocket-tilkobling til en spesifikk backend-klynge. Den står der . Hver klient til hver tidsperiode sender hva han gjør og hvilket spor han ser på. Deretter blir denne informasjonen samlet ved hjelp av raske Hazelcast-jobber og sendt tilbake til alle som ser på disse sporene. Vi ser i hjørnet hvor mange som er hos oss nå.
Den samme informasjonen er lagret i og går til vår datainnsjø, hvorfra vi har muligheten til å bygge en mer interessant graf. Spørsmålet oppstår: hvor mange unike brukere så denne rapporten? Vi går til , det er ping fra alle personene som kom etter ID-en til denne rapporten. Vi samlet, aggregerte unike, og nå kan vi forstå.
Nikolay: Men samtidig mottar vi også sanntidsdata fra Prometheus. Det er satt mot alle Kubernetes-tjenester, mot Kubernetes selv. Den samler absolutt alt, og med Grafana kan vi bygge hvilke som helst grafer i sanntid.
Vladimir: På den ene siden laster vi ned dette for videre OLAP-behandling. Og for OLTP laster applikasjonen ned hele greia til Prometheus, Grafana og grafene konvergerer til og med!
– Dette er tilfellet når grafene konvergerer.
Dynamiske endringer
— Fortell oss hvordan dynamiske endringer rulles ut: Hvis rapporten ble kansellert 6 minutter før start, hva er handlingskjeden? Hvilken rørledning fungerer?
Vladimir: Rørledningen er svært betinget. Det er flere muligheter. Den første er at plangenereringsprogrammet fungerte og endret tidsplanen. Den endrede tidsplanen lastes opp til Contentful. Deretter forstår backend at det er endringer for denne konferansen i Contentful, tar den og bygger den opp igjen. Alt samles og sendes via websocket.
Den andre muligheten, når alt skjer i et forrykende tempo: redaktøren endrer manuelt informasjonen i Contentful (lenke til Telegram, høyttalerens presentasjon osv.) og samme logikk fungerer som første gang.
Nikolay: Alt skjer uten å oppdatere siden. Alle endringer skjer helt sømløst for klienten. Det samme gjelder bytte av rapporter. Når tiden kommer, endres rapporten og grensesnittet.
Vladimir: Det er også tidsavbrudd for starten av rapporter i tidslinjen. Helt i begynnelsen er det ingenting. Og hvis du holder musen over den røde stripen, vil det på et tidspunkt, takket være kringkastingssjefen, vises avskjæringer. Regissøren setter riktig start på sendingen, backend fanger opp denne endringen, beregner start- og sluttid for hele sporets presentasjoner i samsvar med konferanseplanen, sender den til kundene våre, og spilleren trekker cutoffs. Nå kan brukeren enkelt navigere til begynnelsen og slutten av rapporten. Det var et strengt forretningskrav, veldig praktisk og nyttig. Du kaster ikke bort tid på å finne det faktiske starttidspunktet for rapporten. Og når vi gjør en forhåndsvisning blir det helt fantastisk.
Utplassering
— Jeg vil gjerne spørre om utplassering. Kolya og teamet brukte mye tid i begynnelsen på å sette opp hele infrastrukturen der alt utfolder seg for oss. Fortell meg, hva er alt laget av?
Nikolay: Fra et teknisk synspunkt hadde vi i utgangspunktet et krav om at produktet skulle være så abstrakt som mulig fra enhver leverandør. Kom til AWS for å lage Terraform-skript spesifikt fra AWS, eller spesifikt fra Yandex, eller fra Azure, etc. passet egentlig ikke. Vi måtte flytte et sted på et tidspunkt.
De første tre ukene lette vi hele tiden etter en måte å gjøre dette bedre på. Som et resultat kom vi til den konklusjonen at Kubernetes i dette tilfellet er vårt alt, fordi det lar oss lage automatisk skaleringstjenester, automatisk utrulling og få nesten alle tjenester ut av esken. Naturligvis måtte alle tjenester trenes til å fungere med Kubernetes, Docker, og teamet måtte også lære.
Vi har to klynger. Test og produksjon. De er helt identiske når det gjelder maskinvare og innstillinger. Vi implementerer infrastruktur som kode. Alle tjenester rulles automatisk ut i tre miljøer fra funksjonsgrener, mastergrener, testgrener og GitLab ved hjelp av en automatisk pipeline. Dette er maksimalt integrert i GitLab, maksimalt integrert med Elastic, Prometheus.
Vi får muligheten til raskt (for backend innen 10 minutter, for frontend innen 5 minutter) å rulle ut endringer til ethvert miljø med alle tester, integrasjoner, kjøring av funksjonstester, integrasjonstester på miljøet, og også teste med belastningstester på et testmiljø omtrent det samme som vi ønsker å få i produksjon.
Om prøver
— Du tester nesten alt, det er vanskelig å tro hvordan du skrev alt. Kan du fortelle oss om backend-testene: hvor mye alt er dekket, hvilke tester?
Vladimir: Det er skrevet to typer prøver. Den første er komponenttester. Løftenivåtester av hele fjærpåføringen og baser inn . Dette er en test av forretningsscenarier på høyeste nivå. Jeg tester ikke funksjoner. Vi tester bare noen store ting. For eksempel, rett i testen, emuleres prosessen med å logge på en bruker, brukerens forespørsel om billetter dit han kan gå, og en forespørsel om tilgang til å se strømmen. Veldig klare brukerscenarier.
Omtrent det samme er implementert i de såkalte integrasjonstestene, som faktisk kjører på miljøet. Faktisk, når neste distribusjon i produksjonen rulles ut, kjører faktiske grunnleggende scenarier også i produksjon. Samme pålogging, forespørsel om billetter, forespørsel om tilgang til CloudFront, sjekke at strømmen virkelig kobles til mine tillatelser, sjekke regissørens grensesnitt.
For øyeblikket har jeg ca 70 komponenttester og ca 40 integrasjonstester om bord. Dekningen er veldig nær 95 %. Dette er for komponenter, mindre for integrering, det er rett og slett ikke så mye nødvendig. Med tanke på at prosjektet involverer all slags kodegenerering, er dette en veldig god indikator. Det var ingen annen måte å gjøre det vi gjorde på tre måneder. For hvis vi testet manuelt, ga funksjoner til testeren vår, og hun ville finne feil og returnere dem til oss for å fikse dem, så ville denne rundturen for å feilsøke koden bli veldig lang, og vi ville ikke overholde noen tidsfrister.
Nikolay: Konvensjonelt, for å utføre en regresjon på hele plattformen når du endrer en funksjon, må du sitte og pirke overalt i to dager.
Vladimir: Derfor er det en stor suksess at når jeg estimerer en funksjon, sier jeg at jeg trenger 4 dager for to enkle penner og 1 websocket, Kolya tillater det. Han er allerede vant til det faktum at disse 4 dagene inkluderer 2 typer tester, og da vil det mest sannsynlig fungere.
Nikolay: Jeg har også skrevet 140 tester: komponent + funksjonell, som gjør det samme. Alle de samme scenariene testes i produksjon, i test og i produksjon. Vi har også nylig lagt til funksjonelle grunnleggende UI-tester. På denne måten dekker vi den mest grunnleggende funksjonaliteten som kan falle fra hverandre.
Vladimir: Selvfølgelig er det verdt å snakke om belastningstester. Det var nødvendig å teste plattformen under en belastning nær den virkelige for å forstå hvordan alt er, hva som skjer med Rabbit, hva som skjer med JVM-ene, hvor mye minne som faktisk trengs.
— Jeg vet ikke med sikkerhet om vi tester noe på stream-siden, men jeg husker at det var problemer med transkodere når vi gjorde meetups. Har vi testet strømmene?
Artyom: Testet iterativt. Organisering av møter. I prosessen med å organisere møter var det omtrent 2300 JIRA-billetter. Dette er bare generiske ting som folk gjorde for å lage møter. Vi tok deler av plattformen inn på en egen side for møter, som ble drevet av Kirill Tolkachev ().
For å være ærlig var det ingen store problemer. Bokstavelig talt et par ganger fanget vi caching-feil på CloudFront, vi løste det ganske raskt - vi rekonfigurerte ganske enkelt policyene. Det var betydelig flere feil hos folk, i strømmesystemene på siden.
Under konferansene måtte jeg skrive flere eksportører for å dekke mer utstyr og tjenester. Noen steder måtte jeg lage mine egne sykler bare for beregningens skyld. Verden av AV (lyd-video) maskinvare er ikke veldig rosenrød - du har en slags "API" av utstyr som du rett og slett ikke kan påvirke. Og det er langt fra et faktum at du vil kunne få den informasjonen du trenger. Maskinvareleverandører er veldig trege, og det er nesten umulig å få det du vil ha fra dem. Totalt er det mer enn 100 maskinvare, de gir ikke tilbake det du trenger, og du skriver merkelige og overflødige eksportører, takket være dem kan du i det minste feilsøke systemet på en eller annen måte.
Оборудование
— Jeg husker hvordan vi før konferansestart delvis kjøpte inn tilleggsutstyr.
Artyom: Vi kjøpte datamaskiner, bærbare datamaskiner og batteripakker. For øyeblikket kan vi leve uten strøm i 40 minutter. I juni var det kraftige tordenvær i St. Petersburg - så vi hadde en slik blackout. Samtidig kommer flere tilbydere til oss med optiske lenker fra ulike punkter. Dette er egentlig 40 minutter med nedetid i bygningen, hvor vi vil ha lys på, lyd, kameraer osv. som fungerer.
— Vi har en lignende historie med Internett. På kontoret der studioene våre holder til, dro vi et voldsomt nett mellom etasjene.
Artyom: Vi har 20 Gbit fiber mellom etasjene. Lenger langs etasjene, et sted er det optikk, et sted er det ingen optikk, men likevel er det færre kanaler enn gigabit-kanaler - vi kjører video på dem mellom sporene fra konferansen. Generelt er det veldig praktisk å jobbe med din egen infrastruktur; du kan sjelden gjøre dette på offline-konferanser på nettsteder.
— Før jeg jobbet i JUG Ru Group, så jeg hvordan maskinvarerom på offline-konferanser ble satt opp over natten, hvor det var en stor skjerm med alle metrikkene du bygger i Grafana. Nå er det også et hovedkontorrom der utviklingsteamet sitter, som under konferansen fikser noen feil og utvikler funksjoner. Samtidig er det et overvåkingssystem som vises på en stor skjerm. Artyom, Kolya og andre karer sitter og passer på at det hele ikke faller ned og fungerer vakkert.
Nysgjerrigheter og problemer
— Du snakket godt om det faktum at vi har streaming med Amazon, det er en aktør med nettet, alt er skrevet på forskjellige programmeringsspråk, feiltoleranse og andre forretningskrav er gitt, inkludert en personlig konto som støttes for juridiske personer og enkeltpersoner, og vi kan integrere med noen som bruker OAuth 2.0, er det anti-svindel, brukerblokkering. Vi kan rulle ut endringer dynamisk fordi vi gjorde det bra, og alt er testet.
Jeg er interessert i å vite hvilke rariteter som var involvert i å få noe i gang. Har det vært noen merkelige situasjoner når du utviklet en backend, frontend, noe sprøtt viste seg og du ikke forsto hva du skulle gjøre med det?
Vladimir: Det virker for meg som om dette bare har skjedd de siste tre månedene. Hver dag. Som du ser er alt håret mitt trukket ut.
Vladimir Krasilshchik etter 3 måneder, da et slags spill viste seg og ingen forsto hva de skulle gjøre med det
Hver dag var det noe sånt som dette, når det var et slikt øyeblikk når du tar det og river av deg håret, eller innser at det ikke er noen andre, og bare du kan gjøre det. Vår første store begivenhet var TechTrain. 6. juni klokken 2 hadde vi ennå ikke rullet ut produksjonsmiljøet, Kolya rullet det ut. Og den personlige kontoen fungerte ikke som en autorisasjonsserver ved bruk av OAuth2.0. Vi gjorde den om til en OAuth2.0-leverandør for å koble plattformen til den. Jeg hadde jobbet i sikkert 18 timer i strekk, jeg så på datamaskinen og så ingenting, jeg forsto ikke hvorfor den ikke fungerte, og Kolya så på koden min eksternt, så etter en feil i vårkonfigurasjonen , fant det, og LC fungerte, og i produksjon også.
Nikolay: Og en time før TechTrain fant utgivelsen sted.
Mange stjerner var på linje her. Vi var ekstremt heldige fordi vi hadde et supert team, og alle ble inspirert av ideen om å gjøre det online. Alle disse tre månedene ble vi drevet av det faktum at vi «lagde YouTube». Jeg tillot meg ikke å rive meg i håret, men fortalte alle at alt ville ordne seg, for faktisk hadde alt blitt beregnet for lenge siden.
Om ytelse
— Kan du fortelle meg hvor mange som var på siden på ett spor? Var det noen ytelsesproblemer?
Nikolay: Det var ingen ytelsesproblemer, som vi allerede sa. Maksimalt antall personer som deltok på en rapport var 1300 personer, denne er på Heisenbug.
— Var det problemer med lokal visning? Og er det mulig å ha en teknisk beskrivelse med diagrammer over hvordan det hele fungerer?
Nikolay: Vi lager en artikkel om dette senere.
Du kan til og med feilsøke strømmer lokalt. Når konferansene startet ble det enda enklere, fordi det dukket opp produksjonsstrømmer som vi kan se hele tiden.
Vladimir: Slik jeg forstår det jobbet front-end-utviklere lokalt med mocks, og siden tiden for å rulle ut til utviklerne i front også er kort (5 minutter), er det ingen problemer med å sjekke hva som skjer med sertifikatene.
— Alt er testet og feilsøkt, også lokalt. Dette betyr at vi skal skrive en artikkel med alle de tekniske funksjonene, vise deg, fortelle deg alt med diagrammer, hvordan det var.
Vladimir: Du kan ta det og gjenta det.
- Om 3 måneder.
Total
— Alt beskrevet sammen høres kult ut, med tanke på at det ble gjort av et lite team på tre måneder.
Nikolay: Et stort lag ville ikke gjort dette. Men det kunne en liten gruppe mennesker som kommuniserer ganske tett og godt med hverandre og kan komme til enighet. De har ingen motsetninger, arkitekturen ble oppfunnet på to dager, ble ferdigstilt og har faktisk ikke endret seg. Det er en veldig streng tilrettelegging for innkommende forretningskrav når det gjelder opphopning av funksjonsforespørsler og endringer.
— Hva sto på listen over videre oppgaver da sommerkonferansene allerede hadde funnet sted?
Nikolay: For eksempel studiepoeng. Krypende linjer på videoen, popup-vinduer enkelte steder i videoen avhengig av innholdet som vises. Foredragsholderen ønsker for eksempel å stille et spørsmål til publikum, og en stemme dukker opp på skjermen, som går tilbake til baksiden basert på stemmeresultatene til foredragsholderen selv. En slags sosial aktivitet i form av likes, hjerter, vurderinger av rapporten under selve presentasjonen, slik at du kan fylle ut tilbakemelding i rett øyeblikk uten å bli distrahert senere av tilbakemeldingsskjemaer. I utgangspunktet slik.
Og legger også til hele plattformen, bortsett fra strømming og konferanse, også en tilstand etter konferansen. Dette er spillelister (inkludert de som er satt sammen av brukere), muligens innhold fra andre tidligere konferanser, integrert, merket, tilgjengelig for brukeren, og også tilgjengelig for visning på nettstedet vårt ().
– Gutter, tusen takk for svarene!
Hvis det blant leserne er de som deltok på våre sommerkonferanser, del gjerne inntrykk av spilleren og sendingen. Hva var praktisk, hva irriterte deg, hva vil du se i fremtiden?
Hvis du er interessert i plattformen og vil se den "i kamp", bruker vi den igjen på vår . Det finnes en hel rekke av dem, så det er nesten helt sikkert en som passer for deg.
Kilde: www.habr.com