Í vor lentum við í mjög glaðværum aðstæðum. Vegna heimsfaraldursins varð ljóst að færa þurfti sumarráðstefnurnar okkar á netið. Og til að framkvæma þær á skilvirkan hátt á netinu henta tilbúnar hugbúnaðarlausnir okkur ekki, við þurftum að skrifa okkar eigin. Og við höfðum þrjá mánuði til að gera þetta.

Það er ljóst að þetta hafa verið spennandi þrír mánuðir. En utan frá er það ekki alveg augljóst: hvað er ráðstefnuvettvangur á netinu? Úr hvaða hlutum er það? Þess vegna spurði ég þá sem stóðu að þessu verkefni á síðustu DevOops ráðstefnum sumarsins:

Nikolay Molchanov - tæknistjóri JUG Ru Group;
Vladimir Krasilshchik er raunsær Java forritari sem vinnur á bakendanum (þú gætir líka séð skýrslur hans á Java ráðstefnum okkar);
Artyom Nikonov er ábyrgur fyrir öllu myndbandsstreymi okkar.

Við the vegur, á haust-vetur ráðstefnum munum við nota endurbætta útgáfu af sama vettvangi - svo margir habra lesendur verða enn notendur þess.

Heildar mynd

— Hver var samsetning liðsins?

Nikolay Molchanov: Við erum með sérfræðing, hönnuð, prófunaraðila, þrjá framenda og bakhlið. Og auðvitað T-laga sérfræðingur!

— Hvernig leit ferlið út almennt?

Nikolay: Þar til um miðjan mars höfðum við alls ekkert tilbúið fyrir netið. Og 15. mars byrjaði öll hringekjan á netinu að snúast. Við settum upp nokkrar geymslur, skipulögðum, ræddum grunnarkitektúrinn og gerðum allt á þremur mánuðum.

Þetta fór auðvitað í gegnum klassískt stig skipulags, byggingarlistar, val á eiginleikum, atkvæðagreiðslu um þá eiginleika, stefnu fyrir þá eiginleika, hönnun þeirra, þróun, prófun. Þar af leiðandi, þann 6. júní, rúlluðum við öllu út í framleiðslu. TechTrain. Það voru 90 dagar fyrir allt.

— Tókst okkur að ná því sem við ætluðum okkur?

Nikolay: Þar sem við erum núna að taka þátt í DevOops ráðstefnunni á netinu þýðir það að hún virkaði. Ég hef persónulega skuldbundið mig til aðalatriðisins: Ég mun færa viðskiptavinum tæki sem þeir geta haldið ráðstefnu á netinu með.

Áskorunin var þessi: gefðu okkur tæki sem við getum útvarpað ráðstefnum okkar til miðaeigenda.

Öllu skipulagi var skipt í nokkur stig og öllum eiginleikum (um 30 á heimsvísu) var skipt í 4 flokka:

sem við munum örugglega gera (við getum ekki lifað án þeirra),
sem við munum gera í öðru lagi,
sem við munum aldrei gera,
og sem við munum aldrei, aldrei gera.

Við gerðum alla eiginleikana úr fyrstu tveimur flokkunum.

— Ég veit að alls voru búin til 600 JIRA tölublöð. Á þremur mánuðum bjóstu til 13 örþjónustur og mig grunar að þær hafi ekki aðeins verið skrifaðar á Java. Þú notaðir mismunandi tækni, þú ert með tvo Kubernetes klasa á þremur framboðssvæðum og 5 RTMP strauma í Amazon.

Við skulum nú skoða hvern hluta kerfisins fyrir sig.

Straumspilun

— Við skulum byrja á því þegar við erum þegar með myndbandsmynd og hún er send til sumra þjónustu. Artyom, segðu okkur hvernig þetta streymi gerist?

Artyom Nikonov: Almennt kerfi okkar lítur svona út: mynd úr myndavélinni -> stjórnherbergið okkar -> staðbundinn RTMP þjónn -> Amazon -> myndbandsspilari. Nánari upplýsingar skrifaði um það á Habré í júní.

Almennt séð eru tvær alþjóðlegar leiðir til að gera þetta: annað hvort á vélbúnaði eða byggðar á hugbúnaðarlausnum. Við völdum hugbúnaðarleiðina vegna þess að það er auðveldara þegar um fjarhátalara er að ræða. Það er ekki alltaf hægt að koma vélbúnaði til hátalara í öðru landi, en það virðist auðveldara og áreiðanlegra að koma hugbúnaði til hátalarans.

Frá vélbúnaðarsjónarmiði erum við með ákveðinn fjölda myndavéla (í vinnustofum okkar og hjá fjarstýrðum hátölurum), ákveðinn fjölda fjarstýringa í stúdíóinu sem stundum þarf að gera við beint undir borðinu á meðan á útsendingu stendur.

Merki frá þessum tækjum fara inn í tölvur með myndatökukortum, inn-/úttakskortum og hljóðkortum. Þar er merkjunum blandað saman og sett saman í skipulag:

Dæmi um skipulag fyrir 4 hátalara

Ennfremur er samfelld útsending veitt með hjálp þriggja tölva: það er ein aðalvél og tvær virkar í röð. Fyrsta tölvan safnar fyrstu skýrslunni, önnur - hlé, fyrsta - næstu skýrslu, önnur - næsta hlé o.s.frv. Og aðalvélin blandar fyrstu saman við seinni.

Þetta skapar eins konar þríhyrning og ef einhver af þessum hnútum mistakast getum við fljótt og án gæðataps haldið áfram að skila efni til viðskiptavina. Við höfðum slíkar aðstæður. Í fyrstu viku ráðstefnunnar laguðum við eina vél, kveiktum/slökktu á henni. Fólk virðist vera ánægt með seiglu okkar.

Næst fara straumarnir frá tölvunum á staðbundinn netþjón, sem hefur tvö verkefni: leiða RTMP strauma og taka afrit. Þannig að við höfum marga upptökupunkta. Vídeóstraumarnir eru síðan sendir í þann hluta kerfisins okkar sem er byggður á Amazon SaaS þjónustu. Við notum MediaLive,S3,CloudFront.

Nikolay: Hvað gerist þar áður en myndbandið nær til áhorfenda? Þú verður að klippa það einhvern veginn, ekki satt?

Artyom: Við þjöppum myndbandinu af okkar hálfu og sendum það til MediaLive. Við kynnum transkóðara þar. Þeir umkóða myndbönd í rauntíma í nokkrar upplausnir svo að fólk geti horft á þau í símanum sínum, í gegnum lélegt net í landinu, og svo framvegis. Síðan eru þessir lækir skornir í klumpur, svona virkar siðareglur HLS. Við sendum lagalista til framenda sem inniheldur ábendingar um þessa bita.

— Erum við að nota 1080p upplausn?

Artyom: Breidd myndbandsins okkar er sú sama og 1080p - 1920 dílar, og hæðin er aðeins minni, myndin er lengri - það eru ástæður fyrir þessu.

Leikmaður

— Artyom lýsti því hvernig myndbandið kemst í strauma, hvernig því er dreift í mismunandi spilunarlista fyrir mismunandi skjáupplausn, klippt í bita og inn í spilarann. Kolya, segðu mér nú hvers konar leikmaður þetta er, hvernig hann eyðir straumnum, hvers vegna HLS?

Nikolay: Við erum með spilara sem allir áhorfendur ráðstefnunnar geta horft á.

Í meginatriðum er þetta umbúðir utan um bókasafnið hls.js, sem margir aðrir leikmenn eru skrifaðir á. En við þurftum mjög sérstaka virkni: spóla til baka og merkja staðinn þar sem viðkomandi er, hvaða skýrslu hann er að horfa á. Okkur vantaði líka okkar eigin útlit, alls kyns lógó og allt annað sem var innbyggt hjá okkur. Þess vegna ákváðum við að skrifa okkar eigið bókasafn (umbúðir yfir HLS) og setja það inn á síðuna.

Þetta er rótarvirknin, svo hún var útfærð næstum fyrst. Og svo óx allt í kringum það.

Reyndar, með heimild, fær spilarinn frá bakendanum lagalista með tenglum á bita sem tengjast tíma og gæðum, hleður niður nauðsynlegum og sýnir þeim notandanum og framkvæmir „töfra“ í leiðinni.

Tímalína dæmi

— Hnappur er innbyggður beint inn í spilarann til að sýna tímalínu yfir allar skýrslur...

Nikolay: Já, við leystum strax vandamálið við notendaleiðsögu. Um miðjan apríl ákváðum við að við myndum ekki senda hverja ráðstefnu okkar á sérstakri vefsíðu heldur sameina allt á eina. Þannig að notendur Full Pass miða geta frjálslega skipt á milli mismunandi ráðstefnur: bæði beinar útsendingar og upptökur af fyrri ráðstefnum.

Og til að auðvelda notendum að vafra um núverandi straum og skipta á milli laga, ákváðum við að búa til „Heil útsending“ hnapp og lárétt tilkynningaspjöld til að skipta á milli laga og skýrslna. Það er lyklaborðsstýring.

— Voru einhverjir tæknilegir erfiðleikar við þetta?

Nikolay: Þeir voru með skrunstiku þar sem upphafsstaðir mismunandi skýrslna voru merktir.

— Að lokum, innleiddir þú þessi merki á skrunstikuna áður en YouTube gerði eitthvað svipað?

Artyom: Þeir voru með það í beta þá. Það virðist sem þetta sé frekar flókinn eiginleiki vegna þess að þeir hafa verið að prófa hann að hluta með notendum undanfarið ár. Og nú er það komið í sölu.

Nikolay: En við fengum það í raun hraðar til sölu. Heiðarlega, á bak við þennan einfalda eiginleika er mikið magn af bakenda, framenda, útreikningum og stærðfræði inni í spilaranum.

Að framanverðu

— Við skulum reikna út hvernig þetta efni sem við sýnum (talkort, hátalarar, vefsíða, dagskrá) kemst í framenda?

Vladimir Krasilshchik: Við erum með nokkur innri upplýsingatæknikerfi. Það er kerfi þar sem allar skýrslur og allir fyrirlesarar eru færðir inn. Það er ferli þar sem fyrirlesari tekur þátt í ráðstefnu. Ræðumaður sendir inn umsókn, kerfið fangar hana, svo er ákveðin leiðsla sem skýrslan er búin til eftir.

Svona sér ræðumaðurinn leiðsluna

Þetta kerfi er innri þróun okkar.

Næst þarftu að búa til áætlun úr einstökum skýrslum. Eins og þú veist er þetta NP-hart vandamál en við leysum það einhvern veginn. Til að gera þetta ræsum við annan íhlut sem býr til áætlun og hleður henni upp á skýjaþjónustu þriðja aðila Contentful. Þar lítur allt út eins og borð þar sem eru ráðstefnudagar, á dögunum eru tímar og í afgreiðslum eru skýrslur, hlé eða styrktarstarfsemi. Þannig að efnið sem við sjáum er staðsett í þjónustu þriðja aðila. Og verkefnið er að koma því á síðuna.

Það virðist sem síðan sé bara síða með spilara og það er ekkert flókið hér. Nema svo er ekki. Bakendinn á bak við þessa síðu fer í Contentful, fær áætlunina þaðan, býr til nokkra hluti og sendir til framenda. Með því að nota nettengingu, sem sérhver viðskiptavinur pallsins okkar gerir, sendum við honum uppfærslu á áætluninni frá bakenda til framenda.

Raunverulegt tilfelli: ræðumaðurinn skipti um starf rétt á meðan á ráðstefnunni stóð. Við þurfum að breyta merki vinnuveitandafyrirtækisins hans. Hvernig gerist þetta frá bakendanum? Uppfærsla er send til allra viðskiptavina í gegnum netsokkinn og síðan teiknar framendinn sjálft tímalínuna. Allt þetta gerist óaðfinnanlega. Samsetning skýjaþjónustunnar og nokkurra íhluta okkar gefur okkur tækifæri til að búa til allt þetta efni og veita það að framan.

Nikolay: Það er mikilvægt að skýra hér að síðan okkar er ekki klassískt SPA forrit. Þetta er bæði útlitsbundin, sýnd vefsíða og SPA. Google lítur í raun á þessa síðu sem endurgert HTML. Þetta er gott fyrir SEO og til að koma efni til notandans. Það bíður ekki eftir að 1,5 megabæti af JavaScript hleðst upp áður en það sér síðuna, það sér strax þá síðu sem þegar hefur verið birt og þú finnur fyrir því í hvert skipti sem þú skiptir um skýrslu. Allt gerist á hálfri sekúndu, þar sem efnið er þegar tilbúið og sett á réttan stað.

- Við skulum draga línu undir allt ofangreint með því að skrá tæknina. Tyoma sagði að við værum með 5 Amazon strauma og við sendum myndband og hljóð þangað. Við erum með bash forskriftir þar, við notum þau til að ræsa og stilla...

Artyom: Þetta gerist í gegnum AWS API, það eru miklu fleiri tæknilegar hliðarþjónustur þar. Við skiptum okkar skyldum þannig að ég skili til CloudFront, og framhlið og bakenda verktaki taka það þaðan. Við erum með fjölda eigin bindinga til að einfalda uppsetningu efnis sem við gerum síðan í 4K o.s.frv. Þar sem frestarnir voru mjög þröngir gerðum við það nánast eingöngu á AWS.

— Síðan fer þetta allt inn í spilarann með því að nota bakendakerfið. Við erum með TypeScript, React, Next.JS í spilaranum okkar. Og á bakendanum höfum við nokkrar þjónustur í C#, Java, Spring Boot og Node.js. Þetta er allt sett upp með Kubernetes með Yandex.Cloud innviði.

Ég vil líka taka það fram að þegar ég þurfti að kynnast vettvangnum reyndist það auðvelt: allar geymslur eru á GitLab, allt er vel nefnt, próf eru skrifuð, það eru skjöl. Það er, jafnvel í neyðartilvikum, sáu þeir um slíkt.

Viðskiptatakmarkanir og greiningar

— Við miðuðum á 10 notendur út frá viðskiptakröfum. Það er kominn tími til að tala um viðskiptatakmarkanir sem við höfðum. Við þurftum að tryggja mikið vinnuálag, tryggja að farið væri að lögum um varðveislu persónuupplýsinga. Og hvað annað?

Nikolay: Upphaflega byrjuðum við á kröfum um myndband. Það mikilvægasta er dreifð myndbandsgeymsla um allan heim fyrir skjótan afhendingu til viðskiptavinarins. Aðrir innihalda 1080p upplausn, sem og spóla til baka, sem margir aðrir útfæra ekki í beinni stillingu. Síðar bættum við við möguleikanum á að virkja 2x hraða, með hjálp hans geturðu „náð“ í beinni og haldið áfram að horfa á ráðstefnuna í rauntíma. Og á leiðinni birtist virkni tímalínumerkingar. Auk þess þurftum við að vera bilunarþolin og þola álagið af 10 tengingum. Frá sjónarhóli bakenda eru þetta um það bil 000 tengingar margfaldaðar með 10 beiðnum fyrir hverja síðuuppfærslu. Og þetta er nú þegar 000 RPS/sek. Nokkuð af.

— Voru einhverjar aðrar kröfur um „sýndarsýningu“ með netbásum samstarfsaðila?

Nikolay: Já, þetta þurfti að gera nokkuð hratt og almennt. Við vorum með allt að 10 samstarfsfyrirtæki fyrir hverja ráðstefnu og þeim öllum þurfti að ljúka á einni eða tveimur vikum. Hins vegar er efni þeirra örlítið mismunandi að sniði. En ákveðin sniðmátsvél var gerð sem setur þessar síður saman á flugi, nánast án frekari þróunarþátttöku.

— Það voru líka kröfur um greiningu á rauntímaskoðunum og tölfræði. Ég veit að við notum Prometheus til þess, en segðu okkur nánar: hvaða kröfur uppfyllum við til greiningar og hvernig er þetta útfært?

Nikolay: Upphaflega höfum við markaðskröfur um söfnun fyrir A/B próf og söfnun upplýsinga til að skilja hvernig á að skila besta efnið til viðskiptavinarins í framtíðinni. Það eru líka kröfur um nokkrar greiningar á starfsemi samstarfsaðila og greiningar sem þú sérð (heimsóknateljari). Öllum upplýsingum er safnað í rauntíma.

Við getum veitt þessar upplýsingar í samanteknu formi jafnvel fyrir ræðumenn: hversu margir voru að horfa á þig á ákveðnum tímapunkti. Á sama tíma, til að fara að alríkislögum 152, er persónulegur reikningur þinn og persónuleg gögn ekki rakin á nokkurn hátt.

Vettvangurinn hefur nú þegar markaðstól og mælikvarða okkar til að mæla virkni notenda í rauntíma (hver horfði á hvaða sekúndu af skýrslunni) til að búa til línurit um aðsókn að skýrslunum. Út frá þessum gögnum er unnið að rannsóknum sem gera næstu ráðstefnur betri.

Svik

— Erum við með kerfi gegn svikum?

Nikolay: Vegna þröngs tímaramma frá viðskiptasjónarmiði var verkefnið upphaflega ekki sett á að loka strax fyrir óþarfa tengingar. Ef tveir notendur skráðu sig inn á sama reikning gætu þeir skoðað efnið. En við vitum hversu margar skoðanir voru samtímis frá einum reikningi. Og við bönnuðum nokkra sérstaklega illgjarna brotamenn.

Vladimir: Til hróss skildi einn af bönnuðu notendunum hvers vegna þetta gerðist. Hann kom, baðst afsökunar og lofaði að kaupa miða.

— Til að allt þetta geti gerst verður þú að rekja alla notendur alveg frá inngöngu til útgöngu, alltaf að vita hvað þeir eru að gera. Hvernig virkar þetta kerfi?

Vladimir: Mig langar að tala um greiningar og tölfræði, sem við greinum síðan með tilliti til árangurs skýrslunnar eða getum síðan veitt samstarfsaðilum. Allir viðskiptavinir eru tengdir í gegnum nettengingu við tiltekinn bakendaklasa. Það stendur þarna hazelcast. Hver viðskiptavinur á hverju tímabili sendir það sem hann er að gera og hvaða lag hann er að horfa á. Síðan er þessum upplýsingum safnað saman með því að nota hröð Hazelcast störf og sendar til baka til allra sem horfa á þessi lög. Við sjáum í horni hversu margir eru hjá okkur núna.

Sömu upplýsingar eru geymdar í Mongó og fer í gagnavatnið okkar, sem við höfum tækifæri til að byggja upp áhugaverðara línurit. Spurningin vaknar: hversu margir einstakir notendur skoðuðu þessa skýrslu? Við förum til postgres, það eru ping frá öllum þeim sem komu með auðkenni þessarar skýrslu. Við söfnuðum, söfnuðum saman einstökum og nú getum við skilið.

Nikolay: En á sama tíma fáum við einnig rauntímagögn frá Prometheus. Það er sett á móti öllum Kubernetes þjónustu, gegn Kubernetes sjálfu. Það safnar nákvæmlega öllu og með Grafana getum við smíðað hvaða línurit sem er í rauntíma.

Vladimir: Annars vegar sækjum við þetta til frekari OLAP vinnslu. Og fyrir OLTP halar forritið öllu til Prometheus, Grafana og línuritin renna jafnvel saman!

- Þetta er raunin þegar línuritin renna saman.

Dýnamískar breytingar

— Segðu okkur hvernig kraftmiklar breytingar eru settar í framkvæmd: ef hætt var við skýrsluna 6 mínútum fyrir upphaf, hver er keðja aðgerða? Hvaða leiðsla virkar?

Vladimir: Lögnin er mjög skilyrt. Það eru nokkrir möguleikar. Hið fyrsta er að áætlunargerðin virkaði og breytti áætluninni. Breytt dagskrá er hlaðið upp á Contentful. Eftir það skilur bakendinn að það eru breytingar fyrir þessa ráðstefnu í Contentful, tekur hana og endurbyggir hana. Öllu er safnað saman og sent í gegnum websocket.

Annar möguleikinn, þegar allt gerist á ógnarhraða: ritstjórinn breytir handvirkt upplýsingum í Contentful (tengill á Telegram, kynningu ræðumanns o.s.frv.) og sama rökfræði virkar og í fyrra skiptið.

Nikolay: Allt gerist án þess að endurnýja síðuna. Allar breytingar eiga sér stað algerlega óaðfinnanlega fyrir viðskiptavininn. Sama gildir um að skipta um skýrslur. Þegar tíminn kemur breytast skýrslan og viðmótið.

Vladimir: Einnig eru tímamörk fyrir upphaf skýrslna á tímalínunni. Strax í upphafi er ekkert. Og ef þú heldur músinni yfir rauðu röndina, þá birtast á einhverjum tímapunkti, þökk sé útvarpsstjóranum, klippingar. Leikstjórinn setur rétta upphaf útsendingar, bakendi tekur þessa breytingu, reiknar út upphafs- og lokatíma kynninga allrar lagsins í samræmi við dagskrá ráðstefnunnar, sendir það til viðskiptavina okkar og spilarinn dregur út lokanir. Nú getur notandinn auðveldlega farið í byrjun og lok skýrslunnar. Það var ströng viðskiptakrafa, mjög þægileg og gagnleg. Þú eyðir ekki tíma í að finna raunverulegan upphafstíma skýrslunnar. Og þegar við gerum sýnishorn verður það alveg yndislegt.

Dreifing

— Mig langar til að spyrja um útsetningu. Kolya og liðið eyddu miklum tíma í upphafi til að setja upp allan innviði þar sem allt þróast fyrir okkur. Segðu mér, úr hverju er þetta allt saman gert?

Nikolay: Frá tæknilegu sjónarhorni höfðum við upphaflega kröfu um að varan væri eins óhlutbundin og mögulegt er frá hvaða söluaðila sem er. Komdu til AWS til að búa til Terraform forskriftir sérstaklega frá AWS, eða sérstaklega frá Yandex, eða frá Azure, o.s.frv. passaði ekki alveg. Við þurftum einhvern tíma að flytja eitthvað.

Fyrstu þrjár vikurnar vorum við stöðugt að leita leiða til að gera þetta betur. Fyrir vikið komumst við að þeirri niðurstöðu að Kubernetes í þessu tilfelli er allt okkar, vegna þess að það gerir okkur kleift að búa til sjálfvirka stærðarþjónustu, sjálfvirka útfærslu og fá nánast alla þjónustu úr kassanum. Auðvitað þurfti að þjálfa alla þjónustu til að vinna með Kubernetes, Docker og teymið þurfti líka að læra.

Við erum með tvo klasa. Próf og framleiðsla. Þeir eru alveg eins hvað varðar vélbúnað og stillingar. Við innleiðum innviði sem kóða. Öll þjónusta er sjálfkrafa rúllað út í þrjú umhverfi frá eiginleikagreinum, aðalútibúum, prófunargreinum og GitLab með sjálfvirkri leiðslu. Þetta er hámarks samþætt í GitLab, hámarks samþætt við Elastic, Prometheus.

Við fáum tækifæri til að fljótt (fyrir bakendann innan 10 mínútna, fyrir framendann innan 5 mínútna) útfæra breytingar á hvaða umhverfi sem er með öllum prófunum, samþættingum, keyrandi virkniprófum, samþættingarprófum á umhverfinu og einnig prófa með álagsprófum á prófunarumhverfi um það bil það sama og við viljum fá í framleiðslu.

Um próf

— Þú prófar næstum allt, það er erfitt að trúa því hvernig þú skrifaðir allt. Geturðu sagt okkur frá bakendaprófunum: hversu mikið er fjallað um allt, hvaða próf?

Vladimir: Tvenns konar próf hafa verið skrifuð. Í fyrsta lagi eru íhlutapróf. Lyftustigsprófanir á allri gormásetningunni og setjið inn Prófílát. Þetta er próf á viðskiptasviðsmyndum á hæsta stigi. Ég prófa ekki aðgerðir. Við prófum aðeins stóra hluti. Til dæmis, strax í prófinu, er líkt eftir ferlinu við að skrá þig inn á notanda, beiðni notandans um miða þangað sem hann getur farið og beiðni um aðgang til að horfa á strauminn. Mjög skýr atburðarás notenda.

Um það bil það sama er útfært í svokölluðum samþættingarprófum, sem keyra í raun á umhverfinu. Reyndar, þegar næsta dreifing í framleiðslu er rúllað út, eru raunverulegar grunnsviðsmyndir einnig í gangi í framleiðslu. Sama innskráning, biðja um miða, biðja um aðgang að CloudFront, athuga hvort straumurinn tengist raunverulegum heimildum mínum, athuga viðmót leikstjórans.

Í augnablikinu er ég með um 70 íhlutapróf og um 40 samþættingarpróf um borð. Þekjan er mjög nálægt 95%. Þetta er fyrir íhluti, minna fyrir samþættingu, það er einfaldlega ekki svo mikil þörf. Miðað við að verkefnið felur í sér alls kyns kóðagerð er þetta mjög góð vísbending. Það var engin önnur leið til að gera það sem við gerðum á þremur mánuðum. Vegna þess að ef við prófuðum handvirkt, gáfum prófaranum okkar eiginleika og hún myndi finna villur og skila þeim til okkar til að lagfæra, þá væri þessi hringferð til að villa kóðann mjög löng og við myndum ekki ná neinum fresti.

Nikolay: Venjulega þarftu að sitja og pota alls staðar í tvo daga til að framkvæma afturför á öllum pallinum þegar þú breytir einhverri aðgerð.

Vladimir: Þess vegna heppnast það mjög vel að þegar ég áætla eiginleika þá segi ég að ég þurfi 4 daga fyrir tvo einfalda penna og 1 nettösku, Kolya leyfir það. Hann er nú þegar vanur því að þessir 4 dagar innihalda 2 tegundir af prófum og þá mun það líklega virka.

Nikolay: Ég er líka með 140 próf skrifuð: component + functional, sem gera það sama. Allar sömu aðstæður eru prófaðar í framleiðslu, í prófun og í framleiðslu. Við bættum einnig nýlega við hagnýtum grunnviðmótsprófum. Þannig náum við yfir helstu grunnvirkni sem getur fallið í sundur.

Vladimir: Auðvitað er þess virði að tala um álagspróf. Það var nauðsynlegt að prófa pallinn undir álagi nálægt hinu raunverulega til að skilja hvernig allt er, hvað er að gerast með Rabbit, hvað er að gerast með JVM, hversu mikið minni þarf í raun.

— Ég veit ekki með vissu hvort við erum að prófa eitthvað straummegin, en ég man að það voru vandamál með transkóðara þegar við fundum. Höfum við prófað straumana?

Artyom: Prófað ítrekað. Skipuleggja fundi. Í því ferli að skipuleggja fundi voru um það bil 2300 JIRA miðar. Þetta eru bara almennir hlutir sem fólk gerði til að halda fundi. Við tókum hluta af pallinum inn á sérstaka síðu fyrir fundi, sem var rekin af Kirill Tolkachev (talkv).

Satt að segja voru engin stór vandamál. Bókstaflega nokkrum sinnum náðum við villur í skyndiminni á CloudFront, við leystum það nokkuð fljótt - við endurstillum einfaldlega reglurnar. Það voru verulega fleiri villur í fólki, í streymiskerfum á síðunni.

Á ráðstefnunum þurfti ég að skrifa fleiri útflytjendur til að ná yfir meiri búnað og þjónustu. Sums staðar þurfti ég að búa til mín eigin reiðhjól bara fyrir mælikvarða. Heimur AV (hljóð-myndbands) vélbúnaðar er ekki mjög bjartur - þú ert með einhvers konar „API“ búnaðar sem þú getur einfaldlega ekki haft áhrif á. Og það er langt frá því að þú getir fengið þær upplýsingar sem þú þarft. Vélbúnaðarframleiðendur eru mjög hægir og það er næstum ómögulegt að fá það sem þú vilt frá þeim. Alls eru meira en 100 stykki af vélbúnaði, þeir gefa ekki til baka það sem þú þarft, og þú skrifar undarlega og óþarfa útflytjendur, þökk sé þeim að þú getur að minnsta kosti einhvern veginn kembiforritið kerfið.

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

— Ég man hvernig við keyptum aukabúnað að hluta áður en ráðstefnurnar hófust.

Artyom: Við keyptum tölvur, fartölvur og rafhlöðupakka. Í augnablikinu getum við lifað án rafmagns í 40 mínútur. Í júní voru mikil þrumuveður í Sankti Pétursborg - þannig að við fengum þvílíka myrkvun. Á sama tíma koma nokkrir veitendur til okkar með sjóntengla frá mismunandi stöðum. Þetta eru í raun og veru 40 mínútur af byggingatíma þar sem kveikt er á ljósum, hljóði, myndavélum osfrv.

— Við höfum svipaða sögu með internetið. Á skrifstofunni þar sem vinnustofur okkar eru, drógum við grimmt net á milli hæða.

Artyom: Við erum með 20 Gbit af trefjum á milli hæða. Lengra eftir hæðunum, einhvers staðar er ljósfræði, einhvers staðar er engin ljósfræði, en samt eru færri rásir en gígabitar - við keyrum myndband á þeim á milli laga ráðstefnunnar. Almennt séð er mjög þægilegt að vinna við eigin innviði; þú getur sjaldan gert þetta á ótengdum ráðstefnum á síðum.

— Áður en ég vann hjá JUG Ru Group sá ég hvernig vélbúnaðarherbergi á ótengdum ráðstefnum voru sett upp á einni nóttu, þar sem það var stór skjár með öllum þeim mæligildum sem þú smíðar í Grafana. Nú er líka höfuðstöðvarherbergi þar sem þróunarteymið situr, sem á ráðstefnunni lagar nokkrar villur og þróar eiginleika. Á sama tíma er eftirlitskerfi sem birtist á stórum skjá. Artyom, Kolya og aðrir krakkar sitja og passa að þetta falli ekki allt og virki fallega.

Forvitni og vandamál

— Þú talaðir vel um þá staðreynd að við höfum streymi með Amazon, það er spilari með vefnum, allt er skrifað á mismunandi forritunarmálum, bilanaþol og aðrar viðskiptakröfur eru veittar, þar á meðal persónulegur reikningur sem er studdur fyrir lögaðila og einstaklinga, og við getum samþætt við einhvern sem notar OAuth 2.0, það er svik gegn svikum, notendalokun. Við getum útfært breytingar á kraftmikinn hátt vegna þess að við gerðum það vel og það er allt prófað.

Ég hef áhuga á að vita hvaða undarleikar voru fólgnir í því að koma einhverju af stað. Hafa verið einhverjar undarlegar aðstæður þegar þú varst að þróa bakenda, framenda, kom eitthvað brjálað í ljós og þú skildir ekki hvað þú átt að gera við það?

Vladimir: Mér sýnist þetta bara hafa gerst síðustu þrjá mánuði. Daglega. Eins og þú sérð er allt hárið mitt dregið úr.

Vladimir Krasilshchik eftir 3 mánuði, þegar einhvers konar leikur kom upp og enginn skildi hvað ég átti að gera við hann

Á hverjum degi var eitthvað svona, þegar það var svona augnablik þegar þú tekur það og rífur hárið úr þér, eða gerir þér grein fyrir að það er enginn annar, og aðeins þú getur gert það. Fyrsti stóri viðburðurinn okkar var TechTrain. Þann 6. júní kl. 2:2.0 höfðum við ekki enn komið framleiðsluumhverfinu í notkun, Kolya var að rúlla því út. Og persónulegi reikningurinn virkaði ekki sem heimildarþjónn með OAuth2.0. Við breyttum því í OAuth18 veitu til að tengja pallinn við hann. Ég hafði verið að vinna í sennilega XNUMX tíma samfleytt, ég horfði á tölvuna og sá ekki neitt, ég skildi ekki hvers vegna hún virkaði ekki, og Kolya horfði á kóðann minn fjarstýrt, leitaði að villu í vorstillingunni , fann það, og LC virkaði, og í framleiðslu líka.

Nikolay: Og klukkutíma fyrir TechTrain fór útgáfan fram.

Margar stjörnur voru í röð hér. Við vorum einstaklega heppin því við vorum með frábært lið og allir voru innblásnir af hugmyndinni um að gera það á netinu. Alla þessa þrjá mánuði vorum við knúin áfram af þeirri staðreynd að við „gerðum YouTube“. Ég leyfði mér ekki að rífa hárið á mér en sagði öllum að allt myndi ganga upp, því í rauninni var allt búið að reikna út fyrir löngu.

Um frammistöðu

— Geturðu sagt mér hversu margir voru á síðunni á einni braut? Voru einhver frammistöðuvandamál?

Nikolay: Það voru engin frammistöðuvandamál, eins og við sögðum þegar. Hámarksfjöldi sem mættu á eina skýrslu var 1300 manns, þetta er á Heisenbug.

— Voru einhver vandamál með staðbundið útsýni? Og er hægt að hafa tæknilega lýsingu með skýringarmyndum um hvernig þetta virkar allt saman?

Nikolay: Við munum gera grein um þetta síðar.

Þú getur jafnvel villuleita strauma á staðnum. Þegar ráðstefnurnar hófust varð það enn auðveldara, því framleiðslustraumar birtust sem við getum horft á allan tímann.

Vladimir: Eins og ég skil það, þá unnu framhliðarframleiðendur staðbundið með spotta, og síðan, þar sem tíminn til að rúlla út til þróunarvélanna að framan er líka stuttur (5 mínútur), þá eru engin vandamál með að athuga hvað er að gerast með skírteinin.

— Allt er prófað og villuleit, jafnvel á staðnum. Þetta þýðir að við munum skrifa grein með öllum tæknilegum eiginleikum, sýna þér, segja þér allt með skýringarmyndum, hvernig það var.

Vladimir: Þú getur tekið það og endurtekið það.

- Eftir 3 mánuði.

Samtals

— Allt sem lýst er saman hljómar flott, miðað við að það var gert af litlu teymi á þremur mánuðum.

Nikolay: Stórt lið myndi ekki gera þetta. En lítill hópur fólks sem hefur náið og vel samskipti sín á milli og getur komist að samkomulagi gæti. Það eru engar mótsagnir í þeim, arkitektúrinn var fundinn upp á tveimur dögum, var lokið og hefur í raun ekki breyst. Það er mjög strangt að auðvelda komandi viðskiptakröfum hvað varðar að hrannast upp eiginleikabeiðnum og breytingum.

— Hvað var á lista þínum yfir frekari verkefni þegar sumarráðstefnurnar höfðu þegar farið fram?

Nikolay: Til dæmis, ein. Skriðlínur á myndbandinu, sprettigluggar sums staðar í myndbandinu eftir því hvaða efni er sýnt. Til dæmis vill ræðumaður spyrja áheyrenda spurningu og atkvæði birtist á skjánum sem fer aftur á bak miðað við niðurstöður atkvæðagreiðslu til ræðumanns sjálfs. Einhvers konar félagsleg virkni í formi likes, hjörtu, einkunna skýrslunnar á kynningunni sjálfri, svo að þú getir fyllt út athugasemdir á réttu augnabliki án þess að láta trufla þig seinna með athugasemdaeyðublöðum. Upphaflega svona.

Og einnig að bæta við allan vettvang, nema streymi og ráðstefnu, einnig ástandi eftir ráðstefnu. Þetta eru spilunarlistar (þar á meðal þeir sem notendur hafa safnað saman), hugsanlega efni frá öðrum fyrri ráðstefnum, samþættir, merktir, aðgengilegir notandanum og einnig hægt að skoða á vefsíðunni okkar (live.jugru.org).

— Krakkar, takk kærlega fyrir svörin!

Ef meðal lesenda eru þeir sem sóttu sumarráðstefnur okkar, vinsamlegast deilið hughrifum ykkar af spilaranum og útsendingunni. Hvað var þægilegt, hvað pirraði þig, hvað myndir þú vilja sjá í framtíðinni?

Ef þú hefur áhuga á pallinum og vilt sjá hann „í bardaga“, notum við hann aftur á okkar haust-vetrarráðstefnur. Það er til fullt úrval af þeim, svo það er næstum örugglega einn sem er réttur fyrir þig.

Heimild: www.habr.com

Þróaðu myndbandsvettvang á 90 dögum