DevOps se tornou um tópico muito popular nos últimos anos. Muita gente sonha em ingressar, mas, como mostra a prática, muitas vezes apenas por causa do nível salarial.
Algumas pessoas listam DevOps em seus currículos, embora nem sempre conheçam ou entendam a essência do termo. Algumas pessoas pensam que depois de estudar Ansible, GitLab, Jenkins, Terraform e similares (a lista pode continuar de acordo com seu gosto), você imediatamente se tornará um “devopsista”. Isto naturalmente não é verdade.
Nos últimos anos, estive envolvido principalmente na implementação de DevOps em diversas empresas. Antes disso, trabalhou por mais de 20 anos em cargos que vão desde administrador de sistemas até diretor de TI. Atualmente engenheiro líder de DevOps na Playgendary.
Quem é DevOps
A ideia de escrever um artigo surgiu após outra pergunta: “quem é DevOps?” Ainda não há um prazo estabelecido para o que ou quem é. Algumas das respostas já estão neste . Primeiro, destacarei os pontos principais e depois compartilharei minhas observações e pensamentos.
DevOps não é um especialista que pode ser contratado, nem um conjunto de utilitários, nem um departamento de desenvolvedores com engenheiros.
DevOps é uma filosofia e metodologia.
Em outras palavras, é um conjunto de práticas que ajuda os desenvolvedores a interagir ativamente com os administradores do sistema. Ou seja, conectar e integrar processos de trabalho entre si.
Com o advento do DevOps, a estrutura e as funções dos especialistas permaneceram as mesmas (existem desenvolvedores, existem engenheiros), mas as regras de interação mudaram. As fronteiras entre os departamentos se confundiram.
Os objetivos do DevOps podem ser descritos em três pontos:
- O software deve ser atualizado regularmente.
- O software deve ser feito rapidamente.
- O software deve ser implantado de forma conveniente e em pouco tempo.
Não existe uma ferramenta única para DevOps. Configurar, entregar e estudar diversos produtos não significa que o DevOps apareceu na empresa. Existem muitas ferramentas e todas são usadas em diferentes estágios, mas servem a um propósito comum.
E isso é apenas parte das ferramentas DevOps
Tenho entrevistado pessoas para o cargo de engenheiro DevOps há mais de 2 anos e percebi como é importante compreender claramente a essência do termo. Acumulei experiências, observações e pensamentos específicos que quero compartilhar.
Pela experiência da entrevista, vejo a seguinte imagem: especialistas que consideram DevOps um cargo geralmente têm mal-entendidos com colegas.
Houve um exemplo notável. Um jovem veio para uma entrevista com muitas palavras inteligentes em seu currículo. Nos últimos três empregos, ele teve de 5 a 6 meses de experiência. Saí de duas startups porque elas “não decolaram”. Mas sobre a terceira empresa, ele disse que ninguém o entende lá: os desenvolvedores escrevem código no Windows, e o diretor força esse código a ser “embrulhado” no Docker normal e integrado ao pipeline de CI/CD. O cara disse muitas coisas negativas sobre seu atual local de trabalho e seus colegas - eu só queria responder: “Então você não vai vender um elefante”.
Então fiz a ele uma pergunta que está no topo da minha lista para todos os candidatos.
— O que DevOps significa para você pessoalmente?
- Em geral ou como percebo isso?
Eu estava interessado em sua opinião pessoal. Ele conhecia a teoria e a origem do termo, mas discordava veementemente delas. Ele acreditava que DevOps era um cargo. É aqui que reside a raiz dos seus problemas. Assim como outros especialistas com a mesma opinião.
Os empregadores, tendo ouvido falar muito sobre a “mágica do DevOps”, querem encontrar uma pessoa que venha e crie essa “mágica”. E os candidatos da categoria “DevOps é um trabalho” não entendem que com esta abordagem não conseguirão atender às expectativas. E, em geral, escreveram DevOps no currículo porque é uma tendência e pagam muito por isso.
Metodologia e filosofia DevOps
A metodologia pode ser teórica e prática. No nosso caso, é o segundo. Como mencionei acima, DevOps é um conjunto de práticas e estratégias utilizadas para atingir objetivos declarados. E em cada caso, dependendo dos processos de negócio da empresa, pode diferir significativamente. O que não faz com que seja melhor ou pior.
A metodologia DevOps é apenas um meio para atingir objetivos.
Agora, sobre o que é a filosofia DevOps. E esta é provavelmente a questão mais difícil.
É bastante difícil formular uma resposta curta e sucinta, porque ainda não foi formalizada. E como os adeptos da filosofia DevOps estão mais engajados na prática, simplesmente não há tempo para filosofar. No entanto, este é um processo muito importante. Além disso, está diretamente relacionado às atividades de engenharia. Existe até uma área especializada de conhecimento - .
Não existia essa matéria na minha universidade, tive que estudar tudo sozinho com os materiais que encontrei nos anos 90. O tema é opcional para o ensino de engenharia, daí a falta de formalização da resposta. Mas aquelas pessoas que estão seriamente imersas em DevOps começam a sentir um certo “espírito” ou “abrangente inconsciente” de todos os processos da empresa.
Usando a minha própria experiência, tentei formalizar alguns dos “postulados” desta filosofia. O resultado é o seguinte:
- DevOps não é algo independente que possa ser separado em uma área separada de conhecimento ou atividade.
- Todos os colaboradores da empresa devem se orientar pela metodologia DevOps no planejamento de suas atividades.
- O DevOps afeta todos os processos dentro de uma empresa.
- O DevOps existe para reduzir os custos de tempo de quaisquer processos dentro de uma empresa para garantir o desenvolvimento dos seus serviços e o máximo conforto do cliente.
- DevOps, em linguagem moderna, é a postura proativa de cada colaborador da empresa, visando reduzir custos de tempo e melhorar a qualidade dos produtos de TI que nos rodeiam.
Acho que meus “postulados” são um tópico separado para discussão. Mas agora há algo em que construir.
O que DevOps faz
A palavra-chave aqui é comunicação. Existem muitas comunicações, cujo iniciador deve ser exatamente o mesmo engenheiro de DevOps. Por que é que? Porque isso é filosofia e metodologia, e só então conhecimento de engenharia.
Não posso falar com 100% de confiança sobre o mercado de trabalho ocidental. Mas sei bastante sobre o mercado DevOps na Rússia. Além de centenas de entrevistas, durante o último ano e meio participei de centenas de pré-vendas técnicas do serviço “Implementação de DevOps” para grandes empresas e bancos russos.
Na Rússia, DevOps ainda é um tema muito jovem, mas já em alta. Pelo que eu sei, só em Moscou a escassez desses especialistas em 2019 foi de mais de 1000 pessoas. E a palavra Kubernetes para empregadores é quase como um trapo vermelho para um touro. Os adeptos desta ferramenta estão prontos para usá-la mesmo quando não for necessária e economicamente lucrativa. O empregador nem sempre entende em quais casos o que é mais apropriado usar e, com implantação adequada, manter um cluster Kubernetes custa 2 a 3 vezes mais do que implantar um aplicativo usando um esquema de cluster convencional. Use-o onde você realmente precisa.
Implementar DevOps é caro em termos de dinheiro. E só se justifica quando traz benefícios económicos noutras áreas, e não por si só.
Os engenheiros de DevOps são, de fato, pioneiros – são eles que deveriam ser os primeiros a implementar essa metodologia na empresa e a construir processos. Para que isso seja bem-sucedido, o especialista deve interagir constantemente com colaboradores e colegas de todos os níveis. Como costumo dizer, todos os colaboradores da empresa devem estar envolvidos no processo de implementação do DevOps: desde a faxineira até o CEO. E este é um pré-requisito. Se o membro mais jovem da equipe não souber e compreender o que é DevOps e por que certas ações organizacionais são executadas, então uma implementação bem-sucedida não funcionará.
Além disso, um engenheiro de DevOps precisa usar um recurso administrativo de tempos em tempos. Por exemplo, para superar a “resistência ambiental” – quando a equipe não está preparada para aceitar ferramentas e metodologia DevOps.
O desenvolvedor deve apenas escrever código e testes. Para fazer isso, ele não precisa de um laptop superpoderoso no qual implantará e dará suporte local a toda a infraestrutura do projeto. Por exemplo, um desenvolvedor front-end mantém todos os elementos da aplicação em seu laptop, incluindo banco de dados, emulador S3 (minio), etc. Ou seja, ele gasta muito tempo mantendo essa infraestrutura local e luta sozinho com todos os problemas dessa solução. Em vez de desenvolver código para o front. Essas pessoas podem ser muito resistentes a qualquer mudança.
Mas há equipas que, pelo contrário, ficam felizes em introduzir novas ferramentas e métodos e em participar ativamente neste processo. Embora mesmo neste caso a comunicação entre o engenheiro DevOps e a equipe não tenha sido cancelada.
Quando o DevOps não é necessário
Existem situações em que o DevOps não é necessário. Isto é um facto – precisa ser compreendido e aceite.
Em primeiro lugar, isto aplica-se a quaisquer empresas (especialmente pequenas empresas), quando o seu lucro não depende diretamente da presença ou ausência de produtos de TI que forneçam serviços de informação aos clientes. E aqui não estamos falando do site da empresa, seja ele um “cartão de visita” estático ou com blocos dinâmicos de notícias, etc.
O DevOps é necessário quando a satisfação do seu cliente e a sua vontade de voltar a contactá-lo dependem da disponibilidade destes serviços de informação para interação com o cliente, da sua qualidade e direcionamento.
Um exemplo notável é um banco bem conhecido. A empresa não possui escritórios tradicionais de clientes, o fluxo de documentos é feito por correio ou entregadores e muitos funcionários trabalham em casa. A empresa deixou de ser apenas um banco e, na minha opinião, passou a ser uma empresa de TI com tecnologias DevOps desenvolvidas.
Muitos outros exemplos e palestras podem ser encontrados nas gravações de encontros e conferências temáticas. Visitei alguns deles pessoalmente - é uma experiência muito útil para quem quer se desenvolver nessa direção. Aqui estão links para canais do YouTube com boas palestras e materiais sobre DevOps:
Agora olhe para o seu negócio e pense no seguinte: Quanto a sua empresa e seus lucros dependem de produtos de TI para permitir a interação com o cliente?
Se sua empresa vende peixes em uma pequena loja e o único produto de TI são duas configurações 1C: Enterprise (Contabilidade e UNF), então não faz sentido falar sobre DevOps.
Se você trabalha em uma grande empresa comercial e industrial (por exemplo, produz rifles de caça), deve pensar a respeito. Você pode tomar a iniciativa e transmitir à sua gestão as perspectivas de implementação do DevOps. Bem, e ao mesmo tempo, lidere esse processo. Uma posição proativa é um dos princípios importantes da filosofia DevOps.
O tamanho e o volume do giro financeiro anual não são o principal critério para determinar se sua empresa precisa de DevOps.
Imaginemos uma grande empresa industrial que não interage diretamente com os clientes. Por exemplo, algumas montadoras e empresas fabricantes de automóveis. Não tenho certeza agora, mas pela minha experiência anterior, durante muitos anos toda a interação com o cliente foi feita por e-mail e telefone.
Seus clientes são uma lista limitada de revendedores de automóveis. E cada um recebe um especialista do fabricante. Todo o fluxo interno de documentos ocorre através do SAP ERP. Os colaboradores internos são essencialmente clientes do sistema de informação. Mas este SI é controlado por meios clássicos de gerenciamento de sistemas de cluster. O que exclui a possibilidade de utilização de práticas DevOps.
Daí a conclusão: para tais empresas, a implementação do DevOps não é algo criticamente importante, se recordarmos os objetivos da metodologia do início do artigo. Mas não descarto que eles usem algumas ferramentas DevOps hoje.
Por outro lado, existem muitas pequenas empresas que desenvolvem software utilizando metodologia, filosofia, práticas e ferramentas DevOps. E acreditam que o custo da implementação do DevOps é o custo que lhes permite competir eficazmente no mercado de software. Exemplos dessas empresas podem ser vistos .
O principal critério para entender se o DevOps é necessário: qual o valor que seus produtos de TI têm para a empresa e para os clientes.
Se o principal produto que gera lucro da empresa é software, você precisa de DevOps. E não é tão importante se você ganha dinheiro de verdade usando outros produtos. Isso também inclui lojas online ou aplicativos móveis com jogos.
Qualquer jogo existe graças ao financiamento: direto ou indireto dos jogadores. Na Playgendary, desenvolvemos jogos mobile gratuitos com mais de 200 pessoas diretamente envolvidas na sua criação. Como usamos DevOps?
Sim, exatamente igual ao descrito acima. Comunico-me constantemente com desenvolvedores e testadores e conduzo treinamentos internos para funcionários sobre metodologia e ferramentas DevOps.
Agora estamos usando ativamente o Jenkins como uma ferramenta de pipelines de CI/CD para executar todos os pipelines de montagem com Unity e subsequente implantação na App Store e no Play Market. Mais do kit de ferramentas clássico:
- Asana - para gerenciamento de projetos. A integração com Jenkins foi configurada.
- Google Meet – para videoconferências.
- Slack – para comunicações e vários alertas, incluindo notificações do Jenkins.
- Atlassian Confluence - para documentação e trabalho em grupo.
Nossos planos imediatos incluem a introdução da análise estática de código usando SonarQube e a realização de testes automatizados de UI usando Selenium no estágio de integração contínua.
Em vez de uma conclusão
Gostaria de finalizar com o seguinte pensamento: para se tornar um engenheiro DevOps altamente qualificado, é vital aprender a se comunicar ao vivo com as pessoas.
Um engenheiro DevOps trabalha em equipe. E nada mais. A iniciativa na comunicação com os colegas deve partir dele e não sob a influência de algumas circunstâncias. Um especialista em DevOps deve enxergar e propor a melhor solução para o time.
E sim, a implementação de qualquer solução exigirá muita discussão e, no final, poderá mudar completamente. Desenvolvendo-se de forma independente, propondo e implementando as suas ideias, tal pessoa tem um valor cada vez maior tanto para a equipa como para o empregador. O que, em última análise, se reflete no valor da sua remuneração mensal ou na forma de bónus adicionais.
Fonte: habr.com