No momento, essa é quase a posição mais cara do mercado. A agitação em torno dos engenheiros de DevOps excede todos os limites imagináveis, muito menos com os engenheiros seniores de DevOps.
Eu trabalho como chefe do departamento de integração e automação, acho que a descriptografia em inglês - DevOps Manager. É improvável que a decodificação em inglês reflita exatamente nossas atividades diárias, mas a versão em russo neste caso é mais precisa. Pela natureza do meu trabalho, é natural que eu precise entrevistar os futuros membros da minha equipe e, no ano passado, cerca de 50 pessoas passaram por mim, e a mesma quantia foi cortada na tela com meus funcionários.
Ainda estamos procurando colegas, porque por trás do rótulo DevOps há uma camada muito grande de vários tipos de engenheiros.
Tudo o que está escrito abaixo é minha opinião pessoal, você não é obrigado a concordar com isso, mas admito que isso trará um toque à sua atitude em relação ao tópico. Apesar do risco de cair em desgraça, publico minha opinião, porque acredito que ele tem um lugar para estar.
As empresas entendem diferentemente quem são os engenheiros do DevOps e, com o objetivo de contratar rapidamente um recurso, colocam esse rótulo para todos. A situação é bastante estranha, porque as empresas estão dispostas a pagar recompensas irrealistas a essas pessoas, recebendo, na maioria dos casos, uma ferramenta administrativa para elas.
Então, quem são os engenheiros de DevOps?
Vamos começar com a história - as Operações de Desenvolvimento apareceram como mais um passo para otimizar a interação em pequenas equipes para aumentar a velocidade de produção do produto, como uma conseqüência esperada. A idéia era fortalecer a equipe de desenvolvimento com conhecimento de procedimentos e abordagens no gerenciamento do ambiente do produto. Em outras palavras, o desenvolvedor deve entender e saber como seu produto funciona sob certas condições, deve entender como implantar seu produto, quais características ambientais devem ser reforçadas para aumentar a produtividade. Então, por algum tempo, os desenvolvedores apareceram com a abordagem DevOps. Os desenvolvedores do DevOps escreveram scripts de compilação e empacotamento para simplificar suas atividades e o desempenho de um ambiente produtivo. No entanto, a complexidade da arquitetura de decisão e a influência mútua dos componentes da infraestrutura ao longo do tempo começaram a piorar o desempenho dos ambientes, a cada iteração, era necessária uma compreensão cada vez mais profunda de determinados componentes, reduzindo a produtividade do próprio desenvolvedor devido ao custo adicional de entender os componentes e os sistemas de ajuste para uma tarefa específica . O custo do próprio desenvolvedor estava aumentando, o custo do produto e os requisitos para novos desenvolvedores da equipe aumentaram bastante, porque eles também tiveram que cobrir as responsabilidades da "estrela" do desenvolvimento e, naturalmente, a "estrela" se tornou menos acessível. Também é importante 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 que esteja familiarizado com essa responsabilidade específica e atribuir-lhe a responsabilidade de um formato semelhante, o que, graças à sua experiência, possibilitou alcançar os mesmos indicadores a um custo menor em comparação com o custo da "estrela" do desenvolvimento. Esses administradores foram colocados em uma equipe e sua principal tarefa era gerenciar ambientes produtivos e de teste, com base nas regras de uma equipe específica, com recursos alocados a essa equipe específica. Então, de fato, o DevOps apareceu na exibição majoritária.
Parcial ou completamente, com o tempo, esses administradores de sistema começaram a entender as necessidades dessa equipe específica no campo de desenvolvimento, como simplificar a vida de desenvolvedores e testadores, como implantar a atualização e não passar a noite no escritório na sexta-feira, corrigindo erros de implantação. Com o passar do tempo, agora os administradores de sistema que entendem o que os desenvolvedores querem estão se tornando as "estrelas". Para minimizar o impacto, os utilitários de gerenciamento começaram a recuperar o atraso, todos se lembraram dos métodos antigos e confiáveis de isolar o nível do sistema operacional, o que permitia minimizar os requisitos de segurança, gerenciar a parte da rede e a configuração do host como um todo e, como resultado, reduzir os requisitos para novas "estrelas".
Uma coisa “maravilhosa” apareceu - janela de encaixe. Por que maravilhoso? Sim, apenas porque criar isolamento no chroot ou na cadeia, assim como no OpenVZ, exigia um conhecimento não trivial do sistema operacional, em um utilitário de contador que permite criar simplesmente um ambiente de aplicativo isolado em um determinado host com tudo o que você precisa dentro e transferir as rédeas para o desenvolvimento novamente e gerenciar apenas o administrador do sistema 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 estão se tornando cada vez mais complicados, mais e mais componentes, um host não satisfaz mais as necessidades do sistema e é necessário criar clusters, voltamos novamente aos administradores de sistemas que são capazes de construir esses sistemas.
Ciclo a ciclo, vários sistemas aparecem que simplificam o desenvolvimento e / ou administração; os sistemas de orquestração parecem que, exatamente até que você precise se afastar do processo padrão, são fáceis de usar. A arquitetura de microsserviço também parecia simplificar tudo o que foi descrito acima - menos relacionamentos, mais fáceis de gerenciar. Na minha experiência, não encontrei uma arquitetura totalmente de microsserviço, diria que 50 a 50 - 50% dos microsserviços, caixas pretas, foram processados, os outros 50 - um monólito rasgado, serviços incapazes de trabalhar separadamente de outros componentes. Tudo isso impôs novamente restrições ao nível de conhecimento de desenvolvedores e administradores.
"Mudanças" similares do nível de conhecimento especializado de um recurso específico continuam até hoje. Mas estávamos um pouco distraídos, há muitos pontos que merecem destaque.
Engenheiro de construção / engenheiro de lançamento
Engenheiros altamente especializados que apareceram como um meio de padronizar os processos de montagem de software e seus lançamentos. No processo de introdução do Agile em massa, parece que eles deixaram de estar em demanda, mas isso está longe de ser o caso. Esta especialização apareceu como um meio de padronização da montagem e entrega de software em escala industrial, isto é, usando técnicas padrão para todos os produtos da empresa. Com o advento do DevOps, os desenvolvedores perderam parcialmente suas funções, já que foram os desenvolvedores que começaram a preparar o produto para entrega e, dada a mudança na infraestrutura e a abordagem para a entrega mais rápida sem levar em conta a qualidade, com o tempo se transformaram em uma barreira para as mudanças, uma vez que a adesão aos padrões de qualidade diminui inevitavelmente as entregas. Assim, gradualmente, parte da funcionalidade Build / Release dos engenheiros migrou para os ombros dos administradores de sistema.
Ops é tão diferente
Seguimos em frente e novamente a presença de uma ampla gama de responsabilidades e a falta de pessoal qualificado nos leva a uma forte especialização, como cogumelos depois da chuva, várias operações aparecem:
- TechOps - administradores de sistema da enike, também conhecidos como HelpDesk Engineer
- LiveOps - administradores de sistema responsáveis principalmente por ambientes produtivos
- CloudOps - administradores de sistema especializados em "nuvens" públicas do 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, aplicação de patches etc.
DevOps - (em teoria) uma pessoa que conhece em primeira mão todos os processos do ciclo de desenvolvimento - desenvolvimento, teste, compreensão da arquitetura do produto, é capaz de avaliar riscos de segurança, familiarizado com as abordagens e ferramentas de automação, pelo menos em um nível alto, e também entende o pré e o pós suporte à liberação do produto. Uma pessoa é capaz de defender tanto Operações quanto Desenvolvimento, o que permite construir uma cooperação favorável entre os dois pilares. Compreender os processos de planejamento da equipe e gerenciar as expectativas do cliente.
Para executar esse tipo de trabalho e responsabilidades, essa pessoa deve ter os meios para controlar não apenas o desenvolvimento, os testes, mas também o gerenciamento da infraestrutura do produto, bem como o planejamento de recursos. Os DevOps nesse sentido não podem estar localizados em TI, P&D, ou mesmo no PMO, devem ter influência em todas essas áreas - o diretor técnico da empresa, Chief Technical Officier.
Isso é verdade na sua empresa? Eu duvido. Na maioria dos casos, isso é TI ou P&D.
A falta de fundos e a possibilidade de influenciar pelo menos uma dessas três linhas de negócios transferem o peso dos problemas para o lado em que essas alterações são mais fáceis de aplicar, como a aplicação de restrições técnicas a liberações relacionadas a códigos sujos, de acordo com os dados dos sistemas de analisador estático. Ou seja, quando o PMO estabelece um prazo apertado para o lançamento da funcionalidade, a P&D não pode fornecer um resultado de alta qualidade dentro desses prazos e o permite, deixando a refatoração para mais tarde, DevOps relacionados à TI, por meios técnicos, bloqueia o lançamento. A falta de autoridade para mudar a situação, no caso de funcionários responsáveis, leva à manifestação de hiperresponsabilidade pelo que eles não podem influenciar, além disso, se esses funcionários entendem e veem os erros, e como corrigi-los é “Felicidade na ignorância” e, como resultado esgotamento e perda desses funcionários.
Market DevOps Resources
Vejamos algumas vagas de trabalho do DevOps de diferentes empresas.
Estamos prontos para encontrá-lo se você:
- Tenha o Zabbix e saiba o que é o Prometheus;
- Iptables;
- Estudante de Pós-Graduação BASH;
- Professor Ansible;
- Guru do Linux
- Saiba como usar o debug e encontre problemas de aplicativos junto com os desenvolvedores (php / java / python);
- O roteamento não causa birras;
- Preste atenção significativa à segurança do sistema;
- Faça backup de "tudo e tudo" e também restaure com êxito esse "tudo e tudo";
- Você sabe como configurar o sistema para extrair do mínimo - máximo;
- Configurar a replicação da hora de dormir no Postgres e MySQL;
- Instalar e ajustar o CI / CD para você é uma necessidade, como café da manhã / almoço / jantar.
- Ter experiência com a AWS;
- Pronto para desenvolver com a empresa;
Então:
- 1 a 6 - administrador do sistema
- 7 - um pouco de administração de rede, que também se encaixa no administrador do sistema, nível intermediário
- 8 - um pouco de segurança, obrigatória para um administrador de sistema de nível médio
- 9-11 - Administrador do sistema intermediário
- 12 - Dependendo das tarefas definidas, administrador do sistema intermediário ou engenheiro de construção
- 13 - Virtualização - Administrador do sistema intermediário, ou o chamado CloudOps, conhecimento avançado dos serviços de uma plataforma de hospedagem específica, para o uso eficiente dos fundos e a redução da carga no serviço
Resumindo esta vaga, podemos dizer que o Administrador do Sistema Médio / Sênior é suficiente para os caras.
A propósito, não separe fortemente os administradores no Linux / Windows. Obviamente, entendo que os serviços e sistemas desses dois mundos são diferentes, mas todos têm uma base e qualquer administrador que se respeite está familiarizado com um ou outro, e mesmo que ele não esteja familiarizado, não será difícil para um administrador competente se familiarizar com isso.
Considere outra vaga:
- Experiência na construção de sistemas altamente carregados;
- Excelente conhecimento do SO Linux, software para todo o sistema e pilha da Web (Nginx, PHP / Python, HAProxy, MySQL / PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Experiência com sistemas de virtualização (KVM, VMWare, LXC / Docker);
- Conhecimento de linguagens de script;
- Compreensão dos princípios de operação de redes de protocolos de rede;
- Compreender os princípios de construção de sistemas tolerantes a falhas;
- Independência e iniciativa;
Analisar:
- 1 - Administrador de sistema sênior
- 2 - Dependendo do significado investido nesta pilha - Administrador de Sistema Médio / Sênior
- 3 - Experiência, incluindo, pode significar - “O cluster não aumentou, mas criou e gerenciava máquinas virtuais, havia um host do Docker, o acesso aos contêineres era sobrecarregado” - Middle System Administrator
- 4 - Administrador júnior do sistema - sim, o administrador não pode escrever scripts de automação elementares, independentemente do idioma, não do administrador.
- 5 - Administrador do sistema intermediário
- 6 - Administrador de sistema sênior
Resumindo - Administrador de Sistema Médio / Sênior
Outro:
- Experiência devops;
- Experiência no uso de um ou mais produtos para formar processos de CI / CD. O IC do Gitlab será uma vantagem;
- Trabalhar com contêineres e virtualização; Se você usou o docker - ótimo, mas se o k8s - ótimo!
- Experiência em equipe ágil;
- Conhecimento de qualquer linguagem de programação;
Vamos ver:
- 1 - Hmm ... o que os caras querem dizer? =) Muito provavelmente eles próprios não sabem o que está por trás disso
- 2 - Engenheiro de Construção
- 3 - Administrador do sistema intermediário
- 4 - Soft-skill, ainda não o consideraremos, embora o Agile seja mais uma coisa que é interpretada como conveniente.
- 5 - Muito volumoso - pode ser uma linguagem de script ou compilada. Curiosamente, ele escreveu na escola sobre Pascal e Basic? =)
Gostaria também de deixar um comentário a respeito de três pontos, a fim de fortalecer a compreensão de por que esse ponto é coberto pelo administrador do sistema. O 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ê faça uma comunicação abstrata com eles, só isso. Por exemplo, considere o Make 'framework de construção', que, a propósito, não considero um framework. Sim, eu sei como empurrar o Make para qualquer lugar, onde é necessário e não necessário - envolver o Maven no Make, por exemplo, a sério?
Em essência, o Make é apenas um invólucro sobre o shell, o que simplifica a compilação, o vínculo, o ambiente de compilação e os k8s.
Certa vez, entrevistei um cara que usava k8s em seu trabalho, além do OpenStack, e ele falou sobre como implantar serviços nele, no entanto, quando perguntei sobre o OpenStack, verificou-se que ele estava sendo administrado e também gerado por administradores de sistema. Você realmente acha que a pessoa que criou o OpenStack, independentemente de qual plataforma ele usa atrás dele, não pode usar o k8s? =)
Na verdade, esse candidato não é o DevOps, mas o mesmo administrador do sistema e, para ser mais preciso, o administrador do Kubernetes.
Resumimos novamente - o Administrador do Sistema Médio / Sênior será suficiente para eles.
Quanto pendurar em gramas
A distribuição dos salários oferecidos para as vagas indicadas é de 90k-200k
Agora, gostaria de traçar um paralelo entre as recompensas monetárias dos Administradores do sistema e dos Engenheiros do DevOps.
Em princípio, para simplificar, você pode espalhar graus de experiência, embora isso não seja preciso, pois os objetivos do artigo são suficientes.
Experiência:
- menores de 3 anos - Júnior
- menores de 6 anos - Médio
- mais de 6 - Senior
O site de pesquisa de funcionários oferece:
Administradores do sistema:
- Junior - 2 anos - esfrega 50k.
- Médio - 5 anos - 70k rublos.
- Senior - 11 anos - 100k rublos.
Engenheiros do DevOps:
- Junior - 2 anos - 100k esfregar.
- Médio - 3 anos - esfrega 160k.
- Senior - 6 anos - 220k esfregar.
De acordo com a experiência do “DevOps”, usamos a experiência, afetando de alguma forma o SDLC.
Do exposto, segue-se que, de fato, as empresas não precisam do DevOps e também que poderiam economizar pelo menos 50% dos custos planejados originalmente contratando o Administrador; além disso, poderiam determinar mais claramente as responsabilidades da pessoa e fechar rapidamente a necessidade. Não se esqueça que uma divisão clara de responsabilidades permite reduzir as necessidades da equipe e criar um ambiente mais favorável na equipe, devido à ausência de cruzamentos. A grande maioria das vagas está cheia de utilitários e etiquetas do DevOps; no entanto, eles realmente não têm os requisitos para o DevOps Engineer, são apenas solicitações para o administrador administrador.
O processo de treinamento dos engenheiros do DevOps também é limitado apenas por um conjunto de trabalhos específicos, utilitários, não fornece uma compreensão geral dos processos e de suas dependências. Certamente é bom quando uma pessoa pode usar o Terraform para implantar o AWS EKS, em conjunto com o carro lateral Fluentd nesse cluster e a pilha do AWS ELK para o sistema de registro em 10 minutos, usando apenas um comando no console, mas se ele não entender o princípio do processamento logs e por que são necessários, para não saber como coletar métricas sobre eles e rastrear a degradação do serviço, será o mesmo processo, capaz de 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 obtenham mais.
Então quem são eles? DevOps ou administradores de sistema gananciosos? =)
Como viver mais?
Para os empregadores - é mais preciso formular requisitos e procurar exatamente aqueles que são necessários, e não os rótulos dispersos. Você não sabe o que os DevOps fazem - você não precisa deles neste caso.
Trabalhadores - Aprenda. Melhore constantemente seu conhecimento, observe a imagem geral dos processos e acompanhe o caminho para a meta. Você pode se tornar o que quiser, basta tentar.