Dette forår befandt vi os i meget muntre forhold. På grund af pandemien blev det klart, at vores sommerkonferencer skulle flyttes online. Og for at kunne udføre dem online effektivt, var færdige softwareløsninger ikke egnede til os, vi var nødt til at skrive vores egne. Og vi havde tre måneder til at gøre dette.

Det er tydeligt, at det har været tre spændende måneder. Men udefra er det ikke helt indlysende: Hvad er en online konferenceplatform? Hvilke dele består den af? Derfor spurgte jeg på den sidste af sommerens DevOops-konferencer dem, der var ansvarlige for denne opgave:

• Nikolay Molchanov - teknisk direktør for JUG Ru Group;
• Vladimir Krasilshchik er en pragmatisk Java-programmør, der arbejder på backend (du kunne også se hans rapporter på vores Java-konferencer);
• Artyom Nikonov er ansvarlig for al vores videostreaming.

I øvrigt vil vi på efterårs-vinterkonferencerne bruge en forbedret version af samme platform - så mange habra-læsere vil stadig være dens brugere.

Generelt billede

– Hvordan var sammensætningen af ​​holdet?

Nikolay Molchanov: Vi har en analytiker, en designer, en tester, tre front-enders og en back-end. Og selvfølgelig en T-formet specialist!

— Hvordan så processen generelt ud?

Nikolay: Indtil midten af ​​marts havde vi overhovedet intet klar til online. Og den 15. marts begyndte hele online-karrusellen at snurre. Vi oprettede flere repositories, planlagde, diskuterede den grundlæggende arkitektur og gjorde alt på tre måneder.

Dette gik selvfølgelig gennem de klassiske stadier af planlægning, arkitektur, funktionsvalg, afstemning om disse funktioner, politik for disse funktioner, deres design, udvikling, testning. Det resulterede i, at vi den 6. juni rullede alt ud til produktion. TechTrain. Der var 90 dage til alt.

— Formåede vi at opnå det, vi forpligtede os til?

Nikolay: Da vi nu deltager i DevOops-konferencen online, betyder det, at det virkede. Jeg har personligt forpligtet mig til det vigtigste: Jeg vil bringe kunderne et værktøj, som de kan lave en online konference med.

Udfordringen var denne: Giv os et værktøj, hvormed vi kan udsende vores konferencer til billetindehavere.

Al planlægning var opdelt i flere faser, og alle funktioner (ca. 30 globale) blev opdelt i 4 kategorier:

• hvilket vi helt sikkert vil gøre (vi kan ikke leve uden dem),
• hvilket vi vil gøre for det andet,
• hvilket vi aldrig vil gøre,
• og som vi aldrig nogensinde vil gøre.

Vi lavede alle funktionerne fra de to første kategorier.

— Jeg ved, at der blev oprettet i alt 600 JIRA-numre. På tre måneder lavede du 13 mikrotjenester, og jeg formoder, at de ikke kun er skrevet i Java. Du brugte forskellige teknologier, du har to Kubernetes-klynger i tre tilgængelighedszoner og 5 RTMP-streams i Amazon.

Lad os nu se på hver komponent i systemet separat.

Streaming

— Lad os starte med, hvornår vi allerede har et videobillede, og det overføres til nogle tjenester. Artyom, fortæl os, hvordan denne streaming foregår?

Artyom Nikonov: Vores generelle skema ser således ud: billede fra kameraet -> vores kontrolrum -> lokal RTMP-server -> Amazon -> videoafspiller. Flere detaljer skrev om det på Habré i juni.

Generelt er der to globale måder at gøre dette på: enten på hardware eller baseret på softwareløsninger. Vi valgte softwareruten, fordi den er nemmere i tilfælde af fjernhøjttalere. Det er ikke altid muligt at bringe hardware til en højttaler i et andet land, men at levere software til højttaleren virker lettere og mere pålideligt.

Ud fra et hardwaresynspunkt har vi et vist antal kameraer (i vores studier og ved fjernhøjttalere), et vist antal fjernbetjeninger i studiet, som nogle gange skal repareres lige under bordet under udsendelsen.

Signaler fra disse enheder kommer ind i computere med capture-kort, input/output-kort og lydkort. Der blandes signalerne og samles til layouts:

Eksempel på layout til 4 højttalere

Eksempel på layout til 4 højttalere

Yderligere leveres kontinuerlig udsendelse ved hjælp af tre computere: der er en hovedmaskine og et par fungerende på skift. Den første computer indsamler den første rapport, den anden - pausen, den første - den næste rapport, den anden - den næste pause og så videre. Og hovedmaskinen blander den første med den anden.

Dette skaber en slags trekant, og hvis nogen af ​​disse noder fejler, kan vi hurtigt og uden kvalitetstab fortsætte med at levere indhold til kunderne. Vi havde sådan en situation. I løbet af den første uges konferencer fik vi en maskine til at slå den til/fra. Folk ser ud til at være tilfredse med vores robusthed.

Derefter går strømmene fra computerne til en lokal server, som har to opgaver: rute RTMP-streams og optage sikkerhedskopier. Så vi har flere optagelsespunkter. Videostreams sendes derefter til den del af vores system, der er bygget på Amazon SaaS-tjenester. Vi bruger MediaLive:,S3,Cloudfront.

Nikolay: Hvad sker der, før videoen når frem til publikum? Du er nødt til at skære den på en eller anden måde, ikke?

Artyom: Vi komprimerer videoen fra vores side og sender den til MediaLive. Vi lancerer transkodere der. De omkoder videoer i realtid til flere opløsninger, så folk kan se dem på deres telefoner, gennem dårligt internet i landet og så videre. Derefter skæres disse vandløb i bidder, sådan fungerer protokollen HLS. Vi sender en afspilningsliste til frontend, der indeholder pointere til disse bidder.

— Bruger vi 1080p opløsning?

Artyom: Bredden af ​​vores video er den samme som 1080p - 1920 pixels, og højden er lidt mindre, billedet er mere aflangt - det er der grunde til.

Spiller

— Artyom beskrev, hvordan videoen kommer i streams, hvordan den distribueres i forskellige afspilningslister til forskellige skærmopløsninger, skæres i bidder og kommer ind i afspilleren. Kolya, fortæl mig nu, hvilken slags spiller dette er, hvordan den forbruger streamen, hvorfor HLS?

Nikolay: Vi har en spiller, som alle konferenceseere kan se.

I det væsentlige er dette en indpakning omkring biblioteket hls.js, som mange andre spillere er skrevet på. Men vi havde brug for meget specifik funktionalitet: tilbagespoling og markering af det sted, hvor personen er, hvilken rapport han i øjeblikket ser. Vi havde også brug for vores egne layouts, alle mulige logoer og alt det andet, der var indbygget hos os. Derfor besluttede vi at skrive vores eget bibliotek (en indpakning over HLS) og indlejre det på siden.

Dette er rodfunktionaliteten, så den blev implementeret næsten først. Og så voksede alt omkring det.

Faktisk modtager spilleren gennem autorisation fra backend en afspilningsliste med links til bidder, der er korreleret med tid og kvalitet, downloader de nødvendige og viser dem til brugeren og udfører noget "magi" undervejs.

Eksempel på tidslinje

— En knap er indbygget lige i afspilleren for at vise en tidslinje over alle rapporter...

Nikolay: Ja, vi løste straks problemet med brugernavigation. I midten af ​​april besluttede vi, at vi ikke ville udsende hver af vores konferencer på en separat hjemmeside, men ville samle alt på én. Så brugere af Full Pass-billet frit kan skifte mellem forskellige konferencer: både live-udsendelser og optagelser af tidligere.

Og for at gøre det nemmere for brugerne at navigere i den aktuelle strøm og skifte mellem spor, besluttede vi at lave en "Hele udsendelse"-knap og vandrette rapportkort til at skifte mellem spor og rapporter. Der er tastaturkontrol.

— Var der tekniske problemer med dette?

Nikolay: De havde en rullebjælke, hvor startpunkterne for forskellige rapporter var markeret.

— I sidste ende, implementerede du disse mærker på rullepanelet, før YouTube gjorde noget lignende?

Artyom: De havde den i beta dengang. Det ser ud til, at dette er en ret kompleks funktion, fordi de delvist har testet den med brugere i løbet af det sidste år. Og nu er den nået til salg.

Nikolay: Men vi fik det faktisk hurtigere til salg. Ærligt, bag denne simple funktion er der en enorm mængde af backend, frontend, beregninger og matematik inde i afspilleren.

Frontend

— Lad os finde ud af, hvordan dette indhold, som vi viser (talekort, højttalere, hjemmeside, tidsplan) kommer til frontenden?

Vladimir Krasilshchik: Vi har flere interne IT-systemer. Der er et system, hvor alle rapporter og alle talere er indtastet. Der er en proces, hvorved en taler deltager i en konference. Taleren indsender en ansøgning, systemet fanger den, så er der en bestemt pipeline, hvorefter rapporten oprettes.

Sådan ser taleren rørledningen

Dette system er vores interne udvikling.

Dernæst skal du opbygge en tidsplan ud fra individuelle rapporter. Som du ved, er dette et NP-hårdt problem, men vi løser det på en eller anden måde. For at gøre dette lancerer vi en anden komponent, der genererer en tidsplan og uploader den til tredjeparts cloud-tjenesten Contentful. Der ligner alt et bord, hvor der er konferencedage, i dagene er der tidsspalter, og i slotsene er der rapporter, pauser eller sponsoraktiviteter. Så det indhold, vi ser, er placeret i en tredjepartstjeneste. Og opgaven er at formidle det til siden.

Det ser ud til, at siden kun er en side med en spiller, og der er ikke noget kompliceret her. Bortset fra at det ikke er det. Backend bag denne side går til Contentful, henter tidsplanen derfra, genererer nogle objekter og sender den til frontend. Ved at bruge en websocket-forbindelse, som hver klient på vores platform laver, sender vi ham en opdatering til tidsplanen fra backend til frontend.

Reelt tilfælde: taleren skiftede job lige under konferencen. Vi er nødt til at ændre hans arbejdsgiverfirmamærke. Hvordan sker dette fra backend? En opdatering sendes til alle klienter via websocket, og derefter gentegner frontenden selv tidslinjen. Alt dette sker problemfrit. Kombinationen af ​​cloud-tjenesten og flere af vores komponenter giver os mulighed for at generere alt dette indhold og levere det til fronten.

Nikolay: Det er vigtigt her at præcisere, at vores side ikke er en klassisk SPA-applikation. Dette er både en layout-baseret, gengivet hjemmeside og en SPA. Google ser faktisk dette websted som gengivet HTML. Dette er godt for SEO og for at levere indhold til brugeren. Den venter ikke på, at 1,5 megabyte JavaScript indlæses, før den ser siden, den ser med det samme den allerede gengivede side, og du mærker den, hver gang du skifter rapporten. Alt sker på et halvt sekund, da indholdet allerede er klar og lagt på det rigtige sted.

— Lad os trække en streg under alt ovenstående ved at liste teknologierne. Tyoma sagde, at vi har 5 Amazon-streams, og vi leverer video og lyd der. Vi har bash-scripts der, vi bruger dem til at starte og konfigurere...

Artyom: Dette sker gennem AWS API, der er mange flere tekniske sidetjenester der. Vi delte vores ansvar, så jeg leverer til CloudFront, og front-end og back-end udviklere tager det derfra. Vi har en række af vores egne bindinger til at forenkle layoutet af indhold, som vi så laver i 4K mv. Da deadlines var meget stramme, gjorde vi det næsten udelukkende på AWS.

— Så går alt dette ind i afspilleren ved hjælp af backend-systemet. Vi har TypeScript, React, Next.JS i vores afspiller. Og på backend har vi flere tjenester i C#, Java, Spring Boot og Node.js. Dette er alt sammen implementeret ved hjælp af Kubernetes ved hjælp af Yandex.Cloud-infrastrukturen.

Jeg vil også bemærke, at da jeg skulle stifte bekendtskab med platformen, viste det sig at være nemt: alle depoterne er på GitLab, alt er godt navngivet, tests er skrevet, der er dokumentation. Det vil sige, selv i nødtilstand tog de sig af sådanne ting.

Forretningsbegrænsninger og analyse

— Vi målrettede 10 brugere baseret på forretningskrav. Det er tid til at tale om de forretningsmæssige begrænsninger, vi havde. Vi skulle sikre en høj arbejdsbyrde, sikre overholdelse af loven om opbevaring af persondata. Og hvad ellers?

Nikolay: I første omgang tog vi udgangspunkt i videokrav. Det vigtigste er distribueret videolagring rundt om i verden for hurtig levering til klienten. Andre inkluderer 1080p opløsning, samt tilbagespoling, som mange andre ikke implementerer i live-tilstand. Senere tilføjede vi muligheden for at aktivere 2x hastighed, med dens hjælp kan du "indhente" live og fortsætte med at se konferencen i realtid. Og undervejs dukkede funktionalitet til tidslinjemarkering op. Derudover skulle vi være fejltolerante og modstå belastningen af ​​10 forbindelser. Fra et backend-synspunkt er dette cirka 000 forbindelser ganget med 10 anmodninger for hver sideopdatering. Og dette er allerede 000 RPS/sek. En hel del af.

— Var der andre krav til en "virtuel udstilling" med online stande af partnere?

Nikolay: Ja, dette skulle gøres ret hurtigt og universelt. Vi havde op til 10 partnervirksomheder til hver konference, og alle skulle gennemføres på en uge eller to. Deres indhold afviger dog lidt i format. Men der blev lavet en bestemt skabelonmotor, der samler disse sider på farten, stort set uden videreudviklingsdeltagelse.

— Der var også krav om analyser af realtidsvisninger og statistikker. Jeg ved godt, at vi bruger Prometheus til dette, men fortæl os mere detaljeret: Hvilke krav opfylder vi til analyse, og hvordan implementeres dette?

Nikolay: I første omgang har vi marketingkrav til indsamling til A/B-test og indsamling af information for at forstå, hvordan man korrekt leverer det bedste indhold til kunden i fremtiden. Der er også krav om nogle analyser på partneraktiviteter og de analyser, du ser (besøgsdisk). Al information indsamles i realtid.

Vi kan give disse oplysninger i aggregeret form selv til højttalere: hvor mange mennesker der så dig på et bestemt tidspunkt. På samme tid, for at overholde føderal lov 152, spores din personlige konto og personlige data ikke på nogen måde.

Platformen har allerede marketingværktøjer og vores målinger til måling af brugeraktivitet i realtid (hvem så hvilken anden del af rapporten) for at opbygge grafer over tilstedeværelse i rapporterne. På baggrund af disse data forskes der, som vil gøre de næste konferencer bedre.

Svig

— Har vi mekanismer til bekæmpelse af svig?

Nikolay: På grund af den stramme tidsramme fra et forretningsmæssigt synspunkt, var opgaven i første omgang ikke sat til straks at blokere for unødvendige forbindelser. Hvis to brugere loggede ind under samme konto, kunne de se indholdet. Men vi ved, hvor mange samtidige visninger der var fra én konto. Og vi forbød flere særligt ondsindede overtrædere.

Vladimir: Til sin ære forstod en af ​​de forbudte brugere, hvorfor dette skete. Han kom, undskyldte og lovede at købe en billet.

— For at alt dette kan ske, skal du helt spore alle brugere fra indgang til udgang, altid vide, hvad de laver. Hvordan fungerer dette system?

Vladimir: Jeg vil gerne tale om analyser og statistik, som vi så analyserer for rapportens succes eller så kan levere til partnere. Alle klienter er forbundet via en websocket-forbindelse til en specifik backend-klynge. Den står der hasselstøbt. Hver klient sender i hvert tidsrum, hvad han laver, og hvilket spor han ser. Derefter samles disse oplysninger ved hjælp af hurtige Hazelcast-jobs og sendes tilbage til alle, der ser disse numre. Vi ser i hjørnet, hvor mange mennesker der nu er hos os.

De samme oplysninger er gemt i Mongo og går til vores datasø, hvorfra vi har mulighed for at bygge en mere interessant graf. Spørgsmålet opstår: hvor mange unikke brugere har set denne rapport? Vi tager til PostgreSQL, der er ping fra alle de mennesker, der kom efter id'et for denne rapport. Vi indsamlede, aggregerede unikke, og nu kan vi forstå.

Nikolay: Men samtidig modtager vi også realtidsdata fra Prometheus. Det er sat mod alle Kubernetes-tjenester, mod Kubernetes selv. Den samler absolut alt, og med Grafana kan vi bygge alle grafer i realtid.

Vladimir: På den ene side downloader vi dette til yderligere OLAP-behandling. Og for OLTP downloader applikationen det hele til Prometheus, Grafana, og graferne konvergerer endda!

- Det er tilfældet, når graferne konvergerer.

Dynamiske ændringer

— Fortæl os, hvordan dynamiske ændringer udrulles: Hvis rapporten blev annulleret 6 minutter før start, hvad er kæden af ​​handlinger? Hvilken rørledning fungerer?

Vladimir: Rørledningen er meget betinget. Der er flere muligheder. Den første er, at skemagenereringsprogrammet virkede og ændrede skemaet. Den ændrede tidsplan uploades til Contentful. Hvorefter backend forstår, at der er ændringer for denne konference i Contentful, tager den og genopbygger den. Alt samles og sendes via websocket.

Den anden mulighed, når alt sker i et hæsblæsende tempo: Redaktøren ændrer manuelt informationen i Contentful (link til Telegram, højttalerens præsentation osv.), og den samme logik fungerer som første gang.

Nikolay: Alt sker uden at opdatere siden. Alle ændringer sker helt problemfrit for kunden. Det samme gælder for at skifte rapporter. Når tiden kommer, ændres rapporten og grænsefladen.

Vladimir: Der er også tidsfrister for starten af ​​rapporter i tidslinjen. Allerede i begyndelsen er der ingenting. Og hvis du holder musen over den røde stribe, så vil der på et tidspunkt, takket være udsendelsesdirektøren, dukke cutoffs op. Direktøren indstiller den korrekte start af udsendelsen, backend opfanger denne ændring, beregner start- og sluttidspunkter for hele nummerets præsentationer i overensstemmelse med konferencens tidsplan, sender det til vores kunder, og spilleren trækker cutoffs. Nu kan brugeren nemt navigere til begyndelsen og slutningen af ​​rapporten. Det var et strengt forretningskrav, meget praktisk og nyttigt. Du spilder ikke tid på at finde det faktiske starttidspunkt for rapporten. Og når vi laver en forpremiere, bliver det helt vidunderligt.

Implementering

— Jeg vil gerne spørge om indsættelsen. Kolya og teamet brugte meget tid i starten på at opsætte hele infrastrukturen, hvor alting udfolder sig for os. Fortæl mig, hvad er det hele lavet af?

Nikolay: Fra et teknisk synspunkt havde vi i første omgang et krav om, at produktet skulle være så abstrakt som muligt fra enhver leverandør. Kom til AWS for at lave Terraform-scripts specifikt fra AWS eller specifikt fra Yandex eller fra Azure osv. passede ikke rigtig. Vi skulle flytte et sted på et tidspunkt.

I de første tre uger ledte vi konstant efter en måde at gøre dette bedre på. Som et resultat kom vi til den konklusion, at Kubernetes i dette tilfælde er vores alt, fordi det giver os mulighed for at oprette automatisk skaleringstjenester, automatisk udrulning og få næsten alle tjenester ud af boksen. Naturligvis skulle alle tjenester trænes til at arbejde med Kubernetes, Docker, og teamet skulle også lære.

Vi har to klynger. Test og produktion. De er helt identiske med hensyn til hardware og indstillinger. Vi implementerer infrastruktur som kode. Alle tjenester rulles automatisk ud i tre miljøer fra funktionsgrene, mastergrene, testgrene og GitLab ved hjælp af en automatisk pipeline. Dette er maksimalt integreret i GitLab, maksimalt integreret med Elastic, Prometheus.

Vi får mulighed for hurtigt (til backend inden for 10 minutter, for frontend inden for 5 minutter) at udrulle ændringer til ethvert miljø med alle test, integrationer, kørende funktionstest, integrationstest på miljøet, og også teste med loadtest på et testmiljø omtrent det samme, som vi ønsker at få i produktion.

Om prøver

- Du tester næsten alt, det er svært at tro, hvordan du skrev alt. Kan du fortælle os om backend-testene: hvor meget er alt dækket, hvilke tests?

Vladimir: Der er skrevet to typer prøver. Den første er komponenttest. Løfteniveautest af hele fjederpåføringen og base ind Testcontainere. Dette er en test af forretningsscenarier på højeste niveau. Jeg tester ikke funktioner. Vi tester kun nogle store ting. For eksempel, lige i testen, emuleres processen med at logge ind på en bruger, brugerens anmodning om billetter til, hvor han kan gå, og en anmodning om adgang til at se streamen. Meget klare brugerscenarier.

Omtrent det samme er implementeret i de såkaldte integrationstests, som faktisk kører på miljøet. Faktisk, når den næste udrulning i produktionen rulles ud, kører rigtige grundscenarier også i produktionen. Det samme login, anmode om billetter, anmode om adgang til CloudFront, kontrollere, at streamen virkelig forbinder med mine tilladelser, tjekke direktørens grænseflade.

I øjeblikket har jeg omkring 70 komponenttests og omkring 40 integrationstests ombord. Dækningen er meget tæt på 95 %. Dette er for komponent, mindre for integration, der er simpelthen ikke så meget nødvendigt. I betragtning af at projektet involverer alle former for kodegenerering, er dette en meget god indikator. Der var ingen anden måde at gøre det, vi gjorde på tre måneder. For hvis vi testede manuelt og gav funktioner til vores tester, og hun ville finde fejl og returnere dem til os for rettelser, så ville denne rundrejse for at fejlsøge koden være meget lang, og vi ville ikke overholde nogen deadlines.

Nikolay: Konventionelt, for at udføre en regression på hele platformen, når du ændrer en eller anden funktion, skal du sidde og stikke overalt i to dage.

Vladimir: Derfor er det en stor succes, at når jeg estimerer en funktion, så siger jeg, at jeg skal bruge 4 dage til to simple penne og 1 websocket, Kolya tillader det. Han er allerede vant til, at disse 4 dage inkluderer 2 typer test, og så vil det højst sandsynligt fungere.

Nikolay: Jeg har også skrevet 140 tests: komponent + funktionel, som gør det samme. Alle de samme scenarier testes i produktion, i test og i produktion. Vi har også for nylig tilføjet funktionelle grundlæggende UI-tests. På denne måde dækker vi den mest basale funktionalitet, der kan falde fra hinanden.

Vladimir: Selvfølgelig er det værd at tale om belastningstest. Det var nødvendigt at teste platformen under en belastning tæt på den rigtige for at forstå, hvordan alting er, hvad der sker med Rabbit, hvad der sker med JVM'erne, hvor meget hukommelse der faktisk er brug for.

- Jeg ved ikke med sikkerhed, om vi tester noget på stream-siden, men jeg kan huske, at der var problemer med transkodere, da vi lavede meetups. Har vi testet strømmene?

Artyom: Testet iterativt. Organisering af møder. I processen med at organisere møder var der cirka 2300 JIRA-billetter. Det er bare generiske ting, som folk gjorde for at lave møder. Vi tog dele af platformen ind på en separat side for møder, som blev drevet af Kirill Tolkachev (talkkv).

For at være ærlig var der ingen store problemer. Bogstaveligt talt et par gange fangede vi caching-fejl på CloudFront, vi løste det ret hurtigt - vi omkonfigurerede simpelthen politikkerne. Der var markant flere fejl i mennesker i streamingsystemerne på siden.

Under konferencerne var jeg nødt til at skrive flere eksportører for at kunne dække mere udstyr og tjenester. Nogle steder var jeg nødt til at lave mine egne cykler bare for metrikkens skyld. Verden af ​​AV (audio-video) hardware er ikke særlig rosenrød - du har en form for "API" af udstyr, som du simpelthen ikke kan påvirke. Og det er langt fra et faktum, at du vil være i stand til at få den information, du har brug for. Hardwareleverandører er virkelig langsomme, og det er næsten umuligt at få, hvad du vil have fra dem. I alt er der mere end 100 stykker hardware, de giver ikke tilbage, hvad du har brug for, og du skriver mærkelige og overflødige eksportører, takket være hvilke du i det mindste på en eller anden måde kan fejlsøge systemet.

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

— Jeg kan huske, hvordan vi før starten af ​​konferencerne delvist købte ekstra udstyr.

Artyom: Vi købte computere, bærbare computere og batteripakker. I øjeblikket kan vi leve uden strøm i 40 minutter. I juni var der voldsomme tordenvejr i Sankt Petersborg – så vi havde sådan et blackout. Samtidig kommer flere udbydere til os med optiske links fra forskellige punkter. Dette er virkelig 40 minutters nedetid i byggeriet, hvor vi vil have lys tændt, lyd, kameraer osv. i gang.

- Vi har en lignende historie med internettet. På kontoret, hvor vores atelierer ligger, slæbte vi et voldsomt net mellem etagerne.

Artyom: Vi har 20 Gbit fiber mellem etagerne. Længere hen ad etagerne, et eller andet sted er der optik, et eller andet sted er der ingen optik, men alligevel er der færre kanaler end gigabit - dem kører vi video på mellem sporene af konferencen. Generelt er det meget praktisk at arbejde på din egen infrastruktur; du kan sjældent gøre dette ved offline konferencer på websteder.

— Før jeg arbejdede hos JUG Ru Group, så jeg, hvordan hardwarerum til offline konferencer blev sat op fra den ene dag til den anden, hvor der var en stor skærm med alle de målinger, man bygger i Grafana. Nu er der også et hovedkvarter, hvori udviklingsteamet sidder, som under konferencen retter nogle fejl og udvikler funktioner. Samtidig er der et overvågningssystem, der vises på en stor skærm. Artyom, Kolya og andre fyre sidder og sørger for, at det hele ikke falder og fungerer smukt.

Nysgerrigheder og problemer

— Du talte godt om, at vi har streaming med Amazon, der er en spiller på nettet, alt er skrevet på forskellige programmeringssprog, fejltolerance og andre forretningskrav er tilvejebragt, inklusive en personlig konto, der understøttes af juridiske enheder og enkeltpersoner, og vi kan integrere med nogen, der bruger OAuth 2.0, er der anti-svindel, brugerblokering. Vi kan udrulle ændringer dynamisk, fordi vi gjorde det godt, og det hele er testet.

Jeg er interesseret i at vide, hvilke særheder der var involveret i at få noget i gang. Har der været nogle mærkelige situationer, hvor du udviklede en backend, frontend, noget skørt viste sig, og du ikke forstod, hvad du skulle gøre med det?

Vladimir: Det forekommer mig, at dette kun er sket i de sidste tre måneder. Hver dag. Som du kan se, er alt mit hår blevet trukket ud.

Vladimir Krasilshchik efter 3 måneder, da en slags spil viste sig, og ingen forstod, hvad de skulle gøre med det

Hver dag var der sådan noget, når der var sådan et øjeblik, hvor du tager det og river dit hår af, eller indser, at der ikke er nogen anden, og kun du kan gøre det. Vores første store begivenhed var TechTrain. Den 6. juni kl. 2 havde vi endnu ikke rullet produktionsmiljøet ud, Kolya var ved at rulle det ud. Og den personlige konto fungerede ikke som en godkendelsesserver ved hjælp af OAuth2.0. Vi forvandlede den til en OAuth2.0-udbyder for at forbinde platformen til den. Jeg havde arbejdet i sikkert 18 timer i træk, jeg kiggede på computeren og så intet, jeg forstod ikke, hvorfor den ikke virkede, og Kolya kiggede på min kode på afstand, ledte efter en fejl i forårets konfiguration , fandt det, og LC'en virkede, og også i produktion.

Nikolay: Og en time før TechTrain fandt udgivelsen sted.

En masse stjerner var på linje her. Vi var ekstremt heldige, fordi vi havde et super hold, og alle blev inspireret af ideen om at gøre det online. Alle disse tre måneder var vi drevet af det faktum, at vi "lavede YouTube". Jeg tillod ikke mig selv at rive mit hår af, men fortalte alle, at alt ville ordne sig, for faktisk var alting blevet beregnet for længe siden.

Om ydeevne

— Kan du fortælle mig, hvor mange mennesker der var på siden på et spor? Var der nogen præstationsproblemer?

Nikolay: Der var ingen præstationsproblemer, som vi allerede sagde. Det maksimale antal personer, der deltog i en rapport var 1300 personer, dette er på Heisenbug.

— Var der problemer med lokal visning? Og er det muligt at få en teknisk beskrivelse med diagrammer over, hvordan det hele fungerer?

Nikolay: Vi laver en artikel om dette senere.

Du kan endda fejlsøge streams lokalt. Da først konferencerne startede, blev det endnu nemmere, fordi der dukkede produktionsstrømme op, som vi kan se hele tiden.

Vladimir: Som jeg forstår det, arbejdede frontend-udviklere lokalt med mocks, og da tiden til at rulle ud til udviklerne i fronten også er kort (5 minutter), er der ingen problemer med at tjekke, hvad der sker med certifikaterne.

— Alt er testet og fejlrettet, også lokalt. Det betyder, at vi skriver en artikel med alle de tekniske funktioner, viser dig, fortæller dig alt med diagrammer, hvordan det var.

Vladimir: Du kan tage det og gentage det.

- Om 3 måneder.

Total

— Alt, der er beskrevet samlet, lyder fedt, når man tager i betragtning, at det blev lavet af et lille team på tre måneder.

Nikolay: Et stort hold ville ikke gøre dette. Men det kunne en lille gruppe mennesker, der kommunikerer ganske tæt og godt med hinanden og kan blive enige. De har ingen modsætninger, arkitekturen blev opfundet på to dage, blev færdiggjort og har faktisk ikke ændret sig. Der er en meget streng lettelse af indgående forretningskrav med hensyn til ophobning af funktionsanmodninger og ændringer.

— Hvad stod på din liste over yderligere opgaver, da sommerkonferencerne allerede havde fundet sted?

Nikolay: For eksempel kreditter. Krybende linjer på videoen, pop-ups nogle steder i videoen afhængigt af indholdet, der vises. For eksempel vil taleren stille et spørgsmål til tilhørerne, og der popper en stemme op på skærmen, som går tilbage til bagsiden baseret på afstemningsresultaterne til taleren selv. En eller anden form for social aktivitet i form af likes, hjerter, vurderinger af rapporten under selve præsentationen, så du kan udfylde feedback på det rigtige tidspunkt uden at blive distraheret senere af feedback-formularer. I starten sådan her.

Og tilføjer også til hele platformen, bortset fra streaming og konference, også en post-konference-tilstand. Disse er afspilningslister (inklusive dem, der er kompileret af brugere), muligvis indhold fra andre tidligere konferencer, integrerede, mærkede, tilgængelige for brugeren og også tilgængelige for visning på vores hjemmeside (live.jugru.org).

– Gutter, mange tak for jeres svar!

Hvis der blandt læserne er dem, der deltog i vores sommerkonferencer, så del gerne dit indtryk af spilleren og udsendelsen. Hvad var praktisk, hvad irriterede dig, hvad ville du gerne se i fremtiden?

Hvis du er interesseret i platformen og vil se den "i kamp", bruger vi den igen på vores efterår-vinter konferencer. Der er en lang række af dem, så der er næsten helt sikkert en, der passer til dig.

Kilde: www.habr.com