Questa primavera ci siamo trovati in condizioni molto divertenti. A causa della pandemia, è diventato chiaro che le nostre conferenze estive dovevano essere spostate online. E per svolgerle online in modo efficace, le soluzioni software già pronte non erano adatte, era necessario scriverne una nostra. E avevamo tre mesi per farlo.
È evidente che sono stati tre mesi entusiasmanti. Ma dall'esterno non è del tutto chiaro: cosa rappresenta effettivamente una piattaforma per conferenze online? Di quali componenti è composta? Così, all'ultima delle conferenze estive DevOops, ho interrogato coloro che si occupavano di questo compito:
- Nikolay Molchanov — direttore tecnico di JUG Ru Group;
- Vladimir Krasilshchik — programmatore Java pragmatico, specializzato nel backend (avete potuto vedere le sue relazioni alle nostre conferenze Java);
- Artyom Nikonov — responsabile di tutto il nostro streaming video.
A proposito, alle conferenze autunnali e invernali utilizzeremo una versione migliorata della stessa piattaforma — quindi molti utenti di Habr si troveranno ad utilizzarla.
Panoramica generale
— Com'era composta la squadra?
Nikolay Molchanov: Abbiamo un analista, un designer, un tester, tre frontend developer e un backend developer. E, naturalmente, abbiamo un professionista a T!
— Com'è stato il processo in generale?
Nikolay: Fino a metà marzo non avevamo niente pronto per l'online. E il 15 marzo è iniziato tutto il movimento online. Abbiamo creato alcuni repository, pianificato, discusso l'architettura di base e abbiamo completato tutto in tre mesi.
Ciò ha certamente seguito le classiche fasi di pianificazione, architettura, scelta delle funzionalità, voto su queste funzionalità, politiche di queste funzionalità, loro design, sviluppo e test. Alla fine, il 6 giugno abbiamo lanciato tutto in produzione su . Per tutto c'erano 90 giorni.
— Siamo riusciti a rispettare ciò a cui ci eravamo impegnati?
Nikolay: Se ora stiamo partecipando alla conferenza DevOops online, significa che ce l'abbiamo fatta. Personalmente mi sono impegnato nella cosa principale: porterò ai clienti uno strumento che permetterà di tenere la conferenza online.
Il compito era questo: dateci uno strumento con cui possiamo trasmettere i nostri eventi agli acquirenti dei biglietti.
Tutta la pianificazione è stata suddivisa in diverse fasi, e tutte le funzionalità (circa 30 globali) sono state divise in 4 categorie:
- che faremo sicuramente (non possiamo vivere senza di essi),
- che faremo in un secondo momento,
- che non faremo mai,
- e che non faremo mai, mai.
Abbiamo realizzato tutte le funzionalità delle prime due categorie.
— So che in totale sono state aperte 600 attività in JIRA. In tre mesi avete sviluppato 13 microservizi e sospetto che non siano scritti solo in Java. Avete utilizzato tecnologie diverse, con due cluster Kubernetes attivi in tre zone di disponibilità e 5 stream RTMP su Amazon.
Adesso esaminiamo ogni componente del sistema singolarmente.
Streaming
— Iniziamo con il momento in cui abbiamo già un'immagine video, e viene inviata a qualche servizio. Artem, raccontaci come avviene questo streaming.
Artem Nikonov: Lo schema generale è il seguente: immagine dalla telecamera -> la nostra regia -> server RTMP locale -> Amazon -> lettore video. Maggiori dettagli su Habr a giugno.
In generale, ci sono due vie principali per ottenere questo: o utilizzare hardware o optare per soluzioni software. Noi abbiamo scelto la soluzione software, perché è più semplice nel caso di relatori remoti. Non sempre è possibile portare l'hardware a un relatore in un altro paese, ma installare il software per il relatore sembra più semplice e affidabile.
Dal punto di vista dell'hardware, abbiamo a disposizione un certo numero di telecamere (nelle nostre studio e da relatori remoti) e un certo numero di console in studio, che a volte devono essere riparate durante la trasmissione, proprio sotto il tavolo.
I segnali provenienti da questi dispositivi arrivano ai computer tramite schede di acquisizione, input/output e schede audio. Qui i segnali vengono miscelati e uniti in layout:
Esempio di layout per 4 relatori
Esempio di layout per 4 relatori
Successivamente, la trasmissione continua è garantita da tre computer: c'è una macchina principale e un paio di macchine che lavorano a turno. Il primo computer gestisce il primo intervento, il secondo gestisce la pausa, il primo il successivo intervento, il secondo la pausa successiva e così via. La macchina principale mescola il primo con il secondo.
In questo modo si crea un certo triangolo: in caso di caduta di uno di questi nodi, possiamo continuare a fornire contenuti ai clienti rapidamente e senza perdita di qualità. Abbiamo già vissuto una situazione simile. Nella prima settimana delle conferenze, abbiamo riparato un server, accendendolo e spegnendolo. Sembra che le persone siano soddisfatte della nostra resilienza.
Successivamente, i flussi dai computer arrivano a un server locale, che ha due compiti: instradare i flussi RTMP e registrare un backup. In questo modo, abbiamo diversi punti di registrazione. Poi, i flussi video vengono inviati a una parte del nostro sistema costruita sui servizi SaaS di Amazon. Utilizziamo , S3, CloudFront.
Nikolay: E cosa succede prima che il video arrivi agli spettatori? Deve essere tagliato in qualche modo?
Artyom: Comprimiamo il video dalla nostra parte e lo inviamo a MediaLive. Lì avviamo i transcoder. Questi ricodificano il video in tempo reale in diverse risoluzioni, in modo che le persone possano vederli sui telefoni, con una connessione internet scadente in campagna, e così via. Poi questi stream vengono suddivisi in , questo è come funziona il protocollo . Al frontend restituiamo una playlist che contiene riferimenti a questi chunk.
— Utilizziamo la risoluzione 1080p?
Artyom: In larghezza abbiamo come il video 1080p — 1920 pixel, mentre in altezza è leggermente inferiore, l'immagine è più allungata — ci sono delle ragioni per questo.
Player
— Artem ha descritto come i video entrano nei flussi, come vengono distribuiti in diverse playlist per diverse risoluzioni degli schermi, frammentati in chunk e arrivano al player. Kolja, ora raccontaci che cos'è questo player, come consuma il flusso, perché HLS?
Nikolay: Abbiamo un player che tutti i partecipanti alla conferenza monitorano.
In sostanza, è un wrapper su una libreria , su cui sono scritti molti altri player. Ma avevamo bisogno di una funzionalità molto specifica: il riavvolgimento e la marcatura del punto in cui si trova una persona, quale presentazione sta guardando. Servivano anche layout personalizzati, loghi e tutto il resto che si integrava con noi. Così abbiamo deciso di scrivere la nostra libreria (un wrapper su HLS) e integrarla nel sito.
Questa è la funzionalità fondamentale, quindi è stata implementata praticamente per prima. E poi attorno a questo tutto il resto è già emerso.
Di fatto, il player ottiene dalla backend un playlist con i link ai chunk, correlati con il tempo e la qualità, scarica i necessari e li mostra all'utente, realizzando nel frattempo una certa "magia".
Esempio di timeline
— All'interno del player è integrato un pulsante per visualizzare la timeline di tutte le presentazioni...
Nikolay: Sì, abbiamo subito affrontato il problema della navigazione dell'utente. A metà aprile abbiamo deciso di non trasmettere ciascuna delle nostre conferenze su un sito separato, ma di unire tutto su uno solo. Così gli utenti con biglietto Full Pass possono facilmente passare tra diverse conferenze: sia in diretta che le registrazioni passate.
Per rendere più semplice per gli utenti muoversi nel live stream e passare tra i track, abbiamo deciso di aggiungere un pulsante "Tutta la diretta" e delle schede orizzontali per passare tra i track e le presentazioni. Ci sono controlli da tastiera.
— Ci sono state delle difficoltà tecniche con questo?
Nikolay: Ci sono state con la barra di scorrimento, sulla quale sono segnati i punti di inizio delle diverse presentazioni.
— Alla fine avete implementato questi marcatori sulla barra di scorrimento prima che YouTube realizzasse qualcosa di simile?
Artyom: All'inizio era in beta. Sembra che sia una funzionalità abbastanza complessa, poiché l'hanno testata parzialmente sugli utenti nell'ultimo anno. E ora è arrivata alla vendita.
Nikolay: Ma in realtà l'abbiamo portata alla vendita più velocemente. A dire la verità, dietro questa semplice funzionalità c'è una grande quantità di backend, frontend e calcoli e logiche all'interno del lettore.
Frontend
— Vediamo come arriva al frontend il contenuto che mostriamo (la scheda della presentazione, gli speaker, il sito, il programma)?
Vladimir Krasil’shchik: Abbiamo diversi sistemi IT interni. C'è un sistema in cui sono registrate tutte le presentazioni e tutti gli speaker. C'è un processo attraverso il quale il relatore partecipa alla conferenza. Lo speaker invia una richiesta, il sistema la acquisisce, e poi c'è un certo pipeline che crea la presentazione.
Così lo speaker vede la pipeline
Questo sistema è una nostra sviluppo interno.
Dai report separati, dobbiamo costruire un programma. Come noto, questa è una questione NP-difficile, ma riusciamo a risolverla in qualche modo. A tal fine, avviamo un altro componente che forma il programma e lo carica in un servizio cloud esterno, Contentful. Lì tutto appare come una tabella, in cui ci sono i giorni della conferenza, all'interno dei giorni ci sono fasce orarie, e nelle fasce orarie ci sono relazioni, pause o attività degli sponsor. Quindi il contenuto che vediamo è archiviato in un servizio esterno. L'obiettivo è portarlo sul sito.
A prima vista, il sito sembra essere semplicemente una pagina con un lettore, e non c'è nulla di complicato in questo. A meno che non sia così. Il backend che sta dietro questa pagina accede a Contentful, estrae il programma, forma alcuni oggetti e invia il tutto al frontend. Utilizzando una connessione WebSocket, ogni cliente della nostra piattaforma riceve aggiornamenti sul programma dal backend al frontend.
Casi reali: un relatore ha cambiato lavoro proprio durante la conferenza. È necessario aggiornare il banner con il nome della nuova azienda. Come avviene tutto questo dal backend? Attraverso il websocket, viene inviato un aggiornamento a tutti i client, e poi il frontend si occupa di rinfrescare il timeline. Tutto ciò avviene senza soluzione di continuità. La combinazione del servizio cloud con alcuni dei nostri componenti ci consente di generare tutto questo contenuto e fornirlo al frontend.
Nikolay: È importante sottolineare che il nostro sito non è un'applicazione SPA classica. È sia un sito web ben impaginato e renderizzato, sia una SPA. In realtà, Google vede questo sito come HTML renderizzato. Questo è utile per la SEO e per la consegna dei contenuti all'utente. Non deve aspettare il caricamento di 1,5 megabyte di JavaScript per vedere la pagina; vede subito la pagina già renderizzata, e tu lo percepisci ogni volta che cambi relatore. Tutto si realizza in mezzo secondo, poiché il contenuto è già pronto e collocato nel posto giusto.
— Riassumiamo quanto detto finora elencando le tecnologie. Tema ha spiegato che abbiamo 5 stream di Amazon, dove consegniamo video e audio. Qui utilizziamo script bash, con i quali lanciamo e configuriamo...
Artyom: Questo avviene tramite l'API AWS, ci sono anche molti altri servizi tecnici secondari. Abbiamo diviso i nostri compiti in modo tale che io mi occupi della consegna su , mentre gli sviluppatori front-end e back-end lo prelevano da lì. Abbiamo una serie di wrapper per semplificare la distribuzione dei contenuti che realizziamo poi in 4K, ecc. Dato che le scadenze erano molto ristrette, abbiamo praticamente fatto tutto basandoci su AWS.
— Tutto questo finisce nel lettore, utilizzando il backend del sistema. Abbiamo nel nostro lettore TypeScript, React, Next.JS. E nel backend abbiamo diversi servizi scritti in C#, Java, Spring Boot e Node.js. Tutto questo viene distribuito utilizzando Kubernetes, sfruttando l'infrastruttura di Yandex.Cloud.
Voglio anche notare che quando ho dovuto familiarizzare con la piattaforma, è stato tutto abbastanza semplice: tutti i repository si trovano su GitLab, tutto è ben nominato, ci sono test scritti, e c'è documentazione. Quindi, anche in modalità di emergenza, ci si è preoccupati di queste cose.
Vincoli aziendali e analisi
— Ci siamo concentrati sui requisiti aziendali per 10.000 utenti. È il momento di parlare delle limitazioni aziendali che abbiamo avuto. Dovevamo garantire un alto carico di lavoro e rispettare la legge sulla protezione dei dati personali. E cos'altro?
Nikolay: Inizialmente, ci siamo basati sui requisiti video. La cosa principale è stata l'archiviazione distribuita dei video nel mondo per una rapida consegna al cliente. Tra le altre, la risoluzione 1080p, oltre alla funzione di riavvolgimento che molti altri non avevano in modalità live. Successivamente, abbiamo aggiunto la possibilità di attivare la velocità 2x, che consente di 'recuperare' il live e guardare la conferenza in tempo reale. Inoltre, abbiamo implementato funzioni di marcatura della timeline. Inoltre, dovevamo essere resiliente e supportare un carico di 10.000 connessioni. Dal punto di vista del backend, ciò significa circa 10.000 connessioni moltiplicate per 8 richieste per ogni aggiornamento della pagina. E questo equivale a 80.000 RPS/sec. Abbastanza.
— C'erano anche requisiti per una 'mostra virtuale' con stand online dei partner?
Nikolay: Sì, doveva essere fatto in modo abbastanza veloce e universale. Avevamo fino a 10 aziende partner per ogni conferenza, e le pagine di tutte dovevano essere elaborate in una o due settimane. Tuttavia, il contenuto variava leggermente per formato. Ma è stato realizzato un certo generatore di modelli che assemblava queste pagine al volo, praticamente senza ulteriore intervento da parte dello sviluppo.
— C'erano anche requisiti per l'analisi delle visualizzazioni in tempo reale e per le statistiche. So che utilizziamo Prometheus per questo, ma potresti raccontare di più: quali requisiti soddisfiamo per l'analisi e come viene realizzato?
Nikolay: Inizialmente abbiamo requisiti di marketing per la raccolta per il test A/B e per la raccolta di informazioni per capire come fornire correttamente al cliente il miglior contenuto in futuro. Ci sono anche requisiti per un certo tipo di analisi sulle attività dei partner e l'analisi che vedi (contatore di visite). Tutte le informazioni vengono raccolte in tempo reale.
Possiamo fornire queste informazioni in forma aggregata anche agli speaker: quante persone ti hanno visto in un determinato momento. Allo stesso tempo, per rispettare la legge 152 FZ, il pannello personale e i dati personali non vengono tracciati in alcun modo.
Sulla piattaforma ci sono già strumenti di marketing e le nostre metriche per misurare l'attività degli utenti in tempo reale (chi ha guardato quale secondo della presentazione), per costruire grafici sulla partecipazione alle presentazioni. Sulla base di questi dati vengono effettuate ricerche che permetteranno di rendere le prossime conferenze migliori.
Frode
— Abbiamo meccanismi anti-frode?
Nikolay: A causa dei rigidi vincoli temporali dal punto di vista commerciale, non era inizialmente previsto bloccare subito le connessioni superflue. Se due utenti accedevano con lo stesso account, potevano guardare il contenuto. Ma sappiamo quante visualizzazioni contemporanee ci sono state da un unico account. E abbiamo bloccato alcuni trasgressori particolarmente gravi.
Vladimir: Bisogna dare atto che uno degli utenti bloccati ha capito perché è successo. È venuto, si è scusato e ha promesso di comprare un biglietto.
— Per far sì che tutto ciò avvenga, è necessario tracciare completamente ogni utente dall'ingresso all'uscita, sapendo sempre cosa stanno facendo. Come funziona questo sistema?
Vladimir: Vorrei parlare dell'analitica e della statistica che analizziamo successivamente per il successo della presentazione o che possiamo fornire poi ai partner. Tutti i clienti sono connessi tramite una connessione WebSocket a un certo cluster di backend. Qui c'è . Ogni cliente invia in ogni momento cosa sta facendo e quale video sta guardando. Successivamente, queste informazioni vengono aggregate rapidamente tramite job Hazelcast e restituite a tutti coloro che stanno guardando questi video. Possiamo vedere nell'angolo quanti utenti sono attualmente con noi.
Queste informazioni vengono anche memorizzate in e inviate al nostro lago dati, che ci aiuta a costruire grafici più interessanti. La domanda arriva: quanti utenti unici hanno visto questa presentazione? Andiamo a , dove ci sono i ping di tutte le persone che sono arrivate tramite l'id di questa presentazione. Abbiamo raccolto, aggregato gli unici e ora possiamo capire.
Nikolay: Tuttavia, riceviamo anche dati in tempo reale da Prometheus. È configurato per monitorare tutti i servizi di Kubernetes, compreso lo stesso Kubernetes. Raccoglie tutto e, con Grafana, possiamo costruire qualsiasi grafico in tempo reale.
Vladimir: Da un lato, scarichiamo questi dati per un ulteriore trattamento di tipo OLAP. D'altra parte, l'applicazione scarica tutto su Prometheus, Grafana e i grafici si allineano perfettamente!
È proprio il caso in cui i grafici si allineano.
Modifiche dinamiche
Raccontateci come vengono effettuate le modifiche dinamiche: se la relazione viene annullata 6 minuti prima dell'inizio, quale sequenza di azioni segue? Quale pipeline si attiva?
Vladimir: La pipeline è piuttosto condizionale. Ci sono diverse possibilità. La prima è che il programma di pianificazione abbia preso piede e modificato il programma. Il programma modificato viene caricato in Contentful. Dopodiché, il backend rileva che ci sono cambiamenti riguardanti quella conferenza in Contentful, riprende e ricompone. Tutto viene assemblato e inviato tramite websocket.
La seconda possibilità è quando tutto accade a un ritmo frenetico: l'editor modifica manualmente in Contentful le informazioni (link a Telegram, presentazione del relatore, ecc.) e scatta la stessa logica di prima.
Nikolay: Tutto avviene senza ricaricare la pagina. Tutte le modifiche avvengono in modo completamente fluido per il cliente. Lo stesso vale per il cambio delle relazioni. Quando arriva il momento, cambia la relazione e l'interfaccia.
Vladimir: Lo stesso vale per i punti temporali di inizio delle relazioni nella timeline. All'inizio non c'è nulla. Ma se si passa il mouse sulla barra rossa, a un certo punto, grazie al regista della trasmissione, appariranno i punti. Il regista imposta il corretto inizio della trasmissione, il backend cattura questa modifica, calcola l'orario di inizio e fine delle relazioni dell'intero track in base al programma della conferenza e lo invia ai nostri clienti, il player disegna i punti. Ora l'utente può navigare agevolmente verso l'inizio e la fine della relazione. Questo era un duro requisito aziendale, molto comodo e utile. Non perdi tempo a cercare il reale orario di inizio della relazione. E quando faremo l'anteprima, sarà davvero fantastico.
Deployment
— Vorrei chiedere del deployment. Kolya e il team hanno perso molto tempo all'inizio per configurare tutta l'infrastruttura in cui si svolge tutto. Racconta, di cosa è composto tutto questo?
Nikolay: Inizialmente avevamo la necessità di astrarre il prodotto il più possibile da qualsiasi fornitore. Non era molto adatto venire in AWS per creare script Terraform specifici per AWS, o specifici per Yandex, o Azure, ecc. Dovevamo trovare una soluzione alternativa.
Nelle prime tre settimane abbiamo costantemente cercato il modo migliore per procedere. Alla fine, siamo giunti alla conclusione che Kubernetes è la nostra soluzione principale, poiché consente di creare servizi scalabili automaticamente, distribuzioni automatiche e di ottenere praticamente tutti i servizi pronti all'uso. Naturalmente, era necessario formare tutti i servizi per lavorare con Kubernetes e Docker, e anche il team doveva imparare.
Abbiamo due cluster: uno di test e uno di produzione. Sono assolutamente identici dal punto di vista dell'hardware e delle configurazioni. Implementiamo l'infrastruttura come codice. Tutti i servizi vengono distribuiti automaticamente in tre ambienti da rami feature, da rami master e da rami di test, utilizzando GitLab. È tutto massimamente integrato in GitLab e con Elastic e Prometheus.
Possiamo rilasciare rapidamente le modifiche in qualsiasi ambiente (10 minuti per il backend, 5 minuti per il frontend) con tutti i test, integrazioni e l'esecuzione di test funzionali e test di integrazione sull'ambiente, e possiamo anche eseguire test di carico sull'ambiente di test, che sono simili a ciò che vogliamo ottenere in produzione.
Sui test
— Testate quasi tutto, è difficile credere a quanto avete scritto. Potete raccontare come sono i test del backend: quanto è coperto, quali test ci sono?
Vladimir: Sono stati scritti due tipi di test. I primi sono test di componenti. Testano il livello di avvio dell'intera applicazione Spring e del database in . Questo serve a verificare i casi d'uso aziendali più elevati. Non testiamo le funzioni. Testiamo solo alcune cose importanti. Ad esempio, nel test viene simulato il processo di login dell'utente, richiesta da parte di quell'utente dei biglietti, dove può andare, richiesta di accesso per visualizzare lo streaming. Sono scenari utente molto chiari.
Un approccio simile è stato implementato nei cosiddetti test di integrazione, che vengono realmente eseguiti nell'ambiente. In effetti, quando un nuovo deployment viene effettuato in produzione, anche scenari di base reali vengono eseguiti in produzione. Lo stesso login, la richiesta di biglietti, la richiesta di accesso a CloudFront, il controllo che lo stream si colleghi effettivamente con le mie autorizzazioni, e la verifica dell'interfaccia del regista.
Attualmente ho circa 70 test componenti e circa 40 test di integrazione. La copertura è molto vicina al 95%. Questo vale per i test componenti, mentre per quelli di integrazione è un po' meno, poiché non è necessario avere così tanti. Considerando che nel progetto ci sono varie generazioni di codice, è un risultato molto buono. Non c'era altro modo per fare ciò che abbiamo realizzato in tre mesi. Infatti, se avessimo testato manualmente, inviando le funzionalità alla nostra tester, che avrebbe trovato bug e restituito per le riparazioni, questo round trip di debug del codice sarebbe stato molto lungo, e non saremmo riusciti a rimanere nei tempi.
Nikolay: In linea di massima, per eseguire un regressione su tutta la piattaforma in seguito a una modifica di qualche funzione, è necessario passare due giorni a cliccare ovunque.
Vladimir: Quindi è un grande successo che, quando stimo una caratteristica, dico che ho bisogno di 4 giorni per due semplici maniglie e 1 websocket, Kolya lo approva. È già abituato al fatto che in questi 4 giorni sono inclusi 2 tipi di test, e poi, probabilmente, funzionerà.
Nikolay: Anch'io ho scritto 140 test: componenti + funzionali, che fanno la stessa cosa. Tutti gli stessi scenari vengono testati sia in produzione, che nei test e in sviluppo. Recentemente, abbiamo anche introdotto test funzionali di base per l'interfaccia utente. In questo modo copriamo le funzionalità di base più critiche che potrebbero rompersi.
Vladimir: Certo, vale la pena parlare dei test di carico. Era necessario verificare la piattaforma sotto un carico simile a quello reale, per capire cosa sta succedendo con Rabbit, cosa sta succedendo con le JVM, quanta memoria è realmente necessaria.
— Non so esattamente se stiamo testando qualcosa lato streaming, ma ricordo che c'erano stati problemi con i transcoder quando organizziamo i meetup. Abbiamo testato gli streaming?
Artyom: Abbiamo testato iterativamente. Organizzando meet-up. Nel processo di organizzazione dei meet-up ci sono stati circa 2300 ticket JIRA. Queste erano solo cose di routine che le persone facevano per organizzare i meet-up. Abbiamo preso parti della piattaforma su una pagina separata per i meet-up, curata da Kirill Tolkachev ().
A essere onesti, non ci sono stati grossi problemi. Solo un paio di volte abbiamo riscontrato bug nella cache su CloudFront, risolti abbastanza rapidamente — abbiamo semplicemente riconfigurato le politiche. C'erano molti più bug legati alle persone, ai sistemi di streaming sulla piattaforma.
Durante le conferenze, ho dovuto scrivere ulteriori esportatori per coprire più apparecchiature e servizi. A volte ho dovuto creare le mie soluzioni solo per le metriche. Il mondo dell'hardware AV (audio-video) non è molto roseo: hai qualche "API" dell'apparecchiatura che non puoi influenzare affatto. E non è affatto sicuro che tu riesca ad ottenere le informazioni di cui hai bisogno. I fornitori di hardware sono davvero lenti e praticamente impossibili da convincere. In totale più di 100 dispositivi, forniscono ciò di cui non hai bisogno e tu scrivi esportatori strani e ridondanti, grazie ai quali puoi comunque debuggare il sistema.
Attrezzature
— Ricordo che, prima dell'inizio delle conferenze, abbiamo parzialmente acquistato ulteriore attrezzatura.
Artyom: Abbiamo acquistato computer, laptop, blocchi di alimentazione. Al momento possiamo vivere senza elettricità per 40 minuti. A giugno a San Pietroburgo ci sono state forti tempeste — quindi abbiamo avuto un'interruzione del genere. Inoltre, abbiamo diversi provider che arriva con connessioni ottiche da vari punti. Questo significa realmente 40 minuti di downtime per l'edificio, durante i quali avremo luce, audio, telecamere, ecc.
— Con internet abbiamo una storia simile. Nell'ufficio dove si trovano i nostri studi, abbiamo esteso una robusta rete tra i piani.
Artyom: Abbiamo 20 Gbps di fibra ottica tra i piani. Più avanti nei piani ci sono alcune linee in fibra, ma non sono tutte, e non ci sono canali gigabit — utilizziamo queste linee per trasmettere video tra le sessioni della conferenza. È davvero molto comodo lavorare con la nostra infrastruttura, specialmente perché di solito è raro poter gestire offline le conferenze negli spazi.
— Anche prima di lavorare con JUG Ru Group, ho visto come le attrezzature venissero assemblate in una notte per le conferenze offline, dove c'è un grande schermo con tutte le metriche che costruite in Grafana. Ora c'è anche un'area di comando, dove si trova il team di sviluppo che durante la conferenza risolve alcuni bug e sviluppa nuove funzionalità. In aggiunta, c'è un sistema di monitoraggio che viene visualizzato su un grande schermo. Artem, Kolya e gli altri ragazzi sono lì per assicurarsi che tutto funzioni bene e senza intoppi.
Curiosità e problemi
— Hai descritto molto bene il nostro servizio di streaming con Amazon, la presenza di un player web, il supporto per vari linguaggi di programmazione, la resilienza del sistema e altri requisiti aziendali, incluso un'area clienti disponibile sia per aziende che per privati. Possiamo anche integrare con altri tramite OAuth 2.0, gestire sistemi antifrode e il blocco degli utenti. Possiamo implementare modifiche dinamicamente, grazie a una buona programmazione, e tutto questo viene rigorosamente testato.
Sono curioso di sapere quali curiosità ci sono state durante il lancio di qualcosa. Ci sono state situazioni stravaganti mentre sviluppavate il backend e il frontend, dove vi sembrava di combattere con qualcosa di assurdo e non sapevate come affrontarlo?
Vladimir: Mi sembra che sia successo solo negli ultimi tre mesi. Ogni giorno. Come potete vedere, ho perso tutti i capelli.
Vladimir Krasil'shchik dopo 3 mesi, quando tutto sembrava un caos e nessuno sapeva come gestirlo.
Ogni giorno c'era qualcosa di simile, un momento in cui ti ritrovi a strapparti i capelli oppure realizzi che non c'è nessun altro e solo tu puoi farlo. Il nostro primo grande evento è stato il TechTrain. Il 6 giugno, alle 2 del mattino, non avevamo ancora distribuito l'ambiente di produzione, lo stava facendo Kolja. E non funzionava il pannello personale, come server di autorizzazione tramite OAuth 2.0. Lo abbiamo trasformato in un provider OAuth 2.0 per connettere la piattaforma. Avevo già lavorato per circa 18 ore di fila, fissando il computer senza vedere nulla, non capivo perché non funzionasse. Kolja controllava il mio codice da remoto, cercando un bug nella configurazione di Spring, lo ha trovato, e il pannello personale ha iniziato a funzionare, anche in produzione.
Nikolay: E un'ora prima del TechTrain il rilascio è avvenuto.
Qui si sono allineate molte stelle. Siamo stati fortunati, perché abbiamo creato un super team, e tutti erano motivati dall'idea di fare qualcosa online. In questi tre mesi, ci ha spinti il fatto che stavamo "facendo YouTube". Non mi permetteva di strappare i capelli, dicevo a tutti che ce l'avremmo fatta, perché in realtà tutto era già stato pianificato.
Riguardo alle prestazioni
— Puoi dirci qual è stato il numero massimo di persone sul sito in un singolo evento? Ci sono stati problemi di prestazioni?
Nikolay: Non ci sono stati problemi di prestazioni, come abbiamo già detto. Il numero massimo di persone che sono state su una singola presentazione è stato di 1300, durante Heisenbug.
— Ci sono stati problemi con la visualizzazione locale? E c'è la possibilità di avere una descrizione tecnica con diagrammi su come è tutto configurato?
Nikolay: Scriveremo un articolo su questo più avanti.
Localmente possiamo persino fare il debug delle streaming. Una volta iniziate le conferenze, è diventato ancora più semplice, grazie agli streaming di produzione che possiamo seguire continuamente.
Vladimir: Da quello che capisco, gli sviluppatori frontend lavoravano localmente con i mock, e poi, poiché il tempo di distribuzione nella dev sul frontend è breve (5 minuti), non ci sono problemi a controllare i certificati.
— Tutto viene testato, debuggato, anche localmente. Quindi scriveremo un articolo con tutte le caratteristiche tecniche, mostreremo e spiegheremo tutto con diagrammi.
Vladimir: Sarete in grado di prendere e ripetere.
— In 3 mesi.
Risultato
— Tutto ciò che è stato descritto suona fantastico considerando che è stato fatto da un piccolo team in tre mesi.
Nikolay: Una grande squadra non riuscirebbe a farlo. Ma un piccolo gruppo di persone che comunica in modo stretto e positivo tra di loro e riesce a prendere accordi potrebbe. Non hanno conflitti, l'architettura è stata concepita in due giorni, finalizzata e non è praticamente cambiata. C'è una facilitazione molto rigorosa delle richieste aziendali in termini di accumulo di richieste di funzionalità e cambiamenti.
— Quali sono emerse nel vostro elenco di compiti futuri dopo le conferenze estive già svolte?
Nikolay: Ad esempio, i sottotitoli. Strisce che scorrono nei video, pop-up in alcuni punti del video a seconda dei contenuti mostrati. Ad esempio, se un relatore desidera porre una domanda al pubblico, appare sullo schermo un sondaggio che, in base ai risultati, ritorna al relatore stesso. Qualche forma di attività sociale come like, cuori, valutazioni della presentazione durante la stessa presentazione, in modo da poter fornire feedback al momento, senza dover ritornare poi ai moduli di feedback. Questa era l'idea iniziale.
Inoltre, l'aggiunta di tutta la piattaforma, ad eccezione dello streaming e delle conferenze, include anche lo stato post-conferenza. Questi sono playlist (comprese quelle create dagli utenti), contenuti di altre conferenze già svolte, integrati e contrassegnati, disponibili per l'utente, e visibili sul nostro sito.).
— Ragazzi, grazie mille per le risposte!
Se tra i lettori ci sono quelli che hanno partecipato alle nostre conferenze estive, condividete le vostre impressioni sul lettore e sulla trasmissione. Cosa è stato comodo, cosa ha infastidito e cosa vorreste vedere in futuro?
Se la piattaforma vi ha interessato e volete vederla "all'opera", la utilizzeremo nuovamente alle nostre . Ce ne sono diverse, quindi è quasi sicuro che ce ne sia una adatta a voi.
Fonte: habr.com
