Recentemente participei do DevOpsForum 2019, organizado pela Logrocon. Nesta conferência, os participantes procuraram encontrar soluções e novas ferramentas para uma interação eficaz entre especialistas em negócios e desenvolvimento e serviços de tecnologia da informação.
A conferência foi um sucesso: houve muitos relatórios úteis, formatos de apresentação interessantes e muita comunicação com os palestrantes. E é especialmente importante que ninguém tenha tentado me vender nada, algo de que os palestrantes em grandes conferências têm sido culpados ultimamente.
Um trecho dos discursos do Raiffeisenbank, Alfastrakhovanie, a experiência da Mango Telecom na implementação de automação e outros detalhes em destaque.
Meu nome é Yana, trabalho como testador, faço automação, além de DevOps, e adoro ir a conferências e encontros. Nos últimos dois anos, estive em conferências de Oleg Bunin (HighLoad++, TeamLead Conf), eventos Jug (Heisenbug, JPoint), TestCon Moscou, DevOps Pro Moscou, Big Data Moscou.
Em primeiro lugar, chamo a atenção para o programa da conferência. Olho menos para o tema do relatório e mais para o orador. Mesmo que o relatório se revele muito tecnológico e interessante, não é fato que você conseguirá aplicar algumas das melhores práticas do relatório em sua empresa. E então você precisa de um alto-falante.
Luz no fim do gasoduto no Raiffeisenbank
Normalmente, procuro palestrantes paralelos que me interessam. No DevOpsForum 2019, um palestrante do Raiffeisenbank, Mikhail Bizhan, despertou meu interesse. Durante seu discurso, ele falou sobre como eles estão gradualmente prendendo suas equipes ao DevOps, por que precisam dele e como vender a ideia da transformação do DevOps para os negócios. Bem, em geral, falei sobre como ver a luz no fim do pipeline.
Mikhail Bizhan, diretor de automação do Raiffeisenbank
Agora eles não têm “DevOps” em sua empresa. Ou seja, ele funciona, mas não em todas as equipes. Ao implementar DevOps, contam com a prontidão das equipes, tanto em termos de engenheiros específicos, quanto em termos da necessidade do produto e da maturidade da plataforma sobre a qual este produto é construído. Misha contou como explicar a uma empresa por que o DevOps é necessário.
O segmento bancário possui diversos drivers de crescimento: custo dos serviços prestados e expansão da base de clientes. Aumentar o custo dos serviços não é um factor muito bom, mas aumentar a base de clientes é o oposto. Se os concorrentes lançam um produto objetivamente interessante, todos os clientes vão para lá e, com o tempo, o mercado se estabiliza. Portanto, a introdução de novos produtos no mercado e a velocidade de sua introdução é o principal foco dos bancos. É exatamente para isso que serve o DevOps, e as empresas entendem isso.
A próxima observação importante: o DevOps nem sempre reduz o tempo de lançamento no mercado. O DevOps não pode funcionar sozinho, é apenas 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 antes do código não está diretamente relacionado ao DevOps. Ou seja, os profissionais de marketing podem estudar o mercado durante anos e passar a vida inteira alcançando os concorrentes. É preciso entender rapidamente o que o cliente precisa e planejar a implementação deste ou daquele recurso – muitas vezes é isso que não é suficiente para o DevOps funcionar e a empresa atingir seu objetivo. Portanto, em primeiro lugar, o Raiffeisenbank concordou com as empresas que era necessário aprender a usar o DevOps. A automação pela automação não ajudará muito na briga por novos clientes.
Em geral, Misha acredita que o DevOps precisa ser implementado, mas com sabedoria. E devemos estar preparados para o fato de que no início da transformação a produtividade da equipe vai cair, vai ganhar menos dinheiro, mas depois vai se justificar.
Automação de testes na Mango Telecom
Outro relatório interessante para mim como testador foi dado por Egor Maslov da Mango Telecom. A apresentação foi chamada “Automação do ciclo completo de testes em uma equipe SCRUM”. Egor acredita que o DevOps foi criado especificamente para SCRUM, mas, ao mesmo tempo, introduzir o DevOps em uma equipe SCRUM é bastante problemático. Isso acontece porque o time SCRUM está sempre correndo em algum lugar, não há tempo para se distrair com inovações e reconstruir o processo. O problema também reside no fato de que o SCRUM não envolve a separação de subequipes da equipe (equipe de teste, equipe de desenvolvimento e assim por diante). Bem, além disso, para automatizar um processo existente, é necessária documentação, e no SCRUM, na maioria das vezes, não há documentação completa - “o produto é mais importante do que algum tipo de escrita”.
Depois de mudar para o SCRUM, os testadores começaram a consultar os desenvolvedores sobre como testar os recursos. Aos poucos, o volume de funcionalidades aumentou, não havia documentação e começaram a detectar muitos bugs na funcionalidade que não eram cobertos pelos testes e em geral não estava mais claro quem testou e quando. Em poucas palavras - confusão e vacilação. Decidimos mudar para a automação de testes. Mas mesmo assim houve um fracasso total. Eles contrataram especialistas terceirizados em automação que escreviam em uma pilha desconhecida pelos testadores internos. A estrutura para autotestes funcionou, é claro, mas depois que os terceirizados saíram, durou duas semanas. A seguir foi 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 conta própria (o vetor certo: construir expertise internamente), dentro do framework SCRUM, e criar documentação no processo. A pilha para automação deve ser igual à pilha do produto (aqui estou adicionando, não teste seu projeto JavaScript com mais nada). No final do sprint, eles fizeram uma demonstração de como funciona o autoteste com toda a equipe (útil). Assim, aumentou 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 seja definitivamente utilizado (e não seja comentado em um mês devido a falhas constantes).
A propósito, no DevOpsForum 2019 houve um microfone aberto - um formato de discurso há muito conhecido e, na minha opinião, útil. Você anda assim, ouve relatos e depois decide que na conferência vale a pena discutir determinado tema ou problema, compartilhando experiências relevantes na solução do problema.
Notei também que os organizadores fizeram uma série de relatórios curtos. Cada relatório não dura mais de 10 minutos, seguido de perguntas. Dessa forma, você pode cobrir muitos tópicos ao mesmo tempo e fazer perguntas aos palestrantes de seu interesse.
Entre as apresentações, andei pelos estandes dos parceiros da conferência e roubei/ganhei muitas coisas. Ah, adorei a apostila!
Mesa redonda e questões DevOps com o diretor de desenvolvimento da Alfastrakhovanie
A cereja do bolo do DevOpsForum 2019 para mim foi a sessão plenária de uma hora com especialistas em DevOps. Quatro participantes da sessão foram convidados a olhar para o DevOps de diferentes ângulos: Anton Isanin (Alfastrakhovanie, diretor de desenvolvimento), Nailya Zamashkina (Fintech Lab, diretor operacional), Oleg Egorkin (Rostelecom, treinador Agile) e Anton Martyanov (especialista independente, olhou para DevOps do ponto de vista empresarial).
Os especialistas sentaram-se mais perto das pessoas e então as coisas começaram a acontecer: durante uma hora inteira, os participantes da plateia fizeram suas perguntas e os especialistas levaram a culpa. Às vezes havia debates reais. As perguntas eram muito diferentes, por exemplo: os engenheiros de DevOps são necessários, por que eles não podem ser treinados como administradores de sistema, o DevOps deve ser oferecido a todos, qual é o seu valor e assim por diante.
Depois conversei pessoalmente com Anton Isanin. Discutimos a necessidade de levar a cultura DevOps a todas as casas e revelamos o lado negro da transformação do DevOps.
Vamos imaginar que todos se reuniram e decidiram que o DevOps é necessário tanto para o produto quanto para o negócio e a equipe. Vamos implementá-lo. Tudo deu certo. Nós exalamos. O DevOps nos aproximou do cliente, agora podemos atender rapidamente todos os seus desejos. Como resultado, temos um grande departamento de operações com regulamentos e requisitos rígidos, que constantemente encontra defeitos no produto e cria uma série de solicitações. Além disso, todos os defeitos recebem o status “urgente”, mesmo que o cliente inesperadamente queira colorir o botão de amarelo em vez de verde. O projeto está crescendo, o número de lançamentos e, consequentemente, o número de defeitos e mal-entendidos de novas funcionalidades por parte dos clientes. O departamento de operações contrata mais 10 pessoas para acompanhar o relato de defeitos, e o desenvolvimento contrata mais 15 para acompanhar o seu fechamento. E em vez de introduzir novos recursos, a equipe trabalha com infinitos SD's, explicando ao usuário a funcionalidade e suporte ao mesmo tempo. Como resultado, tanto as operações quanto o desenvolvimento estão funcionando, mas o cliente e a empresa estão insatisfeitos: novos recursos ficam presos. Acontece que o DevOps parece existir, mas parece não existir.
Quanto à necessidade de implementação do DevOps, Anton afirmou claramente que isso depende diretamente da escala do negócio. Se atender a um cliente por ano gera um bilhão para a empresa, o DevOps não é necessário (desde que você não precise implementar novas alterações nesse cliente regularmente). Tudo está coberto de chocolate. Mas se o negócio crescer e aparecerem mais clientes, você precisa obedecer. Via de regra, inicialmente não há operações legais na empresa. Primeiro cortamos o produto e só depois entendemos que para o produto funcionar é preciso ficar de olho nos servidores e monitorar o abastecimento. É aí que o Ops surge. Resta entender que as operações, como uma divisão separada, começarão a colocar uma série de barreiras ao desenvolvimento e todas as entregas começarão a estagnar. Ou seja, neste caso, a cultura DevOps já é relevante, mas não podemos esquecer do seu lado negro.
Fonte: habr.com