Dizze maitiid fûnen wy ús yn tige fleurige omstannichheden. Troch de pandemy waard dúdlik dat ús simmerkonferinsjes online ferpleatst wurde moasten. En om se effisjint online te fieren, wiene klearmakke softwareoplossingen net geskikt foar ús; wy moasten ús eigen skriuwe. En wy hiene trije moanne om dit te dwaan.
It is dúdlik dat it trije spannende moannen west hat. Mar fan bûten is it net hielendal dúdlik: wat is in online konferinsjeplatfoarm? Ut hokker dielen bestiet it? Dêrom, op 'e lêste fan' e simmer DevOops-konferinsjes, frege ik dyjingen dy't ferantwurdlik wiene foar dizze taak:
- Nikolay Molchanov - technysk direkteur fan JUG Ru Group;
- Vladimir Krasilshchik is in pragmatyske Java-programmeur dy't wurket oan 'e efterkant (jo koenen ek syn rapporten sjen op ús Java-konferinsjes);
- Artyom Nikonov is ferantwurdlik foar al ús fideostreaming.
Trouwens, op 'e hjerst-winterkonferinsjes sille wy in ferbettere ferzje fan itselde platfoarm brûke - safolle habra-lêzers sille noch har brûkers wêze.
Algemiene ôfbylding
- Wat wie de gearstalling fan it team?
Nikolaj Molchanov: Wy hawwe in analist, in ûntwerper, in tester, trije front-enders, en in back-end. En, fansels, in T-foarmige spesjalist!
- Hoe seach it proses der yn 't algemien út?
Nikolay: Oant heal maart hiene wy hielendal neat klear foar online. En op 15 maart begûn de hiele online karrousel te draaien. Wy sette ferskate repositories op, planden, bepraten de basisarsjitektuer en diene alles yn trije moannen.
Dit gie fansels troch de klassike stadia fan planning, arsjitektuer, seleksje fan funksjes, stimmen foar dy funksjes, belied foar dy funksjes, har ûntwerp, ûntwikkeling, testen. As gefolch hawwe wy op 6 juny alles útrôle nei produksje. . Der wiene 90 dagen foar alles.
- Is it ús slagge om te berikken wat wy ynset hawwe?
Nikolay: Om't wy no online dielnimme oan 'e DevOops-konferinsje, betsjut it dat it wurke. Ik persoanlik ynsette foar it wichtichste ding: ik sil klanten in ark bringe wêrmei se in online konferinsje kinne meitsje.
De útdaging wie dit: jou ús in ark wêrmei't wy ús konferinsjes útstjoere kinne nei kaarthâlders.
Alle planning waard ferdield yn ferskate stadia, en alle funksjes (sawat 30 wrâldwiid) waarden ferdield yn 4 kategoryen:
- wat wy perfoarst sille dwaan (wy kinne net sûnder har libje),
- wat wy as twadde sille dwaan,
- wat wy noait sille dwaan,
- en dat sille wy nea, ea dwaan.
Wy hawwe alle funksjes makke fan 'e earste twa kategoryen.
- Ik wit dat der yn totaal 600 JIRA-útjeften makke binne. Yn trije moannen hawwe jo 13 mikrotsjinsten makke, en ik tink dat se net allinich yn Java binne skreaun. Jo hawwe ferskate technologyen brûkt, jo hawwe twa Kubernetes-klusters yn trije beskikberensônes en 5 RTMP-streamen yn Amazon.
Litte wy no elke komponint fan it systeem apart sjen.
Streaming
- Litte wy begjinne mei wannear't wy al in fideoôfbylding hawwe, en it wurdt oerdroegen oan guon tsjinsten. Artyom, fertel ús hoe't dizze streaming bart?
Artyom Nikonov: Us algemiene skema sjocht der sa út: ôfbylding fan 'e kamera -> ús kontrôlekeamer -> lokale RTMP-tsjinner -> Amazon -> fideospieler. Mear details op Habré yn juny.
Yn 't algemien binne d'r twa wrâldwide manieren om dit te dwaan: itsij op hardware as basearre op softwareoplossingen. Wy hawwe de softwarerûte keazen om't it makliker is yn it gefal fan sprekkers op ôfstân. It is net altyd mooglik om hardware nei in sprekker yn in oar lân te bringen, mar it leverjen fan software oan de sprekker liket makliker en betrouberder.
Ut hardware eachpunt hawwe wy in bepaald oantal kamera's (yn ús studio's en by sprekkers op ôfstân), in bepaald oantal ôfstânsbetsjinnings yn 'e studio, dy't by de útstjoering soms krekt ûnder de tafel reparearre wurde moatte.
Sinjalen fan dizze apparaten komme kompjûters yn mei capturekaarten, ynfier- / útfierkaarten en lûdkaarten. Dêr wurde de sinjalen mingd en gearstald yn yndielingen:
Foarbyld fan in yndieling foar 4 sprekkers
Foarbyld fan in yndieling foar 4 sprekkers
Fierder wurdt trochgeande útstjoering fersoarge mei help fan trije kompjûters: d'r is ien haadmasine en in pear wurkjende. De earste kompjûter sammelet it earste rapport, de twadde - de brek, de earste - de folgjende rapport, de twadde - de folgjende brek, ensfh. En de wichtichste masine mingt de earste mei de twadde.
Dit soarget foar in soarte fan trijehoek, en as ien fan dizze knooppunten mislearret, kinne wy fluch en sûnder ferlies fan kwaliteit trochgean mei it leverjen fan ynhâld oan kliïnten. Wy hiene sa'n situaasje. Yn 'e earste wike fan konferinsjes hawwe wy ien masine fêststeld, it oan / útskeakele. Minsken lykje bliid te wêzen mei ús fearkrêft.
Dêrnei geane de streamen fan 'e kompjûters nei in lokale server, dy't twa taken hat: route RTMP-streams en record backups. Sa hawwe wy meardere opnamepunten. De fideostreamen wurde dan stjoerd nei it diel fan ús systeem boud op Amazon SaaS-tsjinsten. Wy brûke ,S3, CloudFront.
Nikolay: Wat bart der foardat de fideo it publyk berikt? Jo moatte it op ien of oare manier snije, krekt?
Artyom: Wy komprimearje de fideo fan ús kant en stjoere it nei MediaLive. Wy lansearje dêr transcoders. Se transkodearje fideo's yn echte tiid yn ferskate resolúsjes, sadat minsken se kinne besjen op har tillefoans, fia min ynternet yn it lân, ensfh. Dan wurde dizze streamen ynknipt , dit is hoe't it protokol wurket . Wy stjoere in playlist nei de frontend dy't oanwizers befettet nei dizze brokken.
- Brûke wy 1080p-resolúsje?
Artyom: De breedte fan ús fideo is itselde as 1080p - 1920 piksels, en de hichte is in bytsje minder, de ôfbylding is langer lang - d'r binne redenen foar dit.
Spiler
- Artyom beskreau hoe't de fideo yn streamen komt, hoe't it wurdt ferdield yn ferskate playlists foar ferskate skermresolúsjes, yn stikken snije en yn 'e spiler komt. Kolya, fertel my no wat foar spiler dit is, hoe't it de stream konsumearret, wêrom HLS?
Nikolay: Wy hawwe in spiler dy't alle konferinsje sjoggers kinne watch.
Yn essinsje is dit in wrapper om 'e biblioteek , dêr't in protte oare spilers binne skreaun. Mar wy hienen in heul spesifike funksjonaliteit nedich: it plak weromlûke en markearje wêr't de persoan is, hokker rapport hy op it stuit sjocht. Ek hiene wy ús eigen opmaak nedich, allerhande logo's en al it oare dat by ús ynboud wie. Dêrom hawwe wy besletten om ús eigen bibleteek te skriuwen (in wrapper oer HLS) en ynbêde it op 'e side.
Dit is de root-funksjonaliteit, dus it waard hast earst ymplementearre. En doe groeide alles der omhinne.
Yn feite, fia autorisaasje, de spiler ûntfangt fan de backend in playlist mei keppelings nei brokken korrelearden mei tiid en kwaliteit, downloads de nedige en toant se oan de brûker, performing wat "magy" lâns de wei.
Foarbyld fan Timeline
- In knop is rjocht yn 'e spiler ynboud om in tiidline fan alle rapporten te werjaan ...
Nikolay: Ja, wy hawwe it probleem fan brûkersnavigaasje fuortendaliks oplost. Heal april hawwe wy besletten dat wy elk fan ús konferinsjes net op in aparte webside sille útstjoere, mar alles op ien kombinearje. Sadat brûkers fan Full Pass-tickets frij kinne wikselje tusken ferskate konferinsjes: sawol live-útstjoerings as opnames fan eardere.
En om it makliker te meitsjen foar brûkers om de aktuele stream te navigearjen en te wikseljen tusken spoaren, hawwe wy besletten om in knop "Hele útstjoering" te meitsjen en horizontale rapportkaarten foar it wikseljen tusken spoaren en rapporten. D'r is toetseboerdkontrôle.
- Wiene der technyske swierrichheden mei?
Nikolay: Se hiene in rôlbalke dêr't de útgongspunten fan ferskate rapporten op markearre waarden.
- Hawwe jo op it lêst dizze tekens op 'e rôlbalke ynfierd foardat YouTube wat ferlykber die?
Artyom: Se hiene it doe yn beta. It liket derop dat dit in frij komplekse funksje is, om't se it it ôfrûne jier foar in part hawwe testen mei brûkers. En no hat it ferkeap berikt.
Nikolay: Mar wy krigen it eins rapper te keap. Earlik sein, efter dizze ienfâldige funksje is d'r in enoarme hoemannichte backend, frontend, berekkeningen en wiskunde binnen de spiler.
Frontend
- Litte wy útfine hoe't dizze ynhâld dy't wy sjen litte (spraakkaart, sprekkers, webside, skema) oan 'e foarkant komt?
Vladimir Krasilshchik: Wy hawwe ferskate ynterne IT-systemen. Der is in systeem wêryn alle ferslaggen en alle sprekkers wurde ynfierd. D'r is in proses wêrby't in sprekker dielnimme oan in konferinsje. De sprekker docht in oanfraach yn, it systeem fangt it op, dan is der in bepaalde pipeline wêrfan it rapport makke wurdt.
Dit is hoe't de sprekker de pipeline sjocht
Dit systeem is ús ynterne ûntwikkeling.
Dêrnei moatte jo in skema bouwe fan yndividuele rapporten. Sa't jo witte, dit is in NP-hurd probleem, mar wy lossen it op ien of oare manier. Om dit te dwaan, lansearje wy in oare komponint dy't in skema generearret en uploadt nei de wolktsjinst fan tredden Contentful. Dêr liket alles op in tafel wêryn't dagen fan 'e konferinsje binne, yn' e dagen binne der tiidslots, en yn 'e slots binne rapporten, pauzes of sponsoraktiviteiten. Dat de ynhâld dy't wy sjogge is te finen yn in tsjinst fan tredden. En de taak is it oer te bringen nei de side.
It soe lykje dat de side is mar in side mei in spiler, en der is neat yngewikkeld hjir. Behalve dat it net is. De backend efter dizze side giet nei Contentful, krijt it skema fan dêrút, genereart wat objekten en stjoert it nei it frontend. Mei help fan in websocket-ferbining, dy't elke klant fan ús platfoarm makket, stjoere wy him in update nei it skema fan 'e efterkant nei it frontend.
Echt gefal: de sprekker feroare fan baan direkt tidens de konferinsje. Wy moatte feroarje syn wurkjouwer bedriuw badge. Hoe bart dit fan 'e efterkant? In update wurdt stjoerd nei alle kliïnten fia de websocket, en dan tekenet de frontend sels de tiidline opnij. Dit alles bart naadloos. De kombinaasje fan 'e wolktsjinst en ferskate fan ús komponinten jout ús de kâns om al dizze ynhâld te generearjen en it oan' e foarkant te leverjen.
Nikolay: It is wichtich om hjir te ferdúdlikjen dat ús side gjin klassike SPA-applikaasje is. Dit is in yndieling, werjûn webside, en SPA. Google sjocht dizze side feitlik as werjûn HTML. Dit is goed foar SEO en foar it leverjen fan ynhâld oan de brûker. It wachtet net foar 1,5 megabytes fan JavaScript om te laden foardat jo de side sjogge, it sjocht fuortendaliks de al werjûn side, en jo fiele it elke kear as jo it rapport wikselje. Alles bart yn in heale sekonde, om't de ynhâld al klear is en op it goede plak pleatst is.
- Litte wy in line tekenje ûnder al it boppesteande troch de technologyen te listjen. Tyoma sei dat wy 5 Amazon-streams hawwe, en wy leverje dêr fideo en lûd. Wy hawwe dêr bash-skripts, wy brûke se om te starten en te konfigurearjen ...
Artyom: Dit bart fia de AWS API, d'r binne dêr folle mear technyske sidetsjinsten. Wy ferdielde ús ferantwurdlikheden sadat ik leverje oan , en front-end en back-end ûntwikkelders nimme it dêrwei. Wy hawwe in oantal fan ús eigen bindingen om de yndieling fan ynhâld te ferienfâldigjen, dy't wy dan meitsje yn 4K, ensfh. Sûnt de deadlines wiene hiel strak, wy diene it hast hielendal op AWS.
- Dan giet dit alles yn 'e spiler mei it backend-systeem. Wy hawwe TypeScript, React, Next.JS yn ús spiler. En op 'e efterkant hawwe wy ferskate tsjinsten yn C #, Java, Spring Boot en Node.js. Dit wurdt allegear ynset mei Kubernetes mei de Yandex.Cloud-ynfrastruktuer.
Ik wol ek opmerke dat doe't ik yn 'e kunde komme moast mei it platfoarm, it maklik blykte te wêzen: alle repositories binne op GitLab, alles is goed neamd, tests wurde skreaun, d'r is dokumintaasje. Dat is, sels yn 'e needmodus hawwe se foar sokke dingen soarge.
Business beheinings en Analytics
- Wy rjochte ús op 10 brûkers basearre op saaklike easken. It is tiid om te praten oer de saaklike beheiningen dy't wy hiene. Wy moasten soargje foar in hege wurkdruk, soargje foar neilibjen fan de wet op it behâld fan persoanlike gegevens. En wat noch mear?
Nikolay: Yn earste ynstânsje begûnen wy fan fideo-easken. It wichtichste ding is ferspraat fideo opslach om 'e wrâld foar snelle levering oan de klant. Oaren omfetsje 1080p-resolúsje, lykas weromspoelen, dy't in protte oaren net yn 'e live-modus ymplementearje. Letter hawwe wy de mooglikheid tafoege om 2x snelheid yn te skeakeljen, mei har help kinne jo de live "ynhelje" en trochgean om de konferinsje yn realtime te besjen. En ûnderweis ferskynde funksjonaliteit foar tiidlinemarkearring. Plus, wy moasten fouttolerant wêze en de lading fan 10 ferbiningen ferneare. Ut in backend eachpunt, dit is likernôch 000 ferbinings fermannichfâldige mei 10 fersiken foar elke side ferfarskje. En dit is al 000 RPS / sek. Hiel wat fan.
- Wiene der oare easken foar in "virtuele tentoanstelling" mei online stands fan partners?
Nikolay: Ja, dit moast frij fluch en universeel dien wurde. Wy hiene oant 10 partnerbedriuwen foar elke konferinsje, en se moasten allegear yn in wike as twa wurde foltôge. Har ynhâld ferskilt lykwols wat yn formaat. Mar in bepaalde sjabloanmotor waard makke dy't dizze siden op 'e flecht gearstalt, mei praktysk gjin dielname oan fierdere ûntwikkeling.
- D'r wiene ek easken foar analyse fan realtime werjeften en statistiken. Ik wit dat wy Prometheus hjirfoar brûke, mar fertel ús yn mear detail: oan hokker easken foldogge wy oan analytyk, en hoe wurdt dit ymplementearre?
Nikolay: Yn earste ynstânsje hawwe wy marketingeasken foar it sammeljen foar A / B-testen en sammeljen fan ynformaasje om te begripen hoe't jo yn 'e takomst de bêste ynhâld goed kinne leverje oan' e klant. D'r binne ek easken foar guon analytiken oer partneraktiviteiten en de analytiken dy't jo sjogge (besiteteller). Alle ynformaasje wurdt sammele yn echte tiid.
Wy kinne dizze ynformaasje yn aggregearre foarm sels oan sprekkers leverje: hoefolle minsken seagen jo op in bepaald momint yn 'e tiid. Tagelyk, om te foldwaan oan Federal Law 152, wurde jo persoanlike akkount en persoanlike gegevens op gjin inkelde manier folge.
It platfoarm hat al marketingynstruminten en ús metriken foar it mjitten fan brûkersaktiviteit yn realtime (wa seach hokker twadde fan it rapport) om grafiken te bouwen fan oanwêzigens by de rapporten. Op grûn fan dizze gegevens wurdt ûndersyk dien dat de folgjende konferinsjes better meitsje sil.
Fraude
- Ha wy anti-fraude meganismen?
Nikolay: Troch it krappe tiidframe út in saaklik eachpunt, wie de taak ynearsten net ynsteld om fuortendaliks ûnnedige ferbinings te blokkearjen. As twa brûkers har oanmeld hawwe ûnder itselde akkount, kinne se de ynhâld besjen. Mar wy witte hoefolle simultane werjeften wiene fan ien akkount. En wy ferbean ferskate benammen kweade oertreders.
Vladimir: Ta syn kredyt begriep ien fan 'e ferbeane brûkers wêrom dit barde. Hy kaam, ferûntskuldigde him en beloofde in kaartsje te keapjen.
- Om dit alles te barren, moatte jo alle brûkers folslein traceare fan yngong oant útgong, altyd witte wat se dogge. Hoe wurket dit systeem?
Vladimir: Ik soe graach prate oer analytics en statistiken, dy't wy dan analysearje foar it sukses fan it rapport of kinne dan leverje oan partners. Alle kliïnten binne ferbûn fia in websocket ferbining mei in spesifyk backend kluster. It stiet dêr . Elke klant stjoert yn elke tiidperioade wat hy docht en hokker spoar hy sjocht. Dan wurdt dizze ynformaasje aggregearre mei snelle Hazelcast-banen en weromstjoerd nei elkenien dy't dizze spoaren sjocht. Wy sjogge yn 'e hoeke hoefolle minsken no by ús binne.
Deselde ynformaasje wurdt opslein yn en giet nei ús gegevensmar, wêrfan wy de kâns hawwe om in nijsgjirriger grafyk te bouwen. De fraach ûntstiet: hoefolle unike brûkers seagen dit rapport? Wy gean nei , der binne pings fan alle minsken dy't kamen troch de id fan dit rapport. Wy sammele, aggregearre unike, en no kinne wy begripe.
Nikolay: Mar tagelyk krije wy ek realtime gegevens fan Prometheus. It is ynsteld tsjin alle Kubernetes tsjinsten, tsjin Kubernetes sels. It sammelt absolút alles, en mei Grafana kinne wy alle grafiken yn realtime bouwe.
Vladimir: Oan 'e iene kant downloade wy dit foar fierdere OLAP-ferwurking. En foar OLTP downloadt de applikaasje it heule ding nei Prometheus, Grafana en de grafiken komme sels gear!
- Dit is it gefal as de grafiken gearkomme.
Dynamyske feroarings
- Fertel ús hoe't dynamyske feroarings wurde útrôle: as it rapport 6 minuten foar it begjin waard annulearre, wat is de keatling fan aksjes? Hokker pipeline wurket?
Vladimir: De pipeline is tige betingst. Der binne ferskate mooglikheden. De earste is dat it programma foar skemageneraasje wurke en it skema feroare. It wizige skema wurdt opladen nei Contentful. Wêrnei't de backend begrypt dat der feroarings binne foar dizze konferinsje yn Contentful, nimt it en bouwt it op 'e nij. Alles wurdt sammele en ferstjoerd fia websocket.
De twadde mooglikheid, as alles bart yn in breakneck tempo: de bewurker feroaret de ynformaasje manuell yn Contentful (keppeling nei Telegram, sprekker syn presintaasje, ensfh) En deselde logika wurket as de earste kear.
Nikolay: Alles bart sûnder de side te ferfarskjen. Alle feroarings komme absolút naadloos foar de klant. Itselde jildt foar it wikseljen fan rapporten. As de tiid komt, feroarje it rapport en ynterface.
Vladimir: Ek binne d'r besunigings foar it begjin fan rapporten yn 'e tiidline. Oan it begjin is der neat. En as jo mei de mûs oer de reade stripe sweve, dan sille op in stuit, tanksij de útstjoerdirekteur, besunigings ferskine. De direkteur stelt it juste begjin fan 'e útstjoering yn, de efterkant nimt dizze feroaring op, berekkent de start- en eintiden fan' e presintaasjes fan 'e hiele spoar yn oerienstimming mei it konferinsjeskema, stjoert it nei ús kliïnten, en de spiler tekent besunigings. No kin de brûker maklik nei it begjin en ein fan it rapport navigearje. It wie in strang saaklike eask, hiel handich en nuttich. Jo fergrieme gjin tiid mei it finen fan de werklike starttiid foar it rapport. En as wy in foarpriuwke dogge, sil it absolút prachtich wêze.
Ynset
- Ik wol freegje oer ynset. Kolya en it team hawwe yn it begjin in protte tiid bestege oan it opsetten fan de hiele ynfrastruktuer wêryn alles foar ús ûntwikkelt. Sis my, wêr is it allegear fan makke?
Nikolay: Ut in technysk eachpunt, wy ynearsten hie in eask foar it produkt te wêzen sa abstrakt mooglik út eltse ferkeaper. Kom nei AWS om Terraform-skripts spesifyk te meitsjen fan AWS, of spesifyk fan Yandex, of fan Azure, ensfh. paste net echt. Wy moasten op in stuit earne ferhúzje.
De earste trije wiken sochten wy hieltyd nei in manier om dit better te dwaan. As gefolch, wy kamen ta de konklúzje dat Kubernetes yn dit gefal is ús alles, omdat it makket it mooglik om te meitsjen automatysk-skaalfergrutting tsjinsten, auto-rollout, en krije hast alle tsjinsten út it fak. Fansels moasten alle tsjinsten trainearre wurde om te wurkjen mei Kubernetes, Docker, en it team moast ek leare.
Wy hawwe twa klusters. Test en produksje. Se binne absolút identyk yn termen fan hardware en ynstellings. Wy implementearje ynfrastruktuer as koade. Alle tsjinsten wurde automatysk útrol yn trije omjouwings fan funksje tûken, master tûken, test tûken, en GitLab mei help fan in automatyske pipeline. Dit is maksimaal yntegrearre yn GitLab, maksimaal yntegrearre mei Elastic, Prometheus.
Wy krije de kâns om fluch (foar de backend binnen 10 minuten, foar de frontend binnen 5 minuten) wizigingen út te rollen nei elke omjouwing mei alle testen, yntegraasjes, funksjonele tests útfiere, yntegraasjetests op 'e omjouwing, en ek testen mei loadtests op in testomjouwing sawat itselde ding dat wy yn produksje wolle krije.
Oer tests
- Jo testje hast alles, it is min te leauwen hoe't jo alles skreaun hawwe. Kinne jo ús fertelle oer de backend-tests: hoefolle alles is bedekt, hokker tests?
Vladimir: Twa soarten tests binne skreaun. De earste binne komponint tests. Lift nivo testen fan de hiele maitiid applikaasje en basis yn . Dit is in test fan saaklike senario's op it heechste nivo. Ik test gjin funksjes. Wy testen allinich wat grutte dingen. Bygelyks, direkt yn 'e test, wurdt it proses fan it oanmelden by in brûker emulearre, it fersyk fan de brûker foar kaartsjes wêr't hy kin gean, en in fersyk foar tagong om de stream te besjen. Hiel dúdlike brûkerssenario's.
Likernôch itselde wurdt útfierd yn de saneamde yntegraasjetests, dy't eins op it miljeu rinne. Yn feite, as de folgjende ynset yn produksje wurdt útrôle, rinne echte basissenario's ek yn produksje. Deselde oanmelding, it oanfreegjen fan tickets, it oanfreegjen fan tagong ta CloudFront, kontrolearjen dat de stream echt oanslút op myn tagongsrjochten, kontrolearjen fan de ynterface fan 'e direkteur.
Op it stuit haw ik sa'n 70 komponinttests en sa'n 40 yntegraasjetests oan board. Dekking is heul tichtby 95%. Dit is foar komponinten, minder foar yntegraasje, d'r is gewoan net sa folle nedich. Yn betinken nommen dat it projekt omgiet alle soarten fan koade generaasje, dit is in hiel goede yndikator. D'r wie gjin oare manier om te dwaan wat wy yn trije moannen dien hawwe. Want as wy mei de hân testen, funksjes jaan oan ús tester, en se soe bugs fine en se nei ús weromjaan foar reparaasjes, dan soe dizze rûnreis om de koade te debuggen heul lang wêze, en wy soene gjin deadlines foldwaan.
Nikolay: Konvinsjoneel, om in regression op it heule platfoarm út te fieren by it feroarjen fan guon funksje, moatte jo twa dagen oeral sitte en poke.
Vladimir: Dêrom is it in grut súkses dat as ik in funksje skatte, sis ik dat ik 4 dagen nedich is foar twa ienfâldige pennen en 1 websocket, Kolya lit it. Hy is al wend oan it feit dat dizze 4 dagen 2 soarten tests befetsje, en dan, nei alle gedachten, sil it wurkje.
Nikolay: Ik haw ek 140 tests skreaun: komponint + funksjoneel, dy't itselde ding dogge. Alle deselde senario's wurde hifke yn produksje, yn test, en yn produksje. Wy hawwe ek koartlyn funksjonele basis UI-tests tafoege. Op dizze manier dekke wy de meast basale funksjonaliteit dy't útinoar falle kinne.
Vladimir: Fansels is it wurdich te praten oer loadtests. It wie nedich om it platfoarm te testen ûnder in lading tichtby de echte om te begripen hoe't alles is, wat bart mei Rabbit, wat bart mei de JVM's, hoefolle ûnthâld is eins nedich.
- Ik wit net wis oft wy wat oan 'e streamkant testen, mar ik wit noch dat d'r problemen wiene mei transcoders doe't wy meetups diene. Hawwe wy de streamen hifke?
Artyom: Iteratyf hifke. It organisearjen fan gearkomsten. Yn it proses fan it organisearjen fan meetups wiene d'r sawat 2300 JIRA-kaarten. Dit binne gewoan generyske dingen dy't minsken dien hawwe om gearkomsten te meitsjen. Wy namen dielen fan it platfoarm op in aparte side foar meetups, dy't rûn waard troch Kirill Tolkachev ().
Om earlik te wêzen, wiene d'r gjin grutte problemen. Letterlik in pear kear hawwe wy caching-bugs op CloudFront fongen, wy hawwe it frij fluch oplost - wy hawwe it belied gewoan opnij konfigureare. D'r wiene signifikant mear bugs yn minsken, yn 'e streamingsystemen op' e side.
Tidens de konferinsjes moast ik noch ferskate eksporteurs skriuwe om mear apparatuer en tsjinsten te dekken. Op guon plakken moast ik gewoan foar de metriken myn eigen fytsen meitsje. De wrâld fan AV (audio-fideo) hardware is net heul roze - jo hawwe in soarte fan "API" fan apparatuer dy't jo gewoan net kinne beynfloedzje. En it is fier fan in feit dat jo kinne krije de ynformaasje dy't jo nedich hawwe. Hardware vendors binne echt stadich, en it is hast ûnmooglik om te krijen wat jo wolle fan harren. Yn totaal binne d'r mear as 100 stikken fan hardware, se jouwe net werom wat jo nedich binne, en jo skriuwe frjemde en oerstallige eksporteurs, wêrtroch jo it systeem op syn minst ien of oare manier kinne debuggen.
Wetter - Agrarwetter
- Ik wit noch hoe't wy foar it begjin fan 'e konferinsjes foar in part ekstra apparatuer kochten.
Artyom: Wy kochten kompjûters, laptops en batterijpakketten. Op it stuit kinne wy 40 minuten sûnder elektrisiteit libje. Yn juny wiene der swiere tongerbuien yn Sint-Petersburch - dus wy hienen sa'n blackout. Tagelyk komme ferskate providers nei ús mei optyske keppelings fan ferskate punten. Dit is echt 40 minuten fan it bouwen fan downtime, wêryn wy ljochten oan, lûd, kamera's, ensfh.
- Wy hawwe in ferlykber ferhaal mei it ynternet. Yn it kantoar dêr't ús ateliers sitte, sleepten wy in fûleindich net tusken de flierren.
Artyom: Wy hawwe 20 Gbit fiber tusken flierren. Fierder lâns de flierren, earne is d'r optyk, earne is d'r gjin optyk, mar dochs binne d'r minder kanalen dan gigabit - wy rinne fideo op har tusken spoaren fan 'e konferinsje. Yn 't algemien is it heul handich om oan jo eigen ynfrastruktuer te wurkjen; jo kinne dit selden dwaan op offline konferinsjes op siden.
- Foardat ik by JUG Ru Group wurke, seach ik hoe't hardwarekeamers op offline konferinsjes fan 'e nacht waarden ynsteld, wêr't in grutte monitor wie mei alle metriken dy't jo bouwe yn Grafana. No is d'r ek in haadkantoar keamer wêryn it ûntwikkelteam sit, dat tidens de konferinsje wat bugs reparearret en funksjes ûntwikkelet. Tagelyk is der in tafersjochsysteem dat op in grut skerm werjûn wurdt. Artyom, Kolya en oare jonges sitte en soargje dat it allegear net falt en moai wurket.
Nijsgjirrichheden en problemen
- Jo sprieken goed oer it feit dat wy streaming hawwe mei Amazon, d'r is in spiler mei it web, alles is skreaun yn ferskate programmeartalen, fouttolerânsje en oare saaklike easken wurde levere, ynklusyf in persoanlik akkount dat wurdt stipe foar juridyske entiteiten en yndividuen, en wy kinne yntegrearje mei immen mei help fan OAuth 2.0, der is anty-fraude, brûker blocking. Wy kinne wizigingen dynamysk útrolje, om't wy it goed dien hawwe, en it is allegear hifke.
Ik bin ynteressearre om te witten hokker nuverheden belutsen wiene by it begjinnen fan wat. Hawwe d'r frjemde situaasjes west doe't jo in backend, frontend ûntwikkele, wat gek die bliken en jo net begrepen wat jo dermei moatte dwaan?
Vladimir: It liket my ta dat dit pas de lêste trije moanne bard is. Eltse dei. Sa't jo sjen kinne, is al myn hier útlutsen.
Vladimir Krasilshchik nei 3 moannen, doe't in soarte fan spultsje die bliken en gjinien begriep wat te dwaan mei it
Elke dei wie der sa'n ding, as der sa'n momint wie dat jo it nimme en jo hier út skuorre, of realisearje dat der gjinien oars is, en allinich jo kinne it dwaan. Us earste grutte evenemint wie TechTrain. Op 6 juny om 2 oere hienen wy de produksjeomjouwing noch net útrôle, Kolya rôle it út. En it persoanlike akkount wurke net as autorisaasjetsjinner mei OAuth2.0. Wy hawwe it feroare yn in OAuth2.0-provider om it platfoarm dêrmei te ferbinen. Ik hie wierskynlik 18 oeren oan it wurk west, ik seach nei de kompjûter en seach neat, ik begriep net wêrom it net wurke, en Kolya seach myn koade op ôfstân, socht nei in brek yn 'e Spring-konfiguraasje , fûn it, en de LC wurke, en ek yn produksje.
Nikolay: En in oere foar TechTrain fûn de frijlitting plak.
In protte stjerren waarden hjir opsteld. Wy wiene ekstreem gelok, om't wy in super team hiene, en elkenien waard ynspirearre troch it idee om it online te dwaan. Al dizze trije moannen waarden wy dreaun troch it feit dat wy "YouTube makken." Ik liet my net myn hier útskuorre, mar sei tsjin elkenien dat alles wol goed komme soe, want eins wie alles lang lyn berekkene.
Oer prestaasjes
- Kinne jo my fertelle hoefolle minsken op ien spoar op 'e side wiene? Wiene der prestaasjesproblemen?
Nikolay: D'r wiene gjin prestaasjesproblemen, lykas wy al sein hawwe. It maksimum oantal minsken dat ien melding bywenne wie 1300 minsken, dit stiet op Heisenbug.
- Wiene der problemen mei it lokale besjen? En is it mooglik om in technyske beskriuwing te hawwen mei diagrammen fan hoe't it allegear wurket?
Nikolay: Wy sille hjir letter in artikel oer meitsje.
Jo kinne sels streams lokaal debugge. Sadree't de konferinsjes begûnen, waard it noch makliker, om't produksjestreamen ferskynden dy't wy de hiele tiid kinne besjen.
Vladimir: As ik it begryp, wurken front-end-ûntwikkelders lokaal mei spots, en dan, om't de tiid om út te rollen nei de devs yn 'e foarkant ek koart is (5 minuten), binne d'r gjin problemen mei it kontrolearjen fan wat der bart mei de sertifikaten.
- Alles wurdt hifke en debuggen, sels lokaal. Dit betsjut dat wy in artikel sille skriuwe mei alle technyske funksjes, jo sjen litte, alles fertelle mei diagrammen, hoe't it wie.
Vladimir: Jo kinne it nimme en it werhelje.
- Yn 3 moannen.
It resultaat
- Alles byinoar beskreaun klinkt cool, yn betinken nommen dat it yn trije moanne dien is troch in lyts team.
Nikolay: In grut team soe dit net dwaan. Mar in lytse groep minsken dy't frij nau en goed mei-inoar kommunisearje en ta in oerienstimming komme kinne. Se hawwe gjin tsjinstridichheden, de arsjitektuer waard yn twa dagen útfûn, waard finalisearre en is eins net feroare. D'r is in heul strikte fasilitearjen fan ynkommende saaklike easken yn termen fan it opstapjen fan funksjefersiken en feroaringen.
- Wat stie op jo list fan fierdere taken doe't de simmerkonferinsjes al west hiene?
Nikolay: Bygelyks, credits. Krûpende rigels op 'e fideo, pop-ups op guon plakken yn' e fideo ôfhinklik fan 'e ynhâld dy't wurdt toand. Bygelyks, de sprekker wol in fraach stelle oan it publyk, en der komt in stimming op it skerm, dy't op basis fan de stimresultaten nei de sprekker sels werom giet. In soarte fan sosjale aktiviteit yn 'e foarm fan likes, herten, wurdearrings fan it rapport tidens de presintaasje sels, sadat jo feedback op it juste momint kinne ynfolje sûnder letter te wurde ôfleid troch feedbackformulieren. Yn earste ynstânsje like this.
En ek tafoegje oan it heule platfoarm, útsein foar streaming en konferinsje, ek in post-konferinsjestatus. Dit binne playlists (ynklusyf dy gearstald troch brûkers), mooglik ynhâld fan oare konferinsjes út it ferline, yntegreare, markearre, tagonklik foar de brûker, en ek beskikber foar besjen op ús webside ().
- Jonges, tige tank foar jo antwurden!
As der ûnder de lêzers degenen binne dy't ús simmerkonferinsjes bywenne, diel dan asjebleaft jo yndrukken fan 'e spiler en útstjoering. Wat wie handich, wat irritearre dy, wat soene jo graach sjen wolle yn 'e takomst?
As jo ynteressearre binne yn it platfoarm en it "yn 'e striid" wolle sjen, brûke wy it opnij op ús . D'r binne in hiele rige fan har, dus d'r is hast wis ien dy't foar jo past.
Boarne: www.habr.com