Hierdie lente het ons onsself in baie vrolike toestande bevind. As gevolg van die pandemie het dit duidelik geword dat ons somerkonferensies aanlyn geskuif moet word. En om dit doeltreffend aanlyn te doen, was gereedgemaakte sagteware-oplossings nie geskik vir ons nie; ons moes ons eie skryf. En ons het drie maande gehad om dit te doen.

Dit is duidelik dat dit 'n opwindende drie maande was. Maar van buite is dit nie heeltemal voor die hand liggend nie: wat is 'n aanlyn konferensieplatform? Uit watter dele bestaan ​​dit? Daarom, by die laaste van die somer DevOops-konferensies, het ek diegene wat vir hierdie taak verantwoordelik was, gevra:

• Nikolay Molchanov - tegniese direkteur van JUG Ru Group;
• Vladimir Krasilshchik is 'n pragmatiese Java-programmeerder wat aan die agterkant werk (jy kan ook sy verslae by ons Java-konferensies sien);
• Artyom Nikonov is verantwoordelik vir al ons videostroming.

Terloops, by die herfs-winterkonferensies sal ons 'n verbeterde weergawe van dieselfde platform gebruik - so baie habra-lesers sal steeds die gebruikers daarvan wees.

Die groot prentjie

— Wat was die samestelling van die span?

Nikolay Molchanov: Ons het 'n ontleder, 'n ontwerper, 'n toetser, drie front-enders en 'n back-end. En natuurlik 'n T-vormige spesialis!

— Hoe het die proses in die algemeen gelyk?

Nikolay: Tot middel Maart het ons glad niks gereed gehad vir aanlyn nie. En op 15 Maart het die hele aanlyn karrousel begin draai. Ons het verskeie bewaarplekke opgerig, beplan, die basiese argitektuur bespreek en alles in drie maande gedoen.

Dit het natuurlik deur die klassieke stadiums van beplanning, argitektuur, kenmerkkeuse gegaan, stem vir daardie kenmerke, beleid vir daardie kenmerke, hul ontwerp, ontwikkeling, toetsing. Gevolglik het ons op 6 Junie alles na produksie uitgerol. Tegniese trein. Daar was 90 dae vir alles.

— Het ons daarin geslaag om te bereik waartoe ons ons verbind het?

Nikolay: Aangesien ons nou aanlyn aan die DevOops-konferensie deelneem, beteken dit dit het gewerk. Ek het my persoonlik verbind tot die belangrikste ding: ek sal kliënte 'n hulpmiddel bring waarmee hulle 'n aanlyn konferensie kan maak.

Die uitdaging was dit: gee ons 'n hulpmiddel waarmee ons ons konferensies aan kaartjiehouers kan uitsaai.

Alle beplanning is in verskeie fases verdeel, en alle kenmerke (ongeveer 30 wêreldwyd) is in 4 kategorieë verdeel:

• wat ons beslis sal doen (ons kan nie sonder hulle lewe nie),
• wat ons tweedens sal doen,
• wat ons nooit sal doen nie,
• en wat ons nooit, ooit sal doen nie.

Ons het al die kenmerke van die eerste twee kategorieë gemaak.

— Ek weet dat 'n totaal van 600 JIRA-uitgawes geskep is. In drie maande het jy 13 mikrodienste gemaak, en ek vermoed dat hulle nie net in Java geskryf is nie. Jy het verskillende tegnologieë gebruik, jy het twee Kubernetes-klusters in drie beskikbaarheidsones en 5 RTMP-strome in Amazon.

Kom ons kyk nou afsonderlik na elke komponent van die stelsel.

Stroom

— Kom ons begin met wanneer ons reeds 'n videobeeld het, en dit word na sommige dienste oorgedra. Artyom, vertel ons hoe hierdie streaming gebeur?

Artyom Nikonov: Ons algemene skema lyk soos volg: beeld van die kamera -> ons beheerkamer -> plaaslike RTMP-bediener -> Amazon -> videospeler. Meer besonderhede daaroor geskryf het op Habré in Junie.

Oor die algemeen is daar twee wêreldwye maniere om dit te doen: óf op hardeware óf gebaseer op sagteware-oplossings. Ons het die sagtewareroete gekies omdat dit makliker is in die geval van afgeleë luidsprekers. Dit is nie altyd moontlik om hardeware na 'n spreker in 'n ander land te bring nie, maar die lewering van sagteware aan die spreker lyk makliker en meer betroubaar.

Uit 'n hardeware-oogpunt het ons 'n sekere aantal kameras (in ons ateljees en by afgeleë luidsprekers), 'n sekere aantal afstandbeheerders in die ateljee, wat soms reg onder die tafel herstel moet word tydens die uitsending.

Seine van hierdie toestelle betree rekenaars met vangkaarte, invoer/afvoerkaarte en klankkaarte. Daar word die seine gemeng en in uitlegte saamgestel:

Voorbeeld van 'n uitleg vir 4 sprekers

Voorbeeld van 'n uitleg vir 4 sprekers

Verder word deurlopende uitsaai met behulp van drie rekenaars voorsien: daar is een hoofmasjien en 'n paar werkendes om die beurt. Die eerste rekenaar versamel die eerste verslag, die tweede - die pouse, die eerste - die volgende verslag, die tweede - die volgende pouse, ensovoorts. En die hoofmasjien meng die eerste met die tweede.

Dit skep 'n soort driehoek, en as enige van hierdie nodusse misluk, kan ons vinnig en sonder verlies aan kwaliteit voortgaan om inhoud aan kliënte te lewer. Ons het so 'n situasie gehad. Gedurende die eerste week van konferensies het ons een masjien reggemaak, dit aan/af geskakel. Dit lyk asof mense gelukkig is met ons veerkragtigheid.

Vervolgens gaan die strome vanaf die rekenaars na 'n plaaslike bediener, wat twee take het: roeteer RTMP-strome en neem rugsteun op. Ons het dus verskeie opnamepunte. Die videostrome word dan gestuur na die deel van ons stelsel wat op Amazon SaaS-dienste gebou is. Ons gebruik MediaLive,S3,Wolkfront.

Nikolay: Wat gebeur daar voordat die video die gehoor bereik? Jy moet dit op een of ander manier sny, reg?

Artyom: Ons druk die video van ons kant saam en stuur dit na MediaLive. Ons stel transkodeerders daar bekend. Hulle transkodeer video's intyds na verskeie resolusies sodat mense dit op hul fone kan kyk, deur swak internet in die land, ensovoorts. Dan word hierdie strome in gesny stukke, dit is hoe die protokol werk HLS. Ons stuur 'n snitlys na die voorkant wat wysers na hierdie stukke bevat.

— Gebruik ons ​​1080p-resolusie?

Artyom: Die breedte van ons video is dieselfde as 1080p - 1920 pixels, en die hoogte is 'n bietjie minder, die prentjie is meer verleng - daar is redes hiervoor.

Speler

— Artyom het beskryf hoe die video in strome beland, hoe dit in verskillende snitlyste vir verskillende skermresolusies versprei word, in stukke gesny word en in die speler kom. Kolya, vertel my nou watter soort speler dit is, hoe dit die stroom verbruik, hoekom HLS?

Nikolay: Ons het 'n speler waarna alle konferensiekykers kan kyk.

In wese is dit 'n omhulsel om die biblioteek hls.js, waarop baie ander spelers geskryf is. Maar ons het baie spesifieke funksionaliteit nodig gehad: terugspoel en merk die plek waar die persoon is, watter verslag hy tans kyk. Ons het ook ons ​​eie uitlegte nodig gehad, allerhande logo's en alles anders wat by ons ingebou is. Daarom het ons besluit om ons eie biblioteek ('n omhulsel oor HLS) te skryf en dit op die webwerf in te sluit.

Dit is die wortelfunksie, so dit is amper eerste geïmplementeer. En toe het alles rondom dit gegroei.

Trouens, deur magtiging ontvang die speler van die agterkant 'n snitlys met skakels na stukke wat met tyd en kwaliteit gekorreleer is, laai die nodige af en wys dit aan die gebruiker, en voer 'n bietjie "towerkrag" langs die pad uit.

Tydlyn voorbeeld

- 'n Knoppie is reg in die speler ingebou om 'n tydlyn van alle verslae te vertoon ...

Nikolay: Ja, ons het dadelik die probleem van gebruikersnavigasie opgelos. In die middel van April het ons besluit dat ons nie elkeen van ons konferensies op 'n aparte webwerf sal uitsaai nie, maar alles op een sal kombineer. Sodat Full Pass-kaartjiegebruikers vryelik tussen verskillende konferensies kan wissel: beide regstreekse uitsendings en opnames van voriges.

En om dit vir gebruikers makliker te maak om deur die huidige stroom te navigeer en tussen snitte te wissel, het ons besluit om 'n "Hele uitsending"-knoppie en horisontale verslagkaarte te maak om tussen snitte en verslae te wissel. Daar is sleutelbordbeheer.

— Was daar enige tegniese probleme hiermee?

Nikolay: Hulle het 'n rolbalk gehad waarop die beginpunte van verskillende verslae gemerk is.

— Het jy uiteindelik hierdie merke op die rolbalk geïmplementeer voordat YouTube iets soortgelyks gedoen het?

Artyom: Hulle het dit toe in beta gehad. Dit lyk asof dit 'n redelik komplekse kenmerk is, want hulle het dit die afgelope jaar gedeeltelik met gebruikers getoets. En nou het dit verkoop bereik.

Nikolay: Maar ons het dit eintlik vinniger te koop gekry. Eerlik, agter hierdie eenvoudige kenmerk is daar 'n groot hoeveelheid backend, frontend, berekeninge en wiskunde binne die speler.

Voorkant

— Kom ons vind uit hoe hierdie inhoud wat ons wys (spraakkaart, sprekers, webwerf, skedule) aan die voorkant kom?

Vladimir Krasilshchik: Ons het verskeie interne IT-stelsels. Daar is 'n stelsel waarin alle verslae en alle sprekers ingevoer word. Daar is 'n proses waardeur 'n spreker aan 'n konferensie deelneem. Die spreker dien 'n aansoek in, die stelsel vang dit vas, dan is daar 'n sekere pyplyn waarvolgens die verslag geskep word.

Dit is hoe die spreker die pyplyn sien

Hierdie stelsel is ons interne ontwikkeling.

Vervolgens moet u 'n skedule uit individuele verslae bou. Soos u weet, is dit 'n NP-harde probleem, maar ons los dit op een of ander manier op. Om dit te doen, begin ons nog 'n komponent wat 'n skedule genereer en dit oplaai na die derdeparty-wolkdiens Contentful. Daar lyk alles soos 'n tafel waarin daar dae van die konferensie is, in die dae is daar tydgleuwe, en in die gleuwe is daar verslae, pouses of borgaktiwiteite. Die inhoud wat ons sien, is dus in 'n derdepartydiens geleë. En die taak is om dit na die webwerf oor te dra.

Dit wil voorkom asof die webwerf net 'n bladsy met 'n speler is, en hier is niks ingewikkeld nie. Behalwe dat dit nie is nie. Die agterkant agter hierdie bladsy gaan na Contentful, kry die skedule van daar af, genereer 'n paar voorwerpe en stuur dit na die frontend. Met behulp van 'n websocket-verbinding, wat elke kliënt van ons platform maak, stuur ons vir hom 'n opdatering van die skedule van die agterkant na die voorkant.

Werklike geval: die spreker het direk tydens die konferensie van werk verander. Ons moet sy werkgewer se maatskappy-kenteken verander. Hoe gebeur dit vanaf die agterkant? 'n Opdatering word aan alle kliënte via die websocket gestuur, en dan teken die frontend self die tydlyn oor. Dit alles gebeur naatloos. Die kombinasie van die wolkdiens en verskeie van ons komponente gee ons die geleentheid om al hierdie inhoud te genereer en dit aan die voorkant te verskaf.

Nikolay: Dit is belangrik om hier te verduidelik dat ons webwerf nie 'n klassieke SPA-toepassing is nie. Dit is beide 'n uitleg-gebaseerde, gelewerde webwerf en 'n SPA. Google sien eintlik hierdie webwerf as gelewerde HTML. Dit is goed vir SEO en om inhoud aan die gebruiker te lewer. Dit wag nie vir 1,5 megagrepe JavaScript om te laai voordat dit die bladsy sien nie, dit sien dadelik die reeds gelewerde bladsy, en jy voel dit elke keer as jy die verslag verander. Alles gebeur binne 'n halwe sekonde, aangesien die inhoud reeds gereed is en op die regte plek geplaas is.

— Kom ons trek 'n streep onder al die bogenoemde deur die tegnologieë te lys. Tyoma het gesê dat ons 5 Amazon-strome het, en ons lewer video en klank daar. Ons het bash-skrifte daar, ons gebruik dit om te begin en op te stel ...

Artyom: Dit gebeur deur die AWS API, daar is baie meer tegniese bydienste daar. Ons het ons verantwoordelikhede verdeel sodat ek lewer aan Wolkfront, en front-end en back-end ontwikkelaars neem dit van daar af. Ons het 'n aantal van ons eie bindings om die uitleg van inhoud te vereenvoudig, wat ons dan in 4K maak, ens. Aangesien die sperdatums baie streng was, het ons dit amper heeltemal op AWS gedoen.

- Dan gaan dit alles na die speler met behulp van die backend-stelsel. Ons het TypeScript, React, Next.JS in ons speler. En op die agterkant het ons verskeie dienste in C#, Java, Spring Boot en Node.js. Dit word alles ontplooi met behulp van Kubernetes met behulp van die Yandex.Cloud-infrastruktuur.

Ek wil ook daarop let dat toe ek met die platform kennis moes maak, dit maklik geblyk het te wees: al die bewaarplekke is op GitLab, alles is goed genoem, toetse word geskryf, daar is dokumentasie. Dit wil sê, selfs in noodmodus het hulle vir sulke goed gesorg.

Besigheidsbeperkings en analise

— Ons het 10 000 gebruikers geteiken op grond van besigheidsvereistes. Dit is tyd om te praat oor die besigheidsbeperkings wat ons gehad het. Ons moes 'n hoë werklading verseker, die nakoming van die wet op die bewaring van persoonlike data verseker. En wat nog?

Nikolay: Aanvanklik het ons van videovereistes begin. Die belangrikste ding is verspreide videoberging regoor die wêreld vir vinnige aflewering aan die kliënt. Ander sluit in 1080p-resolusie, sowel as terugspoel, wat baie ander nie in lewendige modus implementeer nie. Later het ons die vermoë bygevoeg om 2x spoed te aktiveer, met die hulp daarvan kan jy die regstreekse "inhaal" en voortgaan om die konferensie intyds te kyk. En langs die pad het tydlynmerkfunksionaliteit verskyn. Boonop moes ons foutverdraagsaam wees en die las van 10 000 verbindings weerstaan. Vanuit 'n backend-oogpunt is dit ongeveer 10 000 verbindings vermenigvuldig met 8 versoeke vir elke bladsyverversing. En dit is reeds 80 000 RPS/sek. Nogal 'n bietjie van.

— Was daar enige ander vereistes vir 'n "virtuele uitstalling" met aanlyn-stalletjies van vennote?

Nikolay: Ja, dit moes redelik vinnig en universeel gedoen word. Ons het tot 10 vennootmaatskappye vir elke konferensie gehad, en almal moes binne 'n week of twee voltooi word. Hul inhoud verskil egter effens in formaat. Maar 'n sekere sjabloon-enjin is gemaak wat hierdie bladsye vinnig bymekaarmaak, met feitlik geen verdere ontwikkelingsdeelname nie.

— Daar was ook vereistes vir ontleding van intydse aansigte en statistieke. Ek weet dat ons Prometheus hiervoor gebruik, maar vertel ons in meer besonderhede: aan watter vereistes voldoen ons vir ontleding, en hoe word dit geïmplementeer?

Nikolay: Aanvanklik het ons bemarkingsvereistes vir die insameling vir A/B-toetsing en die insameling van inligting om te verstaan ​​hoe om die beste inhoud in die toekoms behoorlik aan die kliënt te lewer. Daar is ook vereistes vir sommige ontledings oor vennootaktiwiteite en die ontledings wat jy sien (besoektoonbank). Alle inligting word intyds ingesamel.

Ons kan hierdie inligting in saamgestelde vorm selfs aan sprekers verskaf: hoeveel mense het jou op 'n sekere tydstip dopgehou. Terselfdertyd, om aan Federale Wet 152 te voldoen, word u persoonlike rekening en persoonlike data op geen manier nagespoor nie.

Die platform het reeds bemarkingsinstrumente en ons maatstawwe om gebruikersaktiwiteit in reële tyd te meet (wie het watter tweede van die verslag gekyk het) om grafieke van bywoning van die verslae te bou. Op grond van hierdie data word navorsing gedoen wat die volgende konferensies beter sal maak.

Bedrog

— Het ons meganismes teen bedrog?

Nikolay: Weens die beknopte tydsraamwerk vanuit 'n besigheidsoogpunt, was die taak aanvanklik nie gestel om onnodige verbindings onmiddellik te blokkeer nie. As twee gebruikers onder dieselfde rekening aangemeld het, kan hulle die inhoud sien. Maar ons weet hoeveel gelyktydige sienings daar uit een rekening was. En ons het verskeie besonder kwaadwillige oortreders verbied.

Vladimir: Tot sy krediet het een van die verbode gebruikers verstaan ​​hoekom dit gebeur het. Hy het gekom, om verskoning gevra en belowe om 'n kaartjie te koop.

— Vir dit alles om te gebeur, moet jy alle gebruikers van ingang tot uitgang heeltemal opspoor, altyd weet wat hulle doen. Hoe werk hierdie stelsel?

Vladimir: Ek wil graag praat oor analise en statistiek, wat ons dan ontleed vir die sukses van die verslag of dan aan vennote kan verskaf. Alle kliënte word via 'n websokverbinding aan 'n spesifieke backend-kluster gekoppel. Dit staan ​​daar haselgiet. Elke kliënt stuur in elke tydperk wat hy doen en watter snit hy kyk. Dan word hierdie inligting saamgevoeg met behulp van vinnige Hazelcast-take en teruggestuur na almal wat hierdie snitte kyk. Ons sien in die hoek hoeveel mense nou by ons is.

Dieselfde inligting word gestoor in Mongo en gaan na ons datameer, waaruit ons die geleentheid het om 'n meer interessante grafiek te bou. Die vraag ontstaan: hoeveel unieke gebruikers het hierdie verslag bekyk? Ons gaan na Nagraadse, daar is pings van al die mense wat deur die id van hierdie verslag gekom het. Ons het uniekes versamel, saamgevoeg, en nou kan ons verstaan.

Nikolay: Maar terselfdertyd ontvang ons ook intydse data van Prometheus. Dit is ingestel teen alle Kubernetes-dienste, teen Kubernetes self. Dit versamel absoluut alles, en met Grafana kan ons enige grafieke in reële tyd bou.

Vladimir: Aan die een kant laai ons dit af vir verdere OLAP-verwerking. En vir OLTP laai die toepassing die hele ding af na Prometheus, Grafana en die grafieke konvergeer selfs!

- Dit is die geval wanneer die grafieke konvergeer.

Dinamiese veranderinge

— Vertel ons hoe dinamiese veranderinge uitgerol word: as die verslag 6 minute voor die begin gekanselleer is, wat is die ketting van aksies? Watter pypleiding werk?

Vladimir: Die pyplyn is baie voorwaardelik. Daar is verskeie moontlikhede. Die eerste is dat die skedulegenereringsprogram gewerk het en die skedule verander het. Die gewysigde skedule word na Contentful opgelaai. Waarna die backend verstaan ​​dat daar veranderings vir hierdie konferensie in Contentful is, neem dit en herbou dit. Alles word afgehaal en via websocket gestuur.

Die tweede moontlikheid, wanneer alles teen 'n yslike pas gebeur: die redigeerder verander met die hand die inligting in Contentful (skakel na Telegram, spreker se aanbieding, ens.) en dieselfde logika werk as die eerste keer.

Nikolay: Alles gebeur sonder om die bladsy te verfris. Alle veranderinge vind absoluut naatloos vir die kliënt plaas. Dieselfde geld vir die omskakeling van verslae. Wanneer die tyd aanbreek, verander die verslag en koppelvlak.

Vladimir: Daar is ook tydafsnypunte vir die begin van verslae in die tydlyn. Heel aan die begin is daar niks. En as jy jou muis oor die rooi streep beweeg, dan sal daar een of ander tyd, danksy die uitsaaidirekteur, afsnypunte verskyn. Die regisseur stel die korrekte begin van die uitsending, die agterkant tel hierdie verandering op, bereken die begin- en eindtye van die hele baan se aanbiedings in ooreenstemming met die konferensieskedule, stuur dit aan ons kliënte, en die speler trek afsnypunte. Nou kan die gebruiker maklik na die begin en einde van die verslag navigeer. Dit was 'n streng besigheidsvereiste, baie gerieflik en nuttig. Jy mors nie tyd om die werklike begintyd vir die verslag te vind nie. En wanneer ons 'n voorskou doen, sal dit absoluut wonderlik wees.

Ontplooiing

— Ek wil graag vra oor ontplooiing. Kolya en die span het aan die begin baie tyd spandeer om die hele infrastruktuur op te rig waarin alles vir ons ontvou. Sê vir my, waaruit is dit alles gemaak?

Nikolay: Uit 'n tegniese oogpunt het ons aanvanklik 'n vereiste gehad dat die produk so abstrak as moontlik van enige verkoper moes wees. Kom na AWS om Terraform-skrifte spesifiek vanaf AWS te maak, of spesifiek van Yandex, of van Azure, ens. het nie regtig gepas nie. Ons moes een of ander tyd iewers heen trek.

Vir die eerste drie weke was ons voortdurend op soek na 'n manier om dit beter te doen. As gevolg hiervan het ons tot die gevolgtrekking gekom dat Kubernetes in hierdie geval ons alles is, want dit stel ons in staat om outomatiese skaaldienste te skep, outomaties te ontplooi en byna alle dienste uit die boks te kry. Natuurlik moes alle dienste opgelei word om met Kubernetes, Docker te werk, en die span moes ook leer.

Ons het twee groepe. Toets en produksie. Hulle is absoluut identies in terme van hardeware en instellings. Ons implementeer infrastruktuur as kode. Alle dienste word outomaties in drie omgewings uitgerol vanaf kenmerktakke, meestertakke, toetstakke en GitLab met behulp van 'n outomatiese pyplyn. Dit is maksimaal geïntegreer in GitLab, maksimaal geïntegreer met Elastic, Prometheus.

Ons kry die geleentheid om vinnig (vir die agterkant binne 10 minute, vir die voorkant binne 5 minute) veranderinge aan enige omgewing uit te voer met alle toetse, integrasies, lopende funksionele toetse, integrasietoetse op die omgewing, en ook toets met lastoetse op 'n toetsomgewing ongeveer dieselfde ding wat ons in produksie wil kry.

Oor toetse

— Jy toets amper alles, dis moeilik om te glo hoe jy alles geskryf het. Kan u ons vertel van die backend-toetse: hoeveel alles gedek word, watter toetse?

Vladimir: Twee tipes toetse is geskryf. Die eerste is komponenttoetse. Lig vlaktoetse van die hele veertoediening en baseer in Toetshouers. Dit is 'n toets van die hoogste vlak besigheid scenario's. Ek toets nie funksies nie. Ons toets net 'n paar groot dinge. Byvoorbeeld, direk in die toets word die proses om by 'n gebruiker aan te meld, nagevolg, die gebruiker se versoek vir kaartjies waarheen hy kan gaan, en 'n versoek om toegang om die stroom te kyk. Baie duidelike gebruikersscenario's.

Ongeveer dieselfde ding word geïmplementeer in die sogenaamde integrasietoetse, wat eintlik op die omgewing loop. Trouens, wanneer die volgende ontplooiing in produksie ontplooi word, loop werklike basiese scenario's ook in produksie. Dieselfde aanmeld, versoek kaartjies, versoek toegang tot CloudFront, kontroleer dat die stroom regtig met my toestemmings verbind, kontroleer die direkteur se koppelvlak.

Op die oomblik het ek sowat 70 komponenttoetse en sowat 40 integrasietoetse aan boord. Dekking is baie naby aan 95%. Dit is vir komponente, minder vir integrasie, daar is eenvoudig nie so nodig nie. As in ag geneem word dat die projek allerhande kodegenerering behels, is dit 'n baie goeie aanwyser. Daar was geen ander manier om te doen wat ons in drie maande gedoen het nie. Want as ons handmatig toets, kenmerke aan ons toetser gee, en sy sou foute vind en dit aan ons terugbesorg vir regstellings, dan sou hierdie rondreis om die kode te ontfout baie lank wees, en ons sou geen sperdatums haal nie.

Nikolay: Konvensioneel, om 'n regressie op die hele platform uit te voer wanneer jy een of ander funksie verander, moet jy vir twee dae oral sit en steek.

Vladimir: Daarom is dit 'n groot sukses dat wanneer ek 'n kenmerk skat, ek sê dat ek 4 dae nodig het vir twee eenvoudige penne en 1 websok, Kolya laat dit toe. Hy is reeds gewoond daaraan dat hierdie 4 dae 2 tipes toetse insluit, en dan sal dit heel waarskynlik werk.

Nikolay: Ek het ook 140 toetse geskryf: komponent + funksioneel, wat dieselfde ding doen. Al dieselfde scenario's word in produksie, in toets en in produksie getoets. Ons het ook onlangs funksionele basiese UI-toetse bygevoeg. Op hierdie manier dek ons ​​die mees basiese funksionaliteit wat uitmekaar kan val.

Vladimir: Natuurlik is dit die moeite werd om oor vragtoetse te praat. Dit was nodig om die platform onder 'n las naby die regte een te toets om te verstaan ​​hoe alles is, wat gebeur met Rabbit, wat gebeur met die JVM's, hoeveel geheue eintlik nodig is.

— Ek weet nie vir seker of ons iets aan die stroomkant toets nie, maar ek onthou dat daar probleme met transkodeerders was toe ons ontmoetings gedoen het. Het ons die strome getoets?

Artyom: Iteratief getoets. Organiseer ontmoetings. In die proses om byeenkomste te reël, was daar ongeveer 2300 XNUMX JIRA-kaartjies. Dit is net generiese dinge wat mense gedoen het om ontmoetings te maak. Ons het dele van die platform na 'n aparte bladsy vir ontmoetings geneem, wat deur Kirill Tolkachev (praatkv).

Om eerlik te wees, was daar geen groot probleme nie. Ons het letterlik 'n paar keer kasfoute op CloudFront gevang, ons het dit redelik vinnig opgelos - ons het eenvoudig die beleide herkonfigureer. Daar was aansienlik meer foute in mense, in die stroomstelsels op die webwerf.

Tydens die konferensies moes ek nog verskeie uitvoerders skryf om meer toerusting en dienste te dek. Op sommige plekke moes ek my eie fietse maak net ter wille van metrieke. Die wêreld van AV (klank-video) hardeware is nie baie rooskleurig nie - jy het 'n soort "API" van toerusting wat jy eenvoudig nie kan beïnvloed nie. En dit is ver van 'n feit dat jy die inligting sal kan kry wat jy nodig het. Hardewareverkopers is baie stadig, en dit is amper onmoontlik om van hulle te kry wat jy wil hê. In totaal is daar meer as 100 stukke hardeware, hulle gee nie terug wat jy nodig het nie, en jy skryf vreemde en oortollige uitvoerders, waardeur jy op een of ander manier die stelsel kan ontfout.

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

— Ek onthou hoe ons voor die aanvang van die konferensies gedeeltelik bykomende toerusting aangekoop het.

Artyom: Ons het rekenaars, skootrekenaars en batterypakke gekoop. Op die oomblik kan ons vir 40 minute sonder elektrisiteit lewe. In Junie was daar hewige donderstorms in St. Petersburg - so ons het so 'n blackout gehad. Terselfdertyd kom verskeie verskaffers na ons toe met optiese skakels vanaf verskillende punte. Dit is regtig 40 minute se bou-stilstand, waartydens ons ligte aan, klank, kameras, ens. sal laat werk.

— Ons het 'n soortgelyke storie met die internet. In die kantoor waar ons ateljees geleë is, het ons 'n kwaai net tussen die vloere gesleep.

Artyom: Ons het 20 Gbit vesel tussen vloere. Verder langs die vloere, iewers is daar optika, iewers is daar geen optika nie, maar steeds is daar minder kanale as gigabit-kanale - ons laat video daarop loop tussen die bane van die konferensie. Oor die algemeen is dit baie gerieflik om aan jou eie infrastruktuur te werk; jy kan dit selde by vanlyn konferensies op werwe doen.

— Voordat ek by JUG Ru Group gewerk het, het ek gesien hoe hardeware kamers by vanlyn konferensies oornag ingerig is, waar daar 'n groot monitor was met al die maatstawwe wat jy in Grafana bou. Nou is daar ook 'n hoofkwartierkamer waarin die ontwikkelingspan sit, wat tydens die konferensie 'n paar foute regstel en kenmerke ontwikkel. Terselfdertyd is daar 'n moniteringstelsel wat op 'n groot skerm vertoon word. Artyom, Kolya en ander ouens sit en sorg dat alles nie val nie en pragtig werk.

Nuuskierigheid en probleme

— Jy het goed gepraat oor die feit dat ons met Amazon stroom, daar is 'n speler met die web, alles is in verskillende programmeertale geskryf, foutverdraagsaamheid en ander besigheidsvereistes word verskaf, insluitend 'n persoonlike rekening wat ondersteun word vir regsentiteite en individue, en ons kan integreer met iemand wat OAuth 2.0 gebruik, is daar anti-bedrog, gebruikersblokkering. Ons kan veranderinge dinamies uitrol omdat ons dit goed gedoen het, en dit is alles getoets.

Ek stel belang om te weet watter eienaardighede betrokke was om iets aan die gang te kry. Was daar enige vreemde situasies toe jy besig was om 'n backend, frontend te ontwikkel, iets mals uitgedraai het en jy nie verstaan ​​het wat om daarmee te doen nie?

Vladimir: Dit lyk vir my of dit net die laaste drie maande gebeur het. Elke dag. Soos jy kan sien, is al my hare uitgetrek.

Vladimir Krasilshchik na 3 maande, toe 'n soort speletjie uitgedraai het en niemand verstaan ​​​​wat om daarmee te doen nie

Elke dag was daar so iets, wanneer daar so 'n oomblik was wanneer jy dit vat en jou hare uitskeur, of besef dat daar niemand anders is nie, en net jy kan dit doen. Ons eerste groot geleentheid was TechTrain. Op 6 Junie om 2:2.0 het ons nog nie die produksie-omgewing uitgerol nie, Kolya was besig om dit uit te rol. En die persoonlike rekening het nie gewerk as 'n magtigingsbediener wat OAuth2.0 gebruik nie. Ons het dit in 'n OAuth18-verskaffer verander om die platform daaraan te koppel. Ek het seker XNUMX uur aaneen gewerk, ek het na die rekenaar gekyk en niks gesien nie, ek het nie verstaan ​​hoekom dit nie werk nie, en Kolya het op afstand na my kode gekyk, 'n fout in die lente-konfigurasie gesoek. , het dit gevind, en die LC het gewerk, en ook in produksie.

Nikolay: En 'n uur voor TechTrain het die vrystelling plaasgevind.

Baie sterre was hier in lyn. Ons was baie gelukkig, want ons het 'n super span gehad, en almal is geïnspireer deur die idee om dit aanlyn te doen. Al hierdie drie maande is ons gedryf deur die feit dat ons "YouTube gemaak het." Ek het myself nie toegelaat om my hare uit te skeur nie, maar vir almal gesê alles sal regkom, want eintlik is alles lankal bereken.

Oor prestasie

— Kan jy vir my sê hoeveel mense op een baan op die werf was? Was daar enige prestasieprobleme?

Nikolay: Daar was geen prestasieprobleme nie, soos ons reeds gesê het. Die maksimum aantal mense wat een verslag bygewoon het was 1300 mense, dit is op Heisenbug.

— Was daar enige probleme met plaaslike besigtiging? En is dit moontlik om 'n tegniese beskrywing met diagramme te hê van hoe dit alles werk?

Nikolay: Ons sal later 'n artikel hieroor maak.

Jy kan selfs strome plaaslik ontfout. Sodra die konferensies begin het, het dit nog makliker geword, want produksiestrome het verskyn waarna ons heeltyd kan kyk.

Vladimir: Soos ek dit verstaan, het front-end ontwikkelaars plaaslik met spots gewerk, en dan, aangesien die tyd om uit te rol na die devs aan die voorkant ook kort is (5 minute), is daar geen probleme om te sien wat aangaan met die sertifikate nie.

— Alles word getoets en ontfout, selfs plaaslik. Dit beteken dat ons 'n artikel met al die tegniese kenmerke sal skryf, jou sal wys, jou alles sal vertel met diagramme, hoe dit was.

Vladimir: Jy kan dit neem en dit herhaal.

- Oor 3 maande.

Totale

— Alles wat saam beskryf word, klink gaaf, as in ag geneem word dat dit in drie maande deur 'n klein span gedoen is.

Nikolay: ’n Groot span sal dit nie doen nie. Maar 'n klein groepie mense wat redelik nou en goed met mekaar kommunikeer en tot 'n vergelyk kan kom. Hulle het geen teenstrydighede nie, die argitektuur is binne twee dae uitgevind, is gefinaliseer en het nie eintlik verander nie. Daar is 'n baie streng fasilitering van inkomende besigheidsvereistes in terme van die opstapel van kenmerkversoeke en veranderinge.

— Wat was op jou lys van verdere take toe die somerkonferensies reeds plaasgevind het?

Nikolay: Byvoorbeeld, krediete. Kruipende lyne op die video, opspringers op sommige plekke in die video, afhangende van die inhoud wat gewys word. Byvoorbeeld, die spreker wil 'n vraag aan die gehoor stel, en 'n stem verskyn op die skerm, wat teruggaan na die agterkant gebaseer op die stemuitslae aan die spreker self. Een of ander sosiale aktiwiteit in die vorm van hou, harte, graderings van die verslag tydens die aanbieding self, sodat jy terugvoer op die regte oomblik kan invul sonder om later deur terugvoervorms afgelei te word. Aanvanklik so.

En voeg ook by tot die hele platform, behalwe vir streaming en konferensie, ook 'n post-konferensie toestand. Dit is snitlyste (insluitend dié wat deur gebruikers saamgestel is), moontlik inhoud van ander vorige konferensies, geïntegreer, geëtiketteer, toeganklik vir die gebruiker, en ook beskikbaar vir besigtiging op ons webwerf (live.jugru.org).

— Ouens, baie dankie vir julle antwoorde!

As daar onder die lesers diegene is wat ons somerkonferensies bygewoon het, deel asseblief jou indrukke van die speler en uitsaai. Wat was gerieflik, wat het jou geïrriteer, wat sou jy graag in die toekoms wou sien?

As jy belangstel in die platform en dit "in die geveg" wil sien, gebruik ons ​​dit weer op ons herfs-winter konferensies. Daar is 'n hele reeks van hulle, so daar is amper seker een wat reg is vir jou.

Bron: will.com