🥇Quem são DevOps?

No momento, esta é quase a posição mais cara do mercado. A agitação em torno dos engenheiros “DevOps” está além de todos os limites imagináveis, e ainda pior com os engenheiros seniores de DevOps.
Trabalho como chefe do departamento de integração e automação, acho que a decodificação em inglês é DevOps Manager. É improvável que a transcrição em inglês reflita nossas atividades diárias, mas a versão em russo neste caso é mais precisa. Pela natureza da minha atividade, é natural que necessite entrevistar futuros membros da minha equipa e, ao longo do último ano, passaram por mim cerca de 50 pessoas, sendo que o mesmo número ficou cortado em pré-seleção com os meus colaboradores.

Ainda estamos procurando colegas, porque por trás do rótulo DevOps existe uma camada muito grande de diferentes tipos de engenheiros escondidos.

Tudo o que está escrito abaixo é minha opinião pessoal, você não precisa concordar com isso, mas admito que vai dar um toque de cor à sua atitude em relação ao tema. Apesar do risco de cair em desgraça, publico minha opinião porque acredito que ela tem um lugar para estar.

As empresas têm entendimentos diferentes sobre quem são os engenheiros de DevOps e, para contratar rapidamente um recurso, colocam esse rótulo em todos. A situação é bastante estranha, uma vez que as empresas estão dispostas a pagar remunerações irrealistas a essas pessoas, recebendo, na maioria dos casos, um administrador de ferramentas para elas.

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

Comecemos pela história do seu surgimento - As Operações de Desenvolvimento surgiram como mais um passo na otimização da interação em pequenas equipes para aumentar a velocidade de produção do produto, como consequência esperada. A ideia era fortalecer a equipe de desenvolvimento com conhecimento de procedimentos e abordagens na gestão do ambiente do produto. Ou seja, o desenvolvedor deve entender e saber como seu produto funciona em determinadas condições, deve entender como implantar seu produto, quais características do ambiente podem ser ajustadas para melhorar o desempenho. Assim, por algum tempo, surgiram desenvolvedores com abordagem DevOps. Os desenvolvedores de DevOps escreveram scripts de construção e empacotamento para simplificar suas atividades e o desempenho do ambiente de produção. Porém, a complexidade da arquitetura da solução e a influência mútua dos componentes da infraestrutura ao longo do tempo começaram a deteriorar o desempenho dos ambientes; a cada iteração, era necessário um entendimento cada vez mais profundo de determinados componentes, reduzindo a produtividade do desenvolvedor devido ao adicional custos de compreensão dos componentes e ajuste dos sistemas para uma tarefa específica. O custo do próprio desenvolvedor cresceu, o custo do produto junto com ele, os requisitos para novos desenvolvedores na equipe aumentaram drasticamente, pois eles também precisavam cobrir as responsabilidades da “estrela” de desenvolvimento e, naturalmente, as “estrelas” tornaram-se menos e menos disponíveis. Também vale a pena notar que, na minha experiência, poucos desenvolvedores estão interessados nas especificidades do processamento de pacotes pelo kernel do sistema operacional, nas regras de roteamento de pacotes e nos aspectos de segurança do host. O passo lógico foi atrair um administrador familiarizado com o assunto e atribuir-lhe responsabilidades semelhantes, o que, graças à sua experiência, permitiu atingir os mesmos indicadores a um custo inferior ao custo de um desenvolvimento “estrela”. Tais administradores eram colocados em uma equipe, e sua principal tarefa era gerenciar ambientes de teste e produção, de acordo com as regras de uma equipe específica, com recursos alocados para essa equipe específica. Foi assim que, de fato, o DevOps apareceu na mente da maioria.

Parcial ou totalmente, com o tempo, esses administradores de sistema começaram a entender as necessidades dessa equipe específica na área de desenvolvimento, como facilitar a vida de desenvolvedores e testadores, como lançar uma atualização e não ter que passar a noite na sexta-feira em escritório, corrigindo erros de implantação. O tempo passou e agora as “estrelas” eram os administradores de sistema que entendiam o que os desenvolvedores queriam. Para minimizar o impacto, começaram a surgir utilitários de gerenciamento; todos se lembraram dos métodos antigos e confiáveis de isolamento do nível do SO, que permitiam minimizar os requisitos de segurança, gerenciamento da parte da rede e configuração do host como um como um todo e, como resultado, reduzir os requisitos para novas “estrelas”.

Apareceu uma coisa “maravilhosa” - docker. Por que maravilhoso? Sim, apenas porque criar isolamento em um chroot ou jail, assim como OpenVZ, exigia conhecimento não trivial do sistema operacional, ao contrário, o utilitário permite simplesmente criar um ambiente de aplicativo isolado em um determinado host com tudo o que você precisa dentro e à mão novamente nas rédeas do desenvolvimento, e o administrador do sistema só pode gerenciar com apenas um host, garantindo sua segurança e alta disponibilidade - uma simplificação lógica. Mas o progresso não pára e os sistemas voltam a tornar-se cada vez mais complexos, há cada vez mais componentes, um host já não satisfaz as necessidades do sistema e é necessário construir clusters, voltamos novamente aos administradores de sistema que são capaz de construir esses sistemas.

Ciclo após ciclo, surgem vários sistemas que simplificam o desenvolvimento e/ou administração, surgem sistemas de orquestração, que, até que seja necessário desviar-se do processo padrão, são fáceis de usar. A arquitetura de microsserviços também surgiu com o objetivo de simplificar tudo o que foi descrito acima – menos relacionamentos, mais fácil de gerenciar. Na minha experiência, não encontrei uma arquitetura completamente de microsserviços, eu diria que 50 a 50 - 50 por cento dos microsserviços, caixas pretas, entraram, saíram processados, os outros 50 são um monólito rasgado, serviços incapazes de funcionar separadamente de outros componentes. Tudo isso novamente impôs restrições ao nível de conhecimento tanto dos desenvolvedores quanto dos administradores.

“Oscilações” semelhantes no nível de conhecimento especializado de um determinado recurso continuam até hoje. Mas divagando um pouco, há muitos pontos que merecem destaque.

Engenheiro de Construção/Engenheiro de Liberação

Engenheiros altamente especializados que surgiram como meio de padronizar processos e versões de construção de software. No processo de introdução do Agile generalizado, parece que eles deixaram de ser procurados, mas isso está longe de ser o caso. Essa especialização surgiu como forma de padronizar a montagem e entrega de software em escala industrial, ou seja, usando técnicas padrão para todos os produtos da empresa. Com o advento do DevOps, os desenvolvedores perderam parcialmente suas funções, pois foram os desenvolvedores que começaram a preparar o produto para entrega, e dada a mudança na infraestrutura e a abordagem para entregar o mais rápido possível sem levar em conta a qualidade, com o tempo eles se transformaram em um obstáculo às mudanças, uma vez que a adesão aos padrões de qualidade inevitavelmente atrasa as entregas. Assim, gradualmente, parte da funcionalidade dos engenheiros de Build/Release migrou para os ombros dos administradores de sistema.

As operações são tão diferentes

Seguimos em frente e novamente a presença de um grande leque de responsabilidades e a falta de pessoal qualificado empurra-nos para uma especialização rigorosa, como cogumelos depois da chuva, aparecem várias Operações:

TechOps - administradores de sistema enikey, também conhecidos como HelpDesk Engineer
LiveOps – administradores de sistema responsáveis principalmente pelos ambientes de produção
CloudOps – administradores de sistemas especializados em nuvens públicas Azure, AWS, GCP, etc.
PlatOps/InfraOps/SysOps – administradores de sistemas de infraestrutura.
NetOps - administradores de rede
SecOps - administradores de sistema especializados em segurança da informação - conformidade com PCI, conformidade com CIS, patches, etc.

DevOps é (em teoria) uma pessoa que entende em primeira mão todos os processos do ciclo de desenvolvimento – desenvolvimento, teste, entende a arquitetura do produto, é capaz de avaliar riscos de segurança, está familiarizado com abordagens e ferramentas de automação, pelo menos em alto nível. Além disso, o nível também compreende pré e pós-processamento, suporte ao lançamento do produto. Uma pessoa capaz de atuar como defensora tanto das Operações como do Desenvolvimento, o que permite uma cooperação favorável entre estes dois pilares. Compreende os processos de planejamento do trabalho das equipes e gerenciamento das expectativas dos clientes.

Para realizar este tipo de trabalho e responsabilidades, esta pessoa deve ter meios para gerenciar não apenas os processos de desenvolvimento e teste, mas também o gerenciamento da infraestrutura do produto, bem como o planejamento de recursos. O DevOps nesse entendimento não pode estar localizado nem na TI, nem no P&D, nem mesmo no PMO; ele deve ter influência em todas essas áreas – o diretor técnico da empresa, o Chief Technical Officer.

Isso é verdade na sua empresa? - Duvido. Na maioria dos casos, trata-se de TI ou P&D.

A falta de fundos e a capacidade de influenciar pelo menos uma destas três áreas de actividade irá transferir o peso dos problemas para onde estas mudanças são mais fáceis de aplicar, tais como a aplicação de restrições técnicas às liberações relacionadas com códigos “sujos” de acordo com dados estáticos. sistemas analisadores. Ou seja, quando o PMO estabelece um prazo rigoroso para o lançamento da funcionalidade, o P&D não consegue produzir um resultado de alta qualidade dentro desses prazos e o produz da melhor maneira possível, deixando a refatoração para depois, o DevOps relacionado à TI bloqueia o lançamento por meios técnicos . A falta de autoridade para mudar a situação, no caso dos funcionários responsáveis, leva à manifestação de hiper-responsabilidade por aquilo que não podem influenciar, principalmente se esses funcionários entendem e veem os erros, e como corrigi-los - “Bem-aventurança é ignorância”, e como consequência ao esgotamento e perda desses colaboradores.

Mercado de recursos DevOps

Vejamos diversas vagas para cargos de DevOps de diferentes empresas.

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

Você possui o Zabbix e sabe o que é Prometheus;

Iptables;

Aluno de doutorado do BASH;

Professor Ansível;

GuruLinux;

Saber usar depuração e encontrar problemas de aplicações junto com desenvolvedores (php/java/python);

O roteamento não deixa você histérico;

Preste muita atenção à segurança do sistema;

Faça backup de “tudo e qualquer coisa” e também restaure com sucesso esse “tudo e qualquer coisa”;

Você sabe configurar o sistema de forma a tirar o máximo do mínimo;

Configure a replicação antes de dormir no Postgres e MySQL;

Configurar e ajustar o CI/CD é tão necessário para você quanto o café da manhã/almoço/jantar.

Ter experiência com AWS;

Pronto para desenvolver com a empresa;

Assim:

de 1 a 6 - administrador do sistema
7 - um pouco de administração de rede, que cabe também no administrador do sistema, nível médio
8 - um pouco de segurança, obrigatória para um administrador de sistema de nível médio
9-11 – Administrador de sistema intermediário
12 — Dependendo das tarefas atribuídas, Administrador de Sistema Médio ou Engenheiro de Construção
13 - Virtualização - Middle System Administrator, ou o chamado CloudOps, conhecimento avançado dos serviços de um determinado site de hospedagem, para uso eficiente de recursos e redução da carga de manutenção

Resumindo essa vaga, podemos dizer que Administrador de Sistemas Médio/Sênior é suficiente para a galera.

A propósito, você não deve dividir fortemente os administradores em Linux/Windows. Claro, eu entendo que os serviços e sistemas desses dois mundos são diferentes, mas a base para todos é a mesma e qualquer administrador que se preze está familiarizado com um e outro, e mesmo que não esteja familiarizado, será não será difícil para um administrador competente se familiarizar com ele.

Vamos considerar outra vaga:

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

Excelente conhecimento de sistema operacional Linux, software de sistema geral e web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);

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

Proficiência em linguagens de script;

Compreensão dos princípios de funcionamento das redes de protocolo de rede;

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

Independência e iniciativa;

Vamos olhar para:

1 – Administrador de Sistema Sênior
2 - Dependendo do significado colocado nesta pilha - Administrador de Sistema Médio/Sênior
3 - Experiência profissional, inclusive, pode significar - “O cluster não levantou, mas criou e gerenciou máquinas virtuais, havia um host Docker, o acesso aos contêineres não estava disponível” - Administrador Médio do Sistema
4 - Administrador de Sistema Júnior - sim, um administrador que não sabe escrever scripts básicos de automação, independente do idioma, não um administrador - enikey.
5 - Administrador de sistema intermediário
6 – Administrador de Sistema Sênior

Para resumir - Administrador de Sistema Médio/Sênior

Mais um:

Experiência Devops;

Experiência no uso de um ou mais produtos para criar processos de CI/CD. Gitlab CI será uma vantagem;

Trabalhando com containers e virtualização; Se você usou o docker, ótimo, mas se usou o k8s, ótimo!

Experiência de trabalho em equipe ágil;

Conhecimento de qualquer linguagem de programação;

Vamos ver:

1 - Hmm... O que os caras querem dizer? =) Provavelmente eles próprios não sabem o que está escondido por trás disso
2 - Engenheiro de Construção
3 - Administrador de sistema intermediário
4 - Soft skills, não vamos considerar isso por enquanto, embora Agile seja outra coisa que é interpretada de uma forma que é conveniente.
5 - Muito detalhado - pode ser uma linguagem de script ou compilada. Eu me pergunto se escrever em Pascal e Basic na escola será adequado para eles? =)

Gostaria também de deixar uma observação em relação ao ponto 3, a fim de reforçar a compreensão do porquê deste ponto ser abordado pelo administrador do sistema. Kubernetes é apenas uma orquestração, uma ferramenta que agrupa comandos diretos para drivers de rede e hosts de virtualização/isolamento em alguns comandos e permite que você torne a comunicação com eles abstrata, só isso. Por exemplo, vamos pegar o Make 'build framework', que, aliás, não considero um framework. Sim, eu conheço a moda de empurrar Make em qualquer lugar, onde é necessário e onde não é necessário - embrulhar Maven em Make, por exemplo, sério?
Essencialmente, Make é apenas um wrapper sobre o shell que simplifica a compilação, vinculação e comandos do ambiente de compilação, assim como o k8s.

Certa vez entrevistei um cara que usava k8s em seu trabalho em cima do OpenStack, e ele falou sobre como implantou serviços nele, porém, quando perguntei sobre o OpenStack, descobriu-se que ele era administrado, bem como levantado pelo sistema administradores. Você realmente acha que uma pessoa que instalou o OpenStack, independente da plataforma que use por trás dele, não é capaz de usar o k8s? =)
Este candidato não é realmente um DevOps, mas um Administrador de Sistema e, para ser mais preciso, um Administrador Kubernetes.

Vamos resumir mais uma vez - Administrador de Sistema Médio/Sênior será suficiente para eles.

Quanto pendurar em gramas

A faixa salarial proposta para as vagas indicadas é de 90k-200k
Agora gostaria de traçar um paralelo entre as recompensas monetárias dos administradores de sistema e dos engenheiros de DevOps.

Em princípio, para simplificar, você pode espalhar as notas com base na experiência profissional, embora isso não seja exato, mas para os fins do artigo será suficiente.

Experiência:

até 3 anos – Júnior
até 6 anos – Médio
mais de 6 – Sênior

O site de pesquisa de funcionários oferece:
Administradores do sistema:

Júnior - 2 anos - 50 mil rublos.
Médio - 5 anos - 70 mil rublos.
Sênior - 11 anos - 100 mil rublos.

Engenheiros DevOps:

Júnior - 2 anos - 100 mil rublos.
Médio - 3 anos - 160 mil rublos.
Sênior - 6 anos - 220 mil rublos.

De acordo com a experiência do “DevOps”, foi utilizada experiência que de alguma forma afetou o SDLC.

Do exposto conclui-se que de facto as empresas não necessitam de DevOps, e também que poderiam poupar pelo menos 50 por cento dos custos inicialmente planeados contratando um Administrador; além disso, poderiam definir mais claramente as responsabilidades da pessoa que procuram e preencha a necessidade mais rapidamente. Não devemos esquecer também que uma divisão clara de responsabilidades permite-nos reduzir as necessidades de pessoal, bem como criar um ambiente mais favorável na equipa, devido à ausência de sobreposições. A grande maioria das vagas está repleta de utilidades e rótulos DevOps, mas não são baseadas em requisitos reais para um Engenheiro DevOps, apenas solicitações para um administrador de ferramentas.

O processo de formação de engenheiros DevOps também se limita apenas a um conjunto de obras específicas, utilidades, e não fornece uma compreensão geral dos processos e suas dependências. Certamente é bom quando uma pessoa pode implantar AWS EKS usando Terraform, em conjunto com o sidecar Fluentd neste cluster e a pilha AWS ELK para o sistema de log em 10 minutos, usando apenas um comando no console, mas se ele não entender o princípio de processar os próprios logs e para que eles são necessários, se você não sabe como coletar métricas sobre eles e rastrear a degradação do serviço, ainda será o mesmo enikey que sabe usar alguns utilitários.

A demanda, no entanto, cria oferta, e vemos um mercado extremamente superaquecido para a posição de DevOps, onde os requisitos não correspondem à função real, mas apenas permitem que os administradores de sistema ganhem mais.

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

Como viver mais?

Os empregadores devem formular os requisitos com mais precisão e procurar exatamente aqueles que são necessários, e não lançar rótulos. Você não sabe o que o DevOps faz – nesse caso, você não precisa deles.

Trabalhadores - Aprenda. Aprimore constantemente seus conhecimentos, observe o panorama geral dos processos e acompanhe o caminho até seu objetivo. Você pode se tornar quem quiser, basta tentar.

Fonte: habr.com

Quem são DevOps?