Questa primavera ci siamo trovati in circostanze molto particolari. A causa della pandemia, è diventato chiaro che le nostre conferenze estive dovevano essere spostate online. E per svolgerle online in modo efficiente, le soluzioni software già pronte non erano adatte a noi; abbiamo dovuto scriverne una nostra. E abbiamo avuto tre mesi per farlo.
Sono stati tre mesi entusiasmanti. Ma dall'esterno non è del tutto ovvio: cos'è una piattaforma per conferenze online? In quali parti è composta? Così, all'ultima conferenza estiva DevOops, ho chiesto ai responsabili di questo compito:
- Nikolay Molchanov - Direttore tecnico del gruppo JUG Ru;
- Vladimir Krasilshchik è un programmatore Java pragmatico che lavora sul backend (potreste aver visto anche i suoi interventi alle nostre conferenze Java);
- Artem Nikonov è responsabile di tutti i nostri streaming video.
A proposito, alle conferenze autunno-inverno utilizzeremo una versione migliorata della stessa piattaforma, quindi molti lettori di Habr continueranno a utilizzarla.
РћР � С ‰ Р � СЏ РєР � СЂС,РёРЅР �
— Qual era la composizione della squadra?
Nikolaj Molchanov: Abbiamo un analista, un designer, un tester, tre front-ender, un back-ender. E, naturalmente, uno specialista a forma di T!
— Come si è svolto il processo nel complesso?
Nikolai: Fino a metà marzo, non avevamo nulla di pronto per l'online. E il 15 marzo, l'intero carosello online ha iniziato 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 queste funzionalità, policy per queste funzionalità, progettazione, sviluppo e test. Di conseguenza, il 6 giugno abbiamo lanciato tutto in produzione su C'erano 90 giorni per tutto.
— Siamo riusciti a realizzare ciò che ci eravamo impegnati?
Nikolai: Dato che ora partecipiamo alla conferenza DevOops online, significa che ha funzionato. Mi sono impegnato personalmente su un aspetto fondamentale: fornire ai clienti uno strumento con cui potranno organizzare la conferenza online.
La sfida era: fornirci uno strumento che ci consentisse di trasmettere le nostre conferenze ai possessori di biglietti.
Tutta la pianificazione è stata suddivisa in diverse fasi e tutte le funzionalità (circa 30 a livello globale) sono state suddivise in 4 categorie:
- cosa che faremo sicuramente (non possiamo vivere senza di loro),
- che faremo in secondo luogo,
- cosa che non faremo mai,
- e che non faremo mai, mai.
Abbiamo realizzato tutte le funzionalità delle prime due categorie.
— So che c'erano 600 task JIRA in totale. In tre mesi, hai creato 13 microservizi e sospetto che non siano stati scritti solo in Java. Hai utilizzato tecnologie diverse, hai due cluster Kubernetes in tre zone di disponibilità e 5 flussi RTMP in Amazon.
Esaminiamo ora separatamente ogni componente del sistema.
Streaming
— Cominciamo dal momento in cui abbiamo già un'immagine video e questa viene trasmessa ad alcuni servizi. Artem, raccontaci come avviene questo streaming?
Artem Nikonov: Il nostro schema generale è il seguente: immagine dalla telecamera -> la nostra sala di controllo -> server RTMP locale -> Amazon -> lettore video. Maggiori dettagli su Habr a giugno.
In generale, ci sono due modi globali per farlo: tramite hardware o tramite soluzioni software. Abbiamo scelto la strada software perché è più semplice nel caso di altoparlanti remoti. Non è sempre possibile installare l'hardware su un altoparlante in un altro Paese, ma installare il software su un altoparlante sembra più semplice e affidabile.
Per quanto riguarda l'hardware, abbiamo diverse telecamere (nei nostri studi e sugli altoparlanti remoti), diverse console in studio, che a volte devono essere riparate sottobanco durante la trasmissione.
I segnali provenienti da questi dispositivi entrano nei computer tramite schede di acquisizione, schede di input/output e schede audio. Lì, i segnali vengono mixati e assemblati in layout:
Esempio di un layout a 4 altoparlanti
Esempio di un layout a 4 altoparlanti
La trasmissione continua è quindi fornita da tre computer: c'è una macchina principale e un paio di macchine che lavorano a turno. Il primo computer raccoglie il primo report, il secondo un'interruzione, il primo il report successivo, il secondo l'interruzione successiva e così via. E la macchina principale mescola il primo con il secondo.
Questo crea un triangolo e, se uno di questi nodi dovesse guastarsi, potremmo continuare a fornire contenuti ai clienti rapidamente e senza perdita di qualità. Ci siamo trovati in questa situazione. Durante la prima settimana di conferenze, abbiamo riparato una macchina, l'abbiamo accesa e spenta. I partecipanti sembrano essere soddisfatti della nostra tolleranza ai guasti.
I flussi video provenienti dai computer vengono quindi inviati a un server locale, che ha due compiti: instradare i flussi RTMP e registrare un backup. Abbiamo quindi diversi punti di registrazione. I flussi video vengono quindi inviati alla parte del nostro sistema basata sui servizi Amazon SaaS. Utilizziamo , S3, CloudFront.
Nikolai: Cosa succede prima che il video raggiunga gli spettatori? Bisogna tagliarlo in qualche modo, giusto?
Artem: Noi comprimiamo il video e lo inviamo a MediaLive. Lì lanciamo i transcodificatori. Ricodificano il video in tempo reale in diverse risoluzioni, in modo che le persone possano guardarlo sui loro telefoni, anche con una connessione internet scadente, in casa, e così via. Poi questi flussi vengono tagliati in , ecco come funziona il protocollo Forniamo al frontend una playlist che contiene puntatori a questi blocchi.
— Stiamo utilizzando una risoluzione 1080p?
Artem: In larghezza abbiamo lo stesso numero di pixel di un video 1080p (1920 pixel), ma in altezza è leggermente inferiore, l'immagine è più allungata: ci sono delle ragioni per questo.
giocatore
— Artem ha descritto come il video viene trasmesso in streaming, come viene distribuito in diverse playlist per diverse risoluzioni dello schermo, tagliato in blocchi e inserito nel player. Kolya, dicci ora che tipo di player è, come consuma lo streaming, perché HLS?
Nikolai: Abbiamo un player visibile a tutti gli spettatori della conferenza.
In pratica, è un contenitore che racchiude la libreria. , su cui sono scritti molti altri giocatori. Ma avevamo bisogno di funzionalità molto specifiche: riavvolgere e contrassegnare il punto in cui si trova la persona, quale notizia sta guardando. Avevamo anche bisogno di layout personalizzati, loghi di ogni tipo e tutto il resto che era integrato nel nostro sito. Così abbiamo deciso di scrivere la nostra libreria (un wrapper per HLS) e di incorporarla nel sito.
Questa è la funzionalità principale, quindi è stata implementata quasi per prima. Poi tutto è cresciuto attorno ad essa.
Infatti, il player, tramite autorizzazione, riceve dal backend una playlist con i link ai chunk, correlati per tempo e qualità, scarica quelli necessari e li mostra all'utente, compiendo una sorta di "magia" lungo il percorso.
Esempio di una linea temporale
— C'è un pulsante integrato nel lettore per visualizzare una cronologia di tutti i report...
Nikolai: Sì, abbiamo risolto immediatamente il problema di navigazione degli utenti. A metà aprile, abbiamo deciso di non trasmettere ciascuna delle nostre conferenze su un sito separato, ma di riunirle tutte in un unico sito. In questo modo, gli utenti con biglietto Full Pass potevano passare liberamente da una conferenza all'altra: sia le dirette che le registrazioni di quelle passate.
Per facilitare la navigazione dello streaming e il passaggio da una traccia all'altra, abbiamo deciso di creare un pulsante "Trasmissione completa" e delle pagelle orizzontali per passare da una traccia all'altra e viceversa. È presente anche un controllo tramite tastiera.
— Ci sono state difficoltà tecniche?
Nikolai: Avevano una barra di scorrimento su cui erano segnati i punti di partenza dei diversi report.
— Quindi hai finito per implementare questi indicatori della barra di scorrimento prima che YouTube facesse qualcosa di simile?
Artem: All'epoca era in versione beta. Sembra una funzionalità piuttosto complessa, perché l'hanno testata parzialmente sugli utenti per l'ultimo anno. E ora sta entrando in produzione.
Nikolai: Ma siamo riusciti a raggiungere le vendite più velocemente. A dire il vero, dietro questa semplice funzionalità c'è un'enorme quantità di backend, frontend, calcoli e calcoli matematici all'interno del player.
Fine frontale
— Cerchiamo di capire come questo contenuto che mostriamo (pagella, relatori, sito web, programma) arriva al frontend?
Vladimir Krasilshchik: Disponiamo di diversi sistemi IT interni. Esiste un sistema in cui vengono inseriti tutti i report e tutti i relatori. Esiste un processo tramite il quale un relatore partecipa a una conferenza. Il relatore invia una domanda, il sistema la acquisisce, quindi viene creato un report tramite una specifica pipeline.
Ecco come l'oratore vede la pipeline
Questo sistema è il nostro sviluppo interno.
Successivamente, dobbiamo creare una pianificazione a partire dai singoli report. Come sapete, si tratta di un problema NP-difficile, ma in qualche modo lo risolviamo. Per farlo, lanciamo un altro componente che genera una pianificazione e la inserisce in un servizio cloud di terze parti, Contentful. Lì, tutto appare come una tabella che contiene i giorni della conferenza, le fasce orarie nei giorni e i report, le pause o le attività di sponsorizzazione nelle fasce orarie. Quindi, il contenuto che vediamo si trova in un servizio di terze parti. E il compito è di distribuirlo al sito.
Sembrerebbe che il sito sia solo una pagina con un player, e non ci sia nulla di complicato. Ma non lo è. Il backend dietro questa pagina si collega a Contentful, riceve il programma da lì, crea alcuni oggetti e li invia al frontend. Utilizzando una connessione websocket, utilizzata da ogni client della nostra piattaforma, inviamo un aggiornamento del programma dal backend al frontend.
Un caso reale: un relatore ha cambiato lavoro proprio durante una 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 un websocket, e poi il frontend stesso ridisegna la timeline. Tutto questo avviene senza soluzione di continuità. La combinazione di un servizio cloud e di diversi nostri componenti ci consente di generare tutti questi contenuti e di fornirli al frontend.
Nikolai: È importante chiarire che il nostro sito non è una classica applicazione SPA. È sia un sito con layout e rendering, sia una SPA. Infatti, Google vede questo sito come HTML renderizzato. Questo è positivo per la SEO e per la distribuzione dei contenuti all'utente. Non aspetta che 1,5 megabyte di JavaScript vengano caricati per visualizzare la pagina, ma vede immediatamente la pagina già renderizzata, e lo si percepisce ogni volta che si cambia il report. Tutto avviene in mezzo secondo, poiché il contenuto è già pronto e pubblicato nel posto giusto.
— Riassumiamo quanto detto sopra elencando le tecnologie. Tyoma ha detto che abbiamo 5 Amazon Stream, dove trasmettiamo video e audio. Abbiamo script bash, con il loro aiuto lanciamo, configuriamo...
Artem: Ciò avviene tramite l'API AWS, dove sono presenti molti servizi tecnici collaterali. Abbiamo suddiviso le nostre responsabilità in modo che io possa consegnare a , e gli sviluppatori frontend e backend si occupano di tutto da lì. Abbiamo diversi binding personalizzati per semplificare il layout dei contenuti, che poi realizziamo in 4K, ecc. Dato che le scadenze erano molto strette, abbiamo lavorato quasi interamente sulla base AWS.
— Tutto questo viene poi trasferito nel player tramite il backend del sistema. Nel player sono presenti TypeScript, React e Next.JS. E sul backend abbiamo diversi servizi in C#, Java, Spring Boot e Node.js. Il tutto distribuito tramite Kubernetes, utilizzando l'infrastruttura Yandex.Cloud.
Voglio anche sottolineare che quando ho avuto bisogno di familiarizzare con la piattaforma, è stato facile: tutti i repository sono su GitLab, tutto è ben nominato, i test sono scritti, c'è la documentazione. Insomma, anche in modalità di emergenza, si sono presi cura di tutto.
Vincoli aziendali e analisi
— Avevamo come obiettivo 10 utenti in base alle esigenze aziendali. Ora è il momento di parlare delle restrizioni aziendali che avevamo. Dovevamo gestire un carico elevato e garantire la conformità alla legge sulla conservazione dei dati personali. Cos'altro?
Nikolai: Inizialmente, siamo partiti dai requisiti per il video. La cosa più importante è l'archiviazione distribuita dei video in tutto il mondo per una consegna rapida al cliente. Altri requisiti includono la risoluzione 1080p e il riavvolgimento, che molti altri non implementano in modalità live. Successivamente, abbiamo aggiunto la possibilità di abilitare una velocità doppia, con il suo aiuto è possibile "recuperare" la diretta e poi guardare la conferenza in tempo reale. E lungo il percorso, è apparsa la funzionalità di marcatura della timeline. Inoltre, dovevamo essere tolleranti ai guasti e supportare un carico di 2 connessioni. Dal punto di vista del backend, si tratta di circa 10 connessioni moltiplicate per 000 richieste per ogni aggiornamento della pagina. E questo è già 10 RPS/sec. Un bel po'.
— C'erano altri requisiti per una "fiera virtuale" con stand di partner online?
Nikolai: Sì, è stato necessario farlo in tempi rapidi e in modo uniforme. Avevamo fino a 10 aziende partner per ogni conferenza e le loro pagine dovevano essere tutte impaginate in una o due settimane. Allo stesso tempo, i loro contenuti differivano leggermente nel formato. Ma è stato sviluppato un motore di template che assembla queste pagine al volo, praticamente senza ulteriori interventi di sviluppo.
— C'erano anche requisiti per analisi e statistiche in tempo reale. So che utilizziamo Prometheus per questo, ma dicci di più: quali requisiti soddisfiamo per l'analisi e come viene implementata?
Nikolai: Inizialmente, abbiamo requisiti di marketing per la raccolta di dati per i test A/B e per la raccolta di informazioni al fine di comprendere come fornire correttamente i contenuti migliori al cliente in futuro. Ci sono anche requisiti per alcune analisi sulle attività dei partner e per le analisi che vengono visualizzate (contatore delle visite). Tutte le informazioni vengono raccolte in tempo reale.
Possiamo fornire queste informazioni in forma aggregata anche ai relatori: quante persone ti hanno guardato in un determinato momento. Allo stesso tempo, al fine di rispettare la Legge Federale 152, gli account personali e i 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) per creare grafici sulla partecipazione ai report. Sulla base di questi dati, vengono condotte ricerche che miglioreranno le prossime conferenze.
Frode
— Abbiamo meccanismi antifrode?
Nikolai: A causa delle tempistiche ristrette dal punto di vista aziendale, l'obiettivo iniziale non era quello di bloccare immediatamente le connessioni non necessarie. Se due utenti avessero effettuato l'accesso con lo stesso account, avrebbero potuto visualizzare i contenuti. Ma sappiamo quante visualizzazioni simultanee ci sono state da un singolo account. E abbiamo bannato diversi trasgressori particolarmente dannosi.
Vladimir: A suo merito, uno degli utenti bannati ha capito il motivo. È venuto, si è scusato e ha promesso di acquistare un biglietto.
— Affinché tutto ciò avvenga, è necessario tracciare completamente tutti gli utenti dall'ingresso all'uscita, sapendo sempre cosa stanno facendo. Come funziona questo sistema?
Vladimir: Vorrei parlare di analisi e statistiche, che poi analizzeremo per la buona riuscita del report o potremo poi fornire ai partner. Tutti i client sono connessi tramite una connessione web socket a uno specifico cluster backend. C'è Ogni client, in ogni intervallo di tempo, invia informazioni su cosa sta facendo e quale traccia sta guardando. Queste informazioni vengono poi aggregate da rapidi processi Hazelcast e inviate a tutti coloro che stanno guardando queste tracce. Nell'angolo in alto a destra vediamo quante persone sono con noi in questo momento.
Le stesse informazioni sono memorizzate in e va al nostro data lake, dove possiamo costruire un grafico più interessante. Sorge la domanda: quanti utenti unici hanno visualizzato questo report? Andiamo a , ci sono i ping di tutte le persone che sono arrivate tramite l'ID di questo report. Abbiamo raccolto e aggregato quelli univoci e ora possiamo capire.
Nikolai: Ma allo stesso tempo, riceviamo anche dati in tempo reale da Prometheus. È impostato su tutti i servizi Kubernetes, su Kubernetes stesso. Raccoglie assolutamente tutto, e con Grafana possiamo costruire qualsiasi grafico in tempo reale.
Vladimir: Da un lato, scarichiamo i dati per elaborarli ulteriormente, come in OLAP. E per OLTP, l'applicazione scarica tutto questo materiale su Prometheus, Grafana e i grafici corrispondono persino!
— Questo è esattamente il caso in cui i grafici convergono.
Cambiamenti dinamici
— Descrivici come vengono implementate le modifiche dinamiche: se un report viene annullato 6 minuti prima del suo inizio, qual è la catena di azioni? Quale pipeline viene attivata?
Vladimir: La pipeline è molto condizionale. Ci sono diverse possibilità. La prima è che il programma di generazione del programma abbia funzionato e abbia modificato questo programma. Il programma modificato viene caricato su Contentful. Dopodiché, il backend capisce che ci sono modifiche per questa conferenza in Contentful, le prende e le riassembla. Tutto viene assemblato e inviato tramite websocket.
La seconda opzione, quando tutto avviene a un ritmo frenetico: l'editor modifica manualmente le informazioni in Contentful (link a Telegram, presentazione del relatore, ecc.) e viene attivata la stessa logica della prima volta.
Nikolai: Tutto avviene senza dover aggiornare la pagina. Tutte le modifiche avvengono in modo assolutamente fluido per il cliente. Lo stesso vale per il passaggio da un report all'altro. Quando arriva il momento, il report e l'interfaccia cambiano.
Vladimir: Lo stesso vale per i limiti di tempo per l'inizio dei report nella timeline. Non c'è nulla all'inizio. Ma se si passa il mouse sulla striscia rossa, a un certo punto, grazie al direttore della trasmissione, appariranno i limiti. Il direttore imposta l'inizio corretto della trasmissione, il backend rileva questa modifica, calcola l'ora di inizio e fine dei report dell'intera traccia in base al programma della conferenza, li invia ai nostri clienti, il player disegna i limiti. Ora l'utente può facilmente navigare all'inizio e alla fine del report. Questo era un requisito aziendale rigoroso, molto comodo e utile. Non si perde tempo a cercare l'ora di inizio effettiva del report. E quando creeremo un'anteprima, sarà fantastica.
Distribuzione
— Vorrei chiedere informazioni sull'implementazione. Kolya e il team hanno dedicato molto tempo all'inizio alla configurazione dell'intera infrastruttura in cui implementiamo tutto. Mi dica, di cosa è fatta?
Nikolai: Inizialmente, dal punto di vista tecnico, avevamo l'esigenza che il prodotto fosse il più possibile astratto da qualsiasi fornitore. Rivolgerci ad AWS per realizzare script Terraform specifici per AWS, o specificamente per Yandex, o Azure, ecc. non era la soluzione ideale. A un certo punto, abbiamo dovuto trasferirci altrove.
Per le prime tre settimane, abbiamo cercato costantemente un modo per migliorare ulteriormente. Alla fine, siamo giunti alla conclusione che Kubernetes, in questo caso, è il nostro tutto, perché ci consente di creare servizi scalabili automaticamente, di eseguire il deployment automaticamente e di avere quasi tutti i servizi pronti all'uso. Naturalmente, abbiamo dovuto insegnare a tutti i servizi a funzionare con Kubernetes e Docker, e anche il team ha dovuto imparare.
Abbiamo due cluster. Test e produzione. Sono assolutamente identici in termini di hardware e impostazioni. Implementiamo l'infrastruttura come codice. Tutti i servizi vengono distribuiti automaticamente in tre ambienti tramite pipeline: dai branch delle feature, dai branch master, dai branch di test e da GitLab. L'integrazione è massima in GitLab, con Elastic e Prometheus.
Abbiamo l'opportunità di implementare rapidamente (per il backend entro 10 minuti, per il frontend entro 5 minuti) le modifiche a qualsiasi ambiente con tutti i test, le integrazioni, l'esecuzione di test funzionali, test di integrazione sull'ambiente e anche test con test di carico sull'ambiente di test, più o meno la stessa cosa che vogliamo ottenere in produzione.
Informazioni sui test
— Testi quasi tutto, è difficile credere a come hai scritto tutto. Puoi parlarci dei test di backend: quanto è coperto, quali test?
Vladimir: Esistono due tipi di test scritti. I primi sono test sui componenti. Test del livello di sollevamento dell'intera applicazione della molla e della base in Questo è un test degli scenari aziendali di più alto livello. Non testo le funzioni. Testiamo solo alcuni aspetti importanti. Ad esempio, il processo di accesso dell'utente, la richiesta di ticket per raggiungere la destinazione, la richiesta di accesso per visualizzare lo streaming vengono emulati direttamente nel test. Scenari utente molto chiari.
Approssimativamente la stessa cosa viene implementata nei cosiddetti test di integrazione, che vengono effettivamente eseguiti nell'ambiente. Infatti, quando la distribuzione successiva viene implementata in produzione, vengono eseguiti anche scenari di base reali. Lo stesso login, la stessa richiesta di ticket, la stessa richiesta di accesso a CloudFront, la verifica che il flusso si connetta effettivamente con le mie autorizzazioni, la verifica dell'interfaccia del director.
Al momento, ho circa 70 test sui componenti e circa 40 test di integrazione a bordo. La copertura è molto vicina al 95%. Questo vale per i test sui componenti, meno per i test di integrazione, semplicemente non ce n'è bisogno. Considerando che il progetto include ogni sorta di generazione di codice, questo è un ottimo indicatore. Non c'era altro modo per fare quello che abbiamo fatto in tre mesi. Perché se avessimo testato manualmente, assegnando funzionalità alla nostra tester, e lei avesse trovato bug e ce li avesse restituiti per correggerli, allora questo percorso di debug del codice sarebbe stato molto lungo e non avremmo rispettato nessuna scadenza.
Nikolai: Di solito, per effettuare una regressione sull'intera piattaforma quando si modifica una funzione, è necessario attendere due giorni e curiosare ovunque.
Vladimir: Quindi è un grande successo che quando valuto una funzionalità, dico che mi servono 4 giorni per due semplici handle e 1 websocket, Kolya me lo permette. È già abituato al fatto che questi 4 giorni includono 2 tipi di test, e quindi, molto probabilmente, funzionerà.
Nikolai: Ho anche 140 test scritti: componente + funzionale, che fanno la stessa cosa. Tutti gli stessi scenari vengono testati in produzione, in fase di test e in fase di sviluppo. Di recente abbiamo anche test funzionali di base dell'interfaccia utente. In questo modo copriamo le funzionalità più basilari che possono non funzionare correttamente.
Vladimir: Naturalmente, vale la pena parlare di test di carico. Era necessario testare la piattaforma con un carico vicino a quello reale, per capire come funziona, cosa succede con Rabbit, cosa succede con le JVM, quanta memoria è realmente necessaria.
— Non so con certezza se testiamo qualcosa sul lato streaming, ma ricordo che ci sono stati problemi con i transcodificatori quando abbiamo fatto i meetup. Abbiamo testato gli streaming?
Artem: Abbiamo effettuato test iterativi, organizzando dei meetup. C'erano circa 2300 ticket JIRA in fase di organizzazione dei meetup. Questi sono solo modelli che le persone hanno utilizzato per organizzare i meetup. Abbiamo spostato parti della piattaforma in una pagina separata per i meetup, gestita da Kirill Tolkachev ().
A dire il vero, non ci sono stati grossi problemi. Abbiamo letteralmente rilevato bug di caching su CloudFront un paio di volte, e sono stati risolti abbastanza rapidamente: abbiamo semplicemente riconfigurato le policy. I bug erano significativamente più numerosi nelle persone, nei sistemi di streaming sulla piattaforma.
Durante le conferenze, ho dovuto scrivere qualche esportatore in più per coprire più apparecchiature e servizi. A volte ho dovuto costruire le mie biciclette solo per questioni di metriche. Il mondo dell'hardware AV (audio-video) non è molto roseo: si ha una sorta di "API" di apparecchiature su cui semplicemente non si può intervenire. Ed è tutt'altro che certo che si riuscirà a ottenere le informazioni necessarie. I fornitori di hardware sono molto lenti ed è quasi impossibile ottenere da loro ciò che si desidera. In totale, più di 100 hardware ti danno qualcosa di diverso da ciò di cui hai bisogno e tu scrivi esportatori strani e ridondanti, grazie ai quali almeno riesci in qualche modo a eseguire il debug del sistema.
Attrezzatura
— Ricordo che prima dell'inizio delle conferenze acquistammo in parte attrezzature aggiuntive.
Artem: 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 dovuto interrompere la fornitura di energia. Allo stesso tempo, diversi provider ci hanno fornito collegamenti ottici da diversi punti. Si tratta di 40 minuti di inattività dell'edificio, durante i quali luci, audio, telecamere, ecc. saranno accesi.
— Abbiamo una storia simile con Internet. Nell'ufficio dove si trovano i nostri studi, abbiamo creato una rete feroce tra i piani.
Artem: Abbiamo 20 Gbps di cavi ottici tra i piani. Più avanti, da qualche parte c'è la fibra ottica, da qualche altra parte no, ma comunque meno di canali Gigabit: gestiamo le videoconferenze tra i binari su di essi. In generale, è molto comodo lavorare sulla propria infrastruttura, mentre nelle conferenze offline in sede è raramente possibile farlo.
— Anche prima di lavorare al JUG Ru Group, ho visto come le sale hardware vengono allestite durante la notte durante le conferenze offline, con un grande monitor su cui sono visualizzate tutte le metriche create in Grafana. Ora c'è anche una sala centrale dove si riunisce il team di sviluppo, che corregge alcuni bug e sviluppa nuove funzionalità durante la conferenza. Allo stesso tempo, c'è un sistema di monitoraggio visualizzato su un grande schermo. Artem, Kolya e gli altri ragazzi si siedono e controllano che tutto funzioni correttamente e non si blocchi.
Curiosità e problemi
— Hai descritto bene che abbiamo lo streaming con Amazon, abbiamo un player con il web, tutto è scritto in diversi linguaggi di programmazione, la tolleranza agli errori e altri requisiti aziendali sono garantiti, incluso un account personale supportato da persone giuridiche e fisiche, e possiamo integrarci con qualcuno tramite OAuth 2.0, c'è la protezione antifrode e il blocco degli utenti. Possiamo implementare le modifiche in modo dinamico, perché lo abbiamo fatto bene, e allo stesso tempo, tutto è testato.
Mi piacerebbe sapere quali episodi divertenti si sono verificati durante il lancio di qualcosa. Ci sono state situazioni strane mentre sviluppavate il backend, il frontend, e sono uscite delle schifezze e non sapevate cosa farne?
Vladimir: Credo che sia così solo da tre mesi. Ogni giorno. Come puoi vedere, ho tutti i capelli strappati.
Vladimir Krasilshchik dopo 3 mesi, quando è uscita una specie di schifezza e nessuno capiva cosa farne
Ogni giorno succedeva qualcosa del genere, quando arrivava il momento in cui ti strappavi i capelli, o capivi che non c'era nessun altro, e che solo tu potevi farcela. 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 per OAuth2.0. Lo abbiamo trasformato in un provider OAuth2.0 per connetterci la piattaforma. Ho lavorato, probabilmente, per 18 ore di fila, ho guardato il computer e non ho visto nulla, non capivo perché non funzionasse, e da remoto Kolya ha esaminato il mio codice, ha cercato un bug nella configurazione di Spring, l'ha trovato, e l'account personale ha funzionato, e anche in produzione.
Nikolai: E un'ora prima di TechTrain è avvenuta la pubblicazione.
Qui si sono riunite tante star. Siamo stati estremamente fortunati perché avevamo un team fantastico e tutti erano motivati dall'idea di farlo online. Per tutti questi tre mesi siamo stati motivati dal fatto che stavamo "facendo YouTube". Non mi sono strappato i capelli, ma ho detto a tutti che tutto si sarebbe sistemato, perché in realtà tutto era stato calcolato molto tempo fa.
A proposito di produttività
— Puoi dirmi quante persone erano al massimo sul sito per ogni traccia? Ci sono stati problemi di prestazioni?
Nikolai: Come abbiamo già detto, non ci sono stati problemi di performance. Il numero massimo di persone che hanno partecipato a un talk è stato di 1300 persone, e questo è avvenuto su Heisenbug.
— Ci sono stati problemi con la visualizzazione locale? Ed è possibile avere una descrizione tecnica con diagrammi di come funziona il tutto?
Nikolai: Più avanti scriveremo un articolo su questo argomento.
Anche i flussi possono essere sottoposti a debug in locale. Una volta iniziate le conferenze, è diventato ancora più semplice perché avevamo flussi di produzione che potevamo guardare in qualsiasi momento.
Vladimir: Per quanto ne so, gli sviluppatori front-end hanno lavorato localmente con i mock e, poiché anche il tempo di implementazione per lo sviluppo front-end è breve (5 minuti), non ci sono problemi nel vedere cosa succede con i certificati.
— Tutto è stato testato e debuggato, anche localmente. Quindi, scriveremo un articolo con tutte le caratteristiche tecniche, mostreremo e racconteremo tutto con diagrammi, com'è stato.
Vladimir: Puoi prenderlo e ripeterlo.
— Tra 3 mesi.
risultato
— Tutto quanto descritto nel suo insieme sembra fantastico, considerando che è stato realizzato da un piccolo team in tre mesi.
Nikolai: Un team numeroso non lo farebbe. Ma un piccolo gruppo di persone che comunicano tra loro in modo approfondito e approfondito e che riescono a trovare un accordo, potrebbe. Non ci sono contraddizioni, l'architettura è stata inventata in due giorni, è stata finalizzata e non è cambiata molto. C'è una gestione molto rigorosa dei requisiti aziendali in arrivo in termini di richieste di funzionalità e modifiche.
— Cosa c'era nella tua lista delle cose da fare ora che le conferenze estive erano finite?
Nikolai: Ad esempio, sottotitoli. Linee di scorrimento sul video, pop-up in alcuni punti del video a seconda del contenuto mostrato. Ad esempio, se il relatore vuole porre una domanda al pubblico, sullo schermo appare un sondaggio, che viene restituito al relatore in base ai risultati della votazione. Un po' di attività social sotto forma di "Mi piace", cuori e valutazioni del report durante la presentazione stessa, in modo da poter compilare il feedback al momento giusto senza essere distratti dai moduli di feedback. Inizialmente, in questo modo.
E aggiungendo all'intera piattaforma, oltre allo streaming e alla conferenza, anche uno stato post-conferenza. Si tratta di playlist (incluse quelle compilate dagli utenti), eventualmente contenenti contenuti di altre conferenze passate, integrate, contrassegnate, disponibili all'utente e consultabili anche sul nostro sito web ().
- Ragazzi, grazie mille per le vostre risposte!
Se qualche lettore ha partecipato alle nostre conferenze estive, vi preghiamo di condividere le vostre impressioni sul player e sulla trasmissione. Cosa vi è sembrato comodo, cosa vi ha dato fastidio, cosa vorreste vedere in futuro?
Se la piattaforma è interessante e vuoi vederla "in azione", la useremo di nuovo nel nostro Ce ne sono moltissimi, quindi è quasi certo che ce ne sarà uno adatto a te.
Fonte: habr.com
