To pomlad smo se znašli v zelo veselih razmerah. Zaradi pandemije je postalo jasno, da je treba naše poletne konference preseliti na splet. In da bi jih učinkovito izvajali na spletu, že pripravljene programske rešitve za nas niso bile primerne, morali smo napisati svoje. In za to smo imeli tri mesece časa.
Jasno je, da so bili to razburljivi trije meseci. Toda od zunaj ni povsem očitno: kaj je spletna konferenčna platforma? Iz katerih delov je sestavljen? Zato sem na zadnji izmed poletnih konferenc DevOops vprašal odgovorne za to nalogo:
- Nikolay Molchanov - tehnični direktor skupine JUG Ru;
- Vladimir Krasilshchik je pragmatičen programer Java, ki dela na zaledju (njegova poročila ste lahko videli tudi na naših konferencah Java);
- Artyom Nikonov je odgovoren za ves naš video pretok.
Mimogrede, na jesensko-zimskih konferencah bomo uporabljali izboljšano različico iste platforme - tako bo veliko bralcev habre še vedno njenih uporabnikov.
Velika slika
— Kakšna je bila sestava ekipe?
Nikolaj Molčanov: Imamo analitika, oblikovalca, preizkuševalca, tri front-ende in back-end. In, seveda, specialist v obliki črke T!
— Kako je na splošno izgledal postopek?
Nikolay: Do sredine marca nismo imeli prav nič pripravljenega za splet. In 15. marca se je ves spletni vrtiljak začel vrteti. Postavili smo več repozitorijev, načrtovali, obravnavali osnovno arhitekturo in vse naredili v treh mesecih.
To je seveda potekalo skozi klasične faze načrtovanja, arhitekture, izbire funkcij, glasovanja za te funkcije, politike za te funkcije, njihove zasnove, razvoja, testiranja. Posledično smo 6. junija vse uvedli v proizvodnjo. . Za vse je bilo na voljo 90 dni.
— Ali nam je uspelo izpolniti zadano?
Nikolay: Ker zdaj sodelujemo na konferenci DevOops na spletu, pomeni, da je uspelo. Osebno sem se zavezal glavnemu: strankam bom prinesel orodje, s katerim bodo lahko naredili spletno konferenco.
Izziv je bil naslednji: dajte nam orodje, s katerim bomo lahko prenašali naše konference imetnikom vstopnic.
Vse načrtovanje je bilo razdeljeno na več stopenj, vse značilnosti (približno 30 globalnih) pa so bile razdeljene v 4 kategorije:
- kar bomo zagotovo storili (brez njih ne moremo živeti),
- kar bomo naredili drugič,
- česar ne bomo nikoli storili,
- in česar nikoli, nikoli ne bomo storili.
Naredili smo vse lastnosti iz prvih dveh kategorij.
— Vem, da je bilo ustvarjenih skupno 600 vprašanj JIRA. V treh mesecih ste naredili 13 mikrostoritev in sumim, da niso bile napisane samo v Javi. Uporabili ste različne tehnologije, imate dve gruči Kubernetes v treh območjih razpoložljivosti in 5 tokov RTMP v Amazonu.
Oglejmo si zdaj vsako komponento sistema posebej.
Pretakanje
— Začnimo s tem, ko že imamo video sliko in se ta posreduje nekaterim storitvam. Arty, povej nam, kako poteka to pretakanje?
Artjom Nikonov: Naša splošna shema izgleda takole: slika iz kamere -> naša nadzorna soba -> lokalni strežnik RTMP -> Amazon -> video predvajalnik. Več podrobnosti junija na Habréju.
Na splošno obstajata dva globalna načina za to: na strojni ali programski rešitvi. Izbrali smo programsko pot, ker je v primeru oddaljenih zvočnikov lažja. Strojne opreme ni vedno mogoče prinesti zvočniku v drugi državi, vendar se zdi, da je dostava programske opreme zvočniku lažja in zanesljivejša.
S strojnega vidika imamo določeno število kamer (v studiih in na oddaljenih zvočnikih), določeno število daljinskih upravljalnikov v studiu, ki jih je včasih treba popravljati kar pod mizo med oddajo.
Signali iz teh naprav vstopajo v računalnike s karticami za zajem, vhodno/izhodnimi karticami in zvočnimi karticami. Tam se signali mešajo in sestavljajo v postavitve:
Primer postavitve za 4 zvočnike
Primer postavitve za 4 zvočnike
Poleg tega je neprekinjeno oddajanje zagotovljeno s pomočjo treh računalnikov: en glavni stroj in par delovnih po vrsti. Prvi računalnik zbira prvo poročilo, drugi - odmor, prvi - naslednje poročilo, drugi - naslednji odmor itd. In glavni stroj meša prvo z drugim.
Tako nastane nekakšen trikotnik in če katero od teh vozlišč odpove, lahko hitro in brez izgube kakovosti nadaljujemo z dostavo vsebine naročnikom. Imeli smo tako situacijo. V prvem tednu konferenc smo popravili en stroj, ga prižgali/izklopili. Zdi se, da so ljudje zadovoljni z našo odpornostjo.
Nato gredo tokovi iz računalnikov na lokalni strežnik, ki ima dve nalogi: usmerjanje tokov RTMP in varnostno kopiranje. Tako imamo več snemalnih točk. Video tokovi se nato pošljejo v del našega sistema, zgrajen na storitvah Amazon SaaS. Uporabljamo ,S3,CloudFront.
Nikolay: Kaj se zgodi tam, preden video doseže občinstvo? Nekako ga moraš odrezati, kajne?
Artjom: Video stisnemo z naše strani in ga pošljemo v MediaLive. Tam lansiramo transkoderje. Videoposnetke v realnem času prekodirajo v več ločljivosti, da jih lahko ljudje gledajo na svojih telefonih, prek slabega interneta v državi ipd. Nato se te potoke razrežejo , tako deluje protokol . V sprednji del pošljemo seznam predvajanja, ki vsebuje kazalce na te dele.
— Ali uporabljamo ločljivost 1080p?
Artjom: Širina našega videa je enaka 1080p - 1920 slikovnih pik, višina pa malo manjša, slika je bolj podolgovata - za to obstajajo razlogi.
Igralec
— Artyom je opisal, kako video pride v tokove, kako se razdeli na različne sezname predvajanja za različne ločljivosti zaslona, razreže na kose in pride v predvajalnik. Kolya, zdaj mi povej, kakšen igralec je to, kako porabi tok, zakaj HLS?
Nikolay: Imamo igralca, ki ga lahko gledajo vsi gledalci konference.
V bistvu je to ovoj okoli knjižnice , na katerem pišejo številni drugi igralci. Potrebovali pa smo zelo specifično funkcionalnost: previjanje nazaj in označevanje mesta, kjer je oseba, katero poročilo trenutno gleda. Potrebovali smo tudi lastne postavitve, vse možne logotipe in vse ostalo, kar je bilo vgrajeno pri nas. Zato smo se odločili napisati lastno knjižnico (ovitek nad HLS) in jo vdelati na spletno mesto.
To je korenska funkcionalnost, zato je bila implementirana skoraj prva. In potem je vse raslo okoli njega.
Pravzaprav s pooblastilom igralec iz ozadja prejme seznam predvajanja s povezavami do kosov, ki so povezani s časom in kakovostjo, prenese potrebne in jih pokaže uporabniku ter med tem izvede nekaj »čarovnije«.
Primer časovnice
— V predvajalnik je vgrajen gumb za prikaz časovnice vseh poročil ...
Nikolay: Da, takoj smo rešili problem uporabniške navigacije. Sredi aprila smo se odločili, da vsake naše konference ne bomo prenašali na ločeni spletni strani, ampak bomo vse združili na enem. Tako lahko uporabniki vstopnic Full Pass prosto preklapljajo med različnimi konferencami: tako prenosi v živo kot posnetki preteklih.
Da bi uporabnikom olajšali krmarjenje po trenutnem toku in preklapljanje med skladbami, smo se odločili narediti gumb »Celotna oddaja« in vodoravne kartice s poročilom za preklapljanje med skladbami in poročili. Obstaja nadzor s tipkovnico.
— Ali so bile pri tem kakšne tehnične težave?
Nikolay: Imeli so drsni trak, na katerem so bila označena izhodišča različnih poročil.
— Na koncu, ali ste te oznake uporabili na drsnem traku, preden je YouTube naredil nekaj podobnega?
Artjom: Takrat so ga imeli v beta različici. Zdi se, da je to precej zapletena funkcija, ker so jo v zadnjem letu delno testirali z uporabniki. In zdaj je dosegel prodajo.
Nikolay: Ampak dejansko smo ga hitreje spravili v prodajo. Iskreno povedano, za to preprosto funkcijo je v predvajalniku ogromno zaledja, sprednjega dela, izračunov in matematike.
Frontend
— Ugotovimo, kako ta vsebina, ki jo prikazujemo (govorna kartica, zvočniki, spletna stran, urnik), pride do sprednjega dela?
Vladimir Krasilščik: Imamo več notranjih informacijskih sistemov. Obstaja sistem, v katerega se vpisujejo vsa poročila in vsi govorci. Obstaja postopek, s katerim govornik sodeluje na konferenci. Govorec odda prijavo, sistem jo zajame, potem pride do določenega cevovoda, po katerem se ustvari poročilo.
Tako zvočnik vidi cevovod
Ta sistem je naš notranji razvoj.
Nato morate sestaviti urnik iz posameznih poročil. Kot veste, je to NP-težka težava, vendar jo nekako rešimo. Da bi to naredili, zaženemo drugo komponento, ki ustvari urnik in ga naloži v storitev Contentful v oblaku tretje osebe. Tam je vse videti kot tabela, v kateri so dnevi konference, v dnevih so termini, v terminih pa poročila, odmori ali sponzorske aktivnosti. Vsebina, ki jo vidimo, se torej nahaja v storitvi tretje osebe. In naloga je prenesti na spletno mesto.
Zdi se, da je spletno mesto le stran s predvajalnikom in tukaj ni nič zapletenega. Razen tega ni. Zaledje za to stranjo gre na Contentful, od tam pridobi urnik, ustvari nekaj predmetov in jih pošlje v sprednji del. S povezavo websocket, ki jo vzpostavi vsak odjemalec naše platforme, mu pošljemo posodobitev urnika iz zaledja v frontend.
Dejanski primer: govorec je zamenjal službo kar med konferenco. Spremeniti moramo značko njegovega delodajalskega podjetja. Kako se to zgodi iz ozadja? Posodobitev je poslana vsem odjemalcem prek spletne vtičnice, nato pa vmesnik sam preriše časovnico. Vse to se zgodi brez težav. Kombinacija storitve v oblaku in več naših komponent nam daje možnost, da ustvarimo vso to vsebino in jo ponudimo v ospredje.
Nikolay: Tukaj je pomembno pojasniti, da naše spletno mesto ni klasična SPA aplikacija. To je hkrati upodobljeno spletno mesto, ki temelji na postavitvi, in SPA. Google dejansko vidi to spletno mesto kot upodobljen HTML. To je dobro za SEO in za dostavo vsebine uporabniku. Ne čaka, da se naloži 1,5 megabajta JavaScripta, preden vidi stran, takoj vidi že upodobljeno stran in to občutite vsakič, ko preklopite poročilo. Vse se zgodi v pol sekunde, saj je vsebina že pripravljena in objavljena na pravem mestu.
— Počrtajmo črto pod vse našteto z naštevanjem tehnologij. Tyoma je rekel, da imamo 5 tokov Amazon in tja dostavljamo video in zvok. Tam imamo skripte bash, uporabljamo jih za zagon in konfiguracijo ...
Artjom: To se zgodi prek API-ja AWS, tam je veliko več tehničnih stranskih storitev. Obveznosti smo si razdelili tako, da dostavim do , od tam pa ga vzamejo razvijalci sprednjega in zadnjega dela. Imamo številne lastne vezave za poenostavitev postavitve vsebine, ki jo nato naredimo v 4K itd. Ker so bili roki zelo kratki, smo to skoraj v celoti izvedli na AWS.
— Nato gre vse to v predvajalnik z uporabo zalednega sistema. V našem predvajalniku imamo TypeScript, React, Next.JS. In na ozadju imamo več storitev v C#, Java, Spring Boot in Node.js. Vse to je razporejeno z uporabo Kubernetesa z uporabo infrastrukture Yandex.Cloud.
Prav tako želim opozoriti, da ko sem se moral seznaniti s platformo, se je izkazalo, da je enostavno: vsi repozitoriji so na GitLabu, vse je dobro poimenovano, testi so napisani, obstaja dokumentacija. Se pravi, tudi v nujnem načinu so poskrbeli za takšne stvari.
Poslovne omejitve in analitika
— Na podlagi poslovnih potreb smo ciljali na 10 uporabnikov. Čas je, da spregovorimo o poslovnih omejitvah, ki smo jih imeli. Zagotoviti smo morali visoko obremenjenost, zagotoviti spoštovanje zakona o varovanju osebnih podatkov. In kaj še?
Nikolay: Sprva smo izhajali iz video zahtev. Najpomembnejša stvar je porazdeljena video shramba po vsem svetu za hitro dostavo naročniku. Drugi vključujejo ločljivost 1080p in previjanje nazaj, ki ga mnogi drugi ne izvajajo v načinu v živo. Kasneje smo dodali možnost omogočanja 2x hitrosti, s pomočjo katere lahko »dohitevate« v živo in še naprej spremljate konferenco v realnem času. In na poti se je pojavila funkcija označevanja časovnice. Poleg tega smo morali biti odporni na napake in vzdržati obremenitev 10 povezav. Z vidika zaledja je to približno 000 povezav, pomnoženih z 10 zahtevami za vsako osvežitev strani. In to je že 000 RPS/sek. Kar malo.
— Ali so bile kakšne druge zahteve za »virtualno razstavo« s spletnimi stojnicami partnerjev?
Nikolay: Da, to je bilo treba storiti precej hitro in univerzalno. Za vsako konferenco smo imeli do 10 partnerskih podjetij in vsa so morala biti zaključena v tednu ali dveh. Njihova vsebina pa se nekoliko razlikuje po obliki. Toda narejen je bil določen mehanizem predloge, ki te strani sestavlja sproti, tako rekoč brez nadaljnjega sodelovanja pri razvoju.
— Obstajajo tudi zahteve za analitiko pogledov v realnem času in statistiko. Vem, da za to uporabljamo Prometheus, a povej nam podrobneje: kakšne zahteve izpolnjujemo za analitiko in kako se to izvaja?
Nikolay: Na začetku imamo trženjske zahteve za zbiranje za testiranje A/B in zbiranje informacij, da bi razumeli, kako pravilno dostaviti najboljšo vsebino stranki v prihodnosti. Obstajajo tudi zahteve za nekatere analitike o aktivnostih partnerjev in analitike, ki jih vidite (števec obiskov). Vse informacije se zbirajo v realnem času.
Te informacije lahko posredujemo v združeni obliki celo govorcem: koliko ljudi vas je gledalo v določenem trenutku. Hkrati se zaradi skladnosti z zveznim zakonom 152 vašemu osebnemu računu in osebnim podatkom na noben način ne sledi.
Platforma že ima marketinška orodja in naše metrike za merjenje aktivnosti uporabnikov v realnem času (kdo je gledal katero sekundo poročila) za izgradnjo grafov obiskanosti poročil. Na podlagi teh podatkov potekajo raziskave, ki bodo naslednje konference naredile boljše.
goljufije
— Ali imamo mehanizme za boj proti goljufijam?
Nikolay: Zaradi tesnega časovnega okvira s poslovnega vidika sprva ni bila zastavljena naloga takojšnje blokade nepotrebnih povezav. Če sta se dva uporabnika prijavila z istim računom, sta si lahko ogledala vsebino. Vemo pa, koliko hkratnih ogledov je bilo iz enega računa. In prepovedali smo več posebej zlonamernih kršiteljev.
Vladimir: Eden od prepovedanih uporabnikov je razumel, zakaj se je to zgodilo. Prišel je, se opravičil in obljubil, da bo kupil vstopnico.
— Da bi se vse to zgodilo, morate popolnoma izslediti vse uporabnike od vstopa do izstopa, vedno vedeti, kaj počnejo. Kako ta sistem deluje?
Vladimir: Govoril bi o analitiki in statistiki, ki jo nato analiziramo za uspešnost poročila ali pa jo nato posredujemo partnerjem. Vsi odjemalci so prek povezave websocket povezani z določeno zaledno gručo. Tam stoji . Vsaka stranka v vsakem časovnem obdobju pošlje, kaj počne in katero skladbo gleda. Nato se te informacije združijo s hitrimi opravili Hazelcast in pošljejo nazaj vsem, ki gledajo te skladbe. V kotu vidimo, koliko ljudi je zdaj z nami.
Iste informacije so shranjene v in gre v naše podatkovno jezero, iz katerega imamo možnost zgraditi bolj zanimiv graf. Postavlja se vprašanje: koliko edinstvenih uporabnikov si je ogledalo to poročilo? Gremo na , obstajajo pingi vseh ljudi, ki so prišli z id-jem tega poročila. Zbrali smo, združili edinstvene in zdaj lahko razumemo.
Nikolay: Toda hkrati od Prometheusa prejemamo tudi podatke v realnem času. Nastavljen je proti vsem storitvam Kubernetes, proti samemu Kubernetesu. Zbira popolnoma vse, z Grafano pa lahko gradimo poljubne grafe v realnem času.
Vladimir: Po eni strani to prenesemo za nadaljnjo obdelavo OLAP. Za OLTP pa aplikacija vse prenese v Prometheus, Grafana in grafi se celo zbližajo!
- To je primer, ko se grafi zbližajo.
Dinamične spremembe
— Povejte nam, kako potekajo dinamične spremembe: če je bilo poročilo preklicano 6 minut pred začetkom, kakšna je veriga dejanj? Kateri cevovod deluje?
Vladimir: Plinovod je zelo pogojen. Možnosti je več. Prvi je, da je program za ustvarjanje urnika deloval in spremenil urnik. Spremenjen urnik se naloži v Contentful. Po tem zaledje razume, da so za to konferenco spremembe v vsebini, jo vzame in znova zgradi. Vse se zbira in pošilja preko websocketa.
Druga možnost, ko se vse dogaja z vrtoglavo hitrostjo: urednik ročno spremeni informacije v vsebini (povezava do Telegrama, predstavitev govorca itd.) in deluje enaka logika kot prvič.
Nikolay: Vse se zgodi brez osveževanja strani. Vse spremembe se zgodijo popolnoma brezhibno za stranko. Enako velja za menjava poročil. Ko pride čas, se poročilo in vmesnik spremenita.
Vladimir: Obstajajo tudi časovne omejitve za začetek poročil na časovnici. Na samem začetku ni nič. In če z miško premaknete nad rdečo črto, se bodo na neki točki, zahvaljujoč režiserju oddaje, pojavili izrezi. Režiser nastavi pravilen začetek oddaje, zaledje pobere to spremembo, izračuna začetni in končni čas predstavitve celotne skladbe v skladu s konferenčnim razporedom, to pošlje našim strankam, igralec pa nariše cutoffs. Zdaj se lahko uporabnik enostavno pomakne na začetek in konec poročila. To je bila stroga poslovna zahteva, zelo priročna in uporabna. Ne izgubljate časa z iskanjem dejanskega začetnega časa za poročilo. In ko naredimo predogled, bo naravnost čudovito.
Razporeditev
— Rad bi vprašal o namestitvi. Kolya in ekipa smo na začetku porabili veliko časa, da smo postavili celotno infrastrukturo, v kateri se nam vse odvija. Povej mi, iz česa je vse narejeno?
Nikolay: S tehničnega vidika smo na začetku imeli zahtevo, da je izdelek čim bolj abstrakten od katerega koli prodajalca. Pridite v AWS, da naredite skripte Terraform posebej iz AWS, ali posebej iz Yandexa, ali iz Azure itd. res ni ustrezalo. V nekem trenutku smo se morali nekam preseliti.
Prve tri tedne smo nenehno iskali način, kako bi to naredili bolje. Posledično smo prišli do zaključka, da je Kubernetes v tem primeru naše vse, saj nam omogoča ustvarjanje storitev s samodejnim spreminjanjem velikosti, samodejno uvajanje in pridobivanje skoraj vseh storitev iz škatle. Seveda je bilo treba vse storitve usposobiti za delo s Kubernetesom, Dockerjem, pa tudi ekipa.
Imamo dva grozda. Test in proizvodnja. Po strojni opremi in nastavitvah sta popolnoma enaka. Infrastrukturo izvajamo kot kodo. Vse storitve se samodejno uvedejo v tri okolja iz vej funkcij, glavnih vej, testnih vej in GitLaba z uporabo samodejnega cevovoda. To je maksimalno integrirano v GitLab, maksimalno integrirano z Elastic, Prometheus.
Dobimo priložnost, da hitro (za zaledje v 10 minutah, za frontend v 5 minutah) uvedemo spremembe v poljubno okolje z vsemi testi, integracijami, izvajanjem funkcionalnih testov, integracijskimi testi v okolju in tudi testiramo z obremenitvenimi testi na testno okolje približno isto stvar, ki jo želimo dobiti v proizvodnji.
O testih
— Preizkusiš skoraj vse, težko je verjeti, kako si vse napisal. Nam lahko poveste o zalednih testih: koliko je vse pokrito, kateri testi?
Vladimir: Napisani sta dve vrsti testov. Prvi so testi komponent. Preizkus nivoja dviga celotne vzmeti in podlage v . To je preizkus poslovnih scenarijev na najvišji ravni. Ne testiram funkcij. Preizkušamo samo nekatere velike stvari. Na primer, prav v testu se emulira postopek prijave uporabnika, uporabnikova zahteva po vstopnicah do mesta, kamor lahko gre, in zahteva za dostop za ogled toka. Zelo jasni uporabniški scenariji.
Približno enako je implementirano v tako imenovane integracijske teste, ki dejansko potekajo v okolju. Pravzaprav, ko se uvede naslednja uvedba v proizvodnji, se v proizvodnji izvajajo tudi resnični osnovni scenariji. Ista prijava, zahtevanje vstopnic, zahtevanje dostopa do CloudFront, preverjanje, ali se tok resnično povezuje z mojimi dovoljenji, preverjanje režiserjevega vmesnika.
Trenutno imam na krovu približno 70 komponentnih testov in približno 40 integracijskih testov. Pokritost je zelo blizu 95%. To je za sestavne, manj za integracijske, enostavno ni toliko potrebnega. Glede na to, da projekt vključuje vse vrste generiranja kode, je to zelo dober pokazatelj. To, kar smo naredili v treh mesecih, ni bilo drugače. Kajti če bi testirali ročno, našemu preizkuševalcu dajali funkcije, ta pa bi našla hrošče in nam jih vrnila za popravke, bi bilo to povratno potovanje za odpravljanje napak v kodi zelo dolgo in ne bi upoštevali nobenih rokov.
Nikolay: Običajno, če želite izvesti regresijo na celotni platformi, ko spremenite neko funkcijo, morate dva dni sedeti in brskati povsod.
Vladimir: Zato je velik uspeh, da ko ocenim funkcijo, rečem, da potrebujem 4 dni za dve enostavni peresnici in 1 websocket, Kolya to dopušča. Navajen je že na dejstvo, da ti 4 dnevi vključujejo 2 vrsti testov, potem pa bo najverjetneje delovalo.
Nikolay: Napisanih imam tudi 140 testov: komponentni + funkcionalni, ki delajo isto stvar. Vsi isti scenariji so testirani v proizvodnji, v testu in v proizvodnji. Nedavno smo dodali tudi funkcionalne osnovne teste uporabniškega vmesnika. Na ta način pokrijemo najosnovnejšo funkcionalnost, ki lahko odpade.
Vladimir: Seveda je vredno govoriti o obremenitvenih testih. Platformo je bilo treba preizkusiti pod obremenitvijo, ki je blizu dejanske, da bi razumeli, kako je vse, kaj se dogaja z Rabbitom, kaj se dogaja z JVM-ji, koliko pomnilnika je dejansko potrebno.
— Ne vem zagotovo, ali preizkušamo kaj na strani toka, vendar se spomnim, da so bile težave s transkoderji, ko smo izvajali srečanja. Ali smo preizkusili tokove?
Artjom: Preizkušeno iterativno. Organiziranje srečanj. V procesu organizacije srečanj je bilo približno 2300 JIRA vstopnic. To so samo splošne stvari, ki so jih ljudje naredili, da bi organizirali srečanja. Dele platforme smo prenesli na ločeno stran za srečanja, ki jo je vodil Kirill Tolkachev ().
Po pravici povedano ni bilo velikih težav. Dobesedno nekajkrat smo ujeli hrošče predpomnjenja na CloudFrontu, kar smo hitro rešili - preprosto smo na novo konfigurirali pravilnike. Bilo je bistveno več napak pri ljudeh, v pretočnih sistemih na spletnem mestu.
Med konferencami sem moral pisati več izvoznikov, da bi pokril več opreme in storitev. Ponekod sem moral samo zaradi metrike izdelati svoja kolesa. Svet AV (avdio-video) strojne opreme ni zelo rožnat - imate nekakšen "API" opreme, na katerega preprosto ne morete vplivati. In še zdaleč ni dejstvo, da boste lahko dobili informacije, ki jih potrebujete. Prodajalci strojne opreme so zelo počasni in skoraj nemogoče je od njih dobiti, kar želite. Skupaj je več kot 100 kosov strojne opreme, ne vrnejo tistega, kar potrebujete, in pišete čudne in odvečne izvoznike, zahvaljujoč katerim lahko vsaj nekako odpravite napake v sistemu.
Оборудование
— Spomnim se, kako smo pred začetkom konferenc delno nabavili dodatno opremo.
Artjom: Nabavili smo računalnike, prenosnike in baterije. Trenutno lahko živimo brez elektrike 40 minut. Junija so bile v Sankt Peterburgu hude nevihte - zato smo imeli takšno zatemnitev. Hkrati prihaja k nam več ponudnikov z optičnimi povezavami z različnih točk. To je res 40 minut zastoja zgradbe, med katerim bomo imeli prižgane luči, ozvočenje, kamere itd.
— Podobno zgodbo imamo z internetom. V pisarni, kjer se nahajajo naši studii, smo med tla vlekli hudo mrežo.
Artjom: Med nadstropji imamo 20 Gbit vlaken. Naprej po nadstropjih, nekje je optika, nekje je ni, a vseeno je kanalov manj kot gigabitnih - na njih predvajamo video med tiri konference. Na splošno je zelo priročno delati na lastni infrastrukturi; redko lahko to storite na konferencah brez povezave na spletnih mestih.
— Preden sem delal v JUG Ru Group, sem videl, kako so se čez noč uredile strojne sobe na offline konferencah, kjer je bil velik monitor z vsemi metrikami, ki jih zgradiš v Grafani. Zdaj je tam tudi štabna soba, v kateri sedi razvojna ekipa, ki med konferenco odpravlja nekatere napake in razvija funkcije. Hkrati je na voljo nadzorni sistem, ki se prikazuje na velikem zaslonu. Artyom, Kolya in drugi fantje sedijo in skrbijo, da vse ne pade in deluje lepo.
Zanimivosti in težave
— Dobro ste povedali, da imamo pretakanje z Amazonom, obstaja predvajalnik s spletom, vse je napisano v različnih programskih jezikih, zagotovljena je toleranca napak in druge poslovne zahteve, vključno z osebnim računom, ki je podprt za pravne osebe in posamezniki in se lahko integriramo z nekom, ki uporablja OAuth 2.0, obstaja zaščita pred goljufijami, blokiranje uporabnikov. Spremembe lahko uvajamo dinamično, ker smo to naredili dobro in je vse preizkušeno.
Zanima me, kakšne nenavadnosti so bile vpletene v začetek nečesa. Ali je prišlo do kakšnih nenavadnih situacij, ko ste razvijali backend, frontend, se je izkazalo nekaj norega in niste razumeli, kaj storiti s tem?
Vladimir: Zdi se mi, da se to dogaja šele zadnje tri mesece. Vsak dan. Kot vidite, so mi izpuljeni vsi lasje.
Vladimir Krasilshchik po 3 mesecih, ko se je izkazala nekakšna igra in nihče ni razumel, kaj storiti z njo
Vsak dan je bilo nekaj takega, ko je bil takšen trenutek, ko vzameš in si raztrgaš lase, ali se zaveš, da ni nikogar drugega in samo ti zmoreš. Naš prvi večji dogodek je bil TechTrain. 6. junija ob 2. uri zjutraj še nismo uvedli produkcijskega okolja, Kolya ga je uvajal. In osebni račun ni deloval kot avtorizacijski strežnik z OAuth2.0. Spremenili smo ga v ponudnika OAuth2.0, da bi z njim povezali platformo. Delal sem verjetno 18 ur zapored, pogledal sem v računalnik in nisem videl ničesar, nisem razumel, zakaj ne deluje, in Kolya je na daljavo pogledal mojo kodo, iskal napako v konfiguraciji Spring , ga je našel in LC je deloval in tudi v proizvodnji.
Nikolay: In uro pred TechTrainom je prišlo do izdaje.
Tu se je postavilo veliko zvezd. Imeli smo izjemno srečo, saj smo imeli super ekipo in vsi so bili navdihnjeni z idejo, da to počnemo prek spleta. Vse te tri mesece nas je gnalo dejstvo, da smo »naredili YouTube«. Nisem si dovolil trgati las, ampak sem vsem rekel, da se bo vse izšlo, ker je bilo v resnici vse že zdavnaj izračunano.
O uspešnosti
— Mi lahko poveste, koliko ljudi je bilo na mestu na eni progi? Ali so bile kakšne težave z delovanjem?
Nikolay: Težav z delovanjem, kot smo že povedali, ni bilo. Največje število ljudi, ki so se udeležili enega poročila, je bilo 1300 ljudi, to je na Heisenbugu.
— Ali so bile kakšne težave z lokalnim gledanjem? In ali je mogoče dobiti tehnični opis z diagrami, kako vse skupaj deluje?
Nikolay: O tem bomo kasneje napisali članek.
Lokalno lahko celo odpravljate napake v tokovih. Ko so se začele konference, je postalo še lažje, saj so se pojavili produkcijski tokovi, ki jih lahko ves čas spremljamo.
Vladimir: Kolikor razumem, so front-end razvijalci delali lokalno z mocki, in potem, ker je tudi čas za uvedbo do razvijalcev na fronti kratek (5 minut), ni težav s preverjanjem, kaj se dogaja s certifikati.
— Vse je testirano in odpravljeno napake, tudi lokalno. To pomeni, da bomo napisali članek z vsemi tehničnimi lastnostmi, vam pokazali, povedali vse z diagrami, kako je bilo.
Vladimir: Lahko ga vzamete in ponovite.
- Čez 3 mesece.
Skupaj
— Vse opisano skupaj se sliši kul, glede na to, da je naredila majhna ekipa v treh mesecih.
Nikolay: Velika ekipa tega ne bi naredila. Toda majhna skupina ljudi, ki med seboj zelo tesno in dobro komunicira in se lahko dogovori, bi se lahko. Nimajo nobenih protislovij, arhitektura je bila izumljena v dveh dneh, dokončno oblikovana in se pravzaprav ni spremenila. Obstaja zelo stroga olajšava dohodnih poslovnih zahtev v smislu kopičenja zahtev za funkcije in sprememb.
— Kaj je bilo na vašem seznamu nadaljnjih nalog, ko so poletne konference že potekale?
Nikolay: Na primer krediti. Plazeče se črte na videu, pojavna okna na nekaterih mestih v videu, odvisno od prikazane vsebine. Na primer, govornik želi občinstvu postaviti vprašanje in na zaslonu se pojavi glasovanje, ki se na podlagi rezultatov glasovanja vrne nazaj k samemu govorniku. Nekakšna družabna aktivnost v obliki všečkov, srčkov, ocen poročila med samo predstavitvijo, tako da lahko v pravem trenutku izpolnite povratne informacije, ne da bi vas kasneje motili obrazci za povratne informacije. Sprva takole.
In tudi dodajanje celotne platforme, razen za pretakanje in konference, tudi pokonferenčno stanje. To so seznami predvajanja (vključno s tistimi, ki so jih sestavili uporabniki), po možnosti vsebine iz drugih preteklih konferenc, integrirani, označeni, dostopni uporabniku in na voljo tudi za ogled na naši spletni strani ().
— Fantje, najlepša hvala za vaše odgovore!
Če so med bralci tisti, ki so se udeležili naših poletnih konferenc, delite svoje vtise o predvajalniku in oddaji. Kaj je bilo priročno, kaj vas je razjezilo, kaj bi radi videli v prihodnosti?
Če vas platforma zanima in jo želite videti »v bitki«, jo ponovno uporabimo na našem . Obstaja jih cela paleta, tako da se skoraj zagotovo najde kakšen pravi za vas.
Vir: www.habr.com