Questa primavera ci siamo trovati in condizioni molto allegre. A causa della pandemia, è diventato chiaro che le nostre conferenze estive dovevano essere spostate online. E per poterli condurre online in modo efficiente, le soluzioni software già pronte non erano adatte a noi; dovevamo scriverne di nostre. E avevamo tre mesi per farlo.
È chiaro che sono stati tre mesi entusiasmanti. Ma dall’esterno non è del tutto ovvio: cos’è una piattaforma per conferenze online? Da quali parti è composto? Pertanto, in occasione dell’ultima conferenza DevOops estiva, ho chiesto a coloro che erano responsabili di questo compito:
- Nikolay Molchanov - direttore tecnico del JUG Ru Group;
- Vladimir Krasilshchik è un pragmatico programmatore Java che lavora sul backend (potresti anche vedere i suoi resoconti alle nostre conferenze Java);
- Artyom Nikonov è responsabile di tutto il nostro streaming video.
A proposito, alle conferenze autunno-inverno utilizzeremo una versione migliorata della stessa piattaforma, quindi molti lettori di habra saranno ancora i suoi utenti.
РћР � С ‰ Р � СЏ РєР � СЂС,РёРЅР �
— Qual era la composizione della squadra?
Nikolaj Molchanov: Abbiamo un analista, un designer, un tester, tre front-end e un back-end. E, naturalmente, uno specialista a forma di T!
— Come è stato il processo in generale?
Nikolai: Fino a metà marzo non avevamo nulla di pronto per l’online. E dal 15 marzo tutta la giostra online ha cominciato a girare. Abbiamo creato diversi repository, pianificato, discusso l'architettura di base e fatto tutto in tre mesi.
Questo, ovviamente, ha attraversato le fasi classiche di pianificazione, architettura, selezione delle funzionalità, votazione per tali funzionalità, politica per tali funzionalità, loro progettazione, sviluppo, test. Di conseguenza, il 6 giugno, abbiamo portato tutto in produzione. . C'erano 90 giorni per tutto.
— Siamo riusciti a portare a termine ciò che ci eravamo impegnati?
Nikolai: Dato che ora stiamo partecipando alla conferenza DevOops online, significa che ha funzionato. Personalmente mi sono impegnato sulla cosa principale: portare ai clienti uno strumento con cui potranno fare una conferenza online.
La sfida era questa: darci uno strumento con cui poter trasmettere le nostre conferenze ai possessori del biglietto.
Tutta la pianificazione è stata suddivisa in più fasi e tutte le funzionalità (circa 30 globali) sono state divise in 4 categorie:
- cosa che faremo sicuramente (non possiamo vivere senza di loro),
- cosa che faremo in secondo luogo,
- cosa che non faremo mai,
- e cosa che non faremo mai e poi mai.
Abbiamo realizzato tutte le funzionalità delle prime due categorie.
— So che sono state create in totale 600 emissioni JIRA. In tre mesi hai realizzato 13 microservizi e sospetto che siano stati scritti non solo in Java. Hai utilizzato tecnologie diverse, hai due cluster Kubernetes in tre zone di disponibilità e 5 flussi RTMP in Amazon.
Consideriamo ora separatamente ciascun componente del sistema.
Streaming
— Cominciamo con quando abbiamo già un'immagine video e questa viene trasmessa ad alcuni servizi. Artyom, raccontaci come avviene questo streaming?
Artyom Nikonov: Il nostro schema generale è simile a questo: immagine dalla telecamera -> la nostra sala di controllo -> server RTMP locale -> Amazon -> lettore video. Più dettagli su Habré in giugno.
In generale, esistono due modi globali per farlo: tramite hardware o tramite soluzioni software. Abbiamo scelto la strada del software perché è più semplice nel caso di altoparlanti remoti. Non è sempre possibile portare l'hardware a un relatore in un altro paese, ma consegnare il software al relatore sembra più semplice e affidabile.
Dal punto di vista hardware, abbiamo un certo numero di telecamere (nei nostri studi e presso gli altoparlanti remoti), un certo numero di telecomandi in studio, che a volte devono essere riparati proprio sotto il tavolo durante la trasmissione.
I segnali provenienti da questi dispositivi entrano nei computer dotati di schede di acquisizione, schede di input/output e schede audio. Lì i segnali vengono mescolati e assemblati in layout:
Esempio di layout per 4 altoparlanti
Esempio di layout per 4 altoparlanti
Inoltre, la trasmissione continua viene fornita con l'ausilio di tre computer: c'è una macchina principale e una coppia di macchine funzionanti a turno. Il primo computer raccoglie il primo rapporto, il secondo l'interruzione, il primo il rapporto successivo, il secondo l'interruzione successiva e così via. E la macchina principale mescola la prima con la seconda.
Questo crea una sorta di triangolo e, se uno qualsiasi di questi nodi fallisce, possiamo continuare a fornire contenuti ai clienti rapidamente e senza perdita di qualità. Abbiamo avuto una situazione del genere. Durante la prima settimana di conferenze, abbiamo riparato una macchina, accendendola e spegnendola. Le persone sembrano essere contente della nostra resilienza.
Successivamente, i flussi provenienti dai computer vanno a un server locale, che ha due compiti: instradare i flussi RTMP e registrare i backup. Quindi abbiamo più punti di registrazione. I flussi video vengono quindi inviati alla parte del nostro sistema basata sui servizi Amazon SaaS. Noi usiamo ,S3,CloudFront.
Nikolai: Cosa succede lì prima che il video raggiunga il pubblico? Devi tagliarlo in qualche modo, giusto?
Artyom: Comprimiamo il video da parte nostra e lo inviamo a MediaLive. Lanciamo i transcodificatori lì. Transcodificano i video in tempo reale in diverse risoluzioni in modo che le persone possano guardarli sui loro telefoni, attraverso la scarsa connessione Internet nel paese e così via. Quindi questi flussi vengono tagliati , ecco come funziona il protocollo . Inviamo una playlist al frontend che contiene puntatori a questi blocchi.
— Stiamo utilizzando la risoluzione 1080p?
Artyom: La larghezza del nostro video è uguale a 1080p - 1920 pixel e l'altezza è leggermente inferiore, l'immagine è più allungata - ci sono ragioni per questo.
giocatore
— Artyom ha descritto come il video entra negli stream, come viene distribuito in diverse playlist per diverse risoluzioni dello schermo, tagliato in blocchi e inserito nel player. Kolya, ora dimmi che tipo di giocatore è questo, come consuma lo streaming, perché HLS?
Nikolai: Abbiamo un giocatore che tutti gli spettatori della conferenza possono guardare.
Essenzialmente, questo è un wrapper attorno alla libreria , su cui sono scritti molti altri giocatori. Ma avevamo bisogno di funzionalità molto specifiche: riavvolgere e contrassegnare il luogo in cui si trova la persona, quale report sta guardando attualmente. Avevamo anche bisogno dei nostri layout, di tutti i tipi di loghi e di tutto ciò che era integrato con noi. Pertanto, abbiamo deciso di scrivere la nostra libreria (un wrapper su HLS) e di incorporarla nel sito.
Questa è la funzionalità root, quindi è stata implementata quasi per prima. E poi tutto è cresciuto attorno ad esso.
Infatti, tramite autorizzazione, il player riceve dal backend una playlist con collegamenti a blocchi correlati a tempo e qualità, scarica quelli necessari e li mostra all'utente, compiendo alcune “magie” lungo il percorso.
Esempio di sequenza temporale
— Nel lettore è integrato un pulsante per visualizzare una sequenza temporale di tutti i report...
Nikolai: Sì, abbiamo risolto immediatamente il problema della navigazione dell'utente. A metà aprile abbiamo deciso che non avremmo trasmesso ciascuna delle nostre conferenze su un sito web separato, ma avremmo riunito tutto in uno solo. In questo modo gli utenti del biglietto Full Pass possono passare liberamente tra diverse conferenze: sia le trasmissioni in diretta che le registrazioni di quelle passate.
E per rendere più semplice per gli utenti la navigazione nel flusso corrente e il passaggio da una traccia all'altra, abbiamo deciso di creare un pulsante "Trasmissione intera" e pagelle orizzontali per passare da una traccia all'altra e da un report all'altro. C'è il controllo da tastiera.
— Ci sono state difficoltà tecniche a riguardo?
Nikolai: Avevano una barra di scorrimento su cui erano contrassegnati i punti di partenza dei diversi report.
— Alla fine, hai implementato questi segni sulla barra di scorrimento prima che YouTube facesse qualcosa di simile?
Artyom: Allora lo avevano in versione beta. Sembra che questa sia una funzionalità piuttosto complessa perché l'hanno parzialmente testata con gli utenti nell'ultimo anno. E ora è in vendita.
Nikolai: Ma in realtà l'abbiamo messo in vendita più velocemente. Onestamente, dietro questa semplice funzionalità c'è un'enorme quantità di backend, frontend, calcoli e matematica all'interno del player.
Fine frontale
— Cerchiamo di capire come i contenuti che mostriamo (discorso, relatori, sito web, programma) arrivano al front-end?
Vladimir Krasilshchik: Disponiamo di diversi sistemi IT interni. Esiste un sistema in cui vengono inseriti tutti i rapporti e tutti gli oratori. Esiste un processo attraverso il quale un relatore prende parte a una conferenza. L'oratore presenta una domanda, il sistema la acquisisce, quindi esiste una determinata pipeline in base alla quale viene creato il rapporto.
Ecco come l'oratore vede la pipeline
Questo sistema è il nostro sviluppo interno.
Successivamente, è necessario creare una pianificazione dai singoli report. Come sai, questo è un problema NP difficile, ma in qualche modo lo risolviamo. Per fare ciò, lanciamo un altro componente che genera un programma e lo carica sul servizio cloud di terze parti Contentful. Lì tutto sembra una tabella in cui ci sono i giorni del convegno, nei giorni ci sono le fasce orarie e nelle fasce orarie ci sono i resoconti, le pause o le attività di sponsorizzazione. Quindi il contenuto che vediamo si trova in un servizio di terze parti. E il compito è trasmetterlo al sito.
Sembrerebbe che il sito sia solo una pagina con un lettore e qui non c'è nulla di complicato. Solo che non lo è. Il backend dietro questa pagina va a Contentful, da lì ottiene la pianificazione, genera alcuni oggetti e li invia al frontend. Utilizzando una connessione websocket, che fa ogni cliente della nostra piattaforma, gli inviamo un aggiornamento del programma dal backend al frontend.
Caso reale: il relatore ha cambiato lavoro proprio durante la conferenza. Dobbiamo cambiare il badge aziendale del suo datore di lavoro. Come avviene questo dal backend? Un aggiornamento viene inviato a tutti i client tramite il websocket, quindi il frontend stesso ridisegna la sequenza temporale. Tutto questo avviene senza soluzione di continuità. La combinazione del servizio cloud e di molti dei nostri componenti ci dà l'opportunità di generare tutti questi contenuti e fornirli in primo piano.
Nikolai: È importante chiarire qui che il nostro sito non è una classica applicazione SPA. Questo è sia un sito Web renderizzato basato su layout che una SPA. Google in realtà vede questo sito come HTML renderizzato. Questo è positivo per la SEO e per fornire contenuti all’utente. Non attende il caricamento di 1,5 megabyte di JavaScript prima di vedere la pagina, vede immediatamente la pagina già renderizzata e lo senti ogni volta che cambi il rapporto. Tutto avviene in mezzo secondo, poiché il contenuto è già pronto e pubblicato nel posto giusto.
— Tracciamo una linea sotto tutto quanto sopra elencando le tecnologie. Tyoma ha detto che abbiamo 5 stream Amazon e lì forniamo video e audio. Abbiamo degli script bash lì, li usiamo per avviare e configurare...
Artyom: Ciò avviene tramite l'API AWS, dove sono presenti molti altri servizi collaterali tecnici. Abbiamo diviso le nostre responsabilità in modo che io consegni a e gli sviluppatori front-end e back-end prendono da lì. Disponiamo di una serie di rilegature nostre per semplificare il layout dei contenuti, che poi realizziamo in 4K, ecc. Dato che le scadenze erano molto strette, lo abbiamo fatto quasi interamente su AWS.
— Quindi tutto questo entra nel lettore utilizzando il sistema backend. Abbiamo TypeScript, React, Next.JS nel nostro lettore. E sul backend abbiamo diversi servizi in C#, Java, Spring Boot e Node.js. Tutto questo viene distribuito utilizzando Kubernetes utilizzando l'infrastruttura Yandex.Cloud.
Voglio anche sottolineare che quando ho avuto bisogno di familiarizzare con la piattaforma, si è rivelato facile: tutti i repository sono su GitLab, tutto ha un buon nome, i test sono scritti, c'è la documentazione. Cioè, anche in modalità emergenza, si sono presi cura di queste cose.
Vincoli aziendali e analisi
— Abbiamo scelto come target 10 utenti in base ai requisiti aziendali. È tempo di parlare delle restrizioni commerciali che abbiamo avuto. Dovevamo garantire un carico di lavoro elevato, garantire il rispetto della legge sulla conservazione dei dati personali. E che altro?
Nikolai: Inizialmente siamo partiti dai requisiti video. La cosa più importante è l'archiviazione video distribuita in tutto il mondo per una consegna rapida al cliente. Altri includono la risoluzione 1080p e il riavvolgimento, che molti altri non implementano in modalità live. Successivamente abbiamo aggiunto la possibilità di abilitare la velocità 2x, con il suo aiuto puoi “recuperare” il live e continuare a guardare la conferenza in tempo reale. E lungo il percorso è apparsa la funzionalità di marcatura della timeline. Inoltre, dovevamo essere tolleranti ai guasti e sopportare il carico di 10 connessioni. Dal punto di vista del backend si tratta di circa 000 connessioni moltiplicate per 10 richieste per ogni aggiornamento della pagina. E questo è già 000 RPS/sec. Un bel po'.
— C’erano altri requisiti per una “mostra virtuale” con stand online dei partner?
Nikolai: Sì, questo doveva essere fatto abbastanza rapidamente e universalmente. Avevamo fino a 10 aziende partner per ogni conferenza e tutte dovevano essere completate in una o due settimane. Tuttavia, il loro contenuto differisce leggermente nel formato. Ma è stato creato un certo motore di template che assembla queste pagine al volo, praticamente senza ulteriore partecipazione allo sviluppo.
— C'erano anche requisiti per l'analisi di visualizzazioni e statistiche in tempo reale. So che utilizziamo Prometheus per questo, ma spiegaci più in dettaglio: quali requisiti soddisfiamo per l'analisi e come viene implementata?
Nikolai: Inizialmente, abbiamo requisiti di marketing per la raccolta di test A/B e raccolta di informazioni per capire come fornire correttamente i migliori contenuti al cliente in futuro. Sono inoltre previsti requisiti per alcune analisi sulle attività dei partner e per le analisi visualizzate (contatore visite). Tutte le informazioni vengono raccolte in tempo reale.
Possiamo fornire queste informazioni in forma aggregata anche ai relatori: quante persone ti stavano guardando in un determinato momento. Allo stesso tempo, per rispettare la legge federale 152, il tuo account personale e i tuoi dati personali non vengono tracciati in alcun modo.
La piattaforma dispone già di strumenti di marketing e delle nostre metriche per misurare l'attività degli utenti in tempo reale (chi ha guardato quale secondo del report) al fine di costruire grafici di partecipazione ai report. Sulla base di questi dati si stanno facendo ricerche che renderanno migliori i prossimi convegni.
Frode
— Esistono meccanismi antifrode?
Nikolai: A causa dei tempi ristretti dal punto di vista aziendale, inizialmente l'attività non era impostata per bloccare immediatamente le connessioni non necessarie. Se due utenti accedessero con lo stesso account, potrebbero visualizzare il contenuto. Ma sappiamo quante visualizzazioni simultanee ci sono state da un account. E abbiamo bandito diversi trasgressori particolarmente dannosi.
Vladimir: A suo merito, uno degli utenti bannati ha capito perché ciò è accaduto. È venuto, si è scusato e ha promesso di comprare un biglietto.
— Perché tutto ciò avvenga è necessario tracciare completamente tutti gli utenti dall’ingresso all’uscita, sapere sempre cosa stanno facendo. Come funziona questo sistema?
Vladimir: Vorrei parlare di analisi e statistiche, che poi analizziamo per il successo del report o che possiamo poi fornire ai partner. Tutti i client sono connessi tramite una connessione websocket a uno specifico cluster backend. Sta lì . Ogni cliente in ogni periodo di tempo invia cosa sta facendo e quale traccia sta guardando. Quindi queste informazioni vengono aggregate utilizzando lavori Hazelcast veloci e rispedite a tutti coloro che guardano queste tracce. Vediamo nell'angolo quante persone sono adesso con noi.
Le stesse informazioni sono memorizzate in e va al nostro data Lake, da cui abbiamo l'opportunità di costruire un grafico più interessante. La domanda sorge spontanea: quanti utenti unici hanno visualizzato questo rapporto? Andiamo a , ci sono i ping di tutte le persone che sono arrivate con l'id di questo rapporto. Abbiamo raccolto, aggregato quelli unici e ora possiamo capire.
Nikolai: Ma allo stesso tempo riceviamo anche dati in tempo reale da Prometheus. È contro tutti i servizi Kubernetes, contro Kubernetes stesso. Raccoglie assolutamente tutto e con Grafana possiamo costruire qualsiasi grafico in tempo reale.
Vladimir: Da un lato lo scarichiamo per un'ulteriore elaborazione OLAP. E per OLTP, l'applicazione scarica tutto su Prometheus, Grafana e i grafici addirittura convergono!
- Questo è il caso in cui i grafici convergono.
Cambiamenti dinamici
— Raccontaci come vengono implementati i cambiamenti dinamici: se il rapporto è stato annullato 6 minuti prima dell'inizio, qual è la catena di azioni? Quale pipeline funziona?
Vladimir: Il gasdotto è molto condizionato. Ci sono diverse possibilità. Il primo è che il programma di generazione della pianificazione ha funzionato e ha modificato la pianificazione. Il programma modificato viene caricato su Contentful. Dopodiché il backend capisce che ci sono modifiche per questa conferenza in Contentful, la prende e la ricostruisce. Tutto viene raccolto e inviato tramite websocket.
La seconda possibilità, quando tutto avviene a un ritmo vertiginoso: l’editor modifica manualmente le informazioni in Contentful (link a Telegram, presentazione del relatore, ecc.) e funziona la stessa logica della prima volta.
Nikolai: Tutto avviene senza aggiornare la pagina. Tutte le modifiche avvengono in modo assolutamente fluido per il cliente. Lo stesso vale per il cambio di rapporto. Quando arriva il momento, il rapporto e l'interfaccia cambiano.
Vladimir: Inoltre, nella sequenza temporale sono previsti limiti di tempo per l'avvio dei report. All'inizio non c'è nulla. E se passi il mouse sulla striscia rossa, ad un certo punto, grazie al direttore della trasmissione, appariranno dei tagli. Il regista imposta l'inizio corretto della trasmissione, il backend rileva questa modifica, calcola gli orari di inizio e fine delle presentazioni dell'intero brano in base al programma della conferenza, lo invia ai nostri clienti e il giocatore disegna i cutoff. Ora l'utente può passare facilmente all'inizio e alla fine del report. Era un requisito aziendale rigoroso, molto conveniente e utile. Non perderai tempo a trovare l'ora di inizio effettiva del report. E quando faremo un'anteprima, sarà assolutamente meraviglioso.
Distribuzione
— Vorrei chiedere informazioni sulla distribuzione. All'inizio Kolya e il team hanno dedicato molto tempo alla realizzazione dell'intera infrastruttura in cui tutto si svolge per noi. Dimmi, di cosa è fatto tutto questo?
Nikolai: Da un punto di vista tecnico, inizialmente avevamo l'esigenza che il prodotto fosse il più astratto possibile da qualsiasi fornitore. Vieni in AWS per creare script Terraform specificatamente da AWS, o specificatamente da Yandex, o da Azure, ecc. non si adattava davvero. Ad un certo punto dovevamo trasferirci da qualche parte.
Per le prime tre settimane siamo stati costantemente alla ricerca di un modo per farlo meglio. Di conseguenza, siamo giunti alla conclusione che Kubernetes in questo caso è il nostro tutto, perché ci consente di creare servizi con scalabilità automatica, implementazione automatica e ottenere quasi tutti i servizi pronti all'uso. Naturalmente tutti i servizi dovevano essere formati per lavorare con Kubernetes e Docker e anche il team doveva imparare.
Abbiamo due cluster. Prova e produzione. Sono assolutamente identici in termini di hardware e impostazioni. Implementiamo l'infrastruttura come codice. Tutti i servizi vengono automaticamente distribuiti in tre ambienti da rami di funzionalità, rami master, rami di test e GitLab utilizzando una pipeline automatica. Questo è integrato al massimo in GitLab, integrato al massimo con Elastic, Prometheus.
Abbiamo l'opportunità di implementare rapidamente (per il backend entro 10 minuti, per il frontend entro 5 minuti) modifiche a qualsiasi ambiente con tutti i test, integrazioni, esecuzione di test funzionali, test di integrazione sull'ambiente e anche test con test di carico su un ambiente di test più o meno lo stesso che vogliamo ottenere in produzione.
A proposito di test
— Provi quasi tutto, è difficile credere come hai scritto tutto. Puoi parlarci dei test di backend: quanto è coperto tutto, quali test?
Vladimir: Sono stati scritti due tipi di test. I primi sono i test dei componenti. Test del livello di sollevamento dell'intera applicazione della molla e base in . Questo è un test degli scenari aziendali di altissimo livello. Non provo le funzioni. Testiamo solo alcune grandi cose. Ad esempio, proprio nel test, viene emulato il processo di accesso di un utente, la richiesta dell'utente di biglietti dove può andare e una richiesta di accesso per guardare lo streaming. Scenari utente molto chiari.
Più o meno la stessa cosa viene implementata nei cosiddetti test di integrazione, che vengono effettivamente eseguiti sull'ambiente. Infatti, quando viene implementata la successiva implementazione in produzione, vengono eseguiti anche scenari di base reali. Lo stesso login, richiedendo ticket, richiedendo accesso a CloudFront, controllando che lo stream si connetta realmente con i miei permessi, controllando l'interfaccia del regista.
Al momento ho a bordo circa 70 test di componenti e circa 40 test di integrazione. La copertura è molto vicina al 95%. Questo è per i componenti, meno per quelli di integrazione, semplicemente non ce n'è molto bisogno. Considerando che il progetto prevede tutti i tipi di generazione di codice, questo è un ottimo indicatore. Non c’era altro modo di fare quello che abbiamo fatto in tre mesi. Perché se testassimo manualmente, fornendo funzionalità al nostro tester, e lei trovasse i bug e ce li restituisse per le correzioni, allora questo viaggio di andata e ritorno per eseguire il debug del codice sarebbe molto lungo e non rispetteremmo alcuna scadenza.
Nikolai: Convenzionalmente, per eseguire una regressione sull'intera piattaforma quando si modifica qualche funzione, è necessario sedersi e frugare ovunque per due giorni.
Vladimir: Pertanto è un grande successo che quando valuto una caratteristica, dico che ho bisogno di 4 giorni per due semplici penne e 1 websocket, Kolya lo consente. È già abituato al fatto che questi 4 giorni includono 2 tipi di test e quindi, molto probabilmente, funzionerà.
Nikolai: Ho scritto anche 140 test: componente + funzionale, che fanno la stessa cosa. Tutti gli stessi scenari vengono testati in produzione, in test e in produzione. Recentemente abbiamo anche aggiunto test funzionali dell'interfaccia utente di base. In questo modo copriamo le funzionalità più basilari che possono andare in pezzi.
Vladimir: Naturalmente vale la pena parlare di test di carico. È stato necessario testare la piattaforma sotto un carico vicino a quello reale per capire come sta il tutto, cosa sta succedendo con Rabbit, cosa sta succedendo con le JVM, quanta memoria è effettivamente necessaria.
— Non so con certezza se stiamo testando qualcosa lato streaming, ma ricordo che ci sono stati problemi con i transcodificatori quando abbiamo fatto gli incontri. Abbiamo testato i flussi?
Artyom: Testato in modo iterativo. Organizzazione di incontri. Durante il processo di organizzazione degli incontri, sono stati ricevuti circa 2300 biglietti JIRA. Queste sono solo cose generiche che le persone hanno fatto per organizzare incontri. Abbiamo portato parti della piattaforma in una pagina separata per gli incontri, gestita da Kirill Tolkachev ().
A dire il vero non ci sono stati grossi problemi. Letteralmente un paio di volte in cui abbiamo rilevato bug di memorizzazione nella cache su CloudFront, l'abbiamo risolto abbastanza rapidamente: abbiamo semplicemente riconfigurato le policy. C'erano molti più bug nelle persone, nei sistemi di streaming sul sito.
Durante le conferenze ho dovuto scrivere a molti altri esportatori per coprire più attrezzature e servizi. In alcuni posti ho dovuto costruire le mie biciclette solo per ragioni metriche. Il mondo dell'hardware AV (audio-video) non è molto roseo: hai una sorta di "API" di apparecchiature che semplicemente non puoi influenzare. Ed è tutt’altro che un dato di fatto che sarai in grado di ottenere le informazioni di cui hai bisogno. I fornitori di hardware sono molto lenti ed è quasi impossibile ottenere ciò che desideri da loro. In totale ci sono più di 100 pezzi di hardware, non restituiscono ciò di cui hai bisogno e scrivi esportatori strani e ridondanti, grazie ai quali puoi almeno in qualche modo eseguire il debug del sistema.
Attrezzatura
— Ricordo come prima dell'inizio delle conferenze abbiamo parzialmente acquistato attrezzature aggiuntive.
Artyom: Abbiamo acquistato computer, laptop e batterie. Al momento possiamo vivere senza elettricità per 40 minuti. A giugno ci sono stati forti temporali a San Pietroburgo, quindi abbiamo avuto un tale blackout. Allo stesso tempo, diversi fornitori si rivolgono a noi con collegamenti ottici da diversi punti. Si tratta in realtà di 40 minuti di inattività dell'edificio, durante i quali avremo luci accese, audio, telecamere, ecc. funzionanti.
— Abbiamo una storia simile con Internet. Nell’ufficio in cui si trovano i nostri studi, abbiamo trascinato una rete feroce tra i pavimenti.
Artyom: Abbiamo 20 Gbit di fibra tra i piani. Più avanti lungo i piani, da qualche parte c'è l'ottica, da qualche parte non c'è l'ottica, ma ci sono comunque meno canali di quelli gigabit: eseguiamo il video su di essi tra le tracce della conferenza. In generale, è molto comodo lavorare sulla propria infrastruttura, raramente puoi farlo durante conferenze offline sui siti.
— Prima di lavorare presso JUG Ru Group, ho visto come venivano allestite durante la notte le sale hardware durante le conferenze offline, dove c'era un grande monitor con tutte le metriche che costruisci in Grafana. Adesso c'è anche una stanza del quartier generale in cui siede il team di sviluppo, che durante la conferenza corregge alcuni bug e sviluppa funzionalità. Allo stesso tempo, esiste un sistema di monitoraggio visualizzato su un grande schermo. Artyom, Kolya e gli altri ragazzi si siedono e si assicurano che tutto non cada e funzioni a meraviglia.
Curiosità e problemi
— Hai parlato bene del fatto che abbiamo lo streaming con Amazon, c'è un player con il web, tutto è scritto in diversi linguaggi di programmazione, viene fornita la tolleranza agli errori e altri requisiti aziendali, incluso un account personale supportato per le persone giuridiche e singoli individui e possiamo integrarci con qualcuno che utilizza OAuth 2.0, è presente la funzione antifrode e il blocco degli utenti. Possiamo implementare le modifiche in modo dinamico perché lo abbiamo fatto bene ed è tutto testato.
Sono interessato a sapere quali stranezze sono state coinvolte nell’avvio di qualcosa. Ci sono state situazioni strane quando stavi sviluppando un backend, un frontend, è successo qualcosa di pazzesco e non capivi cosa farne?
Vladimir: Mi sembra che questo sia successo solo negli ultimi tre mesi. Ogni giorno. Come puoi vedere, mi sono stati strappati tutti i capelli.
Vladimir Krasilshchik dopo 3 mesi, quando è venuto fuori una specie di gioco e nessuno ha capito cosa farne
Ogni giorno succedeva qualcosa del genere, quando arrivava un momento in cui lo prendi e ti strappi i capelli, o ti rendi conto che non c'è nessun altro, e solo tu puoi farlo. Il nostro primo grande evento è stato TechTrain. Il 6 giugno alle 2 del mattino non avevamo ancora implementato l'ambiente di produzione, Kolya lo stava implementando. E l'account personale non funzionava come server di autorizzazione utilizzando OAuth2.0. Lo abbiamo trasformato in un provider OAuth2.0 per connettervi la piattaforma. Ho lavorato probabilmente per 18 ore di fila, ho guardato il computer e non ho visto nulla, non capivo perché non funzionava e Kolya ha guardato il mio codice da remoto, ha cercato un bug nella configurazione di Spring , l'ho trovato e l'LC ha funzionato, e anche in produzione.
Nikolai: E un'ora prima del rilascio di TechTrain.
Molte stelle erano allineate qui. Siamo stati estremamente fortunati perché avevamo un super team e tutti erano ispirati dall’idea di farlo online. In tutti questi tre mesi siamo stati guidati dal fatto di "creare YouTube". Non mi sono permesso di strapparmi i capelli, ma ho detto a tutti che tutto avrebbe funzionato, perché in realtà tutto era stato calcolato molto tempo fa.
A proposito di prestazioni
— Puoi dirmi quante persone c'erano sul sito su una traccia? Ci sono stati problemi di prestazioni?
Nikolai: Non ci sono stati problemi di prestazioni, come abbiamo già detto. Il numero massimo di persone che hanno partecipato a un rapporto è stato di 1300 persone, questo è su Heisenbug.
— Ci sono stati problemi con la visione locale? Ed è possibile avere una descrizione tecnica con schemi di come funziona il tutto?
Nikolai: Faremo un articolo su questo più tardi.
Puoi anche eseguire il debug dei flussi localmente. Una volta iniziate le conferenze, tutto è diventato ancora più semplice, perché sono apparsi flussi di produzione che possiamo guardare in ogni momento.
Vladimir: A quanto ho capito, gli sviluppatori front-end hanno lavorato localmente con i mock e quindi, poiché anche il tempo per l'implementazione agli sviluppatori front-end è breve (5 minuti), non ci sono problemi nel controllare cosa sta succedendo con i certificati.
— Tutto viene testato e sottoposto a debug, anche localmente. Ciò significa che scriveremo un articolo con tutte le caratteristiche tecniche, vi mostreremo, vi racconteremo tutto con i diagrammi, com'è andata.
Vladimir: Puoi prenderlo e ripeterlo.
- Tra 3 mesi.
risultato
— Tutto quanto descritto insieme sembra interessante, considerando che è stato realizzato da un piccolo team in tre mesi.
Nikolai: Una grande squadra non lo farebbe. Ma un piccolo gruppo di persone che comunicano abbastanza strettamente e bene tra loro e riescono a mettersi d'accordo, potrebbe farlo. Non hanno contraddizioni, l'architettura è stata inventata in due giorni, è stata ultimata e in realtà non è cambiata. Esiste una facilitazione molto rigorosa dei requisiti aziendali in entrata in termini di accumulo di richieste di funzionalità e modifiche.
— Quali erano i vostri ulteriori compiti quando si erano già svolte le conferenze estive?
Nikolai: Ad esempio, i crediti. Linee striscianti sul video, popup in alcuni punti del video a seconda del contenuto mostrato. Ad esempio, l'oratore vuole porre una domanda al pubblico e sullo schermo viene visualizzato un voto, che risale in fondo in base ai risultati della votazione per l'oratore stesso. Una sorta di attività sociale sotto forma di Mi piace, cuori, valutazioni del report durante la presentazione stessa, in modo da poter compilare il feedback al momento giusto senza essere distratti in seguito dai moduli di feedback. Inizialmente così.
E aggiungendo inoltre all'intera piattaforma, fatta eccezione per streaming e conference, anche uno stato post-conference. Si tratta di playlist (comprese quelle compilate dagli utenti), eventualmente contenuti di altri convegni passati, integrati, etichettati, accessibili all'utente e disponibili anche per la visualizzazione sul nostro sito web ().
— Ragazzi, grazie mille per le vostre risposte!
Se tra i lettori c'è chi ha partecipato alle nostre conferenze estive, condividete le vostre impressioni sul player e sulla trasmissione. Cosa ti è stato conveniente, cosa ti ha irritato, cosa ti piacerebbe vedere in futuro?
Se sei interessato alla piattaforma e vuoi vederla “in battaglia”, la utilizziamo nuovamente sul ns . Ce ne sono un'intera gamma, quindi quasi sicuramente ce n'è uno adatto a te.
Fonte: habr.com