Em 7 de dezembro, a terceira conferência do
DevOpsDays Moscow foi organizada pela comunidade do Moscow DevOps com o apoio do Mail.ru Cloud Solutions. Além dos relatórios dos principais profissionais de DevOps, os participantes puderam participar de palestras relâmpago motivadoras, workshops e bate-papo em espaços abertos.
Reunimos informações importantes de seis apresentações e conduzimos entrevistas com vários oradores para descobrir o que ficou de fora dos relatórios.
Dentro:
- Baruch Sadogursky, JFrog: “Deixe o software fluir do fornecedor para o usuário, como um líquido”
- Pavel Selivanov, Southbridge: “Dev e Ops têm uma tarefa comum - criar um produto que funcione”
- Vladimir Utratenko, X5 Retail Group: “DevOps in Enterprise é desenvolvimento sem dores e incêndios”
- Sergey Puzyrev, Facebook: “O engenheiro de produção cuida do serviço como um todo: para que usuários e desenvolvedores se sintam bem”
- Mikhail Chinkov, AMBOSS: "Uma unidade não pode seguir o caminho do DevOps, toda a empresa deve segui-lo"
- Entusiastas do DevOps do Rosbank: "1000 dias para implementar o DevOps na sangrenta empresa"
1. Baruch Sadogursky, JFrog: "Deixe o software fluir do fornecedor para o usuário, como um líquido"
As falhas na atualização do software acontecem a cada hora e para todos. Aqui está apenas uma história assustadora do discurso: a Knight Capital perdeu US $ 440 milhões por hora após uma atualização malsucedida.
Baruch falou sobre os padrões de DevOps de atualizações contínuas que ajudarão a evitar falhas e ódio do usuário:
Reversão local - mantenha a versão anterior do software no dispositivo para reverter em caso de algo. Isso o protegerá se tudo estiver tão ruim que você não poderá enviar o patch pelo ar.
As atualizações aéreas são melhores e contínuas. Será diferente, como nos desenvolvedores da Jaguar: por causa de um bug no sistema de freio que não pôde ser atualizado por via aérea, foi necessário recuperar os carros da venda. Foi doloroso e caro.
Atualizações contínuas - atualize o software continuamente assim que um novo recurso estiver pronto. Com atualizações raras, os recursos são agrupados, uma atualização crítica pode esperar por atualizações não críticas. Como em Tesla, uma atualização que deveria consertar a frenagem aleatória aguardava a atualização do jogo de xadrez.
Implantação automatizada - substitua pessoas por máquinas, porque as pessoas não sabem como executar ações de rotina.
Atualizações frequentes - ajude a desenvolver um hábito e a se livrar do medo. Atualizações raras se transformam em um evento de emergência.
Conhecimento do estado do dispositivo - atualizações de teste, não instalação do zero. Isso é importante, pois as atualizações podem se comportar de maneira diferente, dependendo do estado do dispositivo.
Canary releases - implemente atualizações para um pequeno número de usuários e assista. Isso reduz os danos se algo der errado.
Atualizações sem inacessibilidade - permita que os clientes percebam apenas novos recursos e não permaneçam sem serviço por várias semanas até que você implante a atualização.
Conversamos com Baruch Sadogursky sobre como as perspectivas do DevOps diferem nas TI russa e ocidental, se a Cloud fará tudo por nós em breve e se todos os serviços de software entrarão no esquema aaS - veja a entrevista:
2. Pavel Selivanov, Southbridge: “Dev e Ops têm uma tarefa comum - criar um produto que funcione”
A implementação do Kubernetes não ajudará a alcançar o DevOps e até vice-versa - ele pode quebrar tudo. Pavel disse por que as tecnologias (mesmo as mais legais) não podem resolver todos os seus problemas:
A complexidade do projeto foi além do código . Anteriormente, havia uma aplicação complexa: interação dentro do projeto e desenvolvimento complexo, mas uma estrutura simples - o administrador implantado, tudo funciona. Mudamos para microsserviços: cada serviço é uma aplicação simples, comunicação usando protocolos padrão e desenvolvimento rápido, mas a estrutura do projeto se tornou mais complicada. A complexidade do projeto com a arquitetura de microsserviço não desapareceu - foi além do código. Agora, o engenheiro do DevOps é responsável por isso.
Os desenvolvedores não desejam alterações após a implementação do DevOps . Como resultado, o fluxo de trabalho com o Kubernetes continua parecendo jogar tarefas do Dev para Ops através de uma parede, mas não é mais metafórico - o Git se torna uma parede. O desenvolvedor coloca o código lá e funciona como antes, e os administradores têm Kubernetes, CI / CD e tudo mais.
No entanto, os desenvolvedores precisam aceitar as alterações . A situação em que os desenvolvedores não sabem o que os administradores fazem e os administradores não sabem o que está acontecendo com os desenvolvedores cria problemas.
Se os desenvolvedores não mudaram nada, eles não percebem que o trabalho do aplicativo é de sua responsabilidade - diferentes truques técnicos não funcionarão.
Com o advento do DevOps e Kubernetes, muita coisa mudará no desenvolvimento. O desenvolvedor deve ser competente em operações e vice-versa. Esses especialistas têm suas próprias habilidades específicas, mas devem estar cientes do trabalho um do outro. Dev e Ops precisam ser amigos antes de implementar o Kubernetes, caso contrário, você quebrará o que é.
Pavel Selivanov falou sobre o que acontecerá com a Kubernetes em 5 anos e sobre o que construir uma pilha tecnológica para uma startup moderna - veja a entrevista:
3. Vladimir Utratenko, X5 Retail Group: “DevOps in Enterprise é desenvolvimento sem dores e incêndios”
As empresas entram na transformação do DevOps quando percebem que o desenvolvimento é muito lento e não atende à realidade, elas desejam desenvolver-se melhor e implementar mais rapidamente.
Vladimir contou como isso acontece e qual é o problema:
- Primeiro, as empresas contratam um engenheiro de DevOps. Este é um administrador de sistema sênior, ele está envolvido na implantação do lançamento na produção, padronização do ambiente de desenvolvimento, configuração da infraestrutura, detecção e correção de vários problemas, automação de processos e outras tarefas técnicas.
- Então, um engenheiro de DevOps não é mais suficiente e a empresa contrata uma equipe de DevOps. Este é um centro de competência, que organiza os esforços de engenheiros diferentes, permite que você os concentre em uma direção.
- De fato, o engenheiro do DevOps e as equipes do DevOps são os antipadrões das transformações do DevOps. Como o DevOps trata de práticas e cultura, além disso, existem implementações do DevOps em empresas de tecnologia (SRE, Engenharia de Produção).
O que fazer? A contratação de uma equipe temporária de DevOps para ajudar a implementar a transformação do DevOps continuará com práticas, cultivará uma cultura de desenvolvimento e uma cultura tecnológica.
Quando uma empresa entra no jogo e investe no DevOps, vários cenários são possíveis: tudo desmorona na decolagem; permanecerá como SRE / Engenharia de Produção ou Operações Incorporadas; passará para o BizOps quando os processos se basearem nas métricas de negócios.
Vladimir Utratenko nos contou o quanto os DevOps "sangrentos" na empresa realmente são e como as práticas estão sendo implementadas nas grandes lojas de varejo - veja a entrevista:
4. Sergey Puzyrev, Facebook: “O engenheiro de produção cuida do serviço como um todo: para que usuários e desenvolvedores se sintam bem”
O Facebook é uma empresa enorme, com muitos componentes, servidores, pessoas, data centers. Apesar de seu tamanho imenso, é muito rápido - os desenvolvedores podem lançar serviços muitas vezes ao dia. O Facebook também está crescendo rapidamente, e não se trata apenas do aumento do número de usuários e servidores, o número de desenvolvedores também está aumentando, o que complica os processos.
Sergey contou o que o engenheiro de produção está fazendo no Facebook:
- O Engenheiro de Produção codifica muito, deve ter conhecimento do sistema: sistemas operacionais, sistemas de arquivos, bancos de dados, redes e similares. Deve ter experiência com sistemas distribuídos e Engenharia de Confiabilidade, ou seja, no suporte à confiabilidade do produto. Ele deve estar de plantão, ou seja, disponível para ligar a qualquer momento.
- O engenheiro de produção difere do engenheiro de software em habilidades avançadas em operação, mas, de fato, é uma subespécie de engenheiro de software. Engenheiro de software codificam mais, eles podem ter habilidades adicionais relacionadas, por exemplo, ao processamento de dados. No Facebook, esses especialistas também devem estar de plantão, o que para muitos é uma surpresa desagradável.
- A pirâmide de necessidades do engenheiro de produção da empresa começa com o monitoramento dos servidores e seu ciclo de vida, ou seja, recebendo novo hardware, configurando-o e colocando-o em operação. O próximo nível é o mesmo no nível de serviço: serviços de monitoramento e seu ciclo de vida. Em seguida, vem a escala perfeita e o monitoramento avançado. Eles mudam para o dimensionamento automático após o ciclo de vida útil ser automatizado. E, no final, você precisa fazer o ajuste para que o dimensionamento seja eficaz, a empresa economiza dinheiro e recursos.
5. Mikhail Chinkov, AMBOSS: "Uma unidade não pode seguir o caminho do DevOps, toda a empresa deve segui-lo"
Michael acredita que o DevOps é um desenvolvimento contínuo. Você não pode apresentar nenhuma ferramenta e parar por aí. Quais problemas impedem as empresas de se tornarem DevOps e como implementar práticas?
Diferença no entendimento do DevOps . Os devops canônicos, como os evangelistas veem, repousam em 5 pilares:
- cultura - foco nas pessoas e colaboração;
- automação - delegação de rotina ao fluxo de trabalho;
- lean - ênfase na entrega de valor ao usuário;
- compartilhamento - compartilhamento contínuo de conhecimento;
- métricas e obter feedback com a ajuda deles.
As empresas geralmente se concentram apenas na automação e na entrega de valor ao usuário. Mas a cultura, o compartilhamento de conhecimento e as métricas de DevOps, pelas quais você pode acompanhar o desenvolvimento, seguem o caminho.
Problemas de padronização do DevOps . As metas do produto são diferentes para todas as empresas, não podem ser padronizadas. O estado dos DevOps na empresa depende da própria empresa, mas muitos não entendem isso e acreditam que é suficiente contratar um engenheiro de DevOps.
Por que ainda não somos DevOps? Existem duas questões principais. Na empresa - o lento desenvolvimento da organização, a dificuldade de mudar o vetor na cabeça de milhares de funcionários. Nas startups, há uma falta de fontes de conhecimento, um problema com a alocação de recursos para transformação.
Fases de desenvolvimento do DevOps na empresa :
- o primeiro é a infraestrutura na nuvem, mas ninguém sabe como funciona, exceto um ou dois administradores;
- o segundo - a infraestrutura é transparente e compreensível para todos os engenheiros, mas os processos não são colocados em operação;
- o terceiro - os engenheiros lançam e reparam independentemente serviços ao vivo;
- o quarto - os engenheiros, se assim o desejarem, contribuirão para a infraestrutura principal, código transparente na nuvem, implantação de botões.
O esquema ideal - todos têm o mesmo acesso à infraestrutura, todos os engenheiros têm acesso ao produto e entendem o que estão fazendo.
Fechando toda a gestalt cultural e técnica, a transformação de DevOps da empresa levará em consideração o feedback das métricas de negócios e métricas da plataforma.
6. Entusiastas do DevOps do Rosbank: "1000 dias para implementar o DevOps na sangrenta empresa"
Yuri Bulich, Dina Maltseva e Eugene Pankov, de Rosbank, contaram como chegaram ao DevOps em três anos. Havia dois objetivos: resolver problemas específicos em equipes específicas e implementar ferramentas centralizadas.
Aqui estão os resultados alcançados:
Resultados para equipes de produtos : montagem 30 vezes mais rápida, instalação 6 vezes mais rápida, economia de até 30% em um ciclo completo. Tivemos a oportunidade de rolar o botão para o produtivo
Resultados para equipes de plataforma : a montagem e instalação são 10 vezes mais rápidas, o número de instalações aumentou 87%, a cobertura com autoteste é de 46%. A equipe de integração deixou de ser um gargalo
Então, como implementar práticas de DevOps na empresa sangrenta?
Primeiro, apresente um projeto piloto : escolha equipes, decida como implementar a arquitetura e escolha ferramentas. Escolhemos ferramentas com uma licença aberta, com a instalação no banco e a experiência em trabalhar com elas. No Rosbank, junto com a plataforma DevOps, uma nuvem privada foi implantada, o que ajudou no início. Na nuvem, era possível obter os recursos necessários por um botão em 15 minutos, antes esse processo poderia levar uma semana.
Em bancos e outras empresas, você precisa resolver as restrições com a equipe de segurança da informação com antecedência e encontrar uma solução que permita implementar as alterações.
Após o piloto, uma solução bem-sucedida deve ser escalada .
- É importante "endireitar" o transportador o máximo possível, eliminando links desnecessários, destacar os fornecedores de valor e remover os componentes restantes. Intermediários são antipadrões. Por exemplo, em Rosbank, várias equipes não tiveram desenvolvimento interno, apenas externas permaneceram. Isso levou ao surgimento de uma equipe dedicada de DevOps, que forneceu a transferência de código de desenvolvedores externos para internos. O problema foi resolvido com a integração do desenvolvimento externo ao CI / CD, para que eles não apenas transferissem o código deles mesmos para o banco, mas também fossem responsáveis por seu sucesso.
- Os elementos da prática do DevOps foram incluídos no modelo de maturidade, as ferramentas foram listadas e os recursos de trabalho com fornecedores externos foram levados em consideração - no futuro, isso ajudou a reduzir rapidamente o atraso de tarefas quando implementado em novas equipes.
- A governança é necessária na forma de controle e recomendações suaves. O Manual do DevOps funciona bem - é um conjunto de características organizacionais e instrumentais que ajudam as equipes a usar a plataforma corretamente.
- Vale a pena prestar atenção imediatamente à cultura, então muitas mudanças serão mais rápidas e fáceis. Cresça a comunidade interna, realize reuniões, oficinas técnicas, treinamentos, atividades divertidas. Dá frutos: as pessoas compartilham suas práticas, veem quem fez o que, sabem para onde se virar, há hype e concorrência saudável dentro da empresa.
- Não faz sentido trabalhar com aqueles que não estão envolvidos no processo, com equipes que não estão maduras; é melhor investir em equipes interessadas e pessoas leais.
- A solução selecionada deve ser conveniente para os engenheiros que a utilizam.
- O desenvolvimento externo não é um bloqueador, você também pode implementar práticas por lá, o principal é que a própria equipe tenha um desejo.
Um pouco mais bom
A lista de livros que devem ser lidos para quem está no DevOps, de Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Vontade e autocontrole".
- Daniel Kahneman "Pensando, rápido e devagar".
- Barbara Oakley "Uma mente para números".
- Maxim Dorofeev "Técnicas Jedi".
- Viktor Frankl "A busca do homem pelo significado".
Fique atento
Também amamos o DevOps. Siga os anúncios das séries @DevOps e @Kubernetes, bem como outros eventos Mail.ru Cloud Solutions, em nosso canal Telegram:
t.me/k8s_mail