Na véspera do DevOps Conf Russia 2018, conversamos com o diretor técnico do Uchi.ru, Alexei Vakhov, sobre os estágios do desenvolvimento da plataforma, quais ferramentas eles usam e quanto o ovo do DevOps existe.
Alexey Vakhov - Diretor Técnico do Uchi.ru. Ele trabalhou como desenvolvedor de C ++ em grandes sistemas (dezenas de milhões de linhas de código). Tecnologia de servidor favorita - Ruby on Rails, está entre os 100 principais colaboradores. Ele gosta da organização de produção, operação, arquitetura de aplicativos da Web.
O Uchi.ru é uma plataforma educacional russa na qual os alunos das séries 1 a 11 estudam as disciplinas escolares de maneira divertida e divertida. A plataforma é usada por mais de 2,5 milhões de estudantes e 220 mil professores na Rússia, EUA, Brasil, Índia, África do Sul e China. É o 36º lugar no ranking global de plataformas de e-learning. A empresa possui mais de 400 funcionários.- Como tudo começou? Quantas pessoas estavam na empresa quando você chegou?- Fui convidado para a empresa em 2012, ou seja, seis anos atrás. Naquela época, eu era o quinto ou sexto funcionário e o único desenvolvedor. Eu digitei e desenvolvi o servidor. Criamos o primeiro aplicativo da Web e o publicamos no Heroku.
"Como estão as coisas agora?" Quantas equipes e quais tamanhos? Quão independente? Como eles interagem entre si?- Hoje temos mais de 400 pessoas, das quais cerca de 100 são engenheiros que estão unidos em cerca de 20 equipes separadas. Temos duas grandes direções: desenvolvimento da produção e desenvolvimento de tarefas interativas.
As equipes individuais têm seu próprio ambiente isolado, sistemas especiais de construção, aprimorados para as tarefas que a equipe executa, seus próprios servidores, códigos-fonte. Eles se comunicam apenas quando necessário.
- Com essa taxa de crescimento da empresa, você consegue criar seu próprio wiki? Como você a apoia?- Temos várias bases de conhecimento. Existe um wiki na forma de confluência, onde há seções gerais e temáticas, e cada equipe tem sua própria seção. Em cada repositório, oferecemos suporte a leia-me e white papers adicionais. De qualquer forma, cada equipe recebe seu próprio espaço, sua própria peça em jira, na confluência, tudo isso organizado de acordo com os desejos da equipe. Não temos um ditado e padronização no design.
- Um aumento acentuado está repleto de perda de controle. Como você lida com isso? Como você coordena o trabalho de tantas equipes?- A coordenação geral é alcançada através da construção de uma hierarquia de gerenciamento. Temos coordenadores de indicação e cada equipe tem seu próprio líder. Tudo é simples aqui.
Se você responder a essa pergunta do ponto de vista da tecnologia, as equipes aderem às regras gerais, por exemplo, os testes são conectados a cada repositório, todo o desenvolvimento vai para novas ramificações, que são verificadas, implementadas no ambiente de teste e depois na produção.
- Quais etapas da formação da empresa você destaca por si mesmo?- Gosto da abordagem que li em um livro interessante, segundo o qual a crise ocorre quando o sistema usual de valores entra em colapso. No nosso caso, devido a um crescimento tão rápido das crises, houve muitas crises e cada uma delas determina o movimento adicional.
A primeira crise ocorreu quando ficamos apertados em um quarto e tivemos que expandir para dois. Nesta fase, surgiram informações que deixaram de ser conhecidas por todos. A segunda e subsequente crise ocorreu quando os desenvolvedores tiveram que se dividir em equipes de produtos. Novamente, nossa grande e amigável equipe foi forçada a se separar e participar de diferentes ângulos.
Quaisquer mudanças que ocorreram conosco foram necessariamente apoiadas por inovações tecnológicas oportunas e relevantes. O mesmo vale para a metodologia DevOps. Podemos dizer que eu mesmo recentemente comecei a entender o que são valores culturais e por que são importantes em grandes equipes. Por exemplo, houve um tempo em que ninguém tinha uma pergunta sobre quem é responsável pela estabilidade do site. Todos entendiam que quem fazia o serviço era responsável por ele. Contratamos uma pessoa que deveria ser responsável apenas pelo servidor - e o confronto "desenvolvedores versus administradores" começou no mesmo dia. Foi incrível, como um livro.
- Conte-me mais sobre cada uma das etapas. Quais ferramentas você tomou para si, quais você teve que abandonar? Pelo que entendi, desde o anúncio de seu desempenho no DevOpsConf 2018, toda a sua infraestrutura é implantada nas nuvens em contêineres de encaixe. Por que você chegou a essa decisão? Desde quando você não poderia viver sem contêineres?- No começo não havia nada, nem mesmo um rastreador. Lançamento apenas para Heroku: git push, e todos estão felizes. Mas Heroku rapidamente deixou de nos satisfazer, já que havia muito ping antes, e eles não toleravam a carga. Mudamos para servidores regulares de ferro e contratamos consultores. Com o tempo, o servidor está cheio de lixo. A essa altura, aumentamos bastante o tráfego, o número de produção, serviços internos e externos. Configuramos servidores através do Chef. Um belo dia, caímos sob carga e à noite nos mudamos para a nuvem usando o Ansible. A sensação de mudar para Ansible era apenas cósmica. Acabou sendo simples e compreensível, especialmente no caso de pequenas infra-estruturas.
Começando com aproximadamente 60 aplicativos, nossa infraestrutura se tornou separada, como os chamamos de "sites". São nuvens isoladas com suas próprias sub-redes, com suas próprias formas de terra e configurações ansíveis.
Com o crescente número de aplicativos e servidores, nossa configuração começou a flutuar, pois há muitas coisas a considerar antes de iniciar um aplicativo simples no RoR. Além disso, parte da configuração de lançamento estava no repositório com o aplicativo, parte nas receitas de conjunto, os desenvolvedores começaram a usar magia secreta, criar links para pastas, algum tipo de sincronização. Como resultado, tornou-se completamente impossível de manter.
Quando tivemos cerca de cem aplicativos em nuvens diferentes, começamos a examinar mais de perto o docker. Isso foi no verão passado. Em cerca de 10 meses, transferimos todos os nossos aplicativos e, nessa época, havia cerca de 150 deles em clusters de docker. Isso se tornou uma verdadeira salvação para nós. Fomos poupados do monitoramento de versões e fragmentos de ambientes nos servidores. Tudo se tornou muito mais conveniente e mais simples: o aplicativo poderia ser facilmente colocado em um cluster de docker, facilmente removido de lá, tinha sua própria meta-informação, da qual fica claro em quais serviços o aplicativo consiste, quais coroas, trabalhos em segundo plano e assim por diante são iniciados.
- Com que firmeza você está na abordagem original do DevOps? Tudo combina com você ou você mudou algo por si mesmo? Foi difícil reconstruir a equipe?- Eu mesmo não tenho uma resposta exata para a pergunta sobre o que é DevOps. No trabalho, eu sempre procedo do simples senso comum. E as pessoas dizem que acontece que aqui o DevOps cresceu. Na verdade, quase não preciso da parte teórica do DevOps, porque a empresa me pede resultados. Em outras palavras, se eu lhes disser lindamente e não fizer nada, será muito ruim, e se eu fizer, mas não contar sobre beleza, será bom de qualquer maneira.
Meu entendimento do DevOps é o seguinte. Por exemplo, há uma grande empresa que deseja fabricar ou já está fabricando produtos digitais. Os produtos digitais são sempre um feedback rápido do mercado. A entrega contínua ocorre automaticamente, os limites entre desenvolvimento e suporte são borrados, a cultura do DevOps está sendo reforçada, o que interpreta as regras de boa forma entre as pessoas responsáveis pela implementação, teste e suporte. Como resultado, esses relacionamentos permitem que eles concordem entre si para alcançar um objetivo comum, além de mudar o foco de suas responsabilidades pessoais para um resultado comum. Em uma empresa grande e bem estabelecida, ocorrem mudanças nos processos, sua quebra.
Como não tínhamos uma empresa bem estabelecida, crescemos rapidamente os princípios de trabalho. Além disso, os negócios constantemente nos lançavam novas tarefas, por isso construímos nossa infraestrutura principalmente com base no senso comum e nos requisitos internos.
A palavra DevOps significava pouco para mim. Mas agora, quando passamos por tudo isso, quando vi o surgimento de pontos de conflito, a confusão de responsabilidades, percebi que o DevOps é como um aspecto cultural da interação entre as pessoas com um objetivo comum. E os objetivos comuns dos produtos digitais são criar novos recursos e lançá-los o mais rápido possível.
- Seria interessante saber como é difícil para iniciantes ingressar no seu trabalho com tantas ferramentas modernas. Como é organizado o seu trabalho com as pessoas?- Temos programas de adaptação. Falamos ao novo funcionário sobre como desenvolvemos e como tudo está organizado agora, anexamos um mentor a ele. No primeiro dia, ajudamos ele a criar o ambiente e a combater, mas não uma tarefa muito difícil. O mentor o acompanha por vários meses, ajuda na adaptação.
- Conte-nos sobre os planos da empresa. Onde você planeja crescer e quais áreas desenvolver? A pilha de tecnologia atual fornece as bases para um crescimento adicional ou será necessário alterá-la novamente?- Os planos de negócios são ambiciosos. Hoje, mais de dois milhões de crianças em idade escolar frequentam regularmente o Uchi.ru, que representa cerca de 30% de todos os alunos da escola primária em todo o país. Continuaremos atraindo novos usuários para a plataforma na Rússia e nos engajando no desenvolvimento internacional.
Tecnicamente, temos 15 clusters de docker isolados e gastamos muito tempo trocando de um para outro, tornando-se difícil manter e atualizar. Os requisitos para velocidade de mudança e confiabilidade estão crescendo apenas. Portanto, há uma reserva, mas também vamos atualizar.
Amigos, se você estiver interessado na experiência de Alexey, nos apressamos em convidar para o
DevOps Conf Russia 2018 , que será realizado de 1 a 2 de outubro. Em seu relatório, ele falará sobre a experiência do uso de nuvens, o uso da metodologia DevOps, os valores e princípios de sua equipe.
Assine o Boletim Temático Ontiko DevOps para receber atualizações do programa assim que estiverem disponíveis. Tentamos tornar as cartas úteis e não invasivas, enviamos notícias da conferência, transcrições de relatórios e vídeos novos.
A propósito, o vídeo pode ser monitorado separadamente no canal do YouTube - há todos os vídeos coletados nos últimos anos e a lista é atualizada constantemente.