Udaberri honetan oso baldintza alaietan aurkitu gara. Pandemia dela eta, argi geratu zen gure udako hitzaldiak sarean mugitu behar zirela. Eta sarean modu eraginkorrean egiteko, prest egindako software-soluzioak ez ziren egokiak guretzat; guk geuk idatzi behar genuen. Eta hiru hilabete izan genituen hau egiteko.
Argi dago hiru hilabete zirraragarriak izan direla. Baina kanpotik ez da guztiz agerikoa: zer da online hitzaldi plataforma bat? Zein zatiz osatuta dago? Hori dela eta, udako DevOops jardunaldien azkenetan, zeregin honen arduradunei galdetu nien:
- Nikolay Molchanov - JUG Ru Taldeko zuzendari teknikoa;
- Vladimir Krasilshchik Java programatzaile pragmatikoa da backend-ean lan egiten duena (bere txostenak gure Java jardunaldietan ere ikus ditzakezu);
- Artyom Nikonov da gure bideo streaming guztien arduraduna.
Bide batez, udazken-neguko jardunaldietan plataforma beraren bertsio hobetua erabiliko dugu -habra irakurle asko izango dira oraindik bere erabiltzaileak-.
Irudi nagusia
— Zein zen taldearen osaera?
Nikolay Molchanov: Analista bat, diseinatzaile bat, probatzaile bat, hiru front-end eta back-end bat ditugu. Eta, noski, T itxurako espezialista!
— Nolakoa izan da oro har prozesua?
Nikolay: Martxoaren erdialdera arte, ez genuen ezer prest sarean egiteko. Eta martxoaren 15ean, lineako karrusel osoa biraka hasi zen. Hainbat biltegi ezarri, planifikatu, oinarrizko arkitekturaz eztabaidatu eta hiru hilabetetan dena egin genuen.
Honek, noski, plangintza, arkitektura, ezaugarrien aukeraketa, ezaugarri horien botoa, ezaugarri horien politika, diseinua, garapena, probak igaro zituen. Ondorioz, ekainaren 6an, dena ekoizpenera zabaldu genuen. . Denetarako 90 egun zeuden.
— Lortu al dugu konpromisoa hartu genuena betetzea?
Nikolay: Orain DevOops konferentzian linean parte hartzen ari garenez, funtzionatu duela esan nahi du. Pertsonalki gauza nagusiarekin konpromisoa hartu nuen: bezeroei sareko hitzaldi bat egiteko tresna bat ekarriko diet.
Erronka hau izan zen: txartelei gure hitzaldiak helarazteko tresna bat ematea.
Plangintza guztia hainbat fasetan banatu zen, eta ezaugarri guztiak (30 inguru global) 4 kategoriatan banatu ziren:
- zalantzarik gabe egingo duguna (ezin gara haiek gabe bizi),
- bigarrenik egingo duguna,
- inoiz egingo ez duguna,
- eta inoiz, inoiz egingo ez duguna.
Lehen bi kategorietako ezaugarri guztiak egin ditugu.
— Badakit guztira 600 JIRA gai sortu zirela. Hiru hilabetetan, 13 mikrozerbitzu egin zenituen, eta susmoa dut ez zirela Javan bakarrik idatziak. Teknologia desberdinak erabili dituzu, Kubernetes bi kluster dituzu hiru erabilgarritasun gunetan eta 5 RTMP korronte Amazonen.
Ikus ditzagun orain sistemaren osagai bakoitza bereizita.
Streaming
— Has gaitezen dagoeneko bideo-irudi bat dugunean, eta zerbitzu batzuetara transmititzen denean. Artyom, kontatu nola gertatzen den streaming hau?
Artyom Nikonov: Gure eskema orokorrak honela dauka: kamerako irudia -> gure kontrol-gela -> RTMP zerbitzari lokala -> Amazon -> bideo erreproduzitzailea. Xehetasun gehiago Habré-n ekainean.
Oro har, bi modu global daude horretarako: hardwarean edo software soluzioetan oinarrituta. Softwarearen ibilbidea aukeratu dugu urruneko bozgorailuen kasuan errazagoa delako. Ez da beti posible hardwarea beste herrialde bateko bozgorailu batera eramatea, baina bozgorailuari softwarea ematea errazagoa eta fidagarriagoa dirudi.
Hardwarearen ikuspuntutik, kamera kopuru jakin bat dugu (gure estudioetan eta urruneko bozgorailuetan), urrutiko aginte kopuru jakin bat estudioan, batzuetan mahai azpian bertan konpondu behar direnak emankizunean zehar.
Gailu hauen seinaleak kaptura-txartelak, sarrera/irteera txartelak eta soinu-txartelak dituzten ordenagailuetara sartzen dira. Bertan seinaleak nahasten dira eta diseinuetan muntatzen dira:
4 bozgorailuentzako diseinuaren adibidea
4 bozgorailuentzako diseinuaren adibidea
Gainera, etengabeko emisioa ematen da hiru ordenagailuren laguntzarekin: makina nagusi bat dago eta txandaka lan egiten duten pare bat dago. Lehenengo ordenagailuak lehen txostena biltzen du, bigarrenak - atsedenaldia, lehena - hurrengo txostena, bigarrenak - hurrengo atsedenaldia, eta abar. Eta makina nagusiak lehenengoa bigarrenarekin nahasten du.
Honek triangelu moduko bat sortzen du, eta nodo horietakoren batek huts egiten badu, azkar eta kalitaterik galdu gabe jarraitu ahal izango dugu bezeroei edukia ematen. Horrelako egoera bat izan genuen. Jardunaldien lehen astean, makina bat konpondu genuen, piztu eta itzali genuen. Badirudi jendea pozik dagoela gure erresilientziarekin.
Ondoren, ordenagailuetako korronteak tokiko zerbitzari batera joaten dira, eta horrek bi zeregin ditu: RTMP korronteak bideratzea eta babeskopiak grabatzea. Beraz, grabazio puntu anitz ditugu. Ondoren, bideo-korronteak Amazon SaaS zerbitzuetan eraikitako gure sistemaren zatira bidaltzen dira. Erabiltzen dugu ,S3,CloudFront.
Nikolay: Zer gertatzen da hor bideoa ikusleengana iritsi aurretik? Moztu egin behar duzu nolabait, ezta?
Artyom: Gure aldetik bideoa konprimitzen dugu eta MediaLive-ra bidaltzen dugu. Han transkodetzaileak abiarazten ditugu. Bideoak denbora errealean transkodetzen dituzte hainbat ebazpenetan, jendeak telefonoz ikusi ahal izateko, herrialdeko Internet eskasaren bidez, etab. Ondoren, korronte hauek mozten dira , horrela funtzionatzen du protokoloak . Erreprodukzio-zerrenda bat bidaltzen dugu zati hauetarako erakusleak dituen frontend-era.
— 1080p bereizmena erabiltzen al dugu?
Artyom: Gure bideoaren zabalera 1080p - 1920 pixelekoa da, eta altuera apur bat txikiagoa da, argazkia luzeagoa da - horretarako arrazoiak daude.
Jokalaria
— Artyomek bideoa korronteetan nola sartzen den deskribatu zuen, nola banatzen den erreprodukzio-zerrenda desberdinetan pantaila bereizmen desberdinetarako, zatitan moztu eta erreproduzitzailean sartzen den. Kolya, orain esaidazu nolako jokalaria den hau, nola kontsumitzen duen korrontea, zergatik HLS?
Nikolay: Konferentziaren ikusle guztiek ikus dezaketen erreproduzitzailea dugu.
Funtsean, liburutegiaren inguruko bilgarri bat da , zeinetan beste jokalari asko idatzita daude. Baina funtzionaltasun oso zehatzak behar genituen: pertsona dagoen lekua atzera bota eta markatzea, zein erreportaje ikusten ari den une honetan. Gure diseinuak ere behar genituen, era guztietako logotipoak eta gurekin eraikitako beste guztia. Hori dela eta, gure liburutegia idaztea erabaki genuen (HLS-en gaineko bilgarri bat) eta webgunean txertatzea.
Hau root funtzionaltasuna da, beraz, ia lehen inplementatu zen. Eta orduan dena hazi zen inguruan.
Izan ere, baimenaren bidez, erreproduzitzaileak backend-etik denborarekin eta kalitatearekin erlazionatutako zatietarako estekak dituen erreprodukzio-zerrenda bat jasotzen du, beharrezkoak deskargatu eta erabiltzaileari erakusten dizkio, bidean "magia" batzuk eginez.
Denbora-lerroaren adibidea
- Botoi bat erreproduzitzailean sartuta dago txosten guztien denbora-lerroa bistaratzeko...
Nikolay: Bai, berehala konpondu genuen erabiltzaileen nabigazioaren arazoa. Apirilaren erdialdean erabaki genuen ez genuela gure hitzaldi bakoitza web gune batean emango, dena bakarrean batuko genuela baizik. Hortaz, Full Pass txartelaren erabiltzaileek askatasun osoz alda ditzakete konferentzia ezberdinetatik: bai zuzeneko emankizunak bai iraganen grabaketak.
Eta erabiltzaileei uneko korrontean nabigatzea eta bide batetik bestera aldatzea errazteko, "Igorpen osoa" botoia eta txartel horizontalak egitea erabaki genuen, pista eta txostenen artean aldatzeko. Teklatuaren kontrola dago.
— Zailtasun teknikorik egon al zen honekin?
Nikolay: Erreportaje ezberdinen abiapuntuak markatzen zituzten korritze-barra zuten.
— Azkenean, marka hauek korritze-barran ezarri dituzu YouTube-k antzeko zerbait egin aurretik?
Artyom: Beta moduan zuten orduan. Badirudi nahiko ezaugarri konplexua dela, azken urtean erabiltzaileekin partzialki probatu dutelako. Eta orain salmentara iritsi da.
Nikolay: Baina, egia esan, azkarrago saldu genuen. Egia esan, funtzio sinple honen atzean backend, frontend, kalkulu eta matematika kopuru handia dago jokalariaren barruan.
Frontend
— Ikus dezagun nola iristen den erakusten dugun eduki hau (hitz-txartela, bozgorailuak, webgunea, ordutegia) frontendera?
Vladimir Krasilshchik: Barneko hainbat sistema informatiko ditugu. Txosten guztiak eta hizlari guztiak sartzen diren sistema bat dago. Hizlari batek hitzaldi batean parte hartzen duen prozesu bat dago. Hiztunak eskaera bat bidaltzen du, sistemak harrapatzen du, gero txostena sortzen den kanalizazio jakin bat dago.
Horrela ikusten du hiztunak kanalizazioa
Sistema hau gure barne garapena da.
Ondoren, banakako txostenetatik abiatuta egutegia sortu behar duzu. Dakizuenez, hau NP-gogorra den arazoa da, baina nolabait konpontzen dugu. Horretarako, programazio bat sortzen duen eta Contentful hirugarrenen hodeiko zerbitzura igotzen duen beste osagai bat abiarazten dugu. Bertan, denak mahai baten itxura du eta bertan jardunaldien egunak daude, egunetan ordu-tarteak daude, eta tarteetan erreportajeak, atsedenaldiak edo babes-jarduerak. Beraz, ikusten dugun edukia hirugarrenen zerbitzu batean kokatzen da. Eta zeregina gunera helaraztea da.
Badirudi gunea jokalari batekin orrialde bat besterik ez dela, eta hemen ez dago ezer konplikaturik. Ez da izan ezik. Orrialde honen atzean dagoen backend-a Contentful-era doa, hortik programazioa lortzen du, objektu batzuk sortzen ditu eta frontend-era bidaltzen ditu. Gure plataformako bezero bakoitzak egiten duen websocket konexioa erabiliz, programazio eguneraketa bat bidaltzen diogu backend-etik frontend-era.
Benetako kasua: hizlaria lanez aldatu zen hitzaldian bertan. Bere enpresaburuaren txapa aldatu behar dugu. Nola gertatzen da hau backend-etik? Eguneratze bat bezero guztiei bidaltzen zaie websocket bidez, eta, ondoren, frontend-ak berak denbora-lerroa berriro marrazten du. Hori guztia ezin hobeto gertatzen da. Hodeiko zerbitzuaren eta gure osagai batzuen konbinazioak eduki hori guztia sortzeko eta aurrealdean emateko aukera ematen digu.
Nikolay: Garrantzitsua da hemen argitzea gure gunea ez dela SPA aplikazio klasiko bat. Hau diseinuan oinarritutako web orri bat eta SPA bat da. Google-k benetan HTML errendatu gisa ikusten du gune hau. Hau ona da SEOrako eta erabiltzaileari edukia emateko. Ez du itxaron 1,5 megabyte JavaScript kargatzeko orria ikusi aurretik, berehala ikusten du jada errendatutako orria, eta hori sentitzen duzu txostena aldatzen duzun bakoitzean. Dena segundo erdian gertatzen da, edukia dagoeneko prest baitago eta leku egokian argitaratuta.
— Marraz dezagun lerro bat aurreko guztiaren azpian teknologiak zerrendatuz. Tyomak esan zuen Amazon 5 korronte ditugula, eta bideoa eta soinua eskaintzen ditugula bertan. Bash script-ak hor ditugu, abiarazteko eta konfiguratzeko erabiltzen ditugu...
Artyom: Hau AWS APIaren bidez gertatzen da, alboko zerbitzu tekniko askoz gehiago daude bertan. Erantzukizunak banatu ditugu, horrela betetzeko , eta front-end eta back-end garatzaileek hortik hartzen dute. Edukien diseinua errazteko geure lotura batzuk ditugu, gero 4K-n egiten ditugunak, etab. Epeak oso estuak zirenez, ia osorik egin genuen AWSn.
— Ondoren, hori guztia erreproduzitzailean sartzen da backend sistema erabiliz. TypeScript, React, Next.JS ditugu gure erreproduzitzailean. Eta atzeko aldean hainbat zerbitzu ditugu C#, Java, Spring Boot eta Node.js. Hau guztia Kubernetes erabiliz zabaltzen da Yandex.Cloud azpiegitura erabiliz.
Kontuan izan nahi dut, gainera, plataforma ezagutu behar nuenean erraza izan zela: biltegi guztiak GitLab-en daude, dena ondo izendatuta dago, probak idatzita daude, dokumentazioa dago. Hau da, larrialdi moduan ere, halakoak zaintzen zituzten.
Negozioen mugak eta analitika
— 10 erabiltzaileri zuzendu ginen negozioaren eskakizunetan oinarrituta. Gure negozioen murrizketez hitz egiteko garaia da. Lan karga handia bermatu behar genuen, datu pertsonalak zaintzeko legea betetzen dela ziurtatu. Eta zer gehiago?
Nikolay: Hasieran, bideo eskakizunetatik abiatu ginen. Garrantzitsuena mundu osoan bideo biltegiratzea da bezeroari azkar bidaltzeko. Besteak beste, 1080p bereizmena, baita atzera egin ere, beste askok zuzeneko moduan ezartzen ez dutena. Geroago 2x abiadura gaitzeko gaitasuna gehitu dugu, bere laguntzarekin zuzenekoarekin "harrapatzeko" eta konferentzia denbora errealean ikusten jarraitu dezakezu. Eta bidean, denbora-lerroa markatzeko funtzionaltasuna agertu zen. Gainera, akatsekiko tolerantzia izan behar genuen eta 10 konexioren kargari eutsi behar genion. Backend-en ikuspuntutik, hau da, gutxi gorabehera, 000 konexio 10 eskaera biderkatuta orrialdea freskatzeko. Eta hau dagoeneko 000 RPS/seg da. Nahiko.
— Bazuen beste baldintzarik bazkideen sareko standekin “erakusketa birtual” baterako?
Nikolay: Bai, hau nahiko azkar eta unibertsalki egin behar zen. Jardunaldi bakoitzeko 10 enpresa bazkide izan genituen gehienez, eta astebete edo bitan osatu behar izan ziren denak. Hala ere, haien edukia apur bat desberdina da formatuan. Baina txantiloi-motor jakin bat egin zen orrialde hauek hegan muntatzen dituena, ia garapen gehiagoko partaidetzarik gabe.
— Denbora errealeko ikuspegien eta estatistiken analisirako ere baldintzak zeuden. Badakit Prometheus erabiltzen dugula horretarako, baina esaiguzu zehatzago: zer baldintza betetzen ditugu analitiketarako, eta nola ezartzen da hori?
Nikolay: Hasieran, marketin-eskakizunak ditugu A/B probak biltzeko eta informazioa biltzeko, etorkizunean bezeroari eduki onena behar bezala nola entregatu ulertzeko. Bazkideen jardueren eta ikusten dituzun analitiken (bisita-kontagailua) analitika batzuen eskakizunak ere badaude. Informazio guztia denbora errealean biltzen da.
Informazio hori modu bateratuan eman diezaiekegu hiztunei ere: zenbat pertsona ikusten ari zaren une jakin batean. Aldi berean, 152 Lege Federala betetzeko, zure kontu pertsonala eta datu pertsonalak ez dira inola ere jarraipena egiten.
Plataformak dagoeneko baditu marketin-tresnak eta erabiltzaileen jarduera denbora errealean neurtzeko gure neurketak (nork ikusi zuen txostenaren zein segundotan) txostenetan asistentziaren grafikoak eraikitzeko. Datu horietatik abiatuta, hurrengo jardunaldiak hobetuko dituzten ikerketak egiten ari dira.
Iruzurra
— Badugu iruzurraren aurkako mekanismorik?
Nikolay: Negozioaren ikuspuntutik denbora tarte estua zela eta, ataza ez zen hasiera batean ezarri alferrikako konexioak berehala blokeatzeko. Bi erabiltzaile kontu berdinarekin saioa hasiz gero, edukia ikusi ahal izango dute. Baina badakigu zenbat ikustaldi zeuden aldibereko kontu batetik. Eta urratzaile bereziki gaizto batzuk debekatu genituen.
Vladimir: Bere onerako, debekatutako erabiltzaileetako batek ulertu zuen zergatik gertatu zen hori. Etorri, barkamena eskatu eta txartela erosiko zuela agindu zuen.
— Hau guztia gerta dadin, erabiltzaile guztiak guztiz jarraitu behar dituzu sarreratik irten arte, beti jakin zer egiten ari diren. Nola funtzionatzen du sistema honek?
Vladimir: Analitikari eta estatistikei buruz hitz egin nahiko nuke, gero txostenaren arrakastarako aztertzen ditugunak edo gero bazkideei eman diezaiekegun. Bezero guztiak websocket konexio baten bidez konektatzen dira backend kluster jakin batera. Hor dago . Bezero bakoitzak denbora-tarte bakoitzean zer egiten ari den eta zer pista ikusten ari den bidaltzen du. Ondoren, informazio hau Hazelcast lan azkarrak erabiliz batzen da eta pista hauek ikusten dituzten guztiei bidaltzen zaie. Txokoan ikusten dugu zenbat jende dagoen orain gurekin.
Informazio bera gordetzen da eta gure data lake-ra doa, eta hortik grafiko interesgarriago bat eraikitzeko aukera dugu. Galdera sortzen da: zenbat erabiltzaile bakar ikusi dute txosten hau? Goazen , txosten honen idarekin etorritako pertsona guztien ping-ak daude. Bakarrak bildu, batu ditugu, eta orain ulertu dezakegu.
Nikolay: Baina, aldi berean, Prometheus-en denbora errealeko datuak ere jasotzen ditugu. Kubernetes zerbitzu guztien aurka ezartzen da, Kubernetes beraren aurka. Guztia biltzen du, eta Grafanarekin edozein grafiko eraiki dezakegu denbora errealean.
Vladimir: Alde batetik, hau deskargatzen dugu OLAP prozesatzeko. Eta OLTPrako, aplikazioak Prometheus-era deskargatzen du, Grafana-ra eta grafikoek bat egiten dute!
- Hau gertatzen da grafikoak bat egiten dutenean.
Aldaketa dinamikoak
— Esaiguzu nola zabaltzen diren aldaketa dinamikoak: txostena hasi baino 6 minutu lehenago bertan behera geratu bazen, zein da ekintzen katea? Zein kanalizazio funtzionatzen du?
Vladimir: Hodibidea oso baldintzatua da. Hainbat aukera daude. Lehenengoa, ordutegiak sortzeko programak funtzionatu zuela eta ordutegia aldatu zuen. Aldatutako ordutegia Contentful-era kargatzen da. Horren ondoren, backendak Contentful-en konferentzia honetarako aldaketak daudela ulertzen du, hartu eta berreraikitzen du. Dena websocket bidez bildu eta bidaltzen da.
Bigarren aukera, dena erritmo bizian gertatzen denean: editoreak eskuz aldatzen du informazioa Contentful-en (Telegramerako esteka, hizlariaren aurkezpena, etab.) eta lehen aldiko logika berdinak funtzionatzen du.
Nikolay: Orria freskatu gabe gertatzen da dena. Aldaketa guztiak guztiz ondo gertatzen dira bezeroarentzat. Gauza bera gertatzen da txostenak aldatzearekin. Unea iristen denean, txostena eta interfazea aldatzen dira.
Vladimir: Era berean, denbora-mugak daude txostenak hasteko denbora-lerroan. Hasieran ez dago ezer. Eta sagua marra gorriaren gainean jartzen baduzu, noizbait, emisio zuzendariari esker, mozketak agertuko dira. Zuzendariak emisioaren hasiera zuzena ezartzen du, backend-ak aldaketa hori jasotzen du, pista osoaren aurkezpenen hasiera eta amaiera orduak kalkulatzen ditu konferentziaren programazioaren arabera, gure bezeroei bidaltzen die eta jokalariak mozketak marrazten ditu. Orain erabiltzaileak erraz nabiga dezake txostenaren hasierara eta amaierara. Negozio-eskakizun zorrotza zen, oso erosoa eta erabilgarria. Ez duzu denborarik galtzen txostenaren benetako hasiera-ordua aurkitzen. Eta aurrebista bat egiten dugunean, guztiz zoragarria izango da.
Hedapena
— Hedapenari buruz galdetu nahiko nuke. Kolya eta taldeak denbora asko eman zuten hasieran dena zabaltzen zaigun azpiegitura osoa martxan jartzen. Esadazu, zertaz osatuta dago dena?
Nikolay: Ikuspuntu teknikotik, hasiera batean produktua edozein saltzailerengandik ahalik eta abstraktuena izateko eskakizuna genuen. Zatoz AWSra Terraform script-ak AWS-tik bereziki, edo Yandex-etik, edo Azure-tik, etab. ez zen benetan egokitzen. Norabait mugitu behar izan genuen noizbait.
Lehenengo hiru asteetan hau hobeto egiteko moduaren bila ibili ginen etengabe. Ondorioz, kasu honetan Kubernetes gure guztia dela ondorioztatu genuen, automatikoki eskalatzeko zerbitzuak sortzeko, automatikoki zabaltzeko eta ia zerbitzu guztiak kaxatik ateratzeko aukera ematen digulako. Jakina, zerbitzu guztiak Kubernetesekin, Dockerrekin lan egiteko trebatu behar ziren eta taldeak ere ikasi behar zuen.
Bi multzo ditugu. Proba eta ekoizpena. Erabat berdinak dira hardware eta ezarpenei dagokienez. Azpiegitura kode gisa ezartzen dugu. Zerbitzu guztiak automatikoki hiru ingurunetan zabaltzen dira ezaugarrien adarretatik, adar nagusietatik, proba adarretatik eta GitLab kanalizazio automatiko bat erabiliz. Hau GitLab-en integratuta dago, eta Elastic, Prometheus-ekin ahalik eta gehien integratuta dago.
Aukera dugu azkar (backend-erako 10 minutuko epean, frontend-erako 5 minutuko epean) edozein ingurunetan aldaketak abiarazteko proba, integrazio, proba funtzionalak exekutatzen, inguruneko integrazio-probak eta karga-testekin ere probak egiteko. produkzioan lortu nahi dugun gauza bera proba-ingurune bat.
Probei buruz
— Ia dena probatzen duzu, zaila da sinestea nola idatzi duzun guztia. Esan al diguzu backend probei buruz: zenbat estalita dagoen guztia, zein probak?
Vladimir: Bi proba mota idatzi dira. Lehenengoak osagaien probak dira. Udaberriaren aplikazio osoaren eta oinarriaren igoera maila probak . Hau maila goreneko negozio-eszenatokien proba da. Ez ditut funtzioak probatzen. Gauza handi batzuk bakarrik probatzen ditugu. Adibidez, proban bertan, erabiltzaile batekin saioa hasteko prozesua emulatzen da, erabiltzaileak joan daitekeen tokira sarrerak eskatzeko eta korrontea ikusteko sarbidea izateko eskaera. Erabiltzaileen eszenatoki oso argiak.
Gutxi gorabehera gauza bera inplementatzen da integrazio test deiturikoak, benetan ingurunean exekutatzen direnak. Izan ere, ekoizpenean hurrengo inplementazioa zabaltzen denean, benetako oinarrizko eszenatokiak ere abian dira ekoizpenean. Saio-hasiera bera, sarrerak eskatzea, CloudFront-erako sarbidea eskatzea, korrontea nire baimenekin benetan konektatzen dela egiaztatzea, zuzendariaren interfazea egiaztatuz.
Momentuz 70 osagai-proba inguru eta 40 bat integrazio-proba ditut taula gainean. Estaldura %95etik oso gertu dago. Hau osagaietarako da, gutxiago integraziorako, ez da hain beharrezkoa. Proiektuak kode-sorkuntza mota guztiak hartzen dituela kontuan hartuta, oso adierazle ona da hau. Hiru hilabetetan egin genuena egiteko beste biderik ez zegoen. Zeren eskuz probatuko bagenu, gure probatzaileari eginbideak emanez, eta akatsak aurkitu eta guri itzuliko bagenitu konponketak egiteko, orduan kodea arazteko joan-etorri hau oso luzea izango litzateke eta ez genuke eperik beteko.
Nikolay: Ohikoki, funtzioren bat aldatzean plataforma osoan erregresio bat egiteko, bi egunez nonahi eseri eta zulatu behar duzu.
Vladimir: Hori dela eta, arrakasta handia da funtzio bat kalkulatzen dudanean, 4 egun behar ditudala bi boligrafo sinple eta 1 websocket, Kolyak aukera ematen du. Dagoeneko ohituta dago 4 egun hauek 2 proba mota biltzen dituztela eta gero, ziurrenik, funtzionatuko duela.
Nikolay: 140 proba ere idatzita ditut: osagai + funtzionalak, gauza bera egiten dutenak. Eszenatoki berdinak probatzen dira ekoizpenean, proban eta ekoizpenean. Oinarrizko UI proba funtzionalak ere gehitu ditugu duela gutxi. Honela, erori daitezkeen funtzionalitate oinarrizkoenak estaltzen ditugu.
Vladimir: Noski, merezi du karga-probei buruz hitz egitea. Plataforma errealetik hurbil dagoen karga baten azpian probatu behar zen dena nola dagoen, Rabbit-ekin zer gertatzen den, JVMekin zer gertatzen den, zenbat memoria behar den benetan ulertzeko.
— Ez dakit ziur ezer probatzen ari garen korrontearen aldetik, baina gogoratzen dut topaketak egiten genituenean transkodetzaileekin arazoak izan zirela. Korronteak probatu al ditugu?
Artyom: Iteratiboki probatua. Topaketak antolatzea. Topaketak antolatzeko prozesuan, gutxi gorabehera 2300 JIRA sarrera zeuden. Jendeak bilerak egiteko egin zituen gauza generikoak besterik ez dira. Plataformaren zatiak topaketarako orri bereizi batean eraman genituen, Kirill Tolkachev-ek zuzentzen zuena ().
Egia esateko, ez zegoen arazo handirik. Literalki, pare bat aldiz harrapatu genituen CloudFront-en cachean gordetzeko akatsak, nahiko azkar konpondu genituen - politikak berriro konfiguratu genituen. Jendeetan akats gehiago zeuden, guneko streaming sistemetan.
Jardunaldietan, hainbat esportatzaile gehiago idatzi behar izan nituen ekipamendu eta zerbitzu gehiago estaltzeko. Zenbait tokitan nire bizikletak egin behar izan nituen neurketagatik. AV (audio-bideo) hardwarearen mundua ez da oso arrosa; besterik gabe, eragin ezin duzun ekipoen "API" mota bat duzu. Eta urrun dago behar duzun informazioa lortzeko gai izango zarenik. Hardware saltzaileak oso motelak dira, eta ia ezinezkoa da haietatik nahi duzuna lortzea. Guztira 100 hardware pieza baino gehiago daude, ez dute behar duzuna itzultzen, eta esportatzaile arraro eta erredundanteak idazten dituzu, horri esker sistema nolabait arazketa dezakezu behintzat.
Оборудование
— Gogoan dut nola jardunaldiak hasi aurretik ekipamendu osagarria partzialki erosi genuen.
Artyom: Ordenagailuak, ordenagailu eramangarriak eta bateria paketeak erosi genituen. Momentuz 40 minutuz elektrizitaterik gabe bizi gaitezke. Ekainean trumoi-ekaitz gogorrak izan ziren San Petersburgon, beraz, halako itzalaldi bat izan genuen. Aldi berean, hainbat hornitzaile etortzen zaizkigu puntu ezberdinetatik lotura optikoekin. Hau benetan 40 minutuko eraikuntza gelditzen da, eta horietan argiak, soinua, kamerak eta abar funtzionatuko ditugu.
— Internetekin antzeko istorio bat dugu. Gure estudioak dauden bulegoan sare gogor bat arrastaka eraman genuen solairuen artean.
Artyom: 20 Gbit zuntz ditugu solairu artean. Solairuetan aurrerago, nonbait optika dago, nonbait ez dago optikarik, baina hala ere gigabit-ak baino kanal gutxiago daude - bideoak exekutatzen ditugu konferentziaren bideen artean. Orokorrean, oso erosoa da zure azpiegituran lan egitea; oso gutxitan egin dezakezu hori guneetako lineaz kanpoko hitzaldietan.
— JUG Ru Group-en lan egin baino lehen, ikusi nuen nola konfiguratzen ziren lineaz kanpoko kongresuetan hardware gelak gauetik, non monitore handi bat zegoen Grafanan eraikitzen dituzun metrika guztiekin. Orain, garapen-taldea esertzen den egoitza gela bat ere badago, hitzaldian zehar akats batzuk konpondu eta funtzioak garatzen dituena. Aldi berean, pantaila handi batean bistaratzen den monitorizazio sistema bat dago. Artyom, Kolya eta beste mutil batzuk esertzen dira eta ziur dena ez dela erortzen eta ederki funtzionatzen duela.
Bitxikeriak eta arazoak
— Ondo hitz egin duzu Amazon-ekin streaminga dugula, sarean erreproduzitzaile bat dagoela, dena programazio-lengoaia ezberdinetan idatzita dago, akatsen tolerantzia eta negozio-eskakizunak eskaintzen dira, pertsona juridikoentzat onartzen den kontu pertsonal bat barne eta partikularrak, eta OAuth 2.0 erabiliz norbaitekin integra gaitezke, iruzurraren aurkakoa, erabiltzaileen blokeoa dago. Aldaketak dinamikoki zabaldu ditzakegu, ondo egin dugulako, eta dena probatuta dago.
Zerbait abiaraztean zer bitxikeria izan ziren jakitea interesatzen zait. Egoera arrarorik egon al da backend-a, frontend-a garatzen ari zinela, zerbait zoroa gertatu zen eta ez zenuen ulertzen zer egin?
Vladimir: Azken hiru hilabeteetan hori bakarrik gertatu dela iruditzen zait. Egunero. Ikusten duzunez, ile guztia atera zait.
Vladimir Krasilshchik 3 hilabeteren buruan, joko motaren bat gertatu zen eta inork ez zuen ulertzen zer egin horrekin
Egunero bazegoen horrelako zerbait, halako momentu bat hartu eta ilea kentzen duzunean edo konturatzen zarenean ez dagoela beste inor, eta zuk bakarrik egin dezakezula. Gure lehen ekitaldi handia TechTrain izan zen. Ekainaren 6an 2:2.0etan oraindik ez genuen produkzio ingurunea zabaldu, Kolya kaleratzen ari zen. Eta kontu pertsonalak ez zuen funtzionatu baimen-zerbitzari gisa OAuth2.0 erabiliz. OAuth18 hornitzaile bihurtu dugu plataforma harekin konektatzeko. Ziurrenik XNUMX orduz lanean aritu nintzen, ordenagailuari begiratu eta ez nuen ezer ikusi, ez nuen ulertzen zergatik ez zuen funtzionatzen, eta Kolyak nire kodea urrunetik begiratu zuen, akats bat bilatu zuen Spring konfigurazioan. , aurkitu zuen eta LCk funtzionatu zuen, eta ekoizpenean ere bai.
Nikolay: Eta TechTrain baino ordubete lehenago kaleratzea gertatu zen.
Izar asko lerrokatu ziren hemen. Zorte handia izan genuen talde super bat geneukalako, eta denak sarean egiteko ideiak inspiratu zituen. Hiru hilabete hauetan "Youtube" egin izanak bultzatu gaitu. Ez nion nire buruari ilea kentzen uzten, baina denak aterako zirela esan nien, izan ere, dena aspaldi kalkulatua baitzen.
Errendimenduari buruz
— Esango al didazu zenbat jende zegoen gunean pista batean? Errendimendu-arazorik egon al da?
Nikolay: Ez zegoen errendimendu arazorik, lehen esan dugun bezala. Txosten batean parte hartu zuten gehieneko jende kopurua 1300 pertsona izan zen, hau Heisenbug-en dago.
— Arazorik egon al da tokian tokiko ikusteko? Eta posible al da deskribapen tekniko bat edukitzea nola funtzionatzen duen eskemekin?
Nikolay: Geroago artikulu bat egingo dugu honi buruz.
Korronteak lokalean arazketa ere egin ditzakezu. Behin hitzaldiak hasita, are errazagoa izan zen, etengabe ikusi ahal izango ditugun ekoizpen korronteak agertu zirelako.
Vladimir: Ulertzen dudanez, frontend-eko garatzaileek mokekin lan egin zuten lokalean, eta, ondoren, aurrealdeko garatzaileetara zabaltzeko denbora ere laburra denez (5 minutu), ez dago arazorik ziurtagiriekin zer gertatzen den egiaztatzeko.
— Dena probatu eta arazketa egiten da, baita lokalean ere. Horrek esan nahi du artikulu bat idatziko dugula ezaugarri tekniko guztiekin, erakutsiko dizugula, diagramekin dena kontatuko dizugula, nola zegoen.
Vladimir: Hartu eta errepikatu dezakezu.
- 3 hilabetetan.
Guztira
— Elkarrekin deskribatutako guztia polita dirudi, talde txiki batek hiru hilabetetan egin zuela kontuan hartuta.
Nikolay: Talde handi batek ez luke horrelakorik egingo. Baina elkarren artean nahiko estu eta ondo komunikatzen diren eta akordio batera iristen diren pertsona talde txiki batek liteke. Ez dute kontraesanik, arkitektura bi egunetan asmatu zen, amaitu zen eta ez da benetan aldatu. Ezaugarrien eskaerak eta aldaketak pilatzeari dagokionez, sarrerako negozio-eskakizunen erraztasun oso zorrotza dago.
— Zein zen zure zeregin gehiagoren zerrendan udako jardunaldiak jada egin zirenean?
Nikolay: Adibidez, kredituak. Bideoko lerroak, pop-upak bideoko leku batzuetan erakusten den edukiaren arabera. Esaterako, hizlariak galdera bat egin nahi dio entzuleei, eta boto bat agertuko da pantailan, bozketa emaitzen arabera itzultzen dena hizlariari berari. Aurkezpenean bertan txostenaren gustukoak, bihotzak, balorazioak moduko gizarte-jarduera moduko bat, iritzia une egokian bete ahal izateko, gero feedback-inprimakiek distraitu gabe. Hasieran honela.
Eta plataforma osoari ere gehitzea, streaming eta konferentzia izan ezik, konferentzia osteko egoera ere. Hauek dira erreprodukzio-zerrendak (erabiltzaileek bildutakoak barne), agian iraganeko beste kongresuetako edukiak, integratuak, etiketatuak, erabiltzaileak eskura daitezkeenak eta gure webgunean ikusteko ere eskuragarri ().
- Mutilak, mila esker erantzunengatik!
Irakurleen artean gure udako kongresuetan parte hartu dutenak badaude, mesedez partekatu jokalariari eta emankizunari buruz dituzun inpresioak. Zer zen komenigarria, zerk haserretu zintuen, zer ikusi nahiko zenuke etorkizunean?
Plataforman interesatzen bazaizu eta "borrokan" ikusi nahi baduzu, berriro erabiltzen dugu gurean . Horietako sorta osoa dago, beraz, ia ziur dago zuretzat egokia den bat.
Iturria: www.habr.com