Em blogs anteriores, meus colegas Arnoud e Sander já falaram sobre os modelos de maturidade e o dimensionamento de nosso departamento de engenharia. No entanto, quero falar sobre como, da perspectiva de um engenheiro de operações, nossa jornada passou de Ops para DevOps.

Quando fundei o Avance Network, tínhamos um departamento de Operações (HOSD) e um departamento de desenvolvimento (Avance Technologies). Os dois departamentos trabalharam juntos para entregar ótimos produtos aos nossos clientes, mas também se separaram um do outro simplesmente porque éramos dois departamentos em andares diferentes.

Então, em algum momento, as equipes e nossa administração chegaram à conclusão de que precisávamos olhar para melhorar a comunicação e a cooperação interdepartamentais. Naquela época (isso foi em 2015), DevOps já era uma grande palavra da moda, então decidimos também ir para uma abordagem DevOps e o departamento de engenharia de produto nasceu (tinha um nome diferente na época, mas isso não vem ao caso).

Para ser honesto, no início eu era cético sobre toda a ideia de DevOps, e dado que apresentamos nossas equipes de Ops ao trabalho em equipes Scrum (o que nossos desenvolvedores já estavam fazendo), a mudança na forma como estamos fazendo nosso trabalho mudou. significativamente.

Depois de alinhar os departamentos, equipes e fazer os preparativos necessários, o “Movimento” finalmente começou. Isso parece mais emocionante do que realmente era. Simplesmente mudamos os locais para nos juntar aos nossos respectivos colegas de desenvolvimento e formamos várias equipes DevOps.

De agora em diante, só falarei sobre a equipe da qual participei, pois a mudança foi, na verdade, apenas isso, a mudança. Ainda estávamos fazendo nossos trabalhos de operações e nossos desenvolvedores ainda fazendo seu trabalho de desenvolvimento. A única coisa que realmente mudou foi que tínhamos standups juntos e quando precisávamos falar um com o outro, não havia mais chão (e escadas) entre nossos departamentos.

Neste ponto, parecia que não havia muita coisa mudada (ainda), mas por volta de dezembro daquele ano concluímos que precisávamos dar mais um passo em nossa transição e decidimos que era hora de fazer outra mudança. Nossa equipe foi dividida em três equipes DevOps menores para obter mais priorização em nossos diferentes produtos.

Esta foi a primeira grande mudança real, porque daquele ponto em diante começamos realmente a trabalhar de forma ágil, adotando cerimônias Scrum como planejamento de sprint e refinamento.

Mas ainda assim (pelo menos da minha perspectiva) não éramos realmente uma equipe DevOps. Fizemos stand-ups, planejamento de sprint e refinamentos juntos, mas ainda assim os caras do Ops fizeram seu trabalho de Ops e nossos desenvolvedores fizeram seus trabalhos de Dev.

A verdadeira mudança veio quando foi tomada a decisão de treinar nossos engenheiros de desenvolvimento em mais trabalho operacional e envolvê-los em nossa rotação de plantão (EOD) 24 horas nos sete dias da semana.

De repente, nos tornamos uma equipe e, apesar de algumas mudanças pessoais, as coisas correram muito bem.

De repente, não havia mais nós e eles. Em vez disso, havia apenas a equipe e realmente começamos a trabalhar juntos, reconhecendo as lutas uns dos outros.

Onde, por exemplo, o pessoal de operações sempre adaptou uma forma de trabalhar, nosso pessoal de desenvolvimento veio com soluções realmente fáceis e elegantes para reduzir nossos gastos com trabalho de operação, dando-nos mais foco como equipe nas melhorias. Passamos esse tempo construindo novos recursos em vez de apagar incêndios e não sermos capazes de planejar nosso trabalho adequadamente devido a tantas cargas de trabalho inesperadas e não planejadas.

No final, conseguimos reduzir drasticamente o nosso trabalho de plantão (basicamente trabalhando fora do horário comercial), implementando mais automação, criando mais documentação e entregando o trabalho às nossas equipes de suporte de primeira e segunda linha. No entanto, o maior impacto veio porque todos se sentiram responsáveis ​​por toda a infraestrutura, do código ao servidor, e toda a equipe queria criar produtos inovadores e incríveis para nossos clientes.

Para mim pessoalmente também foi uma grande revelação, porque no início eu era cético e, para ser honesto, um pouco contra toda a ideia, agora vejo os benefícios da maneira como fazemos as coisas. No final das contas obtive minha Certificação SCRUM Master e ajudei a adaptar uma forma Agile de trabalhar sempre que posso. Eu até passei os últimos 3 meses temporariamente preenchendo o cargo de SCRUM Master para nossa equipe.

Para concluir, no final fizemos realmente uma mudança drástica e embora no início não parecesse muito, percorremos um longo caminho tornando as nossas equipas mais flexíveis e conseguindo responder com maior rapidez às mudanças imprevistas.

Uma última dica que quero compartilhar com todos vocês, se vocês estão enfrentando uma transformação de Ops para DevOps: mergulhe de cabeça e mantenha a mente aberta porque no final os benefícios farão todo o processo valer a pena.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.