Nesta primavera nos encontramos em condições muito alegres. Devido à pandemia, ficou claro que as nossas conferências de verão precisavam de ser transferidas para online. E para conduzi-los online de forma eficiente, soluções de software prontas não eram adequadas para nós; precisávamos escrever as nossas próprias. E tivemos três meses para fazer isso.
Está claro que foram três meses emocionantes. Mas visto de fora não é totalmente óbvio: o que é uma plataforma de conferências online? Em que partes ele consiste? Portanto, na última conferência de verão do DevOops, perguntei aos responsáveis por esta tarefa:
- Nikolay Molchanov - diretor técnico do Grupo JUG Ru;
- Vladimir Krasilshchik é um programador Java pragmático que trabalha no backend (você também pode ver seus relatórios em nossas conferências Java);
- Artyom Nikonov é responsável por todo o nosso streaming de vídeo.
A propósito, nas conferências outono-inverno usaremos uma versão melhorada da mesma plataforma - muitos leitores do Habra ainda serão seus usuários.
Quadro geral
— Qual era a composição da equipe?
Nikolai Molchanov: Temos um analista, um designer, um testador, três front-ends e um back-end. E, claro, um especialista em formato de T!
— Como foi o processo em geral?
Nikolay: Até meados de março, não tínhamos nada pronto para online. E no dia 15 de março todo o carrossel online começou a girar. Montamos vários repositórios, planejamos, discutimos a arquitetura básica e fizemos tudo em três meses.
Isso, é claro, passou pelos estágios clássicos de planejamento, arquitetura, seleção de recursos, votação para esses recursos, política para esses recursos, seu design, desenvolvimento e testes. Como resultado, em 6 de junho, colocamos tudo em produção. . Foram 90 dias para tudo.
— Conseguimos cumprir o que nos comprometemos?
Nikolay: Como agora estamos participando online da conferência DevOops, significa que funcionou. Pessoalmente, me comprometi com o principal: levarei aos clientes uma ferramenta com a qual eles possam fazer uma conferência online.
O desafio era este: dar-nos uma ferramenta com a qual pudéssemos transmitir as nossas conferências aos portadores de bilhetes.
Todo o planejamento foi dividido em várias etapas, e todas as funcionalidades (cerca de 30 globais) foram divididas em 4 categorias:
- o que com certeza faremos (não podemos viver sem eles),
- o que faremos em segundo lugar,
- o que nunca faremos,
- e o que nunca, jamais faremos.
Criamos todos os recursos das duas primeiras categorias.
— Eu sei que foram criados um total de 600 problemas do JIRA. Em três meses você criou 13 microsserviços e suspeito que eles não foram escritos apenas em Java. Você usou tecnologias diferentes, tem dois clusters Kubernetes em três zonas de disponibilidade e 5 fluxos RTMP na Amazon.
Vejamos agora cada componente do sistema separadamente.
Transmissão
— Vamos começar quando já temos uma imagem de vídeo e ela está sendo transmitida para alguns serviços. Artyom, conte-nos como acontece esse streaming?
Artem Nikonov: Nosso esquema geral é assim: imagem da câmera -> nossa sala de controle -> servidor RTMP local -> Amazon -> player de vídeo. Mais detalhes em Habré em junho.
Em geral, existem duas maneiras globais de fazer isso: em hardware ou com base em soluções de software. Escolhemos a rota do software porque é mais fácil no caso de alto-falantes remotos. Nem sempre é possível levar hardware para um alto-falante de outro país, mas entregar software ao alto-falante parece mais fácil e confiável.
Do ponto de vista do hardware, temos um certo número de câmeras (em nossos estúdios e em alto-falantes remotos), um certo número de controles remotos no estúdio, que às vezes precisam ser consertados logo abaixo da mesa durante a transmissão.
Os sinais desses dispositivos entram em computadores com placas de captura, placas de entrada/saída e placas de som. Lá os sinais são misturados e montados em layouts:
Exemplo de layout para 4 alto-falantes
Exemplo de layout para 4 alto-falantes
Além disso, a transmissão contínua é fornecida com a ajuda de três computadores: há uma máquina principal e um par de máquinas em funcionamento. O primeiro computador coleta o primeiro relatório, o segundo - o intervalo, o primeiro - o próximo relatório, o segundo - o próximo intervalo e assim por diante. E a máquina principal mistura a primeira com a segunda.
Isso cria uma espécie de triângulo e, se algum desses nós falhar, podemos continuar entregando conteúdo aos clientes de forma rápida e sem perda de qualidade. Tivemos uma situação assim. Durante a primeira semana de conferências, consertamos uma máquina, ligamos/desligamos. As pessoas parecem estar felizes com a nossa resiliência.
Em seguida, os fluxos dos computadores vão para um servidor local, que tem duas tarefas: rotear fluxos RTMP e gravar backups. Portanto, temos vários pontos de gravação. Os streams de vídeo são então enviados para a parte do nosso sistema construída nos serviços Amazon SaaS. Nós usamos ,S3,CloudFront.
Nikolay: O que acontece antes do vídeo chegar ao público? Você tem que cortar de alguma forma, certo?
Artem: Comprimimos o vídeo de nossa parte e o enviamos para o MediaLive. Lançamos transcodificadores lá. Eles transcodificam vídeos em tempo real em diversas resoluções para que as pessoas possam assisti-los em seus telefones, na má Internet do país e assim por diante. Então esses fluxos são cortados em , é assim que o protocolo funciona . Enviamos uma lista de reprodução para o frontend que contém ponteiros para esses blocos.
— Estamos usando resolução 1080p?
Artem: A largura do nosso vídeo é igual a 1080p - 1920 pixels, e a altura é um pouco menor, a imagem é mais alongada - há razões para isso.
Jogador
— Artyom descreveu como o vídeo entra nos streams, como é distribuído em diferentes playlists para diferentes resoluções de tela, cortado em pedaços e colocado no player. Kolya, agora me diga que tipo de player é esse, como ele consome o stream, por que HLS?
Nikolay: Temos um player que todos os telespectadores podem assistir.
Essencialmente, este é um wrapper da biblioteca , no qual muitos outros jogadores estão escritos. Mas precisávamos de uma funcionalidade bem específica: retroceder e marcar o local onde a pessoa está, qual reportagem ela está assistindo no momento. Também precisávamos de nossos próprios layouts, todos os tipos de logotipos e tudo mais que foi construído conosco. Portanto, decidimos escrever nossa própria biblioteca (um wrapper sobre HLS) e incorporá-la no site.
Esta é a funcionalidade raiz, por isso foi implementada quase primeiro. E então tudo cresceu em torno disso.
Na verdade, através da autorização, o jogador recebe do backend uma playlist com links para pedaços correlacionados com tempo e qualidade, baixa os necessários e mostra-os ao usuário, realizando alguma “mágica” ao longo do caminho.
Exemplo de linha do tempo
— Um botão está embutido no player para exibir uma linha do tempo de todos os relatórios...
Nikolay: Sim, resolvemos imediatamente o problema de navegação do usuário. Em meados de abril, decidimos que não iríamos transmitir cada uma das nossas conferências num site separado, mas combinaríamos tudo num só. Para que os usuários do ingresso Full Pass possam alternar livremente entre as diferentes conferências: tanto transmissões ao vivo quanto gravações de conferências anteriores.
E para tornar mais fácil para os usuários navegar no stream atual e alternar entre faixas, decidimos criar um botão “Transmissão completa” e boletins horizontais para alternar entre faixas e relatórios. Existe controle de teclado.
— Houve alguma dificuldade técnica com isso?
Nikolay: Eles tinham uma barra de rolagem na qual estavam marcados os pontos de partida dos diferentes relatórios.
— No final, você implementou essas marcas na barra de rolagem antes do YouTube fazer algo semelhante?
Artem: Eles tinham isso em beta então. Parece que este é um recurso bastante complexo porque eles o testaram parcialmente com usuários no ano passado. E agora chegou à venda.
Nikolay: Mas na verdade conseguimos vendê-lo mais rápido. Honestamente, por trás desse recurso simples há uma enorme quantidade de backend, frontend, cálculos e matemática dentro do player.
A parte dianteira
— Vamos descobrir como esse conteúdo que a gente mostra (carta de fala, palestrantes, site, programação) chega ao front end?
Vladimir Krasilshchik: Temos vários sistemas internos de TI. Existe um sistema no qual todos os relatórios e todos os palestrantes são inseridos. Existe um processo pelo qual um palestrante participa de uma conferência. O palestrante envia uma inscrição, o sistema captura, então há um determinado pipeline segundo o qual o relatório é criado.
É assim que o palestrante vê o pipeline
Este sistema é o nosso desenvolvimento interno.
Em seguida, você precisa criar um cronograma a partir de relatórios individuais. Como você sabe, este é um problema NP-difícil, mas de alguma forma nós o resolvemos. Para fazer isso, lançamos outro componente que gera um cronograma e o carrega no serviço de nuvem de terceiros Contentful. Lá tudo parece uma tabela em que há dias de conferência, nos dias há horários, e nos horários há reportagens, intervalos ou atividades de patrocínio. Portanto, o conteúdo que vemos está localizado em um serviço de terceiros. E a tarefa é transmitir isso ao site.
Parece que o site é apenas uma página com um player, e não há nada complicado aqui. Exceto que não é. O backend por trás desta página vai para o Contentful, pega o cronograma de lá, gera alguns objetos e envia para o frontend. Através de uma conexão websocket, que todo cliente de nossa plataforma faz, enviamos a ele uma atualização da programação do backend para o frontend.
Caso real: o palestrante mudou de emprego logo durante a conferência. Precisamos mudar o crachá da empresa empregadora. Como isso acontece no back-end? Uma atualização é enviada a todos os clientes através do websocket e, em seguida, o próprio frontend redesenha a linha do tempo. Tudo isso acontece perfeitamente. A combinação do serviço cloud e vários dos nossos componentes dá-nos a oportunidade de gerar todo este conteúdo e disponibilizá-lo à frente.
Nikolay: É importante esclarecer aqui que nosso site não é um aplicativo clássico de SPA. Este é um site renderizado baseado em layout e um SPA. Na verdade, o Google vê este site como HTML renderizado. Isso é bom para SEO e para entregar conteúdo ao usuário. Ele não espera o carregamento de 1,5 megabytes de JavaScript antes de ver a página, ele vê imediatamente a página já renderizada e você sente isso toda vez que alterna o relatório. Tudo acontece em meio segundo, pois o conteúdo já está pronto e postado no lugar certo.
- Vamos traçar um limite para todos os itens acima, listando as tecnologias. Tyoma disse que temos 5 streams da Amazon e entregamos vídeo e som lá. Temos scripts bash lá, usamos eles para iniciar e configurar...
Artem: Isso acontece por meio da API da AWS, há muitos outros serviços técnicos lá. Dividimos nossas responsabilidades para que eu entregue para , e os desenvolvedores front-end e back-end partem daí. Temos várias ligações próprias para simplificar o layout do conteúdo, que depois fazemos em 4K, etc. Como os prazos eram muito apertados, fizemos isso quase inteiramente na AWS.
— Então tudo isso vai para o player usando o sistema backend. Temos TypeScript, React, Next.JS em nosso player. E no backend temos diversos serviços em C#, Java, Spring Boot e Node.js. Tudo isso é implantado usando Kubernetes usando a infraestrutura Yandex.Cloud.
Quero ressaltar também que quando precisei conhecer a plataforma acabou sendo fácil: todos os repositórios estão no GitLab, tudo está bem nomeado, os testes estão escritos, tem documentação. Ou seja, mesmo em modo de emergência eles cuidaram dessas coisas.
Restrições e análises de negócios
— Almejamos 10 usuários com base nos requisitos de negócios. É hora de falar sobre as restrições comerciais que tivemos. Tínhamos que garantir uma elevada carga de trabalho, garantir o cumprimento da lei de preservação de dados pessoais. E o que mais?
Nikolay: Inicialmente, partimos dos requisitos de vídeo. O mais importante é o armazenamento de vídeo distribuído em todo o mundo para entrega rápida ao cliente. Outros incluem resolução de 1080p, bem como retrocesso, que muitos outros não implementam no modo ao vivo. Posteriormente adicionamos a capacidade de habilitar velocidade 2x, com sua ajuda você pode “acompanhar” ao vivo e continuar assistindo à conferência em tempo real. E ao longo do caminho, apareceu a funcionalidade de marcação da linha do tempo. Além disso, tínhamos que ser tolerantes a falhas e suportar a carga de 10 mil conexões. Do ponto de vista de back-end, são aproximadamente 000 conexões multiplicadas por 10 solicitações para cada atualização de página. E isso já é 000 RPS/seg. Bastante.
— Houve algum outro requisito para uma “exposição virtual” com stands online de parceiros?
Nikolay: Sim, isso tinha que ser feito de forma rápida e universal. Tínhamos até 10 empresas parceiras para cada conferência, e todas elas precisavam ser concluídas em uma ou duas semanas. No entanto, o seu conteúdo difere ligeiramente no formato. Mas foi criado um certo mecanismo de modelo que monta essas páginas dinamicamente, praticamente sem nenhuma participação adicional no desenvolvimento.
— Havia também requisitos para análise de visualizações e estatísticas em tempo real. Eu sei que usamos o Prometheus para isso, mas conte-nos com mais detalhes: quais requisitos atendemos para análise e como isso é implementado?
Nikolay: Inicialmente, temos requisitos de marketing para coleta para testes A/B e coleta de informações para entender como entregar adequadamente o melhor conteúdo ao cliente no futuro. Também existem requisitos para algumas análises sobre atividades de parceiros e as análises que você vê (balcão de visitas). Todas as informações são coletadas em tempo real.
Podemos fornecer essas informações de forma agregada até mesmo para os palestrantes: quantas pessoas estavam assistindo você em um determinado momento. Ao mesmo tempo, para cumprir a Lei Federal 152, sua conta pessoal e seus dados pessoais não são rastreados de forma alguma.
A plataforma já conta com ferramentas de marketing e nossas métricas para medir em tempo real a atividade dos usuários (quem assistiu qual segundo do relatório) para construir gráficos de atendimento nos relatórios. Com base nesses dados, estão sendo feitas pesquisas que irão melhorar as próximas conferências.
Fraude
— Temos mecanismos antifraude?
Nikolay: Devido ao prazo apertado do ponto de vista comercial, a tarefa não foi inicialmente definida para bloquear imediatamente conexões desnecessárias. Se dois usuários fizessem login na mesma conta, eles poderiam visualizar o conteúdo. Mas sabemos quantas visualizações simultâneas houve de uma conta. E banimos vários violadores particularmente maliciosos.
Vladimir: Para seu crédito, um dos usuários banidos entendeu por que isso aconteceu. Ele veio, pediu desculpas e prometeu comprar uma passagem.
— Para que tudo isso aconteça, é preciso rastrear completamente todos os usuários desde a entrada até a saída, saber sempre o que estão fazendo. Como esse sistema funciona?
Vladimir: Gostaria de falar sobre análises e estatísticas, que depois analisamos para o sucesso do relatório ou podemos fornecer aos parceiros. Todos os clientes são conectados por meio de uma conexão websocket a um cluster backend específico. Está lá . Cada cliente em cada período envia o que está fazendo e qual trilha está acompanhando. Em seguida, essas informações são agregadas usando trabalhos rápidos do Hazelcast e enviadas de volta a todos que assistem a essas faixas. Vemos no canto quantas pessoas estão conosco agora.
As mesmas informações são armazenadas em e vai para o nosso data lake, a partir do qual temos a oportunidade de construir um gráfico mais interessante. Surge a pergunta: quantos usuários únicos visualizaram este relatório? Nós vamos para , há pings de todas as pessoas que acessaram o id deste relatório. Coletamos, agregamos itens únicos e agora podemos entender.
Nikolay: Mas, ao mesmo tempo, também recebemos dados do Prometheus em tempo real. É definido contra todos os serviços do Kubernetes, contra o próprio Kubernetes. Ele coleta absolutamente tudo e com o Grafana podemos construir qualquer gráfico em tempo real.
Vladimir: Por um lado, baixamos isso para processamento OLAP adicional. E para OLTP, o aplicativo baixa tudo para Prometheus, Grafana e os gráficos até convergem!
- Este é o caso quando os gráficos convergem.
Mudanças Dinâmicas
— Conte-nos como as mudanças dinâmicas são implementadas: se o relatório foi cancelado 6 minutos antes do início, qual é a cadeia de ações? Qual pipeline funciona?
Vladimir: O pipeline é muito condicional. Existem várias possibilidades. A primeira é que o programa de geração de cronograma funcionou e alterou o cronograma. A programação modificada é carregada no Contentful. Depois disso, o backend entende que há alterações para esta conferência no Contentful, pega-a e reconstrói-a. Tudo é coletado e enviado via websocket.
A segunda possibilidade, quando tudo acontece em um ritmo alucinante: o editor altera manualmente as informações no Contentful (link para Telegram, apresentação do palestrante, etc.) e funciona a mesma lógica da primeira vez.
Nikolay: Tudo acontece sem atualizar a página. Todas as alterações ocorrem de forma absolutamente integrada para o cliente. O mesmo se aplica à troca de relatórios. Quando chegar a hora, o relatório e a interface mudam.
Vladimir: Além disso, há limites de tempo para o início dos relatórios na linha do tempo. No começo não há nada. E se você passar o mouse sobre a faixa vermelha, em algum momento, graças ao diretor de transmissão, aparecerão cortes. O diretor define o início correto da transmissão, o backend capta essa alteração, calcula os horários de início e término de toda a apresentação da faixa de acordo com a programação da conferência, envia para nossos clientes e o jogador faz os cortes. Agora o usuário pode navegar facilmente até o início e o final do relatório. Era uma exigência comercial estrita, muito conveniente e útil. Você não perde tempo descobrindo a hora real de início do relatório. E quando fizermos uma prévia, será absolutamente maravilhoso.
Implantação
— Eu gostaria de perguntar sobre a implantação. Kolya e a equipe dedicaram muito tempo no início para montar toda a infraestrutura em que tudo se desenrola para nós. Diga-me, do que tudo isso é feito?
Nikolay: Do ponto de vista técnico, inicialmente tínhamos a exigência de que o produto fosse o mais abstrato possível de qualquer fornecedor. Venha para a AWS para criar scripts Terraform especificamente da AWS, ou especificamente do Yandex, ou do Azure, etc. realmente não se encaixava. Tivemos que nos mudar para algum lugar em algum momento.
Nas primeiras três semanas, procuramos constantemente uma maneira de fazer isso melhor. Como resultado, chegamos à conclusão de que o Kubernetes, neste caso, é tudo para nós, porque nos permite criar serviços com escalonamento automático, implementação automática e obter quase todos os serviços prontos para uso. Naturalmente, todos os serviços tiveram que ser treinados para trabalhar com Kubernetes, Docker, e a equipe também teve que aprender.
Temos dois clusters. Teste e produção. Eles são absolutamente idênticos em termos de hardware e configurações. Implementamos infraestrutura como código. Todos os serviços são implementados automaticamente em três ambientes: ramificações de recursos, ramificações principais, ramificações de teste e GitLab usando um pipeline automático. Isso é integrado ao máximo ao GitLab, integrado ao máximo ao Elastic, Prometheus.
Temos a oportunidade de implementar rapidamente (para back-end em 10 minutos, para front-end em 5 minutos) alterações em qualquer ambiente com todos os testes, integrações, execução de testes funcionais, testes de integração no ambiente e também testar com testes de carga em um ambiente de teste aproximadamente o mesmo que queremos obter na produção.
Sobre testes
— Você testa quase tudo, é difícil acreditar como você escreveu tudo. Você pode nos contar sobre os testes de back-end: quanto tudo é coberto, quais testes?
Vladimir: Dois tipos de testes foram escritos. Os primeiros são testes de componentes. Testes de nível de elevação de toda a aplicação da mola e base em . Este é um teste dos cenários de negócios de mais alto nível. Eu não testo funções. Testamos apenas algumas coisas grandes. Por exemplo, logo no teste é emulado o processo de login de um usuário, a solicitação do usuário de ingressos para onde ele pode ir e uma solicitação de acesso para assistir ao stream. Cenários de usuário muito claros.
Aproximadamente a mesma coisa é implementada nos chamados testes de integração, que na verdade são executados no ambiente. Na verdade, quando a próxima implantação na produção for lançada, cenários básicos reais também estarão em execução na produção. O mesmo login, solicitando tickets, solicitando acesso ao CloudFront, verificando se o stream realmente se conecta com minhas permissões, verificando a interface do diretor.
No momento tenho cerca de 70 testes de componentes e cerca de 40 testes de integração integrados. A cobertura está muito próxima de 95%. Isto é para os componentes, menos para os de integração, simplesmente não há tanta necessidade. Considerando que o projeto envolve todo tipo de geração de código, este é um indicador muito bom. Não havia outra maneira de fazer o que fizemos em três meses. Porque se testássemos manualmente, dando recursos para nossa testadora, e ela encontrasse bugs e os devolvesse para nós para correções, então essa viagem de ida e volta para depurar o código seria muito longa e não cumpriríamos nenhum prazo.
Nikolay: Convencionalmente, para realizar uma regressão em toda a plataforma ao alterar alguma função, é preciso sentar e fuçar em todos os lugares durante dois dias.
Vladimir: Portanto, é um grande sucesso quando estimo um recurso, digo que preciso de 4 dias para duas canetas simples e 1 websocket, Kolya permite. Ele já está acostumado com o fato de que esses 4 dias incluem 2 tipos de testes, e então, muito provavelmente, funcionará.
Nikolay: Também tenho 140 testes escritos: componente + funcional, que fazem a mesma coisa. Todos os mesmos cenários são testados em produção, em teste e em produção. Também adicionamos recentemente testes de UI básicos funcionais. Desta forma, cobrimos as funcionalidades mais básicas que podem falhar.
Vladimir: Claro, vale a pena falar sobre testes de carga. Foi necessário testar a plataforma sob uma carga próxima da real para entender como está tudo, o que está acontecendo com o Rabbit, o que está acontecendo com as JVMs, quanta memória é realmente necessária.
— Não sei ao certo se estamos testando alguma coisa no lado do stream, mas lembro que houve problemas com transcodificadores quando fizemos encontros. Testamos os streams?
Artem: Testado iterativamente. Organização de encontros. No processo de organização dos meetups, foram gerados aproximadamente 2300 tickets do JIRA. Essas são apenas coisas genéricas que as pessoas faziam para marcar encontros. Colocamos partes da plataforma em uma página separada para encontros, dirigida por Kirill Tolkachev ().
Para ser honesto, não houve grandes problemas. Literalmente, algumas vezes, detectamos bugs de cache no CloudFront e resolvemos isso rapidamente - simplesmente reconfiguramos as políticas. Houve significativamente mais bugs nas pessoas, nos sistemas de streaming do site.
Durante as conferências, tive que escrever a vários outros exportadores para cobrir mais equipamentos e serviços. Em alguns lugares, tive que fabricar minhas próprias bicicletas apenas por uma questão de métrica. O mundo do hardware AV (áudio e vídeo) não é muito otimista - você tem algum tipo de “API” de equipamento que simplesmente não pode influenciar. E está longe de ser verdade que você conseguirá obter as informações de que precisa. Os fornecedores de hardware são muito lentos e é quase impossível conseguir o que deseja deles. No total são mais de 100 peças de hardware, elas não devolvem o que você precisa e você escreve exportadores estranhos e redundantes, graças aos quais você pode pelo menos de alguma forma depurar o sistema.
Оборудование
— Lembro-me de que, antes do início das conferências, adquirimos parcialmente equipamentos adicionais.
Artem: Compramos computadores, laptops e baterias. Neste momento podemos viver sem electricidade durante 40 minutos. Em junho, ocorreram fortes tempestades em São Petersburgo - então tivemos um grande apagão. Ao mesmo tempo, vários provedores chegam até nós com links ópticos de diversos pontos. Na verdade, são 40 minutos de inatividade do edifício, durante os quais teremos luzes acesas, som, câmeras, etc.
— Temos uma história semelhante com a Internet. No escritório onde ficam nossos estúdios, arrastamos uma rede feroz entre os andares.
Artem: Temos 20 Gbit de fibra entre andares. Mais adiante nos andares, em algum lugar há ótica, em algum lugar não há ótica, mas ainda há menos canais do que os de gigabit - rodamos vídeo neles entre as faixas da conferência. Em geral, é muito conveniente trabalhar em sua própria infraestrutura, raramente você pode fazer isso em conferências offline em sites.
— Antes de trabalhar no JUG Ru Group, vi como eram montadas salas de hardware em conferências offline durante a noite, onde havia um grande monitor com todas as métricas que você constrói no Grafana. Agora existe também uma sala sede onde fica a equipe de desenvolvimento, que durante a conferência corrige alguns bugs e desenvolve funcionalidades. Ao mesmo tempo, existe um sistema de monitoramento que é exibido em uma tela grande. Artyom, Kolya e outros caras sentam-se e garantem que tudo não caia e funcione perfeitamente.
Curiosidades e problemas
— Você falou bem sobre o fato de termos streaming com a Amazon, existe um player com a web, tudo é escrito em diferentes linguagens de programação, tolerância a falhas e outros requisitos de negócios são fornecidos, incluindo uma conta pessoal que é suportada para pessoas jurídicas e indivíduos, e podemos integrar com alguém usando OAuth 2.0, existe antifraude, bloqueio de usuários. Podemos implementar as alterações dinamicamente porque fizemos isso bem e tudo foi testado.
Estou interessado em saber quais esquisitices estavam envolvidas no início de algo. Já houve alguma situação estranha quando você estava desenvolvendo um backend, frontend, algo maluco aconteceu e você não entendeu o que fazer com isso?
Vladimir: Parece-me que isso só aconteceu nos últimos três meses. Diariamente. Como você pode ver, todo o meu cabelo foi arrancado.
Vladimir Krasilshchik depois de 3 meses, quando algum tipo de jogo apareceu e ninguém entendeu o que fazer com ele
Todos os dias acontecia algo assim, quando chegava um momento em que você pegava e arrancava os cabelos, ou percebia que não há mais ninguém, e só você pode fazer isso. Nosso primeiro grande evento foi o TechTrain. No dia 6 de junho, às 2h, ainda não havíamos implementado o ambiente de produção, Kolya estava implementando. E a conta pessoal não funcionou como servidor de autorização usando OAuth2.0. Nós o transformamos em um provedor OAuth2.0 para conectar a plataforma a ele. Eu estava trabalhando provavelmente há 18 horas seguidas, olhei para o computador e não vi nada, não entendi porque não estava funcionando, e Kolya olhou meu código remotamente, procurou por um bug na configuração do Spring , encontrei, e o LC funcionou, e em produção também .
Nikolay: E uma hora antes do TechTrain acontecer o lançamento.
Muitas estrelas estavam alinhadas aqui. Tivemos muita sorte porque tínhamos uma super equipe e todos se inspiraram na ideia de fazer online. Durante todos esses três meses fomos motivados pelo fato de termos “criado o YouTube”. Não me permiti arrancar os cabelos, mas disse a todos que tudo daria certo, porque na verdade tudo já estava calculado há muito tempo.
Sobre desempenho
— Você pode me dizer quantas pessoas estavam no site em uma faixa? Houve algum problema de desempenho?
Nikolay: Não houve problemas de desempenho, como já dissemos. O número máximo de pessoas que compareceram a uma reportagem foi de 1300 pessoas, isto é, no Heisenbug.
— Houve algum problema com a visualização local? E é possível ter uma descrição técnica com diagramas de como tudo funciona?
Nikolay: Faremos um artigo sobre isso mais tarde.
Você pode até depurar streams localmente. Depois que as conferências começaram, ficou ainda mais fácil, porque surgiram fluxos de produção que podemos assistir o tempo todo.
Vladimir: Pelo que entendi, os desenvolvedores front-end trabalharam localmente com simulações e, como o tempo de implementação para os desenvolvedores na frente também é curto (5 minutos), não há problemas em verificar o que está acontecendo com os certificados.
— Tudo é testado e depurado, mesmo localmente. Isso significa que vamos escrever um artigo com todas as características técnicas, mostrar, contar tudo com diagramas, como foi.
Vladimir: Você pode pegar e repetir.
- Em 3 meses.
Total
— Tudo descrito em conjunto parece legal, considerando que foi feito por uma equipe pequena em três meses.
Nikolay: Uma grande equipe não faria isso. Mas um pequeno grupo de pessoas que se comunicam bem e de perto umas com as outras e podem chegar a um acordo, poderia. Não têm contradições, a arquitetura foi inventada em dois dias, foi finalizada e não mudou de fato. Há uma facilitação muito estrita dos requisitos de negócios recebidos em termos de acumulação de solicitações e alterações de recursos.
— O que estava na sua lista de tarefas adicionais quando as conferências de verão já haviam ocorrido?
Nikolay: Por exemplo, créditos. Linhas rastejantes no vídeo, pop-ups em alguns lugares do vídeo dependendo do conteúdo que está sendo mostrado. Por exemplo, o palestrante quer fazer uma pergunta ao público, e uma votação aparece na tela, que volta para trás com base nos resultados da votação para o próprio palestrante. Algum tipo de atividade social na forma de curtidas, corações, avaliações do relatório durante a própria apresentação, para que você possa preencher o feedback no momento certo sem se distrair posteriormente com os formulários de feedback. Inicialmente assim.
E também agregando a toda a plataforma, exceto streaming e conferência, também um estado pós-conferência. São playlists (incluindo aquelas compiladas pelos usuários), possivelmente conteúdos de outras conferências anteriores, integradas, rotuladas, acessíveis ao usuário, e também disponíveis para visualização em nosso site ().
— Pessoal, muito obrigado pelas respostas!
Se entre os leitores houver quem tenha participado de nossas conferências de verão, compartilhe suas impressões sobre o player e a transmissão. O que foi conveniente, o que te irritou, o que você gostaria de ver no futuro?
Se você se interessou pela plataforma e quer vê-la “em batalha”, voltamos a utilizá-la em nosso . Há uma grande variedade deles, então é quase certo que haja um que seja certo para você.
Fonte: habr.com