Ovo proljeće zatekli smo se u vrlo veselim uvjetima. Zbog pandemije postalo je jasno da naše ljetne konferencije trebamo premjestiti online. A kako bismo ih učinkovito proveli online, gotova softverska rješenja nisu nam odgovarala; morali smo napisati vlastita. A imali smo tri mjeseca da to učinimo.
Jasno je da su to bila uzbudljiva tri mjeseca. Ali izvana nije posve očito: što je internetska konferencijska platforma? Od kojih se dijelova sastoji? Stoga sam na posljednjoj od ljetnih DevOops konferencija pitao one koji su bili odgovorni za ovaj zadatak:
- Nikolaj Molčanov - tehnički direktor JUG Ru Grupe;
- Vladimir Krasilshchik je pragmatičan Java programer koji radi na pozadini (mogli ste također vidjeti njegova izvješća na našim Java konferencijama);
- Artyom Nikonov odgovoran je za sav naš video streaming.
Inače, na jesensko-zimskim konferencijama koristit ćemo poboljšanu verziju iste platforme – pa će mnogi čitatelji habre i dalje biti njezini korisnici.
Velika slika
— Kakav je bio sastav ekipe?
Nikolaj Molčanov: Imamo analitičara, dizajnera, testera, tri front-enda i back-enda. I, naravno, stručnjak u obliku slova T!
— Kako je taj proces općenito izgledao?
Nikolaj: Sve do sredine ožujka nismo imali ništa spremno za online. A 15. ožujka počeo se vrtjeti cijeli internetski vrtuljak. Postavili smo nekoliko repozitorija, planirali, razgovarali o osnovnoj arhitekturi i sve napravili u tri mjeseca.
To je, naravno, prošlo kroz klasične faze planiranja, arhitekture, odabira značajki, glasanja za te značajke, politike za te značajke, njihovog dizajna, razvoja, testiranja. Kao rezultat toga, 6. lipnja sve smo pustili u proizvodnju. . Za sve je bilo 90 dana.
— Jesmo li uspjeli ispuniti ono na što smo se obvezali?
Nikolaj: Budući da sada sudjelujemo na DevOops konferenciji online, znači da je uspjelo. Osobno sam se obvezao na ono glavno: kupcima ću donijeti alat pomoću kojeg mogu napraviti internetsku konferenciju.
Izazov je bio sljedeći: dajte nam alat s kojim možemo emitirati naše konferencije vlasnicima ulaznica.
Cijelo planiranje podijeljeno je u nekoliko faza, a sve značajke (oko 30 globalnih) podijeljene su u 4 kategorije:
- što ćemo svakako učiniti (bez njih ne možemo živjeti),
- što ćemo učiniti drugo,
- što nikada nećemo učiniti,
- i što nikada, nikada nećemo učiniti.
Napravili smo sve karakteristike iz prve dvije kategorije.
— Znam da je stvoreno ukupno 600 izdanja JIRA-e. U tri mjeseca ste napravili 13 mikroservisa, a sumnjam da nisu napisani samo u Javi. Koristili ste različite tehnologije, imate dva Kubernetes klastera u tri zone dostupnosti i 5 RTMP streamova u Amazonu.
Pogledajmo sada svaku komponentu sustava zasebno.
Streaming
— Počnimo s time kad već imamo video sliku i ona se prenosi nekim servisima. Artyem, reci nam kako se događa ovaj streaming?
Artjom Nikonov: Naša opća shema izgleda ovako: slika s kamere -> naša kontrolna soba -> lokalni RTMP poslužitelj -> Amazon -> video player. Više detalja na Habréu u lipnju.
Općenito, postoje dva globalna načina za to: ili na hardveru ili na temelju softverskih rješenja. Odabrali smo softverski put jer je lakši u slučaju daljinskih zvučnika. Nije uvijek moguće donijeti hardver zvučniku u drugoj zemlji, ali isporuka softvera zvučniku čini se jednostavnijom i pouzdanijom.
Hardverski gledano, imamo određeni broj kamera (u našim studijima i na udaljenim zvučnicima), određeni broj daljinskih upravljača u studiju, koji se ponekad moraju popraviti odmah ispod stola tijekom emitiranja.
Signali iz ovih uređaja ulaze u računala s karticama za snimanje, ulazno/izlaznim karticama i zvučnim karticama. Tamo se signali miješaju i sastavljaju u rasporede:
Primjer rasporeda za 4 zvučnika
Primjer rasporeda za 4 zvučnika
Nadalje, kontinuirano emitiranje osigurano je uz pomoć tri računala: postoji jedan glavni stroj i par radnih zauzvrat. Prvo računalo prikuplja prvo izvješće, drugo - pauzu, prvo - sljedeće izvješće, drugo - sljedeću pauzu i tako dalje. A glavni stroj miješa prvo s drugim.
To stvara svojevrsni trokut, a ako bilo koji od tih čvorova zakaže, možemo brzo i bez gubitka kvalitete nastaviti isporučivati sadržaj klijentima. Imali smo takvu situaciju. Tijekom prvog tjedna konferencija popravili smo jedan stroj, uključili ga/isključili. Čini se da su ljudi zadovoljni našom otpornošću.
Zatim, streamovi s računala idu na lokalni poslužitelj, koji ima dva zadatka: usmjeravanje RTMP streamova i snimanje sigurnosnih kopija. Dakle, imamo više točaka snimanja. Video streamovi se zatim šalju u dio našeg sustava izgrađen na Amazon SaaS uslugama. Koristimo ,S3,CloudFront.
Nikolaj: Što se tamo događa prije nego video dođe do publike? Morate to nekako prerezati, zar ne?
Artjom: S naše strane komprimiramo video i šaljemo ga MediaLiveu. Tamo lansiramo transkodere. Prekodiraju videe u stvarnom vremenu u nekoliko rezolucija kako bi ih ljudi mogli gledati na svojim telefonima, preko lošeg interneta u zemlji i tako dalje. Zatim se ti potoci usjeku , ovako funkcionira protokol . Sučelju šaljemo popis za reprodukciju koji sadrži pokazivače na te dijelove.
— Koristimo li rezoluciju 1080p?
Artjom: Širina našeg videa je ista kao 1080p - 1920 piksela, a visina je malo manja, slika je izduženija - postoje razlozi za to.
Igrač
— Artyom je opisao kako video dospijeva u streamove, kako se distribuira na različite popise za reprodukciju za različite rezolucije zaslona, reže na dijelove i ulazi u player. Kolya, sad mi reci kakav je ovo igrač, kako troši stream, zašto HLS?
Nikolaj: Imamo igrača kojeg mogu gledati svi gledatelji konferencije.
U biti, ovo je omot oko knjižnice , na kojem su ispisani mnogi drugi igrači. Ali trebala nam je vrlo specifična funkcionalnost: premotavanje i označavanje mjesta gdje se osoba nalazi, koji izvještaj trenutno gleda. Trebali su nam i vlastiti izgledi, raznorazni logotipi i sve ostalo što je ugrađeno kod nas. Stoga smo odlučili napisati vlastitu biblioteku (omot preko HLS-a) i ugraditi je na stranicu.
Ovo je root funkcija, pa je implementirana gotovo prva. A onda je sve raslo oko toga.
Zapravo, kroz autorizaciju, igrač od pozadine prima popis za reprodukciju s poveznicama na dijelove u korelaciji s vremenom i kvalitetom, preuzima one potrebne i prikazuje ih korisniku, usput izvodeći neku "čaroliju".
Primjer vremenske trake
— Gumb je ugrađen izravno u player za prikaz vremenske trake svih izvješća...
Nikolaj: Da, odmah smo riješili problem korisničke navigacije. Sredinom travnja odlučili smo da nećemo svaku našu konferenciju prenositi na zasebnoj web stranici, već ćemo sve objediniti na jednoj. Tako da korisnici Full Pass ulaznica mogu slobodno prelaziti između različitih konferencija: i prijenosa uživo i snimaka prošlih.
A kako bismo korisnicima olakšali kretanje kroz trenutni stream i prebacivanje između zapisa, odlučili smo napraviti gumb "Cijelo emitiranje" i vodoravne kartice izvješća za prebacivanje između zapisa i izvješća. Postoji kontrola tipkovnice.
— Je li bilo tehničkih poteškoća s ovim?
Nikolaj: Imali su traku za pomicanje na kojoj su bile označene početne točke različitih izvješća.
— Na kraju, jeste li implementirali ove oznake na traku za pomicanje prije nego što je YouTube napravio nešto slično?
Artjom: Tada su to imali u beta verziji. Čini se da je ovo prilično složena značajka jer su je djelomično testirali s korisnicima tijekom prošle godine. I sada je stigao u prodaju.
Nikolaj: Ali zapravo smo ga brže doveli u prodaju. Iskreno, iza ove jednostavne značajke postoji ogromna količina backend-a, frontend-a, izračuna i matematike unutar playera.
Frontend
— Hajdemo shvatiti kako ovaj sadržaj koji prikazujemo (govorna kartica, govornici, web stranica, raspored) dolazi do front enda?
Vladimir Krasilščik: Imamo nekoliko internih IT sustava. Postoji sustav u koji se unose svi izvještaji i svi govornici. Postoji proces kojim govornik sudjeluje na konferenciji. Govornik podnese prijavu, sustav je uhvati, zatim postoji određeni pipeline prema kojem se kreira izvještaj.
Ovako govornik vidi cjevovod
Ovaj sustav je naš interni razvoj.
Zatim trebate napraviti raspored od pojedinačnih izvješća. Kao što znate, ovo je NP-težak problem, ali mi ga nekako rješavamo. Da bismo to učinili, pokrećemo drugu komponentu koja generira raspored i prenosi ga na uslugu treće strane u oblaku Contentful. Tu sve izgleda kao tablica u kojoj su dani konferencije, u danima termini, a u terminima izvješća, pauze ili sponzorske aktivnosti. Dakle, sadržaj koji vidimo nalazi se u usluzi treće strane. A zadatak je to prenijeti na stranicu.
Čini se da je stranica samo stranica s igračem i ovdje nema ništa komplicirano. Osim što nije. Pozadina koja stoji iza ove stranice odlazi na Contentful, od tamo dobiva raspored, generira neke objekte i šalje ih sučelju. Koristeći websocket vezu, koju uspostavlja svaki klijent naše platforme, šaljemo mu ažuriranje rasporeda od backenda do frontenda.
Pravi slučaj: govornik je promijenio posao tijekom konferencije. Moramo promijeniti značku njegove tvrtke poslodavca. Kako se to događa iz pozadine? Ažuriranje se šalje svim klijentima putem websocketa, a zatim sam frontend iscrtava vremensku traku. Sve se to događa neprimjetno. Kombinacija usluge u oblaku i nekoliko naših komponenti daje nam priliku da generiramo sav ovaj sadržaj i damo ga naprijed.
Nikolaj: Ovdje je važno pojasniti da naša stranica nije klasična SPA aplikacija. Ovo je i renderirano web mjesto temeljeno na izgledu i SPA. Google ovu stranicu zapravo vidi kao prikazani HTML. Ovo je dobro za SEO i isporuku sadržaja korisniku. Ne čeka da se učita 1,5 megabajta JavaScripta prije nego što vidi stranicu, odmah vidi već prikazanu stranicu, a vi to osjetite svaki put kada promijenite izvješće. Sve se događa u pola sekunde jer je sadržaj već spreman i postavljen na pravo mjesto.
— Podvucimo crtu ispod svega navedenog nabrajajući tehnologije. Tyoma je rekao da imamo 5 Amazonovih streamova, tamo isporučujemo video i zvuk. Tamo imamo bash skripte, koristimo ih za pokretanje i konfiguraciju...
Artjom: To se događa putem AWS API-ja, tamo ima mnogo više tehničkih sporednih usluga. Podijelili smo odgovornosti tako da ja dostavljam , a front-end i back-end programeri to preuzimaju odatle. Imamo nekoliko vlastitih veza za pojednostavljenje rasporeda sadržaja, koje zatim izrađujemo u 4K, itd. Budući da su rokovi bili jako kratki, gotovo u potpunosti smo to napravili na AWS-u.
— Zatim sve to ide u player pomoću pozadinskog sustava. Imamo TypeScript, React, Next.JS u našem playeru. A na pozadini imamo nekoliko usluga u C#, Javi, Spring Boot i Node.js. Sve je to implementirano pomoću Kubernetesa pomoću infrastrukture Yandex.Cloud.
Također želim napomenuti da kada sam se trebao upoznati s platformom, pokazalo se da je lako: svi repozitoriji su na GitLabu, sve je dobro imenovano, testovi su napisani, postoji dokumentacija. Odnosno, čak iu hitnom režimu, oni su vodili računa o takvim stvarima.
Poslovna ograničenja i analitika
— Ciljali smo 10 korisnika na temelju poslovnih zahtjeva. Vrijeme je da razgovaramo o poslovnim ograničenjima koja smo imali. Morali smo osigurati veliko opterećenje, osigurati poštivanje zakona o čuvanju osobnih podataka. I što drugo?
Nikolaj: U početku smo krenuli od video zahtjeva. Najvažnija stvar je distribuirana video pohrana po cijelom svijetu za brzu isporuku klijentu. Drugi uključuju rezoluciju od 1080p, kao i premotavanje unatrag, što mnogi drugi ne provode u načinu rada uživo. Kasnije smo dodali mogućnost omogućavanja 2x brzine, uz njenu pomoć možete „uhvatiti korak“ sa uživo i nastaviti gledati konferenciju u stvarnom vremenu. Usput se pojavila i funkcija označavanja vremenske trake. Osim toga, morali smo biti otporni na pogreške i izdržati opterećenje od 10 veza. S pozadinske točke gledišta, to je približno 000 10 veza pomnoženo s 000 zahtjeva za svako osvježavanje stranice. A ovo je već 8 RPS/sec. Prilično malo.
— Jesu li postojali neki drugi zahtjevi za "virtualnu izložbu" s online štandovima partnera?
Nikolaj: Da, to je moralo biti učinjeno prilično brzo i univerzalno. Za svaku smo konferenciju imali do 10 partnerskih tvrtki i sve su se morale završiti u tjedan ili dva. Međutim, njihov se sadržaj malo razlikuje u formatu. Ali napravljen je određeni predložak koji sastavlja te stranice u hodu, praktički bez daljnjeg sudjelovanja u razvoju.
— Postojali su i zahtjevi za analitikom prikaza i statistike u stvarnom vremenu. Znam da za to koristimo Prometheus, ali recite nam detaljnije: koje zahtjeve ispunjavamo za analitiku i kako se to provodi?
Nikolaj: U početku imamo marketinške zahtjeve za prikupljanje za A/B testiranje i prikupljanje informacija kako bismo razumjeli kako ispravno isporučiti najbolji sadržaj klijentu u budućnosti. Također postoje zahtjevi za neke analitike o aktivnostima partnera i analitike koje vidite (brojač posjeta). Sve informacije se prikupljaju u realnom vremenu.
Ove informacije možemo pružiti u skupnom obliku čak i govornicima: koliko vas je ljudi gledalo u određenom trenutku. U isto vrijeme, u skladu sa Saveznim zakonom 152, vaš osobni račun i osobni podaci se ne prate ni na koji način.
Platforma već ima marketinške alate i naše metrike za mjerenje aktivnosti korisnika u stvarnom vremenu (tko je gledao koju sekundu izvješća) kako bi se izgradili grafikoni posjećenosti izvješća. Na temelju tih podataka rade se istraživanja koja će sljedeće konferencije učiniti boljima.
Prijevara
— Imamo li mehanizme protiv prijevara?
Nikolaj: Zbog tijesnog vremenskog okvira s poslovne točke gledišta, u početku nije postavljen zadatak da se odmah blokiraju nepotrebne veze. Ako su se dva korisnika prijavila pod istim računom, mogli su vidjeti sadržaj. Ali znamo koliko je istodobnih pregleda bilo s jednog računa. I zabranili smo nekoliko posebno zlonamjernih prekršitelja.
Vladimir: Svaka čast, jedan od baniranih korisnika shvatio je zašto se to dogodilo. Došao je, ispričao se i obećao da će kupiti kartu.
— Da bi se sve ovo dogodilo, morate potpuno pratiti sve korisnike od ulaza do izlaza, uvijek znati što rade. Kako ovaj sustav funkcionira?
Vladimir: Želio bih govoriti o analitici i statistici, koju zatim analiziramo za uspjeh izvješća ili ih onda možemo dati partnerima. Svi su klijenti povezani putem websocket veze na određeni backend klaster. Stoji tamo . Svaki klijent u svakom vremenskom razdoblju šalje što radi i koju stazu gleda. Zatim se te informacije skupljaju pomoću brzih Hazelcast poslova i šalju natrag svima koji gledaju te zapise. Vidimo u kutu koliko je ljudi sada s nama.
Iste informacije pohranjene su u i ide u naše jezero podataka, iz kojeg imamo priliku izgraditi zanimljiviji grafikon. Postavlja se pitanje: koliko je jedinstvenih korisnika pogledalo ovo izvješće? idemo na , postoje pingovi svih ljudi koji su došli preko id-a ovog izvješća. Prikupili smo, agregirali jedinstvene i sada možemo razumjeti.
Nikolaj: Ali u isto vrijeme od Prometeja primamo i podatke u stvarnom vremenu. Postavljen je protiv svih usluga Kubernetesa, protiv samog Kubernetesa. Sakuplja apsolutno sve, a s Grafanom možemo graditi bilo koje grafove u stvarnom vremenu.
Vladimir: S jedne strane, preuzimamo ovo za daljnju OLAP obradu. A za OLTP, aplikacija preuzima cijelu stvar u Prometheus, Grafana i grafikoni se čak spajaju!
- To je slučaj kada se grafikoni spoje.
Dinamičke promjene
— Recite nam kako se uvode dinamičke promjene: ako je izvješće otkazano 6 minuta prije početka, kakav je lanac radnji? Koji cjevovod radi?
Vladimir: Cjevovod je vrlo uvjetan. Postoji nekoliko mogućnosti. Prvi je da je program za generiranje rasporeda radio i promijenio raspored. Izmijenjeni raspored učitava se u Contentful. Nakon toga pozadina razumije da postoje promjene za ovu konferenciju u Contentfulu, preuzima je i ponovno gradi. Sve se preuzima i šalje putem websocketa.
Druga mogućnost, kada se sve događa vrtoglavom brzinom: urednik ručno mijenja informacije u Contentfulu (link na Telegram, izlaganje govornika itd.) i radi ista logika kao i prvi put.
Nikolaj: Sve se događa bez osvježavanja stranice. Sve promjene se odvijaju apsolutno neprimjetno za klijenta. Isto vrijedi i za prebacivanje izvješća. Kada dođe vrijeme, izvješće i sučelje se mijenjaju.
Vladimir: Također, postoje vremenska ograničenja za početak izvješća na vremenskoj traci. Na samom početku nema ništa. A ako prijeđete mišem preko crvene pruge, tada će se u nekom trenutku, zahvaljujući redatelju emitiranja, pojaviti odsječci. Redatelj postavlja ispravan početak emitiranja, pozadina preuzima ovu promjenu, izračunava vrijeme početka i završetka prezentacije cijele pjesme u skladu s rasporedom konferencije, šalje to našim klijentima, a igrač crta cutoffs. Sada se korisnik može jednostavno kretati do početka i kraja izvješća. Bio je to strog poslovni zahtjev, vrlo zgodan i koristan. Ne gubite vrijeme tražeći stvarno vrijeme početka izvješća. A kad napravimo pregled, bit će apsolutno prekrasno.
Raspoređivanje
— Htio bih pitati o raspoređivanju. Kolya i ekipa potrošili su dosta vremena na početku da postave cijelu infrastrukturu u kojoj se sve odvija za nas. Reci mi od čega je sve napravljeno?
Nikolaj: S tehničke točke gledišta, u početku smo imali zahtjev da proizvod bude što apstraktniji od bilo kojeg dobavljača. Dođite na AWS da napravite Terraform skripte posebno iz AWS-a, ili posebno iz Yandexa, ili iz Azurea itd. nije baš odgovaralo. Morali smo se negdje preseliti u nekom trenutku.
Prva tri tjedna stalno smo tražili način da ovo učinimo boljim. Kao rezultat toga, došli smo do zaključka da je Kubernetes u ovom slučaju naše sve, jer nam omogućuje stvaranje usluga koje se automatski skaliraju, automatsko uvođenje i dobivanje gotovo svih usluga iz kutije. Naravno, sve servise je trebalo osposobiti za rad s Kubernetesom, Dockerom, a i tim je morao učiti.
Imamo dva klastera. Test i proizvodnja. Apsolutno su identični što se tiče hardvera i postavki. Infrastrukturu implementiramo kao kod. Sve usluge automatski se uvode u tri okruženja od značajnih grana, glavnih grana, testnih grana i GitLaba pomoću automatskog cjevovoda. Ovo je maksimalno integrirano u GitLab, maksimalno integrirano u Elastic, Prometheus.
Dobivamo priliku brzo (za backend u roku od 10 minuta, za frontend u roku od 5 minuta) uvesti promjene u bilo koje okruženje sa svim testovima, integracijama, izvođenjem funkcionalnih testova, integracijskim testovima na okruženju, te također testirati s testovima opterećenja na testna okolina otprilike ista stvar koju želimo dobiti u proizvodnji.
O testovima
— Testirate gotovo sve, teško je vjerovati kako ste sve napisali. Možete li nam reći nešto o backend testovima: koliko je sve pokriveno, koji testovi?
Vladimir: Napisane su dvije vrste testova. Prvi su testovi komponenti. Ispitivanje razine podizanja cijele aplikacije opruge i baze u . Ovo je test poslovnih scenarija najviše razine. Ne testiram funkcije. Testiramo samo neke velike stvari. Na primjer, odmah u testu emulira se proces prijave korisnika, korisnikov zahtjev za ulaznicama gdje može ići i zahtjev za pristup gledanju streama. Vrlo jasni korisnički scenariji.
Otprilike ista stvar implementirana je u takozvanim integracijskim testovima, koji se zapravo pokreću u okruženju. Zapravo, kada se uvede sljedeća implementacija u proizvodnju, stvarni osnovni scenariji također se izvode u proizvodnji. Ista prijava, traženje ulaznica, traženje pristupa CloudFrontu, provjera povezuje li se stream stvarno s mojim dopuštenjima, provjera sučelja redatelja.
Trenutačno imam oko 70 komponentnih testova i oko 40 integracijskih testova. Pokrivenost je vrlo blizu 95%. Ovo je za sastavne, manje za integracijske, jednostavno nema toliko potrebe. S obzirom da projekt uključuje sve vrste generiranja koda, ovo je vrlo dobar pokazatelj. Nije bilo drugog načina da napravimo ono što smo napravili u tri mjeseca. Jer ako bismo testirali ručno, dajući značajke našem testeru, a ona bi pronašla greške i vratila nam ih na popravke, onda bi ovo povratno putovanje za otklanjanje pogrešaka u kodu bilo jako dugo, a mi ne bismo ispunili nikakve rokove.
Nikolaj: Konvencionalno, da biste izvršili regresiju na cijeloj platformi pri promjeni neke funkcije, trebate sjediti i čačkati posvuda dva dana.
Vladimir: Stoga je veliki uspjeh da kad procjenjujem značajku, kažem da mi treba 4 dana za dvije obične olovke i 1 websocket, Kolya to dopušta. Već je navikao na činjenicu da ova 4 dana uključuju 2 vrste testova, a onda će, najvjerojatnije, uspjeti.
Nikolaj: Imam i 140 napisanih testova: komponentni + funkcionalni, koji rade istu stvar. Svi se isti scenariji testiraju u proizvodnji, u testu iu proizvodnji. Također smo nedavno dodali funkcionalne osnovne testove korisničkog sučelja. Na taj način pokrivamo najosnovnije funkcije koje se mogu raspasti.
Vladimir: Naravno, vrijedi razgovarati o testovima opterećenja. Platformu je bilo potrebno testirati pod opterećenjem bliskim stvarnom kako bi se shvatilo kako je sve, što se događa s Rabbitom, što se događa s JVM-ovima, koliko je memorije zapravo potrebno.
— Ne znam sa sigurnošću testiramo li nešto na strani streama, ali sjećam se da je bilo problema s transkoderima kad smo radili susrete. Jesmo li testirali streamove?
Artjom: Testirano iterativno. Organiziranje susreta. U procesu organizacije meetupa bilo je oko 2300 JIRA ulaznica. Ovo su samo generičke stvari koje su ljudi radili kako bi organizirali susrete. Prenijeli smo dijelove platforme na zasebnu stranicu za susrete, koju je vodio Kirill Tolkachev ().
Iskreno govoreći, nije bilo velikih problema. Doslovno smo nekoliko puta uhvatili greške u predmemoriranju na CloudFrontu, riješili smo to prilično brzo - jednostavno smo rekonfigurirali pravila. Bilo je znatno više grešaka u ljudima, u sustavima za streaming na stranici.
Tijekom konferencija morao sam napisati još nekoliko izvoznika kako bih pokrio više opreme i usluga. Na nekim sam mjestima morao napraviti vlastite bicikle samo radi metrike. Svijet AV (audio-video) hardvera nije baš ružičast - imate nekakav “API” opreme na koji jednostavno ne možete utjecati. I daleko je od činjenice da ćete moći dobiti informacije koje su vam potrebne. Dobavljači hardvera stvarno su spori i gotovo je nemoguće od njih dobiti ono što želite. Ukupno postoji više od 100 komada hardvera, ne vraćaju ono što vam treba, a pišete čudne i suvišne izvoznike, zahvaljujući kojima možete barem nekako debugirati sustav.
Оборудование
— Sjećam se kako smo prije početka konferencija djelomično nabavili dodatnu opremu.
Artjom: Kupovali smo računala, laptope i baterije. U ovom trenutku možemo živjeti bez struje 40 minuta. U lipnju su bile jake grmljavinske oluje u St. Petersburgu - pa smo imali takvo zamračenje. U isto vrijeme, više pružatelja dolazi nam s optičkim vezama s različitih točaka. Ovo je stvarno 40 minuta zastoja zgrade, tijekom kojih će nam raditi svjetla, zvuk, kamere itd.
— Imamo sličnu priču s internetom. U uredu u kojem se nalaze naši studiji razvukli smo žestoku mrežu između podova.
Artjom: Imamo 20 Gbit vlakana između katova. Dalje po katovima, negdje ima optike, negdje je nema, ali ipak ima manje kanala od gigabitnih - na njih puštamo video između traka konferencije. Općenito, vrlo je zgodno raditi na vlastitoj infrastrukturi; rijetko to možete učiniti na izvanmrežnim konferencijama na web-mjestima.
— Prije nego što sam radio u JUG Ru Grupi, vidio sam kako se hardverske sobe na offline konferencijama postavljaju preko noći, gdje je veliki monitor sa svim metrikama koje gradiš u Grafani. Sada postoji i centralna soba u kojoj sjedi razvojni tim koji tijekom konferencije popravlja neke greške i razvija značajke. Istovremeno, tu je i sustav nadzora koji se prikazuje na velikom ekranu. Artjom, Kolja i drugi dečki sjede i paze da sve ne padne i da lijepo radi.
Zanimljivosti i problemi
— Dobro ste govorili o tome da imamo streaming s Amazonom, postoji player s webom, sve je napisano u različitim programskim jezicima, omogućena je tolerancija na greške i ostali poslovni zahtjevi, uključujući osobni račun koji je podržan za pravne osobe i pojedincima, a možemo se integrirati s nekim tko koristi OAuth 2.0, postoji zaštita od prijevara, blokiranje korisnika. Možemo dinamički uvoditi promjene jer smo to dobro napravili i sve je testirano.
Zanima me koje su neobičnosti bile uključene u pokretanje nečega. Je li bilo čudnih situacija kada ste razvijali backend, frontend, ispalo je nešto ludo i niste razumjeli što s tim?
Vladimir: Čini mi se da se to događa tek zadnja tri mjeseca. Svaki dan. Kao što vidite, sva kosa mi je počupana.
Vladimir Krasilshchik nakon 3 mjeseca, kada je ispala neka vrsta igre i nitko nije razumio što s njom
Svaki dan je bilo ovako nešto, kada je bio takav trenutak kada uzmeš i počupaš kosu, ili shvatiš da nema niko drugi, i samo ti to možeš. Naš prvi veliki događaj bio je TechTrain. 6. lipnja u 2 ujutro još nismo izveli proizvodno okruženje, Kolja ga je izbacivao. I osobni račun nije radio kao autorizacijski poslužitelj koristeći OAuth2.0. Pretvorili smo ga u OAuth2.0 davatelja kako bismo s njim povezali platformu. Radio sam valjda 18 sati bez prestanka, gledao sam u računalo i nisam ništa vidio, nisam razumio zašto ne radi, a Kolja je gledao moj kod na daljinu, tražio grešku u konfiguraciji Springa , pronašao ga je i LC je radio, i to u proizvodnji također.
Nikolaj: A sat vremena prije TechTraina puštanje se dogodilo.
Ovdje se posložilo puno zvijezda. Imali smo veliku sreću jer smo imali super tim i svi su bili inspirirani idejom da to radimo online. Sva ova tri mjeseca bili smo vođeni činjenicom da smo “napravili YouTube”. Nisam si dozvolio da počupam kosu, već sam svima govorio da će sve uspjeti, jer je zapravo sve odavno proračunato.
O izvedbi
— Možete li mi reći koliko je ljudi bilo na stranici na jednoj stazi? Je li bilo problema s izvedbom?
Nikolaj: Nije bilo problema s performansama, kao što smo već rekli. Maksimalan broj ljudi koji je prisustvovao jednom izvješću bio je 1300 ljudi, ovo je na Heisenbugu.
— Je li bilo problema s lokalnim gledanjem? I je li moguće imati tehnički opis sa dijagramima kako to sve radi?
Nikolaj: O tome ćemo kasnije napisati članak.
Možete čak i lokalno ispravljati pogreške u streamovima. Kad su konferencije krenule, postalo je još lakše jer su se pojavili produkcijski streamovi koje možemo pratiti cijelo vrijeme.
Vladimir: Koliko sam shvatio, front-end programeri radili su lokalno s mockovima, a zatim, budući da je vrijeme za izvođenje programerima u frontu također kratko (5 minuta), nema problema s provjerom što se događa s certifikatima.
— Sve se testira i otklanjaju se pogreške, čak i lokalno. To znači da ćemo napisati članak sa svim tehničkim karakteristikama, pokazati vam, ispričati sve sa dijagramima, kako je bilo.
Vladimir: Možete uzeti i ponoviti.
- Za 3 mjeseca.
Ukupan
— Sve opisano zajedno zvuči cool, s obzirom da je to napravio mali tim u tri mjeseca.
Nikolaj: Velika ekipa ovo ne bi napravila. Ali mala grupa ljudi koja međusobno dosta blisko i dobro komunicira i može se dogovoriti mogla bi. Oni nemaju nikakvih proturječja, arhitektura je izmišljena u dva dana, dovršena je i zapravo se nije promijenila. Postoji vrlo striktno olakšavanje dolaznih poslovnih zahtjeva u smislu gomilanja zahtjeva za značajkama i promjena.
— Što je bilo na vašem popisu daljnjih zadataka kad su ljetne konferencije već bile?
Nikolaj: Na primjer, krediti. Puzajuće linije na videozapisu, skočni prozori na nekim mjestima u videozapisu, ovisno o sadržaju koji se prikazuje. Na primjer, govornik želi postaviti pitanje publici, a glasovanje se pojavljuje na ekranu, koje se vraća na poleđinu na temelju rezultata glasovanja do samog govornika. Neka vrsta društvene aktivnosti u obliku lajkova, srca, ocjena izvješća tijekom same prezentacije, tako da možete ispuniti povratnu informaciju u pravom trenutku, a da vas kasnije ne ometaju obrasci za povratne informacije. U početku ovako.
I također dodavanje cijeloj platformi, osim za streaming i konferenciju, također stanje nakon konferencije. To su popisi za reprodukciju (uključujući one koje su sastavili korisnici), po mogućnosti sadržaji s drugih prošlih konferencija, integrirani, označeni, dostupni korisniku, a također dostupni za gledanje na našoj web stranici ().
— Ljudi, hvala vam puno na odgovorima!
Ako među čitateljima ima onih koji su bili na našim ljetnim konferencijama, podijelite svoje dojmove o igraču i prijenosu. Što je bilo zgodno, što vas je iritiralo, što biste voljeli vidjeti u budućnosti?
Ako ste zainteresirani za platformu i želite je vidjeti "u borbi", koristimo je ponovno na našem . Ima ih cijeli niz, tako da je gotovo sigurno jedan pravi za vas.
Izvor: www.habr.com