O tema DevOps tornou-se muito popular nos últimos anos. Muitos aspiram a se inserir, mas, como mostra a prática, frequentemente é apenas devido aos níveis salariais.
Alguns mencionam DevOps em seus currículos, embora nem sempre saibam e compreendam o significado do termo. Alguns acham que, ao aprender Ansible, GitLab, Jenkins, Terraform e similares (a lista pode continuar a gosto), logo se tornam 'DevOps'. Isso, certamente, não é verdade.
Nos últimos anos, venho me dedicando principalmente à implementação do DevOps em diversas empresas. Antes disso, trabalhei por mais de 20 anos em posições que vão de administrador de sistemas a diretor de TI. Atualmente, sou Engenheiro DevOps Lead na Playgendary.
Quem é um DevOps
A ideia de escrever este artigo surgiu após mais uma pergunta: 'quem é um DevOps?'. Até hoje, não existe um termo consolidado sobre o que ou quem isso é. Parte das respostas já pode ser encontrada neste . Primeiro, vou destacar os principais pontos desse artigo e, em seguida, compartilharei minhas observações e reflexões.
DevOps não é um especialista que pode ser contratado, nem um conjunto de utilitários, e não é um departamento de desenvolvedores com engenheiros.
DevOps é uma filosofia e uma metodologia.
Em outras palavras, é um conjunto de práticas que ajuda a promover a interação ativa entre desenvolvedores e administradores de sistemas. Ou seja, conectar e integrar fluxos de trabalho entre si.
Com a chegada 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 tornaram mais fluidas.
Os objetivos do DevOps podem ser descritos em três pontos:
- O software deve ser atualizado regularmente.
- O software deve ser desenvolvido rapidamente.
- O software deve ser implantado de forma conveniente e em um curto espaço de tempo.
Não existe uma única ferramenta para DevOps. Configurar, instalar e aprender vários produtos não significa que a empresa tenha um DevOps. Existem muitas ferramentas, e todas são utilizadas em diferentes etapas, mas servem a um objetivo comum.
E isso é apenas uma parte das ferramentas DevOps.
Já há mais de 2 anos que estou entrevistando pessoas para a posição de engenheiro DevOps e cheguei à consciência de quão importante é entender claramente o significado do termo. Acumulei experiências, observações e reflexões específicas que gostaria de compartilhar.
Com base na minha experiência em entrevistas, eu vejo a seguinte situação: os especialistas que consideram DevOps como uma função geralmente têm mal-entendidos com os colegas..
Houve um exemplo claro. Um jovem chegou à entrevista com uma infinidade de palavras inteligentes em seu currículo. Nos últimos três empregos, teve uma experiência de 5 a 6 meses. Saiu de duas startups porque "não decolaram". E quanto à terceira empresa, ele disse que ninguém o compreendia: os desenvolvedores escrevem código para Windows, e o diretor o obriga a "embalar" esse código em um Docker comum e integrá-lo no pipeline CI/CD. O rapaz falou muito negativamente sobre seu atual local de trabalho e seus colegas — a vontade era responder: "Então você não consegue vender o elefante".
Depois fiz a ele uma pergunta que está entre as minhas primeiras para cada candidato.
— O que DevOps significa pessoalmente para você?
— Geralmente ou como eu percebo?
Eu estava interessado em sua opinião pessoal. Ele sabia a teoria e a origem do termo, mas era categoricamente contra. Ele acreditava que DevOps era um cargo. E aí está a raiz de seus problemas. Assim como outros especialistas com a mesma opinião.
Os empregadores, ouvindo sobre a "magia do DevOps", querem encontrar alguém que venha e crie essa "magia". E os candidatos que pensam que "DevOps é um cargo" não entendem que, com essa abordagem, não poderão atender às expectativas. Além disso, escreveram em seu currículo DevOps porque é uma tendência e pagam bem por isso.
Metodologia e filosofia do DevOps
A metodologia pode ser teórica e prática. No nosso caso — a segunda. Como mencionei acima, DevOps é um conjunto de práticas e estratégias aplicadas para alcançar os objetivos declarados. E, em cada caso, dependendo dos processos de negócios da empresa, pode diferir substancialmente. O que não a torna melhor ou pior.
A metodologia DevOps é apenas um meio para alcançar os objetivos estabelecidos.
Agora, sobre o que é a filosofia do DevOps. E essa provavelmente é a pergunta mais difícil.
Formular uma resposta concisa e eficaz é bastante difícil, pois ainda não está formalizada. E como os adeptos da filosofia DevOps se concentram mais na prática — simplesmente não há tempo para filosofar. No entanto, esse é um processo muito importante. E está diretamente relacionado à atividade de engenharia. Existe até uma área de conhecimento especializada — .
Na minha instituição de ensino, não havia essa matéria, então tive que estudar tudo sozinho com os materiais que consegui encontrar nos anos 90. O tema não é obrigatório para a formação em engenharia, daí a ausência de uma resposta formalizada. Mas aquelas pessoas que se aprofundaram seriamente em DevOps começam a sentir uma certa "essência" ou "inconsciência abrangente" de todos os processos da empresa.
Com base na minha experiência, tentei formalizar alguns "postulados" dessa filosofia. O resultado foi o seguinte:
- DevOps não é um campo independente, que possa ser destacado como um direcionamento específico de conhecimento ou atividade.
- Todos os colaboradores da empresa devem se guiar pela metodologia DevOps ao planejar suas atividades.
- DevOps abrange todos os processos dentro da empresa.
- DevOps existe para reduzir o tempo gasto em qualquer processo dentro da empresa, visando o desenvolvimento de seus serviços e o máximo conforto para o cliente.
- DevOps, em termos modernos, é a posição proativa de cada colaborador da empresa, voltada para a redução de desperdício de tempo e a melhoria da qualidade dos produtos de TI ao nosso redor.
Acredito que meus "postulados" são um assunto para discussão à parte. Mas agora temos uma base para partir.
O que faz o DevOps
A palavra-chave aqui é comunicação. Há muitas comunicações, cujo iniciador deve ser exatamente esse engenheiro de DevOps. Por quê? Porque é uma filosofia e metodologia, e só depois vem o conhecimento técnico.
Não posso falar com 100% de certeza sobre o mercado de trabalho ocidental. Mas conheço bastante sobre o mercado de DevOps na Rússia. Além de centenas de entrevistas, nos últimos um ano e meio eu participei de uma centena de pré-vendas técnicas para o serviço de "Implementação de DevOps" para grandes empresas e bancos russos.
No Brasil, o DevOps ainda é um assunto muito novo, mas já está na moda. Pelo que eu sei, apenas em Moscovo, a falta de especialistas nesse campo ultrapassou mil pessoas em 2019. E a palavra Kubernetes para os empregadores é quase como um pano vermelho para um touro. Os adeptos desta ferramenta estão prontos para usá-la mesmo onde não é necessário e economicamente viável. O empregador nem sempre entende em quais casos é mais apropriado usar, enquanto, com a devida implementação, o custo de um cluster Kubernetes pode ser de 2 a 3 vezes mais caro do que implementar uma aplicação através de um esquema de cluster normal. Use-o onde realmente é necessário.
A implementação do DevOps, do ponto de vista financeiro, é cara. E é justificada apenas onde traz benefícios econômicos em outras áreas, e não por si só.
Os engenheiros de DevOps são, de fato, os pioneiros — são eles que devem primeiro implementar essa metodologia na empresa e construir os processos. Para que isso seja bem-sucedido, o especialista deve constantemente interagir com os funcionários e colegas em todos os níveis. Como eu costumo dizer, todos os funcionários da empresa devem estar envolvidos no processo de implantação do DevOps: do faxineiro ao CEO. E essa é uma condição obrigatória. Se o membro mais novo da equipe não souber e entender o que é DevOps e por que certas ações organizacionais são realizadas, a implementação bem-sucedida não ocorrerá.
Além disso, o engenheiro de DevOps precisa, de tempos em tempos, utilizar recursos administrativos. Por exemplo, para superar a "resistência do ambiente" — quando a equipe não está pronta para aceitar as ferramentas e a metodologia do DevOps.
O desenvolvedor deve escrever apenas código e testes. Para isso, ele não precisa de um laptop superpoderoso, no qual ele irá configurar e manter toda a infraestrutura do projeto localmente. Por exemplo, o frontend deve ter em seu laptop todos os elementos do aplicativo, incluindo o banco de dados, emulador S3 (minio) e outros. Ou seja, ele gastará muito tempo mantendo essa infraestrutura local e lutando sozinho com todos os problemas de tal solução. Em vez de desenvolver código para a interface. Essas pessoas podem se opor fortemente a quaisquer mudanças.
Mas há equipes que, ao contrário, estão felizes com a implementação de novas ferramentas e métodos, e participam ativamente desse processo. Embora, mesmo assim, a comunicação entre o engenheiro DevOps e a equipe não possa ser descartada.
Quando DevOps não é necessário
Existem situações em que o DevOps não é necessário. Esse é um fato — é preciso entendê-lo e aceitá-lo.
Em primeiro lugar, isso diz respeito a qualquer empresa (especialmente pequenas empresas) cuja receita não dependa diretamente da presença ou ausência de produtos de TI que fornecem serviços de informação aos clientes. E aqui não estamos falando do site da empresa, seja ele um cartão de visitas estático ou com blocos de notícias dinâmicas e afins.
O DevOps é necessário quando a satisfação do seu cliente e seu desejo de retornar a você dependem da disponibilidade, qualidade e direcionamento desses serviços de informação que interagem com o cliente.
Um exemplo marcante é um banco conhecido. A empresa não possui as tradicionais agências, a documentação é trocada por correio ou mensageiros, e muitos funcionários trabalham de casa. A empresa deixou de ser apenas um banco e, na minha opinião, se transformou em uma empresa de TI com tecnologias DevOps avançadas.
Existem muitos outros exemplos e palestras disponíveis nas gravações de meetups e conferências temáticas. Alguns dos quais eu assisti pessoalmente — é uma experiência muito útil para quem deseja se desenvolver nessa área. Aqui estão links para canais do YouTube com boas palestras e materiais sobre DevOps:
Agora olhe para o seu negócio e pense: quão dependente sua empresa e sua lucratividade estão dos produtos de TI que garantem a interação com o cliente?
Se sua empresa vende peixe em uma pequena loja e os únicos produtos de TI são duas configurações do 1C: Enterprise (Contabilidade e UHN), então provavelmente não faz sentido falar sobre DevOps.
Por outro lado, se você trabalha em uma grande empresa comercial e industrial (por exemplo, fabricando armas de caça), vale a pena considerar. Você pode tomar a iniciativa e comunicar à sua gerência as perspectivas para a implementação do DevOps. E, de quebra, liderar esse processo. Uma posição proativa é um dos importantes postulados da filosofia DevOps.
O tamanho e o volume da receita financeira anual não são o critério principal para determinar se sua empresa precisa de DevOps.
Vamos imaginar uma grande empresa industrial que não interage diretamente com os clientes. Por exemplo, algumas montadoras e empresas do setor automotivo. Atualmente, não tenho certeza, mas, pela minha experiência passada, durante muitos anos toda a interação com os clientes era realizada por e-mail e telefone.
Seus clientes são uma lista restrita de concessionárias de automóveis. A cada uma delas é atribuído um especialista do fabricante. Todo o fluxo de documentos internos ocorre através do ERP SAP. Os funcionários internos, na essência, são os clientes do sistema de informação. Mas a gestão desse SI é feita por meio de métodos tradicionais de gestão de sistemas em cluster. Isso exclui a possibilidade de usar práticas de DevOps.
Daqui vem a conclusão: para tais empresas, a implementação de DevOps não é algo criticamente importante, se lembrarmos dos objetivos da metodologia no início do artigo. Mas não descarto que algumas ferramentas de DevOps sejam utilizadas por elas hoje.
Por outro lado, há muitas pequenas empresas que desenvolvem software utilizando a metodologia, filosofia, práticas e ferramentas de DevOps. E elas acreditam que os custos da implementação do DevOps são despesas que lhes permitem competir de forma eficaz no mercado de software. Exemplos dessas empresas podem ser vistos. .
O principal critério para entender se você precisa de DevOps é: qual é o valor dos seus produtos de TI para a empresa e os clientes.
Se o principal produto da empresa, que gera lucro, é software — você precisa de DevOps. E não importa se você ganha dinheiro real com outros produtos. Isso também se aplica a lojas online ou aplicativos móveis com jogos.
Qualquer jogo existe graças ao financiamento: direto ou indireto por parte dos jogadores. Na Playgendary, desenvolvemos jogos móveis gratuitos, cuja criação direta envolve mais de 200 pessoas. Como usamos DevOps?
Da mesma forma que descrito acima. Eu mantenho comunicação constante com os desenvolvedores e testadores, realizo treinamentos internos sobre a metodologia e ferramentas de DevOps.
Atualmente, estamos ativamente usando o Jenkins como ferramenta de CI/CD pipelines para realizar todos os processos de build com Unity e o subsequente deploy na App Store e Play Market. Além do conjunto clássico de ferramentas:
- Asana — para gerenciamento de projetos. Integração configurada com Jenkins.
- Google Meet — para realizar videoconferências.
- Slack — para comunicação e vários alertas, incluindo notificações do Jenkins.
- Atlassian Confluence — para documentação e trabalho em grupo.
Nos planos futuros está implementar a análise estática de código com o SonarQube e realizar testes de UI automatizados com o Selenium na fase de Integração Contínua.
Em conclusão
Quero terminar com o seguinte pensamento: para se tornar um engenheiro DevOps altamente qualificado, é vital aprender a se comunicar com as pessoas.
Um engenheiro DevOps é um jogador de equipe. E de nenhuma outra forma. A iniciativa na comunicação com os colegas deve vir dele mesmo, e não sob a influência de circunstâncias. O especialista em DevOps deve identificar e propor a melhor solução para a equipe.
E sim, a implementação de qualquer solução exigirá muitas discussões e pode até mudar completamente ao final. Ao se desenvolver por conta própria, propondo e realizando suas ideias — essa pessoa representa um valor cada vez maior tanto para a equipe quanto para o empregador. O que, em última análise, reflete no tamanho de sua remuneração mensal ou na forma de bônus adicionais.
Fonte: habr.com
