Visitei recentemente o DevOpsForum 2019 hospedado pela Logrocon. Nesta conferência, os participantes tentaram encontrar soluções e novas ferramentas para a interação eficaz de empresas e especialistas nos serviços de desenvolvimento e tecnologia da informação.
A conferência foi um sucesso: havia realmente muitos relatórios úteis, formatos de apresentação interessantes e muita comunicação com os palestrantes. E é especialmente importante que ninguém tente me vender nada, do que os palestrantes de grandes conferências ultimamente culparam.
Espremendo dos discursos do Raiffeisenbank, Alfastrakhovanie, a experiência da Mango Telecom na implementação da automação e outros detalhes sob o corte.
Meu nome é Yana, trabalho como testador, estou envolvido em automação, bem como DevOps e adoro ir a conferências e reuniões. Nos últimos dois anos, participei das conferências de Oleg Bunin (HighLoad ++, TeamLead Conf), eventos de jarros (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Antes de tudo, presto atenção ao programa da conferência. Em menor grau, olho para o que será o relatório, em maior medida - para o orador. Mesmo que o relatório seja muito tecnológico e interessante, não é fato que você poderá aplicar algumas práticas recomendadas do relatório em sua empresa. E então você precisa de um alto-falante.
Luz no final do gasoduto em Raiffeisenbank
Normalmente, procuro oradores interessantes à margem. No DevOpsForum 2019, um palestrante do Raiffeisenbank, Mikhail Bizhan, entrou no meu campo de interesse. Durante o discurso, ele contou como eles estão plantando constantemente suas equipes no DevOps, por que precisam e como vender a idéia da transformação do DevOps para os negócios. Bem, em geral, eu falei sobre como ver a luz no final do pipeline.
Mikhail Bizhan, diretor de automação do RaiffeisenbankAgora, a empresa deles não tem "DevOps". Ou seja, ele é verdade, mas não em todas as equipes. Ao implementar o DevOps, eles contam com a disposição das equipes, tanto do ponto de vista de engenheiros específicos, quanto do ponto de vista das necessidades do produto e da maturidade da plataforma na qual esse produto é construído. Misha contou como explicar à empresa por que o DevOps é necessário.
O segmento bancário possui 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 fator muito bom, mas o crescimento da base de clientes é o contrário. Se os concorrentes produzem um produto objetivamente legal, todos os clientes vão para lá, com o tempo o mercado se iguala. Portanto, o lançamento de novos produtos no mercado e a velocidade de seu lançamento são a principal coisa pela qual os bancos são guiados. É exatamente para isso que o DevOps é, e a empresa entende isso.
A seguinte observação importante: O DevOps nem sempre reduz o tempo de colocação no mercado. O DevOps não pode funcionar sozinho, é apenas parte do processo de criação e lançamento de um produto no mercado, do desenvolvimento à produção (do código ao cliente). Mas tudo antes do código não tem relação direta com o DevOps. Ou seja, os profissionais de marketing podem estudar o mercado por anos e acompanhar os concorrentes por toda a vida. Você precisa entender rapidamente o que o cliente precisa e planejar a implementação de um recurso específico - geralmente isso não é suficiente para o DevOps funcionar e a empresa alcançar o objetivo. Portanto, antes de tudo, o Raiffeisenbank concordou com a empresa que era necessário aprender a usar o DevOps. A automação em prol da automação não ajudará muito na luta por novos clientes.
Em geral, Misha acredita que o DevOps deve ser implementado, mas com sabedoria. E você deve estar preparado para o fato de que, no início da transformação, a equipe perderá produtividade, ganhará menos dinheiro, mas se tornará realidade.
Automação de Testes na Mango Telecom
Yegor Maslov, da Mango Telecom, fez outro relatório interessante para mim como testador. A apresentação foi denominada "Automação do ciclo completo de testes na equipe SCRUM". Egor acredita que o DevOps foi criado especificamente para o SCRUM, mas, ao mesmo tempo, a introdução do DevOps na equipe do SCRUM é bastante problemática. Isso ocorre porque a equipe do SCRUM está sempre funcionando em algum lugar, não há tempo para se distrair com as inovações e reconstruir o processo. O problema também está no fato de que o SCRUM não implica sub-equipes (equipe de testadores, equipe de desenvolvimento etc.). Além disso, é necessária documentação para automatizar o processo existente e, na SCRUM, na maioria das vezes não há documentação - “um produto é mais importante do que algum tipo de rabisco”.
Após a mudança para o SCRUM, os testadores começaram a consultar os desenvolvedores sobre como testar os recursos. Gradualmente, o volume de funcionalidade aumentou, a documentação estava faltando e eles começaram a detectar muitos erros na funcionalidade em que não havia cobertura de teste e, em geral, não estava mais claro quem e quando a testou. Em poucas palavras - confusão e cambalhota. Decidimos mudar para a automação de testes. Mas então houve uma falha completa. Eles atraíram especialistas terceirizados para automação que escreviam em uma pilha desconhecida pelos testadores regulares. A estrutura de autoteste certamente funcionou, mas depois que os terceirizados saíram, ele viveu por duas semanas. Depois, houve uma tentativa de introduzir o autoteste número dois. Tudo começou com o fato de que tudo precisa ser construído dentro da empresa, por si só (o vetor certo: aumentar a experiência dentro), dentro da estrutura do SCRUM e no processo de criação de documentação. A pilha para automação deve ser igual à pilha do produto (aqui vou direcionar mais, bem, não teste seu projeto em JavaScript com mais nada). No final do sprint, eles organizaram uma demonstração de como o autoteste funciona, com a participação de toda a equipe (útil). Assim, aumentou o envolvimento de todos os membros da equipe no processo de automação, a confiança nos autotestes e a chance de que esse autoteste seja usado com precisão (e não será comentado em um mês devido a falhas constantes).
A propósito, um microfone aberto funcionou no DevOpsForum 2019 - um formato de performances conhecido e, na minha opinião, útil. Você caminha assim, ouve os relatórios e decide que vale a pena discutir um tópico ou problema dentro da estrutura da conferência e compartilhar experiências relevantes na solução do problema.
Também notei que os organizadores fizeram um fluxo de relatórios curtos. Cada relatório não dura mais que 10 minutos e, em seguida, surgem perguntas. Assim, você pode abordar muitos tópicos de uma só vez e incomodar as perguntas dos palestrantes interessados.
Entre os relatórios, eu andei pelas arquibancadas dos parceiros da conferência e puxei / ganhei muitas coisas. Eh, eu amo razdatku!Mesa-redonda e perguntas sobre o DevOps com o Alfastrah Development Director
A cereja do bolo do DevOpsForum 2019 para mim foi uma sessão plenária de uma hora com especialistas em DevOps. Quatro participantes foram convidados a assistir DevOps de diferentes ângulos: Anton Isanin (Alfastrakhovanie, Diretor de Desenvolvimento), Naila Zamashkina (Fintech Lab, Diretor de Operações), Oleg Egorkin (Rostelecom, Agile-coach) e Anton Martyanov (independente especialista, analisou o DevOps da perspectiva dos negócios).
Os especialistas sentaram-se mais perto das pessoas e tudo começou: por uma hora os participantes da platéia fizeram suas perguntas e os especialistas bufaram. Às vezes, saía um debate real. As perguntas eram muito diferentes, por exemplo: se os engenheiros do DevOps são necessários, por que você não pode aumentá-los dos administradores de sistema, se o DevOps deve ser oferecido a todos, qual é o seu valor e assim por diante.
Então, conversei com Anton Isanin pessoalmente. Discutimos a necessidade de levar a cultura do DevOps para todos os lares e revelamos o lado sombrio da transformação do DevOps.
Imagine que todos se reuniram e decidiram que o DevOps é necessário tanto para o produto quanto para os negócios e a equipe. Apressado para apresentar. Tudo deu certo. Exalado. O DevOps nos aproximou do cliente, agora podemos satisfazer rapidamente todos os seus desejos. Como resultado, temos uma grande divisão de operações com regulamentos e requisitos estritos, e constantemente descobre defeitos no produto, cria um monte de aplicativos. Além disso, todos os defeitos vêm com o status de "urgente", mesmo que o cliente repentinamente quisesse pintar o botão em amarelo em vez de verde. O projeto está crescendo, o número de lançamentos está aumentando e, consequentemente, o número de defeitos e mal-entendidos de novas funcionalidades pelos clientes. Ops contrata outras 10 pessoas para acompanhar os defeitos, e o desenvolvimento contrata outras 15 para acompanhá-los. E, em vez de introduzir novos recursos, a equipe trabalha com SD intermináveis, explicando a funcionalidade ao usuário e dando suporte a um. Como resultado, o Ops e o desenvolvimento estão trabalhando, mas o cliente e os negócios estão descontentes: novos recursos ficam parados. Acontece que o DevOps parece estar lá, mas não parece estar.
Sobre a necessidade de implementar o DevOps, Anton afirmou inequivocamente que isso depende diretamente da escala dos negócios. Se a manutenção de um cliente por ano gerar um bilhão de dólares para a empresa - o DevOps não será necessário (desde que você não precise lançar novas alterações nesse cliente regularmente). Tudo é tão chocolate. Mas se o negócio cresce, mais clientes aparecem, então já devemos estar em conformidade. Como regra, a empresa não tem operações legais inicialmente. Primeiro vimos o produto e só então entendemos que o produto deve funcionar, é preciso olhar para os servidores, monitorar as entregas. Então Ops surge. Resta entender que a Ops, como uma unidade separada, começará a expor um monte de barreiras ao desenvolvimento e todas as entregas começarão a parar. Ou seja, nesse caso, a cultura DevOps já é relevante, mas você não deve esquecer seu lado sombrio.