Recentemente estive no DevOpsForum 2019, organizado pela Logrocon. Nesta conferência, os participantes tentaram encontrar soluções e novas ferramentas para uma interação eficaz entre negócios e profissionais de desenvolvimento e suporte técnico.
A conferência foi um sucesso: houve muitos palestras úteis, formatos de apresentação interessantes e uma abundância de interações com os palestrantes. E, especialmente importante, ninguém tentou me vender nada, algo que os palestrantes em grandes conferências têm feito ultimamente.
Resumo das apresentações do Raiffeisen Bank, Alpha Insurance, a experiência da Mango Telecom na implementação de automação e outros detalhes abaixo.
Meu nome é Yana, sou testadora, trabalho com automação, também me envolvo com DevOps e adoro ir a conferências e meetups. Nos últimos dois anos, estive nas conferências de Oleg Bunin (HighLoad++, TeamLead Conf), nos eventos Jug (Heisenbug, JPoint), no TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Primeiramente, presto atenção à programação da conferência. Olho menos para o que será apresentado e mais para o palestrante. Mesmo que a apresentação seja altamente técnica e interessante, não é garantido que você consiga aplicar alguma das melhores práticas discutidas na sua empresa. E então você precisa do palestrante.
A luz no fim do pipeline no Raiffeisen Bank
Normalmente, costumo caçar palestrantes que me interessam nos bastidores. No DevOpsForum 2019, um dos meus interesses foi o palestrante do Raiffeisen Bank — Mikhail Bijan. Durante sua apresentação, ele contou como a empresa está progressivamente integrando suas equipes no DevOps, por que isso é necessário e como vender a ideia de transformação DevOps para o negócio. E, em geral, falou sobre como ver a luz no fim do pipeline.
Mikhail Bijan, diretor de automação no Raiffeisen Bank
Atualmente, em sua empresa, não existe um 'verdadeiro DevOps'. Ou seja, ele é verdadeiro, mas não em todas as equipes. Ao implementar o DevOps, eles se baseiam na prontidão das equipes, tanto do ponto de vista dos engenheiros específicos quanto da necessidade do produto e da maturidade da plataforma na qual esse produto está construído. Misha explicou como explicar ao negócio por que o DevOps é necessário.
O segmento bancário tem vários fatores de crescimento: o custo dos serviços e a expansão da base de clientes. Aumentar o custo dos serviços não é um bom fator, mas o crescimento da base de clientes, por outro lado, é positivo. Se os concorrentes lançam um produto realmente bom, todos os clientes vão para lá, e depois, com o tempo, o mercado se estabiliza. Portanto, o lançamento de novos produtos e a velocidade com que são lançados é o principal foco dos bancos. É exatamente para isso que o DevOps é necessário, e o negócio entende isso.
Um próximo ponto importante: o DevOps nem sempre reduz o time to market. O DevOps não pode funcionar sozinho; é apenas uma parte do processo de criação e lançamento de um produto no mercado, desde o desenvolvimento até a produção (do código ao cliente). Mas tudo o que está antes do código não tem relação direta com o DevOps. Ou seja, os profissionais de marketing podem passar anos estudando o mercado e ainda assim levar a vida toda para alcançar os concorrentes. É necessário entender rapidamente o que o cliente precisa e planejar a implementação de certas funcionalidades — muitas vezes é exatamente isso que falta para que o DevOps funcione e a empresa alcance seus objetivos. Portanto, em primeiro lugar, no Raiffeisenbank, foi acordado com os negócios que era necessário aprender a usar o DevOps. Automatizar por automatizar não ajudará muito na luta por novos clientes.
Em geral, Misha acredita que o DevOps deve ser implementado, mas com sabedoria. E é preciso estar preparado para o fato de que, no início da transformação, a equipe terá queda na produtividade, ganhará menos dinheiro, mas depois isso valerá a pena.
Automatização de testes na 'Mango Telecom'
Mais uma apresentação interessante para mim como testador foi feita por Eгор Маслов da «Манго Телеком». A apresentação se chamava «Automatização do ciclo completo de testes na equipe SCRUM». Егор acredita que o DevOps foi criado exatamente para o SCRUM, mas, ao mesmo tempo, implementar DevOps em uma equipe SCRUM é bastante problemático. Isso acontece porque a equipe SCRUM está sempre correndo, não há tempo para desviar a atenção para inovações e reestruturar o processo. O problema também reside no fato de que o SCRUM não prevê a criação de sub-equipes (equipe de testadores, equipe de desenvolvedores, etc.). Além disso, para automatizar o processo existente, é necessária documentação, e no SCRUM, muitas vezes, a documentação está completamente ausente — "o produto é mais importante do que qualquer papelada".
Após a transição para o SCRUM, os testadores começaram a consultar os desenvolvedores sobre como testar as funcionalidades. Gradualmente, o volume de funcionalidades aumentou, a documentação estava ausente e eles começaram a encontrar muitos bugs naquela funcionalidade que não tinha cobertura de testes e, na verdade, já não estava claro quem e quando a testou. Em poucas palavras — desordem. Eles decidiram passar para a automação de testes. Mas mesmo assim houve um completo falhanço. Eles contrataram especialistas de outsourcing para a automação, que programavam em uma pilha desconhecida para os testadores internos. O framework para testes automatizados, claro, funcionou, mas após a saída dos terceirizados, ele sobreviveu apenas duas semanas. Depois, houve uma tentativa de introduzir a automação de testes número dois. Essa começou com a necessidade de construir tudo internamente, com as próprias forças (o vetor correto: aumente a expertise interna), no âmbito do SCRUM, e criar documentação durante o processo. A pilha para automação deve ser igual à pilha do produto (aqui, assino embaixo; não testem um projeto em JavaScript com outra coisa). No final do sprint, eles faziam uma demo de como funcionava o autoteste, com a participação de toda a equipe (útil). Assim, aumentava o envolvimento de todos os membros da equipe no processo de automação, bem como a confiança nos autotestes e a chance de que esse autoteste fosse realmente utilizado (e não fosse comentado após um mês devido a falhas constantes).
Aliás, na DevOpsForum 2019 houve um microfone aberto — um formato de apresentação bem conhecido e, na minha opinião, útil. Você anda por aí, escuta as palestras, e depois decide que é hora de discutir um tema ou problema ou compartilhar experiências relevantes sobre como resolver uma tarefa.
Eu também notei que os organizadores fizeram um fluxo de apresentações curtas. Cada apresentação dura no máximo 10 minutos, seguidas de perguntas. Assim, conseguimos abordar muitos temas de uma só vez e fazer perguntas aos palestrantes que nos interessaram.
Entre as palestras, dei uma volta pelos estandes dos parceiros da conferência e ganhei muita coisa legal. Ah, como eu adoro brindes!
Mesa-redonda e perguntas sobre DevOps com o diretor de desenvolvimento da AlfaStrakhovanie.
A cereja do bolo da DevOpsForum 2019 para mim foi a sessão plenária de uma hora com especialistas em DevOps. Foram convidados quatro participantes que deveriam analisar o DevOps de diferentes perspectivas: Anton Isanin (AlfaStrakhovanie, diretor de desenvolvimento), Nailya Zamashkina (Fintech Lab, diretora operacional), Oleg Yegorkin (Rostelecom, Agile coach) e Anton Martyano (especialista independente, olhando para o DevOps do ponto de vista dos negócios).
Os especialistas se aproximaram do público e começou a festa: por uma hora, os participantes da plateia fizeram suas perguntas, enquanto os especialistas se esforçavam para responder. Às vezes, surgiam verdadeiros debates. As perguntas eram as mais variadas, por exemplo: precisamos mesmo de engenheiros DevOps, por que não é possível formá-los a partir de administradores de sistemas, devemos oferecer DevOps a todos, qual é seu valor e assim por diante.
Depois disso, conversei pessoalmente com Anton Isanin. Discutimos a necessidade de levar a cultura DevOps a cada lar e revelamos o lado obscuro da transformação DevOps.
Vamos imaginar que todos se reuniram e decidiram que DevOps é necessário tanto para o produto quanto para os negócios e a equipe. Começaram a implementar. Tudo funcionou. Respiração aliviada. O DevOps nos aproximou do cliente, agora podemos atender rapidamente todos os seus pedidos. No final, temos um grande departamento de Ops com regulamentos e requisitos rigorosos, e ele está constantemente criando defeitos no produto, gerando uma infinidade de solicitações. E todos os defeitos têm o status de "urgente", mesmo que o cliente inesperadamente quisesse pintar um botão de amarelo em vez de verde. O projeto cresce, o número de lançamentos aumenta e, consequentemente, o número de defeitos e a falta de compreensão das novas funcionalidades por parte dos clientes também aumentam. Ops contrata mais 10 pessoas para conseguir reportar os defeitos, enquanto a equipe de desenvolvimento contrata mais 15 para conseguir fechá-los. E em vez de implementar novas funcionalidades, a equipe trabalha com intermináveis SDs, explicando as funcionalidades ao usuário e também ao suporte. No final, tanto Ops quanto desenvolvimento estão ocupados, mas o cliente e os negócios estão insatisfeitos: novas funcionalidades ficam paradas. Ou seja, parece que existe DevOps, mas na verdade não.
Quanto à necessidade de implementar DevOps, Anton declarou categoricamente que isso depende diretamente da escala do negócio. Se atender um único cliente por ano traz um bilhão para a empresa, o DevOps não é necessário (desde que não seja preciso lançar novas mudanças para esse cliente regularmente). Tudo está no caminho certo. Mas se o negócio cresce e surgem mais clientes, é preciso se adequar. Geralmente, a empresa não tem um Ops competente desde o início. Primeiro, desenvolvemos o produto e só depois percebemos que, para o produto funcionar, precisamos acompanhar as entregas. servidores, monitorar as fornecimentos. É aí que surge o Ops. Resta entender que o Ops, como um departamento separado, começará a estabelecer inúmeras barreiras para o desenvolvimento e todas as entregas começarão a patinar. Ou seja, neste caso, a cultura DevOps já é relevante, apenas precisamos não esquecer seu lado obscuro.
Fonte: habr.com
