Esta primavera atopámonos nunhas condicións moi alegres. Debido á pandemia, quedou claro que as nosas conferencias de verán debían moverse en liña. E para levalos a cabo en liña de forma eficiente, as solucións de software xa preparadas non eran adecuadas para nós; necesitabamos escribir as nosas. E tivemos tres meses para facelo.
Está claro que foron tres meses emocionantes. Pero desde fóra non é totalmente obvio: que é unha plataforma de conferencias en liña? De que partes consta? Por iso, na última das conferencias de verán de DevOops, preguntei aos responsables desta tarefa:
- Nikolay Molchanov - director técnico do JUG Ru Group;
- Vladimir Krasilshchik é un programador pragmático de Java que traballa no backend (tamén podes ver os seus informes nas nosas conferencias de Java);
- Artyom Nikonov é responsable de toda a nosa transmisión de vídeo.
Por certo, nas xornadas de outono-inverno empregaremos unha versión mellorada da mesma plataforma, polo que moitos lectores de habra seguirán sendo os seus usuarios.
Imaxe xeral
—¿Cal era a composición do equipo?
Nikolay Molchanov: Temos un analista, un deseñador, un probador, tres front-end e un back-end. E, por suposto, un especialista en T!
—¿Como foi o proceso en xeral?
Nikolay: Ata mediados de marzo, non tiñamos nada preparado para en liña. E o 15 de marzo, todo o carrusel en liña comezou a xirar. Montamos varios repositorios, planificamos, discutimos a arquitectura básica e fixemos todo en tres meses.
Isto, por suposto, pasou polas etapas clásicas de planificación, arquitectura, selección de funcións, votación por esas características, política para esas características, o seu deseño, desenvolvemento e probas. Como resultado, o 6 de xuño, lanzamos todo á produción. . Houbo 90 días para todo.
—¿Conseguimos cumprir o que nos comprometiamos?
Nikolay: Xa que agora estamos participando na conferencia DevOops en liña, significa que funcionou. Eu persoalmente comprométeme co principal: levarei aos clientes unha ferramenta coa que poidan facer unha conferencia en liña.
O reto era este: darnos unha ferramenta coa que poder transmitir as nosas conferencias aos posuidores de entradas.
Toda a planificación dividiuse en varias etapas e todas as características (uns 30 globais) dividíronse en 4 categorías:
- que definitivamente faremos (non podemos vivir sen eles),
- que faremos en segundo lugar,
- que nunca faremos,
- e que nunca, nunca faremos.
Fixemos todas as funcións das dúas primeiras categorías.
— Sei que se crearon un total de 600 números de JIRA. En tres meses fixeches 13 microservizos e sospeito que non só foron escritos en Java. Usaches tecnoloxías diferentes, tes dous clústeres de Kubernetes en tres zonas de dispoñibilidade e 5 fluxos RTMP en Amazon.
Vexamos agora cada compoñente do sistema por separado.
Transmisión en directo
— Empecemos por cando xa temos unha imaxe de vídeo, e esta se transmite a algúns servizos. Artyom, cóntanos como ocorre esta transmisión?
Artyom Nikonov: O noso esquema xeral ten este aspecto: imaxe da cámara -> a nosa sala de control -> servidor RTMP local -> Amazon -> reprodutor de vídeo. Máis detalles en Habré en xuño.
En xeral, hai dúas formas globais de facelo: ben en hardware ou en solucións de software. Escollemos a ruta do software porque é máis fácil no caso dos altofalantes remotos. Non sempre é posible levar hardware a un altofalante doutro país, pero entregarlle software ao altofalante parece máis fácil e fiable.
Desde o punto de vista do hardware, temos un certo número de cámaras (nos nosos estudos e nos altofalantes remotos), un certo número de mandos a distancia no estudo, que ás veces hai que reparar xusto debaixo da mesa durante a emisión.
Os sinais destes dispositivos entran nos ordenadores con tarxetas de captura, tarxetas de entrada/saída e tarxetas de son. Alí os sinais mestúranse e reúnense en esquemas:
Exemplo de disposición para 4 altofalantes
Exemplo de disposición para 4 altofalantes
Ademais, a emisión continua prodúcese coa axuda de tres ordenadores: hai unha máquina principal e un par de que funcionan á súa vez. O primeiro ordenador recolle o primeiro informe, o segundo - o descanso, o primeiro - o seguinte informe, o segundo - o seguinte descanso, etc. E a máquina principal mestura o primeiro co segundo.
Isto crea unha especie de triángulo e, se algún destes nodos falla, podemos seguir entregando contido aos clientes de forma rápida e sen perda de calidade. Tiñamos unha situación así. Durante a primeira semana de conferencias, arranxamos unha máquina, acendemos/apagamos. A xente parece estar contenta coa nosa resistencia.
A continuación, os fluxos dos ordenadores van a un servidor local, que ten dúas tarefas: enrutar fluxos RTMP e gravar copias de seguridade. Polo tanto, temos varios puntos de gravación. A continuación, os fluxos de vídeo envíanse á parte do noso sistema construída nos servizos SaaS de Amazon. Usamos ,S3,CloudFront.
Nikolay: Que pasa alí antes de que o vídeo chegue ao público? Tes que cortalo dalgún xeito, non?
Artyom: Comprimimos o vídeo pola nosa parte e enviámolo a MediaLive. Lanzamos transcodificadores alí. Transcodifican vídeos en tempo real a varias resolucións para que a xente poida velos nos seus teléfonos, a través da mala Internet do país, etc. Entón estes regatos son cortados , así funciona o protocolo . Enviamos unha lista de reprodución ao frontend que contén punteiros a estes anacos.
—Estamos a usar unha resolución de 1080p?
Artyom: O ancho do noso vídeo é o mesmo que 1080p - 1920 píxeles, e a altura é un pouco menor, a imaxe é máis alongada - hai razóns para iso.
Xogador
— Artyom describiu como o vídeo entra en emisións, como se distribúe en diferentes listas de reprodución para diferentes resolucións de pantalla, como se corta en anacos e se introduce no reprodutor. Kolya, dime agora que tipo de xogador é este, como consume o fluxo, por que HLS?
Nikolay: Temos un reprodutor que todos os espectadores da conferencia poden ver.
Esencialmente, este é un envoltorio arredor da biblioteca , no que están escritos moitos outros xogadores. Pero necesitabamos unha funcionalidade moi específica: rebobinar e marcar o lugar onde está a persoa, que reportaxe está a ver actualmente. Tamén necesitabamos os nosos propios deseños, todo tipo de logotipos e todo o que se construíu con nós. Polo tanto, decidimos escribir a nosa propia biblioteca (un envoltorio sobre HLS) e incorporala no sitio.
Esta é a funcionalidade raíz, polo que se implementou case primeiro. E entón todo medrou ao seu redor.
De feito, a través da autorización, o xogador recibe do backend unha lista de reprodución con enlaces a anacos correlacionados co tempo e a calidade, descarga os necesarios e móstraos ao usuario, realizando algunha "maxia" no camiño.
Exemplo de cronograma
— Un botón está integrado directamente no reprodutor para mostrar unha liña de tempo de todos os informes...
Nikolay: Si, solucionamos inmediatamente o problema da navegación do usuario. A mediados de abril, decidimos que non transmitiríamos cada unha das nosas conferencias nun sitio web separado, senón que combinaríamos todo nun só. Para que os usuarios de billetes Full Pass poidan cambiar libremente entre as diferentes conferencias: tanto as emisións en directo como as gravacións das anteriores.
E para facilitar aos usuarios a navegación polo fluxo actual e o cambio entre as pistas, decidimos crear un botón "Emisión completa" e boletíns de notas horizontais para cambiar entre as pistas e os informes. Hai control de teclado.
—¿Houbo dificultades técnicas con isto?
Nikolay: Contaban cunha barra de desprazamento na que se marcaban os puntos de partida de diferentes reportaxes.
— Ao final, implementou estas marcas na barra de desprazamento antes de que YouTube fixera algo semellante?
Artyom: Daquela o tiñan en versión beta. Parece que esta é unha característica bastante complexa porque estiveron probando parcialmente cos usuarios durante o ano pasado. E agora chegou á venda.
Nikolay: Pero en realidade puxémolo á venda máis rápido. Sinceramente, detrás desta sinxela función hai unha gran cantidade de backend, frontend, cálculos e matemáticas dentro do xogador.
Frontend
— Imos descubrir como chega este contido que mostramos (tarxeta de voz, altofalantes, sitio web, horario)?
Vladimir Krasilshchik: Contamos con varios sistemas informáticos internos. Existe un sistema no que se introducen todos os informes e todos os altofalantes. Hai un proceso polo cal un orador participa nunha conferencia. O falante envía unha solicitude, o sistema captaa, entón hai unha determinada canalización segundo a cal se crea o informe.
Así é como o altofalante ve a canalización
Este sistema é o noso desenvolvemento interno.
A continuación, cómpre crear unha programación a partir de informes individuais. Como sabes, este é un problema NP-difícil, pero dalgunha maneira resolvemolo. Para iso, lanzamos outro compoñente que xera unha programación e súbea ao servizo na nube de terceiros Contentful. Alí todo semella unha mesa na que hai días de xornada, nos días hai franxas horarias, e nas franxas hai relatorios, descansos ou actividades de patrocinio. Polo tanto, o contido que vemos está situado nun servizo de terceiros. E a tarefa é transmitilo ao sitio.
Parece que o sitio é só unha páxina cun reprodutor, e aquí non hai nada complicado. Excepto que non o é. O backend detrás desta páxina vai a Contentful, obtén a programación dende alí, xera algúns obxectos e envíao ao frontend. Usando unha conexión websocket, que fai cada cliente da nosa plataforma, enviámoslle unha actualización da programación desde o backend ata o frontend.
Caso real: o relator cambiou de traballo xusto durante a conferencia. Temos que cambiarlle o distintivo da empresa patronal. Como ocorre isto dende o backend? Envíase unha actualización a todos os clientes a través do websocket e, a continuación, o propio frontend redesea a liña de tempo. Todo isto ocorre sen problemas. A combinación do servizo na nube e varios dos nosos compoñentes dános a oportunidade de xerar todo este contido e proporcionalo á fronte.
Nikolay: É importante aclarar aquí que o noso sitio non é unha aplicación clásica de SPA. Este é un sitio web renderizado e baseado en deseño e un SPA. Google realmente ve este sitio como HTML renderizado. Isto é bo para o SEO e para entregar contido ao usuario. Non espera a que se carguen 1,5 megabytes de JavaScript antes de ver a páxina, ve inmediatamente a páxina xa renderizada e séntao cada vez que cambia o informe. Todo sucede en medio segundo, xa que o contido xa está listo e publicado no lugar axeitado.
— Debuxemos unha liña baixo todo o anterior enumerando as tecnoloxías. Tyoma dixo que temos 5 emisións de Amazon e que ofrecemos vídeo e son alí. Temos scripts bash alí, usámolos para lanzar e configurar...
Artyom: Isto ocorre a través da API de AWS, hai moitos máis servizos técnicos secundarios alí. Dividimos as nosas responsabilidades para que eu entregue a , e os desenvolvedores front-end e back-end tómano desde alí. Temos unha serie de ligazóns propias para simplificar o deseño do contido, que despois realizamos en 4K, etc. Dado que os prazos eran moi axustados, fixémolo case na súa totalidade en AWS.
— Entón todo isto entra no reprodutor usando o sistema de backend. Temos TypeScript, React, Next.JS no noso reprodutor. E no backend temos varios servizos en C#, Java, Spring Boot e Node.js. Todo isto implícase mediante Kubernetes mediante a infraestrutura Yandex.Cloud.
Tamén quero sinalar que cando necesitaba familiarizarme coa plataforma resultou fácil: todos os repositorios están en GitLab, todo está ben nomeado, as probas están escritas, hai documentación. É dicir, mesmo en modo de emerxencia, facíanse cargo de tales cousas.
Restricións comerciais e analítica
— Apuntámonos a 10 usuarios en función dos requisitos comerciais. É hora de falar das restricións comerciais que tiñamos. Había que garantir unha carga de traballo elevada, garantir o cumprimento da lei de conservación de datos persoais. E que máis?
Nikolay: Inicialmente, partimos dos requisitos de vídeo. O máis importante é o almacenamento de vídeo distribuído por todo o mundo para a entrega rápida ao cliente. Outros inclúen resolución de 1080p, así como rebobinado, que moitos outros non implementan no modo en directo. Máis tarde engadimos a posibilidade de activar a velocidade 2x, coa súa axuda podes "poñerte ao día" co directo e seguir vendo a conferencia en tempo real. E ao longo do camiño, apareceu a funcionalidade de marcado da liña de tempo. Ademais, tivemos que ser tolerantes a fallos e soportar a carga de 10 conexións. Desde o punto de vista do backend, isto supón aproximadamente 000 conexións multiplicadas por 10 solicitudes por cada actualización de páxina. E isto xa é de 000 RPS/seg. Un pouco de.
— Había outros requisitos para unha “exposición virtual” con stands en liña dos socios?
Nikolay: Si, isto tiña que ser feito bastante rápido e universalmente. Tiñamos ata 10 empresas colaboradoras para cada conferencia, e todas tiñan que estar rematadas nunha ou dúas semanas. Non obstante, o seu contido difire lixeiramente no seu formato. Pero fíxose un determinado motor de modelos que ensambla estas páxinas sobre a marcha, sen practicamente ningunha participación no desenvolvemento.
— Tamén había requisitos para a análise de vistas e estatísticas en tempo real. Sei que usamos Prometheus para iso, pero cóntanos con máis detalle: que requisitos cumprimos para as analíticas e como se implementa isto?
Nikolay: Inicialmente, temos requisitos de mercadotecnia para recoller para probas A/B e recoller información para comprender como entregar correctamente o mellor contido ao cliente no futuro. Tamén hai requisitos para algunhas análises sobre as actividades dos socios e as analíticas que ves (contador de visitas). Toda a información recóllese en tempo real.
Podemos proporcionar esta información de forma agregada incluso aos falantes: cantas persoas te estaban vendo nun momento determinado. Ao mesmo tempo, para cumprir coa Lei Federal 152, a súa conta persoal e os datos persoais non son rastreados de ningún xeito.
A plataforma xa conta con ferramentas de mercadotecnia e as nosas métricas para medir a actividade dos usuarios en tempo real (quen viu en que segundo o informe) co fin de construír gráficas de asistencia aos informes. A partir destes datos, estase facendo investigacións que mellorarán as próximas conferencias.
Fraude
—¿Temos mecanismos antifraude?
Nikolay: Debido ao axustado período de tempo desde o punto de vista empresarial, a tarefa non estaba configurada inicialmente para bloquear inmediatamente conexións innecesarias. Se dous usuarios iniciaron sesión coa mesma conta, poderían ver o contido. Pero sabemos cantas visualizacións simultáneas houbo desde unha conta. E prohibimos varios infractores especialmente maliciosos.
Vladimir: No seu mérito, un dos usuarios prohibidos entendeu por que ocorreu isto. Veu, pediu desculpas e prometeu mercar un billete.
— Para que todo isto suceda, debes rastrexar completamente a todos os usuarios desde a entrada ata a saída, saber sempre o que están a facer. Como funciona este sistema?
Vladimir: Gustaríame falar de análises e estatísticas, que despois analizamos para o éxito do informe ou que logo podemos proporcionar aos socios. Todos os clientes están conectados mediante unha conexión websocket a un clúster de backend específico. Queda alí . Cada cliente en cada período de tempo envía o que está facendo e que pista está a ver. Despois, esta información agrégase mediante traballos rápidos de Hazelcast e envíase de volta a todos os que vexan estas pistas. Vemos no recuncho canta xente está agora con nós.
A mesma información almacénase e vai ao noso lago de datos, desde o que temos a oportunidade de construír un gráfico máis interesante. Xorde a pregunta: cantos usuarios únicos viron este informe? Imos a , hai pings de todas as persoas que se achegaron polo id deste informe. Recollemos, agregamos únicos, e agora podemos entendelo.
Nikolay: Pero ao mesmo tempo, tamén recibimos datos en tempo real de Prometheus. Establécese contra todos os servizos de Kubernetes, contra o propio Kubernetes. Recolle absolutamente todo e con Grafana podemos construír calquera gráfica en tempo real.
Vladimir: Por unha banda, descargamos isto para un posterior procesamento OLAP. E para OLTP, a aplicación descarga todo a Prometheus, Grafana e ata converxen os gráficos.
- Este é o caso cando as gráficas converxen.
Cambios dinámicos
— Cóntanos como se desenvolven os cambios dinámicos: se o informe foi cancelado 6 minutos antes do comezo, cal é a cadea de accións? Que canalización funciona?
Vladimir: O gasoduto é moi condicional. Hai varias posibilidades. O primeiro é que o programa de xeración de horarios funcionou e cambiou o horario. A programación modificada cárgase en Contentful. Despois diso, o backend entende que hai cambios para esta conferencia en Contentful, tómao e reconstruílo. Todo recóllese e envíase a través de websocket.
A segunda posibilidade, cando todo sucede a un ritmo vertixinoso: o editor cambia manualmente a información en Contentful (ligazón a Telegram, presentación do orador, etc.) e funciona a mesma lóxica que a primeira vez.
Nikolay: Todo sucede sen actualizar a páxina. Todos os cambios ocorren de forma absolutamente sen problemas para o cliente. O mesmo ocorre co cambio de informes. Chegado o momento, o informe e a interface cambian.
Vladimir: Ademais, hai límites de tempo para o inicio dos informes na liña de tempo. Ao principio non hai nada. E se pasas o rato sobre a franxa vermella, nalgún momento, grazas ao director de transmisión, aparecerán cortes. O director establece o inicio correcto da emisión, o backend recolle este cambio, calcula as horas de inicio e finalización das presentacións de toda a pista de acordo co calendario da conferencia, envíao aos nosos clientes e o xogador debuxa cortes. Agora o usuario pode navegar facilmente ata o inicio e o final do informe. Era un requisito comercial estrito, moi cómodo e útil. Non perdas tempo buscando a hora de inicio real do informe. E cando fagamos unha vista previa, será absolutamente marabilloso.
Despregamento
— Gustaríame preguntar sobre a implantación. Kolya e o equipo dedicaron moito tempo ao principio a montar toda a infraestrutura na que todo se desenvolve para nós. Dime, de que está feito todo?
Nikolay: Desde o punto de vista técnico, inicialmente tiñamos o requisito de que o produto fose o máis abstracto posible de calquera vendedor. Ven a AWS para facer scripts de Terraform especificamente desde AWS, ou específicamente desde Yandex, ou desde Azure, etc. non encaixaba realmente. Tivemos que movernos nalgún momento.
Durante as tres primeiras semanas buscamos constantemente unha forma de facelo mellor. Como resultado, chegamos á conclusión de que Kubernetes, neste caso, é todo o noso, porque nos permite crear servizos de escalado automático, o lanzamento automático e sacar case todos os servizos da caixa. Por suposto, todos os servizos tiñan que ser adestrados para traballar con Kubernetes, Docker e o equipo tamén tiña que aprender.
Temos dous grupos. Proba e produción. Son absolutamente idénticos en termos de hardware e configuración. Implementamos a infraestrutura como código. Todos os servizos desenvólvense automaticamente en tres ambientes desde ramas de funcións, ramas mestras, ramas de proba e GitLab mediante unha canalización automática. Este está integrado ao máximo en GitLab, ao máximo con Elastic, Prometheus.
Temos a oportunidade de implementar de forma rápida (para o backend en 10 minutos, para o frontend en 5 minutos) cambios en calquera ambiente con todas as probas, integracións, execución de probas funcionais, probas de integración no ambiente e tamén probas con probas de carga. un ambiente de proba aproximadamente o mesmo que queremos conseguir en produción.
Sobre as probas
— Probas case todo, é difícil crer como escribiches todo. Podes falarnos das probas do backend: canto está cuberto todo, que probas?
Vladimir: Escribíronse dous tipos de probas. Os primeiros son probas de compoñentes. Probas de nivel de elevación de toda a aplicación do resorte e base . Esta é unha proba dos escenarios empresariais de máis alto nivel. Non comprobo funcións. Só probamos algunhas cousas grandes. Por exemplo, xusto na proba, emúlase o proceso de inicio de sesión nun usuario, a solicitude de entradas para onde pode ir e unha solicitude de acceso para ver a transmisión. Escenarios de usuario moi claros.
Aproximadamente o mesmo se implementa nas chamadas probas de integración, que en realidade se executan no entorno. De feito, cando se lanza a próxima implantación en produción, tamén se executan escenarios básicos reais en produción. O mesmo inicio de sesión, solicitando entradas, solicitando acceso a CloudFront, comprobando que o fluxo se conecta realmente cos meus permisos, comprobando a interface do director.
Polo momento teño a bordo unhas 70 probas de compoñentes e unhas 40 de integración. A cobertura está moi próxima ao 95%. Isto é para os compoñentes, menos para os de integración, simplemente non hai tanto necesidade. Tendo en conta que o proxecto implica todo tipo de xeración de código, este é un indicador moi bo. Non había outra forma de facer o que fixemos en tres meses. Porque se probasemos manualmente, dándolle funcións ao noso probador, e ela atopase erros e nos devolvía para correccións, entón esta viaxe de ida e volta para depurar o código sería moi longa e non cumpririamos ningún prazo.
Nikolay: Convencionalmente, para levar a cabo unha regresión en toda a plataforma ao cambiar algunha función, cómpre sentarse e picar en todas partes durante dous días.
Vladimir: Polo tanto, é un gran éxito que cando estimo unha función, diga que necesito 4 días para dous bolígrafos simples e 1 websocket, Kolya permíteo. Xa está afeito a que estes días 4 inclúen 2 tipos de probas, e despois, o máis probable é que funcione.
Nikolay: Tamén teño 140 probas escritas: compoñente + funcionais, que fan o mesmo. Todos os mesmos escenarios son probados en produción, en proba e en produción. Tamén engadimos recentemente probas de IU básicas funcionais. Deste xeito cubrimos a funcionalidade máis básica que pode desmoronarse.
Vladimir: Por suposto, paga a pena falar de probas de carga. Foi necesario probar a plataforma baixo unha carga próxima á real para entender como está todo, que está a pasar con Rabbit, que está a pasar coas JVM, canta memoria se necesita realmente.
— Non sei con certeza se estamos probando algo no lado do fluxo, pero recordo que houbo problemas cos transcodificadores cando fixemos reunións. Probamos os fluxos?
Artyom: Probado iterativamente. Organización de encontros. No proceso de organización de encontros, houbo aproximadamente 2300 entradas de JIRA. Son cousas xenéricas que a xente fixo para facer encontros. Levamos partes da plataforma a unha páxina separada para reunións, que foi dirixida por Kirill Tolkachev ().
Para ser honesto, non houbo grandes problemas. Literalmente un par de veces detectamos erros de almacenamento na caché en CloudFront, solucionámolo con bastante rapidez: simplemente reconfiguramos as políticas. Houbo moito máis erros nas persoas, nos sistemas de transmisión do sitio.
Durante as conferencias, tiven que escribir a varios exportadores máis para cubrir máis equipos e servizos. Nalgúns lugares tiven que facer as miñas propias bicicletas só por mor das métricas. O mundo do hardware AV (audio-vídeo) non é moi bo: tes algún tipo de "API" de equipos que simplemente non podes influír. E está lonxe de ser un feito que poderás obter a información que necesitas. Os provedores de hardware son moi lentos e é case imposible obter o que queres deles. En total hai máis de 100 pezas de hardware, non devolven o que necesitas e escribes exportadores estraños e redundantes, grazas aos cales podes polo menos depurar o sistema dalgún xeito.
Оборудование
— Lembro como antes do comezo das conferencias compramos parcialmente equipos adicionais.
Artyom: Compramos ordenadores, portátiles e baterías. Polo momento podemos vivir sen electricidade durante 40 minutos. En xuño houbo fortes tormentas en San Petersburgo, polo que tivemos un apagón. Ao mesmo tempo, varios provedores chegan a nós con enlaces ópticos desde distintos puntos. Estes son realmente 40 minutos de inactividade do edificio, durante os cales teremos luces acesas, son, cámaras, etc. funcionando.
— Temos unha historia semellante con Internet. Na oficina onde están os nosos estudos, arrastramos unha feroz rede entre os pisos.
Artyom: Temos 20 Gbit de fibra entre pisos. Máis ao longo dos pisos, nalgún lugar hai óptica, nalgún lugar non hai óptica, pero aínda así hai menos canles que as de gigabit: publicamos nelas vídeos entre as pistas da conferencia. En xeral, é moi cómodo traballar na túa propia infraestrutura; raramente podes facelo en conferencias fóra de liña nos sitios.
— Antes de traballar en JUG Ru Group, vin como se configuraban durante a noite as salas de hardware nas conferencias fóra de liña, onde había un gran monitor con todas as métricas que se crean en Grafana. Agora tamén hai unha sala da sede na que se asenta o equipo de desenvolvemento, que durante a conferencia corrixe algúns erros e desenvolve funcións. Ao mesmo tempo, hai un sistema de vixilancia que se mostra nunha pantalla grande. Artyom, Kolya e outros rapaces séntanse e asegúranse de que todo non caia e funcione moi ben.
Curiosidades e problemas
— Falou ben do feito de que temos streaming con Amazon, que hai un reprodutor coa web, que todo está escrito en diferentes linguaxes de programación, que se proporciona tolerancia a fallos e outros requisitos comerciais, incluída unha conta persoal compatible con persoas xurídicas e individuos e podemos integrarnos con alguén que use OAuth 2.0, hai bloqueo de usuarios e antifraude. Podemos implementar cambios de forma dinámica porque o fixemos ben e todo está probado.
Estou interesado en saber cales son as rarezas que implicaron para comezar algo. Houbo algunha situación estraña cando estabas a desenvolver un backend, un frontend, algo tolo resultou e non entendías que facer con el?
Vladimir: Paréceme que isto só pasou nos últimos tres meses. Tódolos días. Como podes ver, todo o meu cabelo foi tirado.
Vladimir Krasilshchik despois de 3 meses, cando se produciu algún tipo de xogo e ninguén entendeu que facer con el
Todos os días había algo así, cando había un momento en que o tomas e te arrincas o pelo, ou te dás conta de que non hai ninguén, e só ti podes facelo. O noso primeiro gran evento foi TechTrain. O 6 de xuño ás 2 a.m. aínda non lanzaramos o ambiente de produción, Kolya estaba a lanzalo. E a conta persoal non funcionaba como servidor de autorización mediante OAuth2.0. Convertémolo nun provedor OAuth2.0 para conectar a plataforma a el. Estiven traballando probablemente 18 horas seguidas, mirei o ordenador e non vin nada, non entendín por que non funcionaba e Kolya mirou o meu código de xeito remoto, buscou un erro na configuración de Spring. , atopouno, e o LC funcionou, e tamén na produción.
Nikolay: E unha hora antes de TechTrain produciuse o lanzamento.
Aquí aliñaron moitas estrelas. Tivemos moita sorte porque tiñamos un súper equipo, e todos estaban inspirados coa idea de facelo en liña. Todos estes tres meses impulsounos o feito de "facer YouTube". Non me permitín arrincarme o pelo, pero díxenlle a todos que todo ía saír, porque de feito, todo estaba calculado hai tempo.
Sobre o rendemento
— Podes dicirme cantas persoas había no sitio nunha pista? Houbo algún problema de rendemento?
Nikolay: Non houbo problemas de rendemento, como xa dixemos. O número máximo de persoas que asistiron a un informe foi de 1300 persoas, isto está en Heisenbug.
— Houbo algún problema coa visualización local? E é posible ter unha descrición técnica con diagramas de como funciona todo?
Nikolay: Máis adiante faremos un artigo sobre isto.
Incluso podes depurar emisións localmente. Unha vez que comezaron as conferencias, foi aínda máis fácil, porque apareceron fluxos de produción que podemos ver todo o tempo.
Vladimir: Segundo entendo, os desenvolvedores front-end traballaron localmente con simulacros, e despois, dado que o tempo para lanzar aos desenvolvedores na fronte tamén é curto (5 minutos), non hai problemas para comprobar o que está a pasar cos certificados.
— Todo é probado e depurado, incluso localmente. Isto significa que escribiremos un artigo con todas as características técnicas, amosarémosche, contarémosche todo con diagramas, como foi.
Vladimir: Podes collelo e repetilo.
- En 3 meses.
Total
— Todo o que se describe en conxunto soa xenial, tendo en conta que o fixo un equipo pequeno en tres meses.
Nikolay: Un gran equipo non faría isto. Pero un pequeno grupo de persoas que se comunican moi ben entre si e poden chegar a un acordo. Non teñen contradicións, a arquitectura inventouse en dous días, finalizou e non cambiou realmente. Hai unha facilitación moi estrita dos requisitos comerciais entrantes en termos de acumulación de solicitudes e cambios de funcións.
— ¿Cal estaba na súa lista de tarefas adicionais cando xa tiñan lugar as xornadas de verán?
Nikolay: Por exemplo, créditos. Liñas progresivas no vídeo, ventás emerxentes nalgúns lugares do vídeo dependendo do contido que se mostra. Por exemplo, o orador quere facer unha pregunta á audiencia e aparece un voto na pantalla, que volve á parte traseira en función dos resultados da votación ao propio orador. Algún tipo de actividade social en forma de gústame, corazóns, valoracións do informe durante a propia presentación, para que poidas cubrir os comentarios no momento oportuno sen que te distrairán despois os formularios de comentarios. Inicialmente así.
E tamén engadindo a toda a plataforma, agás o streaming e a conferencia, tamén un estado posterior á conferencia. Estas son listas de reprodución (incluídas as compiladas polos usuarios), posiblemente contido doutras conferencias pasadas, integradas, etiquetadas, accesibles para o usuario e tamén dispoñibles para a súa visualización no noso sitio web ().
- Rapaces, moitas grazas polas vosas respostas!
Se entre os lectores hai quen asistiu ás nosas xornadas de verán, por favor comparta as vosas impresións sobre o xogador e a emisión. Que era conveniente, que che irritaba, que che gustaría ver no futuro?
Se estás interesado na plataforma e queres vela "en batalla", volvémola usar no noso . Hai unha gran variedade deles, polo que case seguro que hai un axeitado para ti.
Fonte: www.habr.com