Get best of the week

Quem é DevOps e quando não é necessário



O tema do DevOps se tornou muito popular nos últimos anos. Muitos sonham em participar, mas, como mostra a prática, geralmente apenas por causa do nível de salários.

Alguns indicam DevOps em seus currículos, embora nem sempre saibam e entendam a essência do termo. Alguém acredita que, tendo estudado Ansible, GitLab, Jenkins, Terraform e afins (a lista pode ser continuada ao seu gosto), ela imediatamente se tornará um "devoop". Claro que não é assim.

Nos últimos anos, estive envolvido principalmente na implementação do DevOps em várias empresas. Antes disso, ele trabalhou por mais de 20 anos em cargos de administrador de sistemas a diretor de TI. Agora - engenheiro líder do DevOps na Playgendary.

Quem é DevOps


A ideia de escrever um artigo surgiu após outra pergunta: "quem é o DevOps?". Ainda não existe um termo estabelecido sobre o que ou quem é. Algumas das respostas já estão neste vídeo . Primeiro, destacarei os pontos principais e depois compartilharei minhas observações e pensamentos.

O DevOps não é um especialista que você pode contratar, nem um conjunto de utilitários e nem um departamento de desenvolvimento com engenheiros.

DevOps é uma filosofia e metodologia.

Em outras palavras, esse é um conjunto de práticas que ajudam 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 (há desenvolvedores, há engenheiros), mas as regras de interação mudaram. Borrou os limites entre os departamentos.

Os objetivos do DevOps podem ser descritos de três maneiras:

  • O software deve ser atualizado regularmente.
  • O software deve ser feito rapidamente.
  • O software deve ser implantado de forma conveniente e em pouco tempo.

O DevOps não possui uma única ferramenta. Configurar, entregar e explorar vários produtos não significa que o DevOps tenha aparecido na empresa. Existem muitas ferramentas e todos estão envolvidos em diferentes estágios, mas eles servem a um objetivo comum.


E isso é apenas parte das ferramentas do DevOps.

Por mais de dois anos, entrevistei pessoas para o cargo de engenheiro do DevOps e percebi o quanto é importante entender claramente a essência do termo. Acumulei experiências, observações e pensamentos específicos que quero compartilhar.

A partir da experiência da entrevista, vejo a seguinte imagem: especialistas que consideram o DevOps um trabalho geralmente têm mal-entendidos com os colegas .

Houve um exemplo vívido. Um jovem veio à entrevista com um monte de palavras inteligentes no currículo. Nos últimos três locais de trabalho, ele teve de 5 a 6 meses de experiência. Ele deixou duas startups porque "não decolaram". Mas, quanto à terceira empresa, ele disse que ninguém entende isso: os desenvolvedores escrevem código no Windows, e o diretor obriga esse código a ser "empacotado" em um Docker comum e incorporado em um pipeline de CI / CD. O cara contou muitas coisas negativas sobre seu trabalho atual e seus colegas - eu queria responder: "Então você não vende o elefante".

Então fiz uma pergunta, que é uma das primeiras da minha lista para cada candidato.

- O que o DevOps significa para você pessoalmente?
- Geralmente ou como eu o percebo?

Eu estava interessado em sua opinião pessoal. Ele conhecia a teoria e a origem do termo, mas discordava totalmente deles. Ele pensou que o DevOps era um post. Aqui reside a raiz dos seus problemas. Como outros profissionais com a mesma opinião.

Os empregadores, depois de ouvirem sobre a "mágica do DevOps", querem encontrar uma pessoa que venha e crie essa "mágica". E os candidatos da categoria "DevOps - esta posição" não entendem que, com essa abordagem, eles não serão capazes de atender às expectativas. E, em geral, o DevOps escreveu em seu currículo, porque essa é uma tendência e eles pagam muito por isso.

DevOps de Metodologia e Filosofia


A metodologia é teórica e prática. No nosso caso, o segundo. Como mencionei acima, o DevOps é um conjunto de práticas e estratégias usadas para atingir as metas estabelecidas. E em cada caso, dependendo dos processos de negócios da empresa, isso pode diferir significativamente. O que não a torna melhor ou pior.

A metodologia DevOps é apenas um meio de atingir seus objetivos.

Agora, qual é a filosofia do DevOps. E esta é provavelmente a pergunta 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. E diretamente relacionado às atividades de engenharia. Existe até um campo especializado de conhecimento - a filosofia da tecnologia .

Na minha universidade não havia esse assunto, tive que estudar tudo sozinho com base nos materiais que encontrei nos anos 90. O tópico é opcional para o ensino de engenharia, daí a falta de formalização da resposta. Mas as pessoas que estão seriamente imersas no DevOps começam a sentir uma espécie de "espírito" ou "abrangência inconsciente" de todos os processos da empresa.

Tentei formalizar alguns dos "postulados" dessa filosofia. Aconteceu o seguinte:

  • O DevOps não é algo independente, que pode ser distinguido em uma área separada de conhecimento ou atividade.
  • A metodologia DevOps deve ser orientada por todos os funcionários da empresa que planejam suas atividades.
  • O DevOps afeta todos os processos dentro da empresa.
  • O DevOps existe para reduzir o tempo gasto em qualquer processo dentro da empresa para garantir o desenvolvimento de seus serviços e o máximo conforto do cliente.
  • O DevOps, em linguagem moderna, é a posição proativa de cada funcionário da empresa, com o objetivo de reduzir custos de tempo e melhorar a qualidade dos produtos de TI que nos cercam.

Eu acho que meus “postulados” são um tópico separado para discussão. Mas agora há algo para construir.

O que o DevOps faz


A palavra-chave aqui é comunicação. Existem muitas comunicações, cujo iniciador deve ser o próprio engenheiro do DevOps. Por que é que? Porque é filosofia e metodologia, e somente então o conhecimento de engenharia.

Não posso falar sobre o mercado de trabalho ocidental com 100% de certeza. Mas eu sei bastante sobre o mercado de DevOps na Rússia. Além de centenas de entrevistas, durante o último ano e meio, participei de centenas de pré-vendas técnicas para o serviço "Implementação do DevOps" para grandes empresas e bancos russos.

Na Rússia, o DevOps ainda é um tópico muito jovem, mas já em alta. Tanto quanto eu sei, apenas em Moscou a escassez de especialistas em 2019 chegou a mais de 1000 pessoas. E a palavra Kubernetes para empregadores é quase como um pano vermelho para um touro. Os adeptos desta ferramenta estão prontos para usá-la mesmo onde não for necessário e economicamente viável. Um empregador nem sempre entende em que casos é mais apropriado usá-lo e, com a implantação adequada, a manutenção de um cluster Kubernetes é 2-3 vezes mais cara do que a implantação de um aplicativo usando um esquema de cluster convencional. Use-o onde você realmente precisar.



A implementação do DevOps em termos de dinheiro é cara. E justifica-se apenas onde traz benefícios econômicos em outras áreas, e não por si só.

Os engenheiros do DevOps, de fato, são pioneiros - eles são os primeiros a introduzir essa metodologia na empresa e criar processos. Para que isso seja bem-sucedido, o especialista deve interagir constantemente com funcionários e colegas de todos os níveis. Como costumo dizer, todos os funcionários da empresa devem estar envolvidos no processo de implementação do DevOps: de uma faxineira a um CEO. E isso é um pré-requisito. Se o membro mais jovem da equipe não souber e entender o que é o DevOps e por que determinadas ações organizacionais são executadas, uma implementação bem-sucedida falhará.

Além disso, o engenheiro do DevOps precisa usar um recurso administrativo de tempos em tempos. Por exemplo, para superar a "resistência do meio 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 fazer isso, ele não precisa de um laptop super poderoso no qual implantará e suportará localmente toda a infraestrutura do projeto. Por exemplo, o front-end mantém no seu laptop todos os elementos do aplicativo, incluindo o banco de dados, o emulador S3 (minio) e muito mais. Ou seja, ele passa muito tempo mantendo essa infraestrutura local e está lutando sozinho com todos os problemas dessa solução. Em vez de desenvolver código para a frente. Essas pessoas podem resistir fortemente a qualquer mudança.

Mas existem equipes que, pelo contrário, têm prazer em introduzir novas ferramentas e métodos e estão ativamente envolvidas nesse processo. Embora mesmo neste caso, a comunicação entre o engenheiro do DevOps e a equipe não tenha sido cancelada.

Quando o DevOps não é necessário


Há situações em que o DevOps não é necessário. Isso é um fato - deve ser entendido e aceito.

Antes de tudo, isso se aplica a qualquer empresa (especialmente pequenas empresas), quando seu lucro não depende 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 um "cartão de visita" estático ou com blocos de notícias dinâmicos etc.

O DevOps é necessário quando a satisfação do seu cliente e seu desejo de retornar a você novamente dependem da disponibilidade desses serviços de informações para interagir com o cliente, sua qualidade e direcionamento.

Um exemplo impressionante é um banco conhecido. A empresa não possui os escritórios de clientes habituais, o fluxo de trabalho é realizado por correio ou correios e muitos funcionários trabalham em casa. A empresa deixou de ser apenas um banco e, na minha opinião, se transformou em uma empresa de TI com tecnologias DevOps desenvolvidas.

Muitos outros exemplos e palestras podem ser encontrados nas gravações de reuniões e conferências temáticas. Eu pessoalmente visitei alguns deles - essa é uma experiência muito útil para quem deseja se desenvolver nessa direção. Aqui estão os links para os canais do YouTube com boas palestras e materiais sobre DevOps:


Agora olhe para o seu negócio e pense sobre isso: quanto sua empresa e seu lucro dependem de produtos de TI que proporcionam interação com o cliente?

Se sua empresa vende peixe em uma pequena loja e o único produto de TI são duas configurações 1C: Enterprise (Accounting e UNF), dificilmente faz sentido falar sobre DevOps.

Se você trabalha em uma grande empresa comercial e industrial (por exemplo, produz rifles de caça), vale a pena considerar. Você pode tomar a iniciativa e transmitir ao seu gerenciamento as perspectivas de implementação do DevOps. Bem, ao mesmo tempo, lidere esse processo. Uma atitude proativa é um dos postulados importantes da filosofia do DevOps.

O tamanho e o volume da rotatividade financeira anual não é o principal critério para determinar se sua empresa precisa de DevOps.

Imagine uma grande empresa industrial que não interage diretamente com os clientes. Por exemplo, algumas montadoras e empresas automotivas. Agora não tenho certeza, mas, pela minha experiência anterior, por muitos anos toda a interação com os clientes foi realizada por email e telefone.

Seus clientes são uma lista limitada de revendedores de automóveis. E um especialista do fabricante é anexado a cada um. Todo o fluxo de trabalho interno ocorre através do SAP ERP. Funcionários internos, de fato, são clientes do sistema de informação. Mas o gerenciamento desse IP é realizado por meios clássicos de gerenciamento de sistemas de cluster. O que exclui a possibilidade de usar práticas de DevOps.

Daí a conclusão: para essas empresas, a implementação do DevOps não é algo de importância crítica, se lembrarmos dos objetivos da metodologia desde o início do artigo. Mas não excluo que algumas ferramentas do DevOps sejam usadas por elas hoje.

Por outro lado, existem muitas pequenas empresas que desenvolvem software usando a metodologia, filosofia, práticas e ferramentas do DevOps. E eles acreditam que os custos de implementação do DevOps são custos que lhes permitem competir efetivamente no mercado de software. Exemplos de tais empresas podem ser vistos aqui .

O principal critério para entender se o DevOps é necessário: qual a importância dos seus produtos de TI para a empresa e os clientes.

Se o principal produto lucrativo da empresa for software, você precisará do DevOps. E não é tão importante se você ganha dinheiro real com a ajuda de outros bens. Isso também inclui lojas online ou aplicativos móveis com jogos.

Existem jogos graças ao financiamento: direto ou indireto dos jogadores. Na Playgendary, estamos desenvolvendo jogos para celular gratuitos nos quais mais de 200 pessoas estão diretamente envolvidas. Como usamos o DevOps?

Sim, como descrito acima. Eu me comunico constantemente com desenvolvedores e testadores, conduzo treinamento interno para a equipe e as ferramentas da metodologia DevOps.

Agora, estamos usando ativamente o Jenkins como uma ferramenta de pipelines de CI / CD para executar todos os pipelines de montagem do Unity e, em seguida, implantar na App Store e Play Market. Mais da caixa de ferramentas clássica:

  • Asana - para gerenciamento de projetos. Integração configurada com Jenkins.
  • Google Meet - para videochamadas.
  • Slack - para comunicações e vários alertas, incluindo notificações de Jenkins.
  • Confluência Atlassian - para documentação e trabalho em grupo.

Em um futuro próximo, apresentaremos a análise de código estático usando o SonarQube e realizaremos testes automatizados de interface do usuário com as ferramentas Selenium no estágio de Integração Contínua.

Em vez de uma conclusão


Quero terminar com o seguinte pensamento: para se tornar um engenheiro de alta qualificação do DevOps, é vital aprender a se comunicar com as pessoas.

O engenheiro do DevOps faz parte da equipe. E de nenhuma outra maneira. A iniciativa de se comunicar com os colegas deve vir de si mesmo e não sob a influência de nenhuma circunstância. O especialista em DevOps deve ver e oferecer a melhor solução para a equipe.

E sim, a implementação de qualquer solução exigirá muita discussão e, no final, poderá até mudar. Ao desenvolver, oferecer e implementar suas idéias de forma independente, essa pessoa tem um valor cada vez maior para a equipe e para o empregador. Que, em última análise, se reflete no valor de sua remuneração mensal ou na forma de bônus adicionais.

More articles:


All Articles