🥇Quem são os DevOps?

Atualmente, essa é, sem dúvida, uma das posições mais caras do mercado. A agitação em torno dos engenheiros de "DevOps" supera todos os limites imagináveis, e o pior é que a situação é ainda mais complicada com engenheiros de DevOps seniores.
Eu trabalho como chefe do departamento de integração e automação, adivinha a tradução em inglês — DevOps Manager. A tradução em inglês reflete realmente nossas atividades diárias? Provavelmente não, enquanto a versão em russo é mais precisa nesse caso. De acordo com meu trabalho, é natural que eu precise entrevistar os futuros membros da minha equipe e, no último ano, passei por cerca de 50 pessoas, e outras tantas foram eliminadas em pré-seleções com meus colaboradores.

Ainda estamos à procura de colegas, pois atrás do rótulo DevOps esconde-se uma grande camada de vários tipos de engenheiros.

Tudo que está escrito abaixo é minha opinião pessoal; você não é obrigado a concordar com ela. No entanto, eu reconheço que pode influenciar sua percepção sobre o assunto. Apesar do risco de desagradar, publico minha opinião porque considero que ela merece ser dita.

As empresas têm entendimentos distintos sobre quem são os engenheiros DevOps e, para uma contratação rápida, aplicam esse rótulo a todos. A situação é estranha, já que as empresas estão dispostas a pagar recompensas irreais a essas pessoas, recebendo, na maioria das vezes, apenas um administrador-ferramenta.

Então, quem são os engenheiros DevOps?

Vamos começar com a história do surgimento — o Development Operations surgiu como mais um passo para otimizar a interação em pequenas equipes, visando aumentar a velocidade de produção do produto como resultado esperado. A ideia era fortalecer a equipe de desenvolvimento com conhecimentos sobre procedimentos e abordagens na gestão do ambiente do produto. Em outras palavras, um desenvolvedor deve entender e saber como seu produto funciona em determinadas condições, deve compreender como implementar seu produto, quais características do ambiente ajustar para aumentar o desempenho. Assim, com o tempo, surgiram desenvolvedores com a abordagem DevOps. Esses desenvolvedores escreviam scripts de construção e empacotamento para facilitar suas atividades e a operação do ambiente produtivo. No entanto, a complexidade da arquitetura das soluções e a influência mútua dos componentes da infraestrutura começaram a piorar o desempenho dos ambientes com o passar do tempo; a cada iteração, eram necessárias compreensões mais profundas de diversos componentes, diminuindo a produtividade do próprio desenvolvedor devido ao custo adicional de entender os componentes e ajustar os sistemas para tarefas específicas. O custo próprio do desenvolvedor aumentava, assim como o custo do produto, e os requisitos para novos desenvolvedores na equipe dispararam, uma vez que também precisavam cobrir as responsabilidades da 'estrela' do desenvolvimento, que, naturalmente, se tornava cada vez menos acessível. Também vale a pena notar que, na minha experiência, poucos desenvolvedores se interessam pela especificidade do manuseio de pacotes pelo núcleo do sistema operacional, pelas regras de roteamento de pacotes e pelos aspectos de segurança do host. O passo lógico foi trazer um administrador, que está familiarizado com isso, e atribuir a ele responsabilidades desse tipo, o que, graças à sua experiência, permitiu alcançar os mesmos resultados a um custo inferior em comparação com o custo da 'estrela' do desenvolvimento. Esses administradores eram colocados na equipe, e sua tarefa principal era gerenciar ambientes de teste e produtivos, de acordo com as regras de uma equipe específica, utilizando recursos designados exclusivamente para essa equipe. Assim, realmente apareceram os DevOps na visão da maioria.

Parcial ou completamente, ao longo do tempo, esses administradores de sistema começaram a entender as necessidades dessa equipe específica de desenvolvimento – como facilitar a vida dos desenvolvedores e testadores, como implantar uma atualização e não ter que passar a noite de sexta-feira no escritório corrigindo erros de implantação. Com o passar do tempo, os administradores de sistema se tornaram os 'heróis', compreendendo o que os desenvolvedores desejavam. Para minimizar o impacto, começaram a ser adotadas ferramentas de gerenciamento, e todos se lembraram de antigos e confiáveis métodos de isolamento em nível de sistema operacional, que permitiam minimizar os requisitos de segurança, de gerenciamento da rede e até da configuração do host como um todo, consequentemente reduzindo as exigências para os novos 'heróis'.

Surge uma 'coisa maravilhosa' – o docker. Por que maravilhoso? Apenas porque a criação de isolamento em chroot ou jail, assim como o OpenVZ, exigia conhecimentos não triviais de sistema operacional, enquanto a ferramenta contrária permite criar facilmente um ambiente isolado para aplicação em um determinado host com tudo necessário dentro, e entregar as rédeas novamente ao desenvolvimento, enquanto o administrador de sistema gerencia apenas um host, garantindo sua segurança e alta disponibilidade – uma simplificação lógica. Contudo, o progresso não para, e os sistemas estão se tornando cada vez mais complexos, com mais e mais componentes, um único host já não atende às necessidades do sistema, e é necessário construir clusters. Retornamos aos administradores de sistema que são capazes de construir esses sistemas.

Ciclo após ciclo, surgem diferentes sistemas que simplificam o desenvolvimento e/ou administração, e aparecem sistemas de orquestração, que até que se precise desviar do processo padrão, são simples de usar. A arquitetura de microserviços também surgiu com o objetivo de simplificar tudo isso – menos interdependências, mais fácil de gerenciar. Em minha experiência, não vivenciei uma arquitetura de microserviços completa, eu diria que é 50 a 50 – 50 por cento são microserviços, caixas pretas, o que entra é processado e sai, os outros 50 – um monólito despedaçado, serviços incapazes de operar separadamente de outros componentes. Tudo isso novamente impôs restrições ao nível de conhecimento tanto dos desenvolvedores quanto dos administradores.

Essas "oscilações" de nível de conhecimento especializado de determinado recurso continuam até hoje. Mas nos desviamos um pouco, há muitos pontos que valem a pena serem abordados.

Engenheiro de Construção/Engenheiro de Lançamento

São engenheiros altamente especializados, surgidos como um meio de padronizar os processos de construção de software e seus lançamentos. Durante a introdução do Agile em larga escala, parecia que haviam perdido a demanda, mas isso está longe de ser verdade. Essa especialização surgiu para justamente padronizar a construção e a entrega de software em grandes escalas, ou seja, utilizando técnicas padrão para todos os produtos da empresa. Com o surgimento do DevOps, os desenvolvedores perderam parcialmente algumas funções, visto que se tornaram responsáveis por preparar o produto para entrega. No entanto, considerando a infraestrutura em mudança e a abordagem voltada para uma entrega rápida, sem se preocupar com a qualidade, acabaram se tornando um impedimento às mudanças, visto que seguir padrões de qualidade inevitavelmente retarda as entregas. Assim, gradualmente, parte das funções dos engenheiros de Build/Release foi transferida para os administradores de sistemas.

Ops variados

Seguimos em frente e uma vez mais, a ampla gama de responsabilidades e a falta de profissionais qualificados nos impulsionam para uma especialização rigorosa. Assim como cogumelos após a chuva, surgem várias operações:

TechOps — administradores de sistemas do tipo enquetes, também conhecidos como Engenheiro de HelpDesk
LiveOps — administradores de sistemas, predominantemente responsáveis por ambientes de produção
CloudOps — administradores de sistemas que se especializam em "nuvens" públicas como Azure, AWS, GCP, etc.
PlatOps/InfraOps/SysOps — administradores de sistemas de infraestrutura.
NetOps — administradores de rede
SecOps — administradores de sistemas que se especializam em segurança da informação — conformidade PCI, conformidade CIS, atualização, etc.

DevOps — uma pessoa que, em teoria, compreende todos os processos do ciclo de desenvolvimento — desenvolvimento, teste, entende a arquitetura do produto, capaz de avaliar riscos de segurança, familiarizada com abordagens e ferramentas de automação, mesmo que em um nível básico, além de compreender também o suporte pré e pós-lançamento do produto. Uma pessoa capaz de atuar como advogada tanto da Operations quanto da Development, permitindo construir uma colaboração favorável entre esses dois pilares. Compreende os processos de planejamento do trabalho das equipes e a gestão das expectativas dos clientes.

Para realizar esse tipo de trabalho e responsabilidades, essa pessoa deve ter ferramentas para gerenciar não apenas os processos de desenvolvimento e teste, mas também a gestão da infraestrutura do produto e o planejamento de recursos. DevOps, nesta compreensão, não pode estar restrito ao IT, R&D ou mesmo ao PMO; ele deve ter influência em todas essas áreas — diretor técnico da empresa, Chief Technical Officer.

É assim em sua empresa? — Duvido. Na maioria das vezes, é ou IT, ou R&D.

A falta de recursos e a capacidade de influência em pelo menos uma dessas três áreas resultará em um deslocamento do foco dos problemas para onde essas mudanças podem ser aplicadas mais facilmente, como a imposição de restrições técnicas em lançamentos devido a um código 'sujo', conforme indicado por sistemas de análise estática. Ou seja, quando o PMO estabelece um prazo rígido para o lançamento de funcionalidades, o R&D não consegue entregar um resultado de qualidade dentro desse prazo e o fornece como pode, deixando o refatoramento para depois; o DevOps relacionado ao IT, por meio de ferramentas técnicas, bloqueia o lançamento. A falta de autoridade para mudar a situação, no caso de funcionários responsáveis, leva ao surgimento de hiperresponsabilidade por aquilo que eles não podem influenciar, especialmente se esses funcionários entendem e veem os erros, e como corrigi-los — 'Felicidade na ignorância', e como consequência, ao burnout e à perda desses colaboradores.

Mercado de recursos DevOps

Vamos considerar algumas vagas para a posição de DevOps de diferentes empresas.

Estamos prontos para nos encontrar com você, se você:

Domina Zabbix e sabe o que é Prometheus;

Iptables;

Estudante de BASH;

Professor de Ansible;

Guru de Linux;

Você sabe usar o debug e, juntamente com os desenvolvedores, identificar problemas em aplicativos (php/java/python);

O roteamento não provoca crises em você;

Você dá grande atenção à segurança do sistema;

Você faz backup de "tudo e todos", e também consegue restaurar esse "tudo e todos" com sucesso;

Você sabe configurar o sistema para extrair o máximo de um mínimo;

Configura replicações antes de dormir no Postgres e MySQL;

Para você, configurar e ajustar CI/CD é uma necessidade, assim como café da manhã/almoço/jantar.

Você tem experiência com AWS;

Está disposto a crescer junto com a empresa;

Então:

de 1 a 6 — administrador de sistema
7 — um pouco de administração de rede, que também se encaixa no perfil de administrador de sistema de nível Middle
8 — um pouco de segurança, que é obrigatório para um administrador de sistema de nível Middle
9-11 — Administrador de Sistema Middle
12 — Dependendo das tarefas a serem realizadas, pode ser Administrador de Sistema Middle ou Build Engineer
13 — Virtualização — Administrador de Sistema Middle, ou o chamado CloudOps, com conhecimento avançado especificamente dos serviços de determinada para PrestaShop plataforma, para um uso eficaz de recursos financeiros e redução da carga operacional

Resumindo, para esta vaga, podemos dizer que os candidatos devem ser Administradores de Sistema de nível Middle/Senior.

A propósito, não deveríamos separar muito os administradores em Linux/Windows. Eu entendo que os serviços e sistemas desses dois mundos diferem, mas a base é a mesma e qualquer administrador autêntico deve estar familiarizado com ambos, e mesmo que não esteja, para um bom administrador não será difícil se familiarizar.

Vamos considerar uma outra vaga:

Experiência na construção de sistemas de alta carga;

Excelentes conhecimentos em OS Linux, software de sistema e pilha web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

Experiência com sistemas de virtualização (KVM, VMWare, LXC/Docker);

Domínio em linguagens de script;

Compreensão dos princípios de funcionamento de redes e protocolos de rede;

Compreensão dos princípios de construção de sistemas tolerantes a falhas;

Autonomia e iniciativa;

Analisando:

1 — Administrador de Sistema Senior
2 — Dependendo do significado atribuído a esse stack — Administrador de Sistema Middle/Senior
3 — Experiência de trabalho, que pode significar — "Não subi o cluster, mas criei e gerenciei máquinas virtuais, havia um host Docker, configurei o acesso aos containers" — Administrador de Sistema Middle
4 — Administrador de Sistema Júnior — Sim, um administrador que não sabe escrever scripts de automação básicos, independentemente da linguagem, não é um administrador — é um suporte técnico.
5 — Administrador de Sistema Pleno
6 — Administrador de Sistema Sênior

Resumindo — Administrador de Sistema Pleno/Sênior

Mais um:

Experiência em DevOps;

Experiência no uso de um ou mais produtos para formação de processos CI/CD. GitLab CI será uma vantagem;

Trabalho com contêineres e virtualização; Se usou Docker – ótimo, mas se usou Kubernetes – perfeito!

Experiência em equipe ágil;

Conhecimento de qualquer linguagem de programação;

Vamos ver:

1 — Hmm... O que os caras querem dizer? =) Provavelmente, eles mesmos não sabem o que está por trás disso.
2 — Engenheiro de Build
3 — Administrador de Sistema Pleno
4 — Soft skills, não vamos considerar por enquanto, embora Agile seja outra coisa que é interpretada da maneira que é conveniente.
5 — Muito vago — pode ser uma linguagem de script ou uma linguagem compilada. Estou curioso, será que ter escrito na escola em Pascal e Basic é suficiente para eles? =)

Gostaria de fazer uma observação sobre o item 3, para reforçar a compreensão de por que este item é coberto pelo administrador de sistemas. Kubernetes é apenas uma orquestração, uma ferramenta que envolve comandos diretos para drivers de rede e hosts de virtualização/isolamento em poucos comandos e permite que a comunicação com eles seja abstrata, e só isso. Para exemplificar, tomemos o 'framework de build' Make, que, a propósito, eu não considero um framework. Sim, eu sei da moda de enfiar Make em qualquer lugar, onde é necessário e onde não é — envolver Maven em Make, por exemplo, a sério?
Na verdade, Make é apenas uma camada sobre o shell, simplificando os comandos de compilação, linkagem e ambiente de compilação, assim como o Kubernetes.

Uma vez, eu entrevistei um cara que usou Kubernetes em seu trabalho sobre OpenStack, e ele falou sobre como implantava serviços nele, no entanto, quando eu perguntei especificamente sobre OpenStack, ficou claro que ele estava administrando, assim como levantando-o, administradores de sistemas. Você realmente acha que uma pessoa que levantou o OpenStack, independentemente da plataforma que ela usa por trás, não é capaz de usar Kubernetes? =)
Este candidato, na verdade, não é um DevOps, mas um Administrador de Sistemas, e para ser mais preciso, Administrador de Kubernetes.

Resumindo mais uma vez — um Administrador de Sistema Pleno/Sênior será suficiente para eles.

Quanto colocar em gramas

A faixa salarial proposta para as vagas mencionadas é de 90k a 200k
Agora, gostaria de traçar um paralelo entre as recompensas monetárias dos Administradores de Sistemas e dos Engenheiros DevOps.

Basicamente, para simplificar, podemos categorizar os níveis por experiência, embora isso não seja preciso, será suficiente para os fins deste artigo.

Experiência:

até 3 anos — Júnior
até 6 anos — Pleno
mais de 6 anos — Sênior

O site de busca de funcionários oferece:
Administradores de Sistemas:

Júnior — 2 anos — 50k rub.
Pleno — 5 anos — 70k rub.
Sênior — 11 anos — 100k rub.

Engenheiros DevOps:

Júnior — 2 anos — 100k rub.
Pleno — 3 anos — 160k rub.
Sênior — 6 anos — 220k rub.

Para a experiência dos 'DevOps', foi considerado um histórico que abranja de alguma forma o SDLC.

Do exposto, conclui-se que, na verdade, as empresas não precisam de DevOps, e que poderiam economizar pelo menos 50% das despesas originalmente planejadas, contratando um Administrador. Além disso, poderiam definir mais claramente as responsabilidades da pessoa buscada e atender rapidamente à demanda. Também não se deve esquecer que uma clara divisão de responsabilidades permite reduzir as exigências sobre o pessoal e criar um ambiente mais favorável na equipe, devido à ausência de sobreposições. Na maioria das vagas, apregoa-se utilitários e rótulos de DevOps, mas que não têm, na verdade, requisitos reais para Engenheiro DevOps, apenas pedidos por um administrador de ferramentas.

O processo de formação de Engenheiros DevOps também é limitado a um conjunto de trabalhos específicos, utilitários, e não proporciona uma compreensão geral dos processos e suas dependências. É claro que é bom quando uma pessoa pode usar o Terraform para implantar o AWS EKS, em conjunto com o Fluentd sidecar nesse cluster e o AWS ELK stack para o sistema de log em 10 minutos, usando apenas um comando no console, mas se ela não entender o princípio da manipulação de logs e para que eles servem, não tiver conhecimento sobre como coletar métricas relacionadas e monitorar a degradação do serviço, então será apenas um suporte técnico que sabe usar algumas utilidades.

A demanda, no entanto, gera oferta, e vemos um mercado extremamente aquecido para a posição de DevOps, onde os requisitos não correspondem à função real, permitindo apenas que administradores de sistemas ganhem mais.

Então, quem são eles? DevOps ou administradores de sistemas gananciosos? =)

Como viver a partir daqui?

Para os empregadores — formular requisitos de forma mais precisa e procurar exatamente aqueles de que precisam, e não dispersar-se com rótulos. Se você não sabe o que fazem os DevOps, eles não são necessários, nesse caso.

Para os trabalhadores — Aprender. Aperfeiçoar constantemente seus conhecimentos, observar a visão geral dos processos e monitorar o caminho para o objetivo estabelecido. Você pode se tornar o que quiser, basta se esforçar.

Fonte: habr.com