Aquesta primavera ens hem trobat en unes condicions molt alegres. A causa de la pandèmia, va quedar clar que les nostres conferències d'estiu s'havien de traslladar en línia. I per dur-los a terme en línia de manera eficient, les solucions de programari ja fetes no eren adequades per a nosaltres; havíem d'escriure les nostres. I vam tenir tres mesos per fer-ho.
Està clar que han estat tres mesos emocionants. Però des de fora no és del tot obvi: què és una plataforma de conferències en línia? De quines parts consta? Per això, a l'última de les conferències de DevOops d'estiu, vaig demanar als responsables d'aquesta tasca:
- Nikolay Molchanov - director tècnic del grup JUG Ru;
- Vladimir Krasilshchik és un programador de Java pragmàtic que treballa al backend (també podeu veure els seus informes a les nostres conferències de Java);
- Artyom Nikonov és responsable de tota la nostra transmissió de vídeo.
Per cert, a les conferències de tardor-hivern farem servir una versió millorada de la mateixa plataforma -per tant, molts lectors d'habra seguiran sent els seus usuaris.
Imatge general
— Quina era la composició de l'equip?
Nikolay Molchanov: Tenim un analista, un dissenyador, un provador, tres front-end i un back-end. I, per descomptat, un especialista en forma de T!
— Com va ser el procés en general?
Nikolay: Fins a mitjans de març, no teníem res preparat per a Internet. I el 15 de març, tot el carrusel en línia va començar a girar. Vam muntar diversos repositoris, vam planificar, vam parlar de l'arquitectura bàsica i vam fer-ho tot en tres mesos.
Això, per descomptat, va passar per les etapes clàssiques de la planificació, l'arquitectura, la selecció de funcions, la votació d'aquestes característiques, la política d'aquestes característiques, el seu disseny, desenvolupament i proves. Com a resultat, el 6 de juny ho vam llançar tot a producció. . Hi havia 90 dies per a tot.
— Vam aconseguir el que ens vam comprometre?
Nikolay: Com que ara participem a la conferència de DevOops en línia, vol dir que va funcionar. Personalment em vaig comprometre amb el principal: portaré als clients una eina amb la qual puguin fer una conferència en línia.
El repte era aquest: donar-nos una eina amb la qual puguem difondre les nostres conferències als titulars d'entrades.
Tota la planificació es va dividir en diverses etapes i totes les característiques (unes 30 globals) es van dividir en 4 categories:
- que definitivament farem (no podem viure sense ells),
- que farem en segon lloc,
- que mai farem,
- i que mai, mai farem.
Hem fet totes les característiques de les dues primeres categories.
— Sé que es van crear un total de 600 números de JIRA. En tres mesos vau fer 13 microserveis i sospito que no només estaven escrits en Java. Heu utilitzat diferents tecnologies, teniu dos clústers de Kubernetes en tres zones de disponibilitat i 5 fluxos RTMP a Amazon.
Vegem ara cada component del sistema per separat.
Transmissió en directe
— Comencem per quan ja tenim una imatge de vídeo, i es transmet a alguns serveis. Artyom, explica'ns com passa aquesta transmissió?
Artyom Nikonov: El nostre esquema general té aquest aspecte: imatge de la càmera -> la nostra sala de control -> servidor RTMP local -> Amazon -> reproductor de vídeo. Més detalls a Habré al juny.
En general, hi ha dues maneres globals de fer-ho: ja sigui en maquinari o basat en solucions de programari. Hem escollit la ruta del programari perquè és més fàcil en el cas dels altaveus remots. No sempre és possible portar maquinari a un altaveu d'un altre país, però lliurar programari a l'altaveu sembla més fàcil i fiable.
Des del punt de vista del maquinari, tenim un cert nombre de càmeres (als nostres estudis i als altaveus remots), un cert nombre de comandaments a distància a l'estudi, que de vegades s'han de reparar just sota la taula durant l'emissió.
Els senyals d'aquests dispositius entren als ordinadors amb targetes de captura, targetes d'entrada/sortida i targetes de so. Allà els senyals es barregen i s'ajunten en dissenys:
Exemple de disseny per a 4 altaveus
Exemple de disseny per a 4 altaveus
A més, la difusió contínua es proporciona amb l'ajuda de tres ordinadors: hi ha una màquina principal i un parell de treballadores al seu torn. El primer ordinador recull el primer informe, el segon - el descans, el primer - el següent informe, el segon - el següent descans, i així successivament. I la màquina principal barreja la primera amb la segona.
Això crea una mena de triangle, i si algun d'aquests nodes falla, podem continuar lliurant contingut als clients ràpidament i sense pèrdua de qualitat. Vam tenir una situació així. Durant la primera setmana de conferències, vam arreglar una màquina, la vam encendre/apagar. La gent sembla estar contenta amb la nostra resiliència.
A continuació, els fluxos dels ordinadors van a un servidor local, que té dues tasques: encaminar els fluxos RTMP i gravar còpies de seguretat. Així que tenim diversos punts de gravació. A continuació, els fluxos de vídeo s'envien a la part del nostre sistema construïda sobre els serveis SaaS d'Amazon. Fem servir ,S3,CloudFront.
Nikolay: Què passa abans que el vídeo arribi al públic? L'has de tallar d'alguna manera, oi?
Artyom: Comprimim el vídeo per la nostra part i l'enviem a MediaLive. Hi posem transcodificadors. Transcodifiquen vídeos en temps real a diverses resolucions perquè la gent els pugui veure als seus telèfons, a través d'Internet deficient al país, etc. A continuació, aquests corrents es tallen , així és com funciona el protocol . Enviem una llista de reproducció a la interfície que conté punters a aquests fragments.
— Estem fent servir una resolució de 1080p?
Artyom: L'amplada del nostre vídeo és la mateixa que 1080p - 1920 píxels, i l'alçada és una mica menor, la imatge és més allargada; hi ha raons per això.
Jugador
— Artyom va descriure com el vídeo entra a les reproduccions, com es distribueix en diferents llistes de reproducció per a diferents resolucions de pantalla, es talla en trossos i entra al reproductor. Kolya, ara digues-me quin tipus de jugador és aquest, com consumeix el flux, per què HLS?
Nikolay: Tenim un reproductor que tots els espectadors de la conferència poden veure.
Essencialment, aquest és un embolcall al voltant de la biblioteca , on hi ha escrits molts altres jugadors. Però necessitàvem una funcionalitat molt concreta: rebobinar i marcar el lloc on es troba la persona, quin reportatge està veient actualment. També necessitàvem els nostres propis dissenys, tot tipus de logotips i tot el que s'incorporava amb nosaltres. Per tant, vam decidir escriure la nostra pròpia biblioteca (un embolcall sobre HLS) i incrustar-la al lloc.
Aquesta és la funcionalitat arrel, de manera que es va implementar gairebé primer. I llavors tot va créixer al seu voltant.
De fet, a través de l'autorització, el jugador rep del backend una llista de reproducció amb enllaços a trossos correlacionats amb el temps i la qualitat, descarrega els necessaris i els mostra a l'usuari, fent una mica de "màgia" al llarg del camí.
Exemple de cronologia
— Hi ha un botó integrat al reproductor per mostrar una línia de temps de tots els informes...
Nikolay: Sí, de seguida vam resoldre el problema de la navegació dels usuaris. A mitjans d'abril, vam decidir que no emetíem cadascuna de les nostres conferències en un lloc web diferent, sinó que ho combinaríem tot en un mateix. Perquè els usuaris d'entrades Full Pass puguin canviar lliurement entre les diferents conferències: tant emissions en directe com enregistraments de les anteriors.
I per facilitar als usuaris navegar pel flux actual i canviar entre les pistes, vam decidir crear un botó "Emissió sencera" i butlletins d'informes horitzontals per canviar entre les pistes i els informes. Hi ha control de teclat.
— Hi ha hagut dificultats tècniques amb això?
Nikolay: Disposaven d'una barra de desplaçament on es marcaven els punts de partida de diferents informes.
— Al final, vau implementar aquestes marques a la barra de desplaçament abans que YouTube fes alguna cosa semblant?
Artyom: Aleshores el tenien en versió beta. Sembla que aquesta és una característica força complexa perquè l'han estat provant parcialment amb usuaris durant l'últim any. I ara ha arribat a la venda.
Nikolay: Però en realitat el vam posar a la venda més ràpid. Sincerament, darrere d'aquesta característica senzilla hi ha una gran quantitat de backend, frontend, càlculs i matemàtiques dins del reproductor.
Frontend
— Anem a esbrinar com arriba aquest contingut que mostrem (targeta de veu, altaveus, lloc web, programació)?
Vladimir Krasilshchik: Disposem de diversos sistemes informàtics interns. Hi ha un sistema en el qual s'introdueixen tots els informes i tots els ponents. Hi ha un procés pel qual un ponent participa en una conferència. L'orador envia una sol·licitud, el sistema la captura, després hi ha una canalització determinada segons la qual es crea l'informe.
Així és com l'orador veu la canalització
Aquest sistema és el nostre desenvolupament intern.
A continuació, heu de crear un calendari a partir d'informes individuals. Com sabeu, aquest és un problema difícil de NP, però d'alguna manera el solucionem. Per fer-ho, posem en marxa un altre component que genera una programació i la puja al servei al núvol de tercers Contentful. Allà, tot sembla una taula en què hi ha dies de conferència, en els dies hi ha franges horàries, i a les franges hi ha informes, descansos o activitats de patrocini. Per tant, el contingut que veiem es troba en un servei de tercers. I la tasca és transmetre-ho al lloc.
Sembla que el lloc és només una pàgina amb un reproductor, i aquí no hi ha res complicat. Excepte que no ho és. El backend darrere d'aquesta pàgina va a Contentful, obté la programació des d'allà, genera alguns objectes i l'envia a la interfície. Mitjançant una connexió websocket, que fa cada client de la nostra plataforma, li enviem una actualització de la programació des del backend fins al frontend.
Cas real: el ponent va canviar de feina just durant la conferència. Hem de canviar el seu distintiu d'empresa empresari. Com passa això des del backend? S'envia una actualització a tots els clients a través del websocket i, a continuació, la pròpia interfície torna a dibuixar la línia de temps. Tot això passa a la perfecció. La combinació del servei al núvol i diversos dels nostres components ens dóna l'oportunitat de generar tot aquest contingut i oferir-lo al davant.
Nikolay: És important aclarir aquí que el nostre lloc no és una aplicació SPA clàssica. Es tracta d'un lloc web renderitzat basat en el disseny i d'un SPA. Google realment veu aquest lloc com a HTML renderitzat. Això és bo per a SEO i per oferir contingut a l'usuari. No espera que es carreguin 1,5 megabytes de JavaScript abans de veure la pàgina, veu immediatament la pàgina ja renderitzada i ho sents cada vegada que canvies d'informe. Tot passa en mig segon, ja que el contingut ja està preparat i publicat al lloc correcte.
— Tracem una línia sota tot l'anterior enumerant les tecnologies. Tyoma va dir que tenim 5 reproduccions d'Amazon i que hi oferim vídeo i so. Tenim scripts bash allà, els fem servir per llançar i configurar...
Artyom: Això passa a través de l'API d'AWS, hi ha molts més serveis tècnics. Hem dividit les nostres responsabilitats de manera que jo lliuri a , i els desenvolupadors front-end i back-end ho prenen des d'allà. Tenim una sèrie de vincles pròpies per simplificar la disposició del contingut, que després fem en 4K, etc. Com que els terminis eren molt ajustats, ho vam fer gairebé completament a AWS.
— Aleshores, tot això passa al reproductor mitjançant el sistema de fons. Tenim TypeScript, React, Next.JS al nostre reproductor. I al backend tenim diversos serveis en C#, Java, Spring Boot i Node.js. Tot això es desplega amb Kubernetes mitjançant la infraestructura Yandex.Cloud.
També vull assenyalar que quan vaig necessitar familiaritzar-me amb la plataforma, va resultar fàcil: tots els repositoris estan a GitLab, tot està ben anomenat, les proves estan escrites, hi ha documentació. És a dir, fins i tot en mode d'emergència, s'encarregaven d'aquestes coses.
Restriccions empresarials i anàlisi
— Ens vam dirigir a 10 usuaris en funció dels requisits empresarials. És hora de parlar de les restriccions comercials que teníem. Havíem de garantir una elevada càrrega de treball, vetllar pel compliment de la llei de preservació de dades personals. I què més?
Nikolay: Al principi, vam partir dels requisits de vídeo. El més important és l'emmagatzematge de vídeo distribuït arreu del món per a un lliurament ràpid al client. Altres inclouen una resolució de 1080p, així com el rebobinat, que molts altres no implementen en mode en directe. Més tard hem afegit la possibilitat d'habilitar la velocitat 2x, amb la seva ajuda, podeu "posar-vos al dia" amb el directe i seguir veient la conferència en temps real. I al llarg del camí, va aparèixer la funcionalitat de marcatge de la línia de temps. A més, havíem de ser tolerants a errors i suportar la càrrega de 10 connexions. Des del punt de vista del backend, es tracta d'aproximadament 000 connexions multiplicades per 10 sol·licituds per a cada actualització de la pàgina. I això ja són 000 RPS/s. Una mica de.
— Hi havia altres requisits per a una “exposició virtual” amb estands en línia de socis?
Nikolay: Sí, això s'havia de fer de manera bastant ràpida i universal. Teníem fins a 10 empreses associades per a cada conferència, i totes s'havien de completar en una o dues setmanes. Tanmateix, el seu contingut difereix lleugerament pel que fa al format. Però es va crear un determinat motor de plantilles que munta aquestes pàgines sobre la marxa, sense pràcticament cap participació en el desenvolupament.
— També hi havia requisits per a l'anàlisi de visualitzacions i estadístiques en temps real. Sé que fem servir Prometheus per a això, però explica'ns amb més detall: quins requisits complim per a l'anàlisi i com s'implementa?
Nikolay: Inicialment, tenim requisits de màrqueting per recopilar proves A/B i recopilar informació per entendre com oferir correctament el millor contingut al client en el futur. També hi ha requisits per a algunes anàlisis sobre les activitats dels socis i les anàlisis que veieu (comptador de visites). Tota la informació es recull en temps real.
Podem proporcionar aquesta informació de forma agregada fins i tot als parlants: quantes persones us miraven en un moment determinat. Al mateix temps, per complir amb la Llei Federal 152, el vostre compte personal i les dades personals no són rastrejats de cap manera.
La plataforma ja disposa d'eines de màrqueting i de les nostres mètriques per mesurar l'activitat dels usuaris en temps real (qui ha vist quin segon de l'informe) per tal de construir gràfics d'assistència als informes. A partir d'aquestes dades, s'estan fent investigacions que milloraran les properes conferències.
Frau
— Tenim mecanismes antifrau?
Nikolay: A causa de l'estret període de temps des del punt de vista empresarial, la tasca no es va establir inicialment per bloquejar immediatament connexions innecessàries. Si dos usuaris inicien sessió amb el mateix compte, podrien veure el contingut. Però sabem quantes visualitzacions simultànies hi havia des d'un mateix compte. I vam prohibir diversos infractors especialment maliciosos.
Vladimir: Pel seu mèrit, un dels usuaris prohibits va entendre per què passava això. Va venir, es va disculpar i va prometre comprar un bitllet.
— Perquè tot això passi, s'ha de rastrejar completament tots els usuaris des de l'entrada fins a la sortida, saber sempre el que estan fent. Com funciona aquest sistema?
Vladimir: M'agradaria parlar d'analítica i estadístiques, que després analitzem per a l'èxit de l'informe o que després podem oferir als socis. Tots els clients estan connectats mitjançant una connexió websocket a un clúster de backend específic. Es troba allà . Cada client en cada període de temps envia el que està fent i quina pista està veient. Aleshores, aquesta informació s'agrega mitjançant treballs ràpids de Hazelcast i s'envia a tothom que vegi aquestes cançons. Veiem al racó quanta gent està ara amb nosaltres.
S'emmagatzema la mateixa informació i va al nostre llac de dades, a partir del qual tenim l'oportunitat de construir un gràfic més interessant. La pregunta sorgeix: quants usuaris únics han vist aquest informe? Anem a , hi ha pings de tota la gent que va venir per l'identificador d'aquest informe. Vam recollir, agregar-ne d'únics i ara ho podem entendre.
Nikolay: Però, al mateix temps, també rebem dades en temps real de Prometheus. S'estableix contra tots els serveis de Kubernetes, contra el mateix Kubernetes. Recull absolutament tot, i amb Grafana podem construir qualsevol gràfic en temps real.
Vladimir: D'una banda, ho descarreguem per a un posterior processament OLAP. I per a OLTP, l'aplicació descarrega tot a Prometheus, Grafana i els gràfics fins i tot convergeixen!
- Aquest és el cas quan els gràfics convergeixen.
Canvis dinàmics
— Expliqueu-nos com es desenvolupen els canvis dinàmics: si l'informe es va cancel·lar 6 minuts abans de l'inici, quina és la cadena d'accions? Quina canonada funciona?
Vladimir: El gasoducte és molt condicional. Hi ha diverses possibilitats. El primer és que el programa de generació d'horaris va funcionar i va canviar l'horari. La programació modificada es puja a Contentful. Després d'això, el backend entén que hi ha canvis per a aquesta conferència a Contentful, l'agafa i la reconstrueix. Tot es recull i s'envia mitjançant websocket.
La segona possibilitat, quan tot passa a un ritme vertiginós: l'editor canvia manualment la informació a Contentful (enllaç a Telegram, presentació del ponent, etc.) i funciona la mateixa lògica que la primera vegada.
Nikolay: Tot passa sense actualitzar la pàgina. Tots els canvis es produeixen de manera absolutament perfecta per al client. El mateix passa amb el canvi d'informes. Quan arriba el moment, l'informe i la interfície canvien.
Vladimir: A més, hi ha límits de temps per a l'inici dels informes a la línia de temps. Al principi no hi ha res. I si passeu el ratolí per sobre de la franja vermella, en algun moment, gràcies al director d'emissió, apareixeran talls. El director estableix l'inici correcte de l'emissió, el backend recull aquest canvi, calcula les hores d'inici i finalització de les presentacions de tota la pista d'acord amb el calendari de conferències, l'envia als nostres clients i el jugador dibuixa els talls. Ara l'usuari pot navegar fàcilment al principi i al final de l'informe. Era un requisit comercial estricte, molt convenient i útil. No perdis el temps buscant l'hora d'inici real de l'informe. I quan fem una vista prèvia, serà absolutament meravellós.
Desplegament
— M'agradaria preguntar sobre el desplegament. Kolya i l'equip van dedicar molt de temps al principi a muntar tota la infraestructura en la qual tot es desenvolupa per nosaltres. Digues-me, de què està fet tot?
Nikolay: Des del punt de vista tècnic, inicialment teníem l'exigència que el producte fos el més abstracte possible de qualsevol proveïdor. Vine a AWS per fer scripts Terraform específicament des d'AWS, o específicament des de Yandex, o des d'Azure, etc. no encaixava realment. En algun moment ens vam haver de traslladar.
Durant les tres primeres setmanes vam estar constantment buscant una manera de fer-ho millor. Com a resultat, vam arribar a la conclusió que Kubernetes en aquest cas és el nostre tot, perquè ens permet crear serveis d'escalada automàtica, llançament automàtic i treure gairebé tots els serveis de la caixa. Naturalment, tots els serveis s'havien d'entrenar per treballar amb Kubernetes, Docker i l'equip també havia d'aprendre.
Tenim dos grups. Prova i producció. Són absolutament idèntics pel que fa al maquinari i la configuració. Implementem la infraestructura com a codi. Tots els serveis es desenvolupen automàticament en tres entorns des de branques de funcions, branques mestres, branques de prova i GitLab mitjançant una canalització automàtica. Això s'integra al màxim a GitLab, al màxim amb Elastic, Prometheus.
Tenim l'oportunitat de desplegar ràpidament (per al backend en 10 minuts, per al frontend en 5 minuts) canvis a qualsevol entorn amb totes les proves, integracions, executant proves funcionals, proves d'integració a l'entorn i també provar amb proves de càrrega a un entorn de prova aproximadament el mateix que volem aconseguir en producció.
Sobre les proves
— Ho proves gairebé tot, costa creure com ho has escrit tot. Ens pots parlar de les proves de fons: quant està tot cobert, quines proves?
Vladimir: S'han escrit dos tipus de proves. Les primeres són proves de components. Proves de nivell d'elevació de tota l'aplicació de la molla i la base . Aquesta és una prova dels escenaris empresarials de més alt nivell. No comprovo les funcions. Només provem algunes coses importants. Per exemple, just a la prova, s'emula el procés d'inici de sessió d'un usuari, la sol·licitud de l'usuari d'entrades on pot anar i una sol·licitud d'accés per veure la transmissió. Escenaris d'usuari molt clars.
Aproximadament el mateix s'implementa en les anomenades proves d'integració, que en realitat s'executen a l'entorn. De fet, quan es desplega el següent desplegament en producció, també s'executen escenaris bàsics reals en producció. El mateix inici de sessió, sol·licitar entrades, sol·licitar accés a CloudFront, comprovar que el flux realment es connecta amb els meus permisos, comprovant la interfície del director.
De moment tinc unes 70 proves de components i unes 40 proves d'integració a bord. La cobertura és molt propera al 95%. Això és per als components, menys per als d'integració, simplement no n'hi ha tant de necessari. Tenint en compte que el projecte implica tot tipus de generació de codi, aquest és un molt bon indicador. No hi havia cap altra manera de fer el que vam fer en tres mesos. Perquè si provessim manualment, donant funcions al nostre verificador, i ella trobés errors i ens els retornés per solucionar-ho, aquest viatge d'anada i tornada per depurar el codi seria molt llarg i no compliríem cap termini.
Nikolay: Convencionalment, per dur a terme una regressió a tota la plataforma quan es canvia alguna funció, cal asseure's i picar a tot arreu durant dos dies.
Vladimir: Per tant, és un gran èxit que quan estimo una característica, dic que necessito 4 dies per a dos bolígrafs simples i 1 websocket, Kolya ho permet. Ja està acostumat al fet que aquests 4 dies inclouen 2 tipus de proves, i després, molt probablement, funcionarà.
Nikolay: També tinc 140 proves escrites: component + funcional, que fan el mateix. Tots els mateixos escenaris es posen a prova en producció, en prova i en producció. També hem afegit recentment proves d'IU bàsiques funcionals. D'aquesta manera cobrim la funcionalitat més bàsica que es pot desfer.
Vladimir: Per descomptat, val la pena parlar de proves de càrrega. Va ser necessari provar la plataforma sota una càrrega propera a la real per entendre com és tot, què passa amb Rabbit, què passa amb les JVM, quanta memòria es necessita realment.
— No sé del cert si estem provant alguna cosa al costat del flux, però recordo que hi va haver problemes amb els transcodificadors quan vam fer trobades. Hem provat els streams?
Artyom: Prova iterativa. Organització de trobades. En el procés d'organització de trobades, hi havia aproximadament 2300 entrades JIRA. Aquestes són només coses genèriques que la gent va fer per fer trobades. Vam portar parts de la plataforma a una pàgina separada per a les trobades, dirigida per Kirill Tolkachev ().
Per ser sincer, no hi va haver grans problemes. Literalment un parell de vegades vam detectar errors de memòria cau a CloudFront, ho vam resoldre amb força rapidesa: simplement vam reconfigurar les polítiques. Hi va haver molt més errors a la gent, als sistemes de reproducció del lloc.
Durant les conferències, vaig haver d'escriure diversos exportadors més per tal de cobrir més equipaments i serveis. En alguns llocs vaig haver de fer les meves pròpies bicicletes només per mesurar les mètriques. El món del maquinari AV (àudio-vídeo) no és gaire bo: teniu algun tipus d'"API" d'equips que simplement no podeu influir. I està lluny de ser un fet que podreu obtenir la informació que necessiteu. Els venedors de maquinari són molt lents i és gairebé impossible obtenir el que voleu d'ells. En total hi ha més de 100 peces de maquinari, no tornen el que necessiteu i escriviu exportadors estranys i redundants, gràcies als quals, almenys, podeu depurar el sistema d'alguna manera.
Оборудование
— Recordo com abans de l'inici de les jornades vam comprar parcialment equipament addicional.
Artyom: Hem comprat ordinadors, portàtils i bateries. De moment podem viure sense electricitat durant 40 minuts. Al juny hi va haver tempestes fortes a Sant Petersburg, així que vam tenir una apagada. Al mateix temps, diversos proveïdors ens arriben amb enllaços òptics des de diferents punts. Això són realment 40 minuts d'inactivitat de l'edifici, durant els quals tindrem llums enceses, so, càmeres, etc.
— Tenim una història semblant amb Internet. A l'oficina on es troben els nostres estudis, arrossegàvem una xarxa ferotge entre els pisos.
Artyom: Disposem de 20 Gbit de fibra entre plantes. Més enllà dels pisos, en algun lloc hi ha òptica, en algun lloc no hi ha òptica, però encara hi ha menys canals que els de gigabit: hi publiquem vídeo entre les pistes de la conferència. En general, és molt convenient treballar amb la vostra pròpia infraestructura; poques vegades podeu fer-ho a les conferències fora de línia als llocs.
— Abans de treballar al JUG Ru Group, vaig veure com s'instal·laven sales de maquinari a les conferències fora de línia durant la nit, on hi havia un monitor gran amb totes les mètriques que creeu a Grafana. Ara també hi ha una sala central on s'asseu l'equip de desenvolupament, que durant la conferència corregeix alguns errors i desenvolupa funcions. Al mateix temps, hi ha un sistema de monitorització que es mostra en una pantalla gran. Artyom, Kolya i altres nois s'asseuen i s'asseguren que no caigui tot i funcioni molt bé.
Curiositats i problemes
— Has parlat bé del fet que tenim streaming amb Amazon, hi ha un reproductor amb la web, tot està escrit en diferents llenguatges de programació, es proporcionen tolerància a errors i altres requisits empresarials, inclòs un compte personal compatible amb persones jurídiques i individus, i podem integrar-nos amb algú que utilitza OAuth 2.0, hi ha antifrau, bloqueig d'usuaris. Podem implementar canvis de manera dinàmica perquè ho hem fet bé i tot està provat.
M'interessa saber quines curiositats van implicar per començar alguna cosa. Hi ha hagut situacions estranyes en què estàveu desenvolupant un backend, una interfície, va sortir alguna cosa boja i no enteniu què fer-hi?
Vladimir: Em sembla que això només ha passat durant els darrers tres mesos. Cada dia. Com podeu veure, m'han estirat tot el cabell.
Vladimir Krasilshchik després de 3 mesos, quan va resultar algun tipus de joc i ningú no va entendre què fer-hi
Cada dia hi havia una cosa així, quan hi havia un moment en què t'ho prens i t'esquisses els cabells, o t'adones que no hi ha ningú més, i només tu pots fer-ho. El nostre primer gran esdeveniment va ser TechTrain. El 6 de juny a les 2 a.m. encara no havíem llançat l'entorn de producció, Kolya l'estava llançant. I el compte personal no funcionava com a servidor d'autorització mitjançant OAuth2.0. El vam convertir en un proveïdor OAuth2.0 per connectar-hi la plataforma. Portava probablement 18 hores treballant seguides, vaig mirar l'ordinador i no vaig veure res, no vaig entendre per què no funcionava i Kolya va mirar el meu codi de forma remota, va buscar un error a la configuració de Spring , el va trobar i el LC va funcionar, i també en producció.
Nikolay: I una hora abans de TechTrain va tenir lloc el llançament.
Aquí hi havia moltes estrelles alineades. Vam tenir molta sort perquè teníem un súper equip, i tothom es va inspirar amb la idea de fer-ho en línia. Tots aquests tres mesos ens va motivar el fet que vam "fer YouTube". No em vaig permetre arrencar-me els cabells, però vaig dir a tothom que tot sortiria, perquè de fet, tot s'havia calculat fa temps.
Sobre el rendiment
— Em pots dir quantes persones hi havia al lloc en una pista? Hi ha hagut problemes de rendiment?
Nikolay: No hi va haver problemes de rendiment, com ja hem dit. El nombre màxim de persones que van assistir a un informe va ser de 1300 persones, això és a Heisenbug.
— Hi ha hagut problemes amb la visualització local? I és possible tenir una descripció tècnica amb esquemes de com funciona tot?
Nikolay: Més endavant farem un article sobre això.
Fins i tot podeu depurar fluxos localment. Un cop van començar les conferències, va ser encara més fàcil, perquè van aparèixer fluxos de producció que podem veure tot el temps.
Vladimir: Segons tinc entès, els desenvolupadors de front-end van treballar localment amb simulacres i, a continuació, com que el temps de llançament als desenvolupadors de la part frontal també és curt (5 minuts), no hi ha problemes per comprovar què passa amb els certificats.
— Tot es prova i es depura, fins i tot localment. Això vol dir que escriurem un article amb totes les característiques tècniques, us mostrarem, us explicarem tot amb diagrames, com va ser.
Vladimir: Podeu agafar-lo i repetir-lo.
- En 3 mesos.
Total
— Tot el que es descriu junts sona genial, tenint en compte que ho va fer un petit equip en tres mesos.
Nikolay: Un equip gran no faria això. Però un grup reduït de persones que es comuniquen bastant estreta i bé entre ells i poden arribar a un acord podria. No tenen cap contradicció, l'arquitectura es va inventar en dos dies, es va finalitzar i en realitat no ha canviat. Hi ha una facilitació molt estricta dels requisits comercials entrants pel que fa a l'acumulació de sol·licituds i canvis de funcions.
— Què hi havia a la vostra llista de tasques posteriors quan ja s'havien fet les conferències d'estiu?
Nikolay: Per exemple, els crèdits. Línies ràpides al vídeo, finestres emergents en alguns llocs del vídeo en funció del contingut que es mostri. Per exemple, l'orador vol fer una pregunta a l'audiència i apareix una votació a la pantalla, que torna a la part posterior en funció dels resultats de la votació al mateix orador. Algun tipus d'activitat social en forma de likes, cors, puntuacions de l'informe durant la pròpia presentació, perquè pugueu omplir els comentaris en el moment adequat sense que us distreguin més tard amb formularis de comentaris. Inicialment així.
I també afegint a tota la plataforma, excepte en streaming i conferència, també un estat posterior a la conferència. Es tracta de llistes de reproducció (incloses les compilades pels usuaris), possiblement contingut d'altres conferències anteriors, integrades, etiquetades, accessibles per a l'usuari i també disponibles per a la seva visualització al nostre lloc web ().
- Nois, moltes gràcies per les vostres respostes!
Si entre els lectors hi ha qui va assistir a les nostres conferències d'estiu, si us plau, compartiu les vostres impressions sobre el jugador i l'emissió. Què era convenient, què t'irritava, què t'agradaria veure en el futur?
Si estàs interessat en la plataforma i vols veure-la "en batalla", la tornem a utilitzar al nostre . N'hi ha una gran varietat, de manera que gairebé segur que n'hi ha un que us convingui.
Font: www.habr.com