Sel kevadel sattusime väga rõõmsatesse oludesse. Pandeemia tõttu sai selgeks, et meie suvekonverentsid tuleb üle viia internetti. Ja selleks, et neid veebis tõhusalt läbi viia, ei sobinud meile valmis tarkvaralahendused, tuli ise kirjutada. Ja meil oli selleks aega kolm kuud.
Selge see, et kolm kuud on olnud põnevad. Kuid väljastpoolt pole see täiesti ilmne: mis on veebikonverentsi platvorm? Millistest osadest see koosneb? Seetõttu küsisin viimasel suvisel DevOopsi konverentsil nendelt, kes selle ülesande eest vastutasid:
- Nikolay Molchanov - JUG Ru Groupi tehniline direktor;
- Vladimir Krasilštšik on pragmaatiline Java programmeerija, kes töötab taustaprogrammi kallal (tema aruandeid võis näha ka meie Java konverentsidel);
- Artjom Nikonov vastutab kogu meie video voogesituse eest.
Muide, sügistalvistel konverentsidel kasutame sama platvormi täiustatud versiooni - nii mõnigi habra lugeja jääb selle kasutajaks.
Üldine pilt
— Milline oli meeskonna koosseis?
Nikolai Molchanov: Meil on analüütik, disainer, testija, kolm esiosa ja tagaosa. Ja loomulikult T-kujuline spetsialist!
— Kuidas see protsess üldiselt välja nägi?
Nikolai: Kuni märtsi keskpaigani polnud meil veebis kasutamiseks üldse midagi valmis. Ja 15. märtsil hakkas kogu netikarussell keerlema. Panime püsti mitu hoidlat, planeerisime, arutasime põhiarhitektuuri üle ja tegime kõik kolme kuuga.
See muidugi läbis klassikalise planeerimise, arhitektuuri, funktsioonide valiku, nende funktsioonide hääletamise, nende funktsioonide poliitika, nende disaini, arendamise ja testimise. Selle tulemusena jõudsime 6. juunil kõik tootmisse. . Kõige jaoks oli aega 90 päeva.
— Kas saime sellega hakkama, millele pühendusime?
Nikolai: Kuna osaleme nüüd veebis DevOopsi konverentsil, tähendab see, et see toimis. Pühendasin isiklikult peamisele: toon klientidele tööriista, millega nad saavad veebikonverentsi teha.
Väljakutse oli järgmine: andke meile tööriist, mille abil saame oma konverentse piletiomanikele edastada.
Kogu planeerimine oli jagatud mitmeks etapiks ja kõik funktsioonid (umbes 30 globaalset) jaotati 4 kategooriasse:
- mida me kindlasti teeme (me ei saa ilma nendeta elada),
- mida me teiseks teeme,
- mida me kunagi ei tee,
- ja mida me kunagi, kunagi ei tee.
Tegime kõik funktsioonid kahest esimesest kategooriast.
— Tean, et kokku loodi 600 JIRA väljaannet. Kolme kuu jooksul tegite 13 mikroteenust ja ma kahtlustan, et need pole kirjutatud ainult Java keeles. Kasutasite erinevaid tehnoloogiaid, teil on Amazonis kaks Kubernetese klastrit kolmes saadavuse tsoonis ja viis RTMP-voogu.
Vaatame nüüd süsteemi iga komponenti eraldi.
Voogesitus
— Alustame sellest, kui meil on juba videopilt olemas ja see edastatakse mõnele teenusele. Artjom, räägi meile, kuidas see voogesitus toimub?
Artjom Nikonov: Meie üldine skeem näeb välja selline: pilt kaamerast -> meie juhtimisruum -> kohalik RTMP server -> Amazon -> videopleier. Rohkem detaile juunil Habrel.
Üldiselt on selleks kaks globaalset võimalust: kas riistvara või tarkvaralahenduste baasil. Valisime tarkvaralise marsruudi, kuna kaugkõlarite puhul on see lihtsam. Alati ei ole võimalik riistvara teise riigi kõlarisse tuua, kuid tarkvara kõlarisse toimetamine tundub lihtsam ja töökindlam.
Riistvaraliselt on meil teatud hulk kaameraid (stuudiotes ja kaugkõlarites), stuudios teatud hulk pulte, mida tuleb vahetevahel saate ajal otse laua all parandada.
Nende seadmete signaalid sisenevad arvutitesse püüdmiskaartide, sisend-/väljundkaartide ja helikaartidega. Seal segatakse signaalid ja koondatakse paigutustesse:
4 kõlari paigutuse näide
4 kõlari paigutuse näide
Edasi toimub pidev leviedastus kolme arvuti abil: on üks põhimasin ja paar töökorras olevat. Esimene arvuti kogub esimese aruande, teine - vaheaja, esimene - järgmise aruande, teine - järgmise pausi jne. Ja põhimasin segab esimese teisega.
See loob omamoodi kolmnurga ja kui mõni neist sõlmedest ebaõnnestub, saame kiiresti ja kvaliteeti kaotamata jätkata sisu klientidele edastamist. Meil oli selline olukord. Esimesel konverentsinädalal tegime ühe masina korda, lülitasime sisse/välja. Tundub, et inimesed on meie vastupidavusega rahul.
Järgmisena lähevad arvutite vood kohalikku serverisse, millel on kaks ülesannet: suunata RTMP-vooge ja salvestada varukoopiaid. Seega on meil mitu salvestuspunkti. Seejärel saadetakse videovood meie süsteemi Amazon SaaS-i teenustele ehitatud ossa. Me kasutame ,S3,CloudFront.
Nikolai: Mis seal toimub enne, kui video publikuni jõuab? Sa pead seda kuidagi lõikama, eks?
Artjom: Tihendame omalt poolt video ja saadame selle MediaLive'i. Käivitame seal transkoodrid. Nad transkodeerivad videoid reaalajas mitmeks eraldusvõimeks, et inimesed saaksid neid vaadata oma telefonis, riigi kehva Interneti kaudu jne. Siis need ojad lõigatakse , nii see protokoll töötab . Saadame esiliidese esitusloendi, mis sisaldab viiteid nendele tükkidele.
— Kas me kasutame 1080p eraldusvõimet?
Artjom: Meie video laius on sama, mis 1080p - 1920 pikslit, ja kõrgus on veidi väiksem, pilt on piklikum - sellel on põhjused.
Mängija
— Artjom kirjeldas, kuidas video voogudesse satub, kuidas see eri ekraaniresolutsioonide jaoks erinevatesse esitusloenditesse jaotatakse, tükkideks lõigatakse ja pleierisse satub. Kolja, ütle nüüd, mis mängija see on, kuidas see voogu tarbib, miks HLS?
Nikolai: Meil on mängija, mida kõik konverentsivaatajad saavad vaadata.
Põhimõtteliselt on see ümbris raamatukogu ümber , millele on kirjutatud paljud teised mängijad. Meil oli aga vaja väga spetsiifilist funktsionaalsust: tagasikerimine ja märkimine, kus inimene on, millist aruannet ta parasjagu vaatab. Vaja oli ka oma paigutusi, kõikvõimalikke logosid ja kõike muud, mis meiega kaasa ehitati. Seetõttu otsustasime kirjutada oma teegi (HLS-i ümbris) ja manustada selle saidile.
See on juurfunktsioon, seega rakendati seda peaaegu esimesena. Ja siis kõik selle ümber kasvas.
Tegelikult saab mängija autoriseerimise kaudu taustaprogrammist esitusloendi, mis sisaldab linke aja ja kvaliteediga seotud tükkidele, laadib need alla ja näitab neid kasutajale, tehes sellel teel teatud maagiat.
Ajaskaala näide
— Otse pleierisse on sisse ehitatud nupp kõigi aruannete ajaskaala kuvamiseks...
Nikolai: Jah, me lahendasime kasutajate navigeerimise probleemi kohe. Aprilli keskel otsustasime, et me ei edasta igat oma konverentsi eraldi veebilehel, vaid ühendame kõik ühele. Et Full Passi pileti kasutajad saaksid vabalt vahetada erinevate konverentside vahel: nii otseülekandeid kui ka möödunud konverentside salvestusi.
Ja selleks, et kasutajatel oleks lihtsam praeguses voos navigeerida ja lugude vahel vahetada, otsustasime luua nupu „Kogu edastus” ja horisontaalsed aruandekaardid lugude ja aruannete vahel vahetamiseks. Klaviatuuri juhtimine on olemas.
— Kas sellega seoses oli tehnilisi probleeme?
Nikolai: Neil oli kerimisriba, millele olid märgitud erinevate aruannete lähtekohad.
— Kas kasutasite lõpuks need märgid kerimisribal enne, kui YouTube midagi sarnast tegi?
Artjom: Neil oli see siis beetaversioonis. Tundub, et see on üsna keeruline funktsioon, kuna nad on seda viimase aasta jooksul kasutajatega osaliselt testinud. Ja nüüd on see müügile jõudnud.
Nikolai: Aga tegelikult saime selle kiiremini müüki. Ausalt öeldes on selle lihtsa funktsiooni taga mängija sees tohutul hulgal taustaprogrammi, esiosa, arvutusi ja matemaatikat.
Esiots
— Mõtleme välja, kuidas see sisu, mida näitame (kõnekaart, kõlarid, veebisait, ajakava) esiotsa jõuab?
Vladimir Krasilštšik: Meil on mitu sisemist IT-süsteemi. Seal on süsteem, kuhu sisestatakse kõik aruanded ja kõik esinejad. On olemas protsess, mille käigus esineja osaleb konverentsil. Kõneleja esitab avalduse, süsteem jäädvustab selle, siis on kindel konveier, mille järgi aruanne koostatakse.
Nii näeb kõneleja torujuhet
See süsteem on meie sisemine areng.
Järgmiseks peate koostama ajakava üksikute aruannete põhjal. Nagu teate, on see NP-raske probleem, kuid me lahendame selle kuidagi. Selleks käivitame teise komponendi, mis genereerib ajakava ja laadib selle üles kolmanda osapoole pilveteenusesse Contentful. Seal näeb kõik välja nagu tabel, milles on konverentsipäevad, päevadel on ajapilud ja pesades aruanded, pausid või sponsortegevused. Nii et sisu, mida näeme, asub kolmanda osapoole teenuses. Ja ülesanne on see saidile edastada.
Näib, et sait on lihtsalt pleieriga leht ja siin pole midagi keerulist. Välja arvatud see, et ei ole. Selle lehe taga olev taustaprogramm läheb Contentfuli, hangib sealt ajakava, genereerib mõned objektid ja saadab selle kasutajaliidese. Kasutades veebipesa ühendust, mida iga meie platvormi klient teeb, saadame talle ajakava uuenduse taustaprogrammist esiservani.
Tegelik juhtum: esineja vahetas konverentsi ajal töökohta. Peame muutma tema tööandja ettevõtte märki. Kuidas see taustaprogrammist toimub? Värskendus saadetakse kõikidele klientidele veebipesa kaudu ja seejärel joonistab kasutajaliides ise ajaskaala ümber. Kõik see toimub sujuvalt. Pilveteenuse ja mitme meie komponendi kombinatsioon annab meile võimaluse kogu see sisu genereerida ja esiplaanile pakkuda.
Nikolai: Siinkohal on oluline selgitada, et meie sait ei ole klassikaline SPA-rakendus. See on nii küljendusepõhine, renderdatud veebisait kui ka SPA. Google näeb seda saiti tegelikult renderdatud HTML-ina. See on kasulik SEO jaoks ja kasutajale sisu edastamiseks. See ei oota 1,5 megabaidi JavaScripti laadimist enne lehe nägemist, vaid näeb kohe juba renderdatud lehte ja tunnete seda iga kord, kui aruannet vahetate. Kõik toimub poole sekundiga, sest sisu on juba valmis ja õigesse kohta postitatud.
— Tõmbame tehnoloogiate loetlemisega joone alla kõigele eelnevale. Tyoma ütles, et meil on 5 Amazoni voogu ning me edastame seal videot ja heli. Meil on seal bash-skriptid, mida kasutame käivitamiseks ja konfigureerimiseks...
Artjom: See toimub AWS API kaudu, seal on palju rohkem tehnilisi kõrvalteenuseid. Jagasime oma kohustused nii, et mina toimetan , ning esiotsa ja tagaotsa arendajad võtavad selle sealt. Meil on sisu paigutuse lihtsustamiseks mitmeid oma köiteid, mille teeme siis 4K-s jne. Kuna tähtajad olid väga kitsad, tegime seda peaaegu täielikult AWS-is.
— Seejärel läheb see kõik taustasüsteemi kasutades mängijasse. Meie mängijas on TypeScript, React, Next.JS. Ja taustaprogrammis on meil mitu teenust C#, Java, Spring Boot ja Node.js keeles. See kõik juurutatakse Kubernetese abil, kasutades Yandex.Cloudi infrastruktuuri.
Samuti tahan märkida, et kui mul oli vaja platvormiga tutvuda, osutus see lihtsaks: kõik repositooriumid on GitLabis, kõik on hästi nimetatud, testid on kirjutatud, dokumentatsioon on olemas. See tähendab, et isegi hädaolukorras hoolitsesid nad selliste asjade eest.
Äripiirangud ja analüüs
— Sihisime ärinõuete alusel 10 000 kasutajat. On aeg rääkida äripiirangutest, mis meil olid. Pidime tagama suure töökoormuse, tagama isikuandmete säilitamise seaduse täitmise. Ja mida veel?
Nikolai: Algselt alustasime videonõuetest. Kõige olulisem on üle maailma hajutatud videosalvestus, et kliendile kiirelt kohale toimetada. Teised hõlmavad eraldusvõimet 1080p, aga ka tagasikerimist, mida paljud teised reaalajas režiimis ei rakenda. Hiljem lisasime 2x kiiruse lubamise võimaluse, mille abil saate otseülekandele "järel jõuda" ja konverentsi reaalajas jälgimist jätkata. Ja selle käigus ilmus ajaskaala märgistamise funktsioon. Lisaks pidime olema tõrketaluvusega ja taluma 10 000 ühenduse koormust. Taustaprogrammi seisukohast on see ligikaudu 10 000 ühendust, mis on korrutatud 8 taotlusega iga lehe värskendamise kohta. Ja see on juba 80 000 RPS/sek. Üsna vähe.
— Kas partnerite online-stendiga „virtuaalnäitusele” oli ka muid nõudeid?
Nikolai: Jah, seda tuli teha üsna kiiresti ja universaalselt. Igal konverentsil oli meil kuni 10 partnerettevõtet ja need kõik pidid valmima nädala või paariga. Nende sisu on aga vormilt veidi erinev. Kuid tehti teatud mallimootor, mis paneb need lehed lennult kokku, praktiliselt ilma edasise arenduseta.
— Nõuded olid ka reaalajas vaadete ja statistika analüüsile. Ma tean, et kasutame selleks Prometheust, kuid rääkige meile üksikasjalikumalt: millistele nõuetele me analüütikale vastame ja kuidas seda rakendatakse?
Nikolai: Esialgu on meil turundusnõuded A/B testimiseks ja teabe kogumiseks, et mõista, kuidas edaspidi kliendile parimat sisu õigesti edastada. Nõuded on ka mõnele partnerite tegevuste analüüsile ja kuvatavale analüüsile (külastusloendur). Kogu teave kogutakse reaalajas.
Saame selle teabe koondatud kujul edastada isegi esinejatele: kui palju inimesi teid teatud ajahetkel jälgis. Samal ajal ei jälgita föderaalseaduse 152 järgimiseks teie isiklikku kontot ega isikuandmeid mingil viisil.
Platvormil on juba turundustööriistad ja meie mõõdikud kasutajate aktiivsuse reaalajas mõõtmiseks (kes vaatas, millisel sekundil aruandest), et koostada aruannete külastamise graafikud. Nende andmete põhjal tehakse uuringuid, mis muudavad järgmised konverentsid paremaks.
Pettus
— Kas meil on pettusevastased mehhanismid?
Nikolai: Ärilisest seisukohast kitsa aja tõttu ei seatud ülesandeks esialgu tarbetuid ühendusi koheselt blokeerida. Kui kaks kasutajat logisid sisse sama kontoga, said nad sisu vaadata. Kuid me teame, kui palju üheaegseid vaateid ühelt kontolt oli. Ja keelustasime mitu eriti pahatahtlikku rikkujat.
Vladimir: Kiituseks tuleb öelda, et üks keelatud kasutajatest mõistis, miks see juhtus. Ta tuli, vabandas ja lubas pileti osta.
— Et see kõik juhtuks, peate kõiki kasutajaid sisenemisest väljumiseni täielikult jälgima, teadma alati, mida nad teevad. Kuidas see süsteem töötab?
Vladimir: Tahaksin rääkida analüütikast ja statistikast, mida me siis analüüsime aruande õnnestumiseks või saame seejärel partneritele edastada. Kõik kliendid on veebipesaühenduse kaudu ühendatud konkreetse taustaklastriga. See seisab seal . Iga klient saadab igal ajaperioodil, mida ta teeb ja millist rada ta vaatab. Seejärel koondatakse see teave kiirete Hazelcasti tööde abil ja saadetakse tagasi kõigile, kes neid lugusid vaatavad. Me näeme nurgas, kui palju inimesi on nüüd meiega.
Sama teave on salvestatud ja läheb meie andmejärve, millest meil on võimalus koostada huvitavam graafik. Tekib küsimus: kui palju unikaalseid kasutajaid vaatas seda aruannet? Me läheme , on kõigi selle aruande ID-ga saabunud inimeste pingid. Kogusime kokku, koondasime unikaalsed ja nüüd saame aru.
Nikolai: Kuid samal ajal saame Prometheuselt ka reaalajas andmeid. See on vastuolus kõigi Kubernetese teenustega, Kubernetese enda vastu. See kogub absoluutselt kõike ja Grafana abil saame reaalajas koostada mis tahes graafikuid.
Vladimir: Ühest küljest laadime selle alla OLAP-i edasiseks töötlemiseks. Ja OLTP puhul laadib rakendus kogu asja alla Prometheusesse, Grafanasse ja graafikud isegi koonduvad!
- Seda juhul, kui graafikud koonduvad.
Dünaamilised muudatused
— Rääkige meile, kuidas dünaamilised muudatused ellu viiakse: kui aruanne tühistati 6 minutit enne algust, siis milline on toimingute ahel? Milline torujuhe töötab?
Vladimir: Torujuhe on väga tinglik. Võimalusi on mitu. Esimene on see, et ajakava koostamise programm töötas ja muutis ajakava. Muudetud ajakava laaditakse üles kausta Sisuline. Pärast seda saab taustaprogramm aru, et selle konverentsi jaoks on Contentfulis muudatusi, võtab selle ja ehitab selle uuesti üles. Kõik kogutakse ja saadetakse veebipesa kaudu.
Teine võimalus, kui kõik toimub meeletu tempoga: toimetaja muudab sisulises infot käsitsi (link Telegramile, esineja esitlus jne) ja toimib sama loogika, mis esimesel korral.
Nikolai: Kõik juhtub ilma lehte värskendamata. Kõik muudatused toimuvad kliendi jaoks täiesti sujuvalt. Sama kehtib aruannete vahetamise kohta. Kui aeg kätte jõuab, muutuvad aruanne ja liides.
Vladimir: Samuti on ajaskaalal aruannete alustamiseks ajapiirangud. Päris alguses pole midagi. Ja kui hõljutate hiirega punase triibu kohal, siis ühel hetkel ilmuvad tänu saatejuhile katkestused. Režissöör määrab ülekande õige alguse, taustaprogramm võtab selle muudatuse üles, arvutab kogu pala esitluste algus- ja lõpuajad vastavalt konverentsi ajakavale, saadab selle meie klientidele ja mängija loosib väljalõike. Nüüd saab kasutaja hõlpsalt liikuda aruande algusesse ja lõppu. See oli range ärinõue, väga mugav ja kasulik. Te ei raiska aega aruande tegeliku algusaja leidmisele. Ja kui teeme eelvaate, on see täiesti imeline.
Kasutuselevõtt
— Tahaksin küsida kasutuselevõtu kohta. Kolya ja meeskond kulutasid alguses palju aega, et luua kogu infrastruktuur, milles kõik meie jaoks areneb. Ütle mulle, millest see kõik tehtud on?
Nikolai: Tehnilisest küljest oli meil algselt nõue, et toode oleks võimalikult abstraktne mis tahes müüjalt. Tulge AWS-i, et teha Terraformi skripte spetsiaalselt AWS-ist või konkreetselt Yandexist või Azure'ist jne. ei sobinud eriti. Pidime mingil hetkel kuhugi kolima.
Esimesed kolm nädalat otsisime pidevalt viisi, kuidas seda paremini teha. Selle tulemusena jõudsime järeldusele, et Kubernetes on antud juhul meie jaoks kõik, sest see võimaldab meil luua automaatselt skaleeruvaid teenuseid, automaatset levitamist ja peaaegu kõiki teenuseid karbist välja võtta. Loomulikult tuli kõiki teenuseid koolitada Kubernetese, Dockeriga töötamiseks ja ka meeskond pidi õppima.
Meil on kaks klastrit. Katsetamine ja tootmine. Riistvara ja seadete poolest on need täiesti identsed. Rakendame infrastruktuuri koodina. Kõik teenused levitatakse automaatse torustiku abil automaatselt kolme keskkonda: funktsioonide harudest, põhiharudest, testharudest ja GitLabist. See on maksimaalselt integreeritud GitLabi, maksimaalselt integreeritud Elasticu, Prometheusega.
Saame võimaluse kiiresti (taustaprogrammi jaoks 10 minuti jooksul, esiprogrammi jaoks 5 minuti jooksul) muudatused levitada mis tahes keskkonda koos kõigi testide, integratsioonide, funktsionaalsete testide ja keskkonna integratsioonitestidega ning testida ka koormustestidega testkeskkond, mis on ligikaudu sama, mida tahame tootmises saada.
Testide kohta
— Testid peaaegu kõike, raske on uskuda, kuidas sa kõike kirjutasid. Kas saate rääkida taustatestide kohta: kui palju kõike on kaetud, millised testid?
Vladimir: Kirjutatud on kahte tüüpi teste. Esimesed on komponentide testid. Kogu vedru pealekandmise ja aluse tõstetaseme testid . See on kõrgeima taseme äristsenaariumide test. Ma ei testi funktsioone. Testime ainult mõningaid suuri asju. Näiteks kohe testis emuleeritakse kasutajasse sisselogimise protsessi, kasutaja taotlust piletite saamiseks, kuhu ta saab minna, ja voo vaatamiseks juurdepääsu taotlust. Väga selged kasutajastsenaariumid.
Ligikaudu sama asja rakendatakse ka nn integratsioonitestides, mis tegelikult keskkonnas jooksevad. Tegelikult, kui järgmine kasutuselevõtt tootmises kasutusele võetakse, töötavad tootmises ka tõelised põhistsenaariumid. Sama sisselogimine, piletite taotlemine, juurdepääsu taotlemine CloudFrontile, kontrollimine, kas voog on tõesti minu lubadega ühenduses, direktori liidese kontrollimine.
Hetkel on mul pardal umbes 70 komponenditesti ja umbes 40 integratsioonitesti. Katvus on väga lähedal 95%. See on mõeldud komponentide jaoks, vähem integreerimiseks, seda pole lihtsalt nii palju vaja. Arvestades, et projekt hõlmab kõikvõimalikku koodi genereerimist, on see väga hea näitaja. Seda, mida me kolme kuuga tegime, ei saanud teisiti teha. Sest kui me testiksime käsitsi, andes funktsioonid oma testijale ja ta leiaks vead ja tagastaks need meile paranduste saamiseks, oleks see koodi silumine väga pikk ja me ei peaks kinni tähtaegadest.
Nikolai: Tavapäraselt tuleb mõne funktsiooni muutmisel kogu platvormil regressiooni tegemiseks kaks päeva istuda ja igal pool torkida.
Vladimir: Seetõttu on suur õnnestumine, et funktsiooni hindamisel ütlen, et mul on kahe lihtsa pliiatsi ja 4 veebipesa jaoks vaja 1 päeva, Kolya seda lubab. Ta on juba harjunud, et need 4 päeva sisaldavad kahte tüüpi teste ja siis tõenäoliselt see töötab.
Nikolai: Mul on kirjas ka 140 testi: komponent + funktsionaalne, mis teevad sama asja. Kõiki samu stsenaariume testitakse tootmises, katsetamises ja tootmises. Lisasime hiljuti ka funktsionaalsed kasutajaliidese põhitestid. Nii katame kõige elementaarsemad funktsioonid, mis võivad laguneda.
Vladimir: Muidugi tasub rääkida koormustestidest. Platvormi oli vaja testida päris lähedase koormuse all, et aru saada, kuidas kõik on, mis toimub Rabbitiga, mis toimub JVM-idega, kui palju mälu tegelikult vaja on.
— Ma ei tea täpselt, kas me voo poolel midagi testime, aga mäletan, et kokkusaamiste ajal oli transkooderitega probleeme. Kas oleme vooge testinud?
Artjom: Testitud iteratiivselt. Kohtumiste korraldamine. Kohtumiste korraldamise käigus kogunes ligikaudu 2300 JIRA piletit. Need on lihtsalt üldised asjad, mida inimesed kohtumiste korraldamiseks tegid. Viisime osad platvormist kohtumiste jaoks eraldi lehele, mida juhtis Kirill Tolkatšov ().
Ausalt öeldes suuri probleeme polnud. Sõna otseses mõttes paar korda tabasime CloudFronti vahemällu salvestamise vigu, lahendasime selle üsna kiiresti - konfigureerisime lihtsalt poliitikad ümber. Inimestes, saidi voogedastussüsteemides oli oluliselt rohkem vigu.
Konverentside ajal pidin kirjutama veel mitu eksportijat, et katta rohkem seadmeid ja teenuseid. Kohati pidin lihtsalt mõõdikute pärast ise jalgrattaid tegema. AV (audio-video) riistvara maailm ei ole väga roosiline - teil on mingisugune seadmete API, mida te lihtsalt ei saa mõjutada. Ja see pole kaugeltki tõsiasi, et saate vajalikku teavet. Riistvaramüüjad on tõesti aeglased ja neilt on peaaegu võimatu saada seda, mida soovite. Kokku on riistvara rohkem kui 100 tükki, nad ei anna seda, mida vajate, ja kirjutate kummalisi ja üleliigseid eksportijaid, tänu millele saate süsteemi vähemalt kuidagi siluda.
Оборудование
— Mäletan, kuidas enne konverentside algust ostsime osaliselt lisavarustust.
Artjom: Ostsime arvuteid, sülearvuteid ja akusid. Hetkel saame ilma elektrita elada 40 minutit. Juunis olid Peterburis tugevad äikesetormid – nii et meil oli selline elektrikatkestus. Samal ajal tulevad optiliste linkidega meie juurde mitmed pakkujad erinevatest punktidest. See on tõesti 40 minutit ehitusseisakut, mille jooksul põlevad tuled, heli, kaamerad jne.
— Internetiga on meil sarnane lugu. Kontoris, kus meie stuudiod asuvad, tirisime ägeda võrgu korruste vahele.
Artjom: Meil on korruste vahel 20 Gbit kiudaineid. Edasi mööda korruseid on kuskil optika, kuskil pole optikat, kuid siiski on kanaleid vähem kui gigabitistes - jookseme neil videot konverentsi radade vahel. Üldiselt on oma infrastruktuuri kallal töötamine väga mugav, saitide võrguühenduseta konverentsidel saate seda harva teha.
— Enne JUG Ru Groupis töötamist nägin, kuidas üleöö rajati võrguühenduseta konverentside riistvararuumid, kus oli suur monitor kõigi Grafana loodud mõõdikutega. Nüüd on seal ka peakorteri ruum, kus istub arendusmeeskond, kes konverentsi käigus parandab mõned vead ja arendab funktsioone. Samal ajal on olemas seiresüsteem, mida kuvatakse suurel ekraanil. Artjom, Kolja ja teised tüübid istuvad ja vaatavad, et see kõik ei kukuks ja toimiks ilusti.
Uudishimud ja probleemid
— Rääkisite hästi sellest, et meil on Amazoniga striimimine, veebiga mängija on olemas, kõik on kirjutatud erinevates programmeerimiskeeltes, tagatud on tõrketaluvus ja muud ärinõuded, sh isiklik konto, mida toetatakse juriidilistele isikutele ja üksikisikutele ja me saame OAuth 2.0 kasutajaga integreerida, on olemas pettustevastane ja kasutajate blokeerimine. Saame muudatusi dünaamiliselt kasutusele võtta, sest tegime seda hästi ja kõik on testitud.
Mind huvitab, millised veidrused olid seotud millegi käivitamisega. Kas on olnud kummalisi olukordi, kui arendasite taustaprogrammi, frontendit, juhtus midagi hullu ja te ei saanud aru, mida sellega peale hakata?
Vladimir: Mulle tundub, et seda on juhtunud vaid viimased kolm kuud. Iga päev. Nagu näete, on mul kõik juuksed välja tõmmatud.
Vladimir Krasilštšik pärast 3 kuud, kui tekkis mingi mäng ja keegi ei saanud aru, mida sellega peale hakata
Iga päev oli midagi sellist, kui oli selline hetk, et võtad ja rebid juuksed välja või saad aru, et kedagi teist pole ja ainult sina saad hakkama. Meie esimene suur üritus oli TechTrain. 6. juunil kell 2 öösel ei olnud me veel tootmiskeskkonda välja lasknud, Kolja tegi seda. Ja isiklik konto ei töötanud OAuth2.0 kasutava autoriseerimisserverina. Muutsime selle OAuth2.0 pakkujaks, et platvorm sellega ühendada. Ma olin töötanud vist 18 tundi järjest, vaatasin arvutit ja ei näinud midagi, ma ei saanud aru, miks see ei tööta ja Kolja vaatas mu koodi eemalt, otsis kevade seadistuses viga. , leidis selle ja LC töötas ja ka tootmises .
Nikolai: Ja tund enne TechTraini ilmus.
Siin oli joondatud palju tähti. Meil vedas tohutult, sest meil oli super meeskond ja kõik said inspiratsiooni ideest teha seda veebis. Kõik need kolm kuud ajendas meid asjaolu, et tegime YouTube'i. Ma ei lubanud endal juukseid välja kiskuda, vaid ütlesin kõigile, et kõik saab korda, sest tegelikult oli kõik juba ammu välja arvutatud.
Esituse kohta
— Kas saate öelda, kui palju inimesi oli saidil ühel rajal? Kas esines jõudlusega probleeme?
Nikolai: Esinemisprobleeme ei olnud, nagu me juba ütlesime. Ühel raportil osales maksimaalselt 1300 inimest, see on Heisenbugis.
— Kas kohaliku vaatamisega oli probleeme? Ja kas on võimalik saada tehnilist kirjeldust koos skeemidega, kuidas see kõik töötab?
Nikolai: Teeme selle kohta artikli hiljem.
Saate isegi vooge kohapeal siluda. Kui konverentsid algasid, läks veelgi lihtsamaks, sest tekkisid tootmisvood, mida saame kogu aeg vaadata.
Vladimir: Nagu ma aru saan, töötasid esiotsa arendajad kohapeal pilkudega ja kuna ka esiküljel olevate arendajateni jõudmise aeg on lühike (5 minutit), pole sertifikaatidega toimuva kontrollimisega probleeme.
— Kõike testitakse ja silutakse, isegi kohapeal. See tähendab, et kirjutame artikli kõigi tehniliste omadustega, näitame teile, räägime teile diagrammidega kõike, kuidas see oli.
Vladimir: Võite selle võtta ja korrata.
- 3 kuu pärast.
Summaarne
— Kõik kirjeldatu kokku kõlab lahedalt, kui arvestada, et see sai tehtud väikese meeskonna käe all kolme kuuga.
Nikolai: Suur meeskond seda ei teeks. Aga väike seltskond inimesi, kes suhtlevad omavahel üsna tihedalt ja hästi ning suudavad kokkuleppele jõuda. Mingeid vastuolusid neis ei ole, arhitektuur leiutati kahe päevaga, sai lõplikult valmis ega ole tegelikult muutunud. Sissetulevaid ärinõudeid lihtsustatakse väga rangelt funktsioonitaotluste ja muudatuste kuhjamise osas.
— Mis oli teie edasiste ülesannete nimekirjas, kui suvekonverentsid olid juba toimunud?
Nikolai: Näiteks krediiti. Videol roomavad jooned, mõnes kohas hüpikaknad videos olenevalt kuvatavast sisust. Näiteks soovib kõneleja esitada publikule küsimuse ja ekraanile hüppab hääletus, mis läheb hääletustulemuste põhjal tagasi kõnelejale endale. Mingi seltskondlik tegevus meeldimiste, südamete, aruande hinnangute näol esitluse enda ajal, et saaksite õigel hetkel tagasisidet täita, ilma et teid hiljem tagasiside vormid segaksid. Esialgu niimoodi.
Ja lisaks kogu platvormile, välja arvatud voogedastus ja konverents, ka konverentsijärgne olek. Need on esitusloendid (sealhulgas kasutajate koostatud), võimalik, et sisu muudelt varasematelt konverentsidelt, integreeritud, sildistatud, kasutajale juurdepääsetavad ja ka meie veebisaidil vaatamiseks saadaval ().
- Poisid, tänan teid väga vastuste eest!
Kui lugejate hulgas on neid, kes meie suvekonverentsidel käisid, siis palun jagage oma muljeid mängijast ja saatest. Mis oli mugav, mis ärritas, mida tahaksid tulevikus näha?
Kui olete platvormist huvitatud ja soovite seda "lahingus" näha, kasutame seda uuesti omal . Neid on terve hulk, nii et peaaegu kindlasti leidub üks, mis teile sobib.
Allikas: www.habr.com