Polo momento, esta é case a posición máis cara do mercado. O alboroto polos enxeñeiros "DevOps" está máis aló de todos os límites imaxinables, e aínda peor cos enxeñeiros seniores de DevOps.
Traballo como xefe do departamento de integración e automatización, adiviño que a decodificación en inglés - DevOps Manager. É improbable que a transcrición en inglés reflicta as nosas actividades diarias, pero a versión rusa neste caso é máis precisa. Debido á natureza da miña actividade, é natural que necesite entrevistar aos futuros membros do meu equipo e, durante o ano pasado, pasaron por min unhas 50 persoas, e o mesmo número foi cortado na prescreen cos meus empregados.
Aínda estamos buscando compañeiros, porque detrás da etiqueta DevOps hai unha capa moi grande de diferentes tipos de enxeñeiros que se agochan.
Todo o escrito a continuación é a miña opinión persoal, non tes que estar de acordo con el, pero admito que lle dará algo de cor á túa actitude ante o tema. A pesar do risco de caer en desgracia, publico a miña opinión porque creo que ten un lugar onde estar.
As empresas teñen diferentes entendementos de quen son os enxeñeiros de DevOps e, para contratar rapidamente un recurso, colgan esta etiqueta en todos. A situación é bastante estraña, xa que as empresas están dispostas a pagarlles remuneracións pouco realistas a estas persoas, recibindo, na maioría dos casos, un administrador de ferramentas para elas.
Entón, quen son os enxeñeiros de DevOps?
Comecemos pola historia da súa aparición: as Operacións de Desenvolvemento apareceron como un paso máis para optimizar a interacción en equipos pequenos para aumentar a velocidade de produción do produto, como consecuencia esperada. A idea era reforzar o equipo de desenvolvemento co coñecemento dos procedementos e enfoques na xestión do entorno do produto. Noutras palabras, o desenvolvedor debe comprender e coñecer como funciona o seu produto en determinadas condicións, debe comprender como despregar o seu produto, que características do ambiente se poden axustar para mellorar o rendemento. Entón, durante algún tempo, apareceron desenvolvedores cun enfoque DevOps. Os desenvolvedores de DevOps escribiron scripts de compilación e empaquetado para simplificar as súas actividades e o rendemento do ambiente de produción. Non obstante, a complexidade da arquitectura da solución e a influencia mutua dos compoñentes da infraestrutura ao longo do tempo comezaron a deteriorar o rendemento dos ambientes; con cada iteración, requería unha comprensión cada vez máis profunda de determinados compoñentes, reducindo a produtividade do desenvolvedor debido ao aumento adicional. custos de comprensión dos compoñentes e sistemas de axuste para unha tarefa específica. O custo do propio desenvolvedor creceu, o custo do produto xunto con el, os requisitos para os novos desenvolvedores no equipo saltaron drasticamente, porque tamén necesitaban cubrir as responsabilidades da "estrela" de desenvolvemento e, naturalmente, as "estrelas" diminuíron. e menos dispoñibles. Tamén vale a pena sinalar que, na miña experiencia, poucos desenvolvedores están interesados nos aspectos específicos do procesamento de paquetes polo núcleo do sistema operativo, as regras de enrutamento de paquetes e os aspectos de seguridade do host. O paso lóxico era atraer a un administrador familiarizado con isto e asignarlle responsabilidades similares, o que, grazas á súa experiencia, permitiu acadar os mesmos indicadores a un custo menor en comparación co custo dun desenvolvemento "estrela". Estes administradores foron colocados nun equipo e a súa principal tarefa era xestionar os ambientes de proba e produción, segundo as normas dun equipo específico, con recursos destinados a este equipo en concreto. Así é como, de feito, DevOps apareceu na mente da maioría.
Parcial ou completamente, co paso do tempo, estes administradores do sistema comezaron a comprender as necesidades deste equipo en particular no campo do desenvolvemento, como facilitar a vida aos desenvolvedores e probadores, como lanzar unha actualización e non ter que pasar a noite o venres en a oficina, corrixindo erros de implantación. Pasou o tempo, e agora as "estrelas" eran administradores do sistema que entendían o que querían os desenvolvedores. Para minimizar o impacto, comezaron a aparecer utilidades de xestión; todos lembraron os métodos antigos e fiables de illar o nivel do sistema operativo, o que permitiu minimizar os requisitos de seguridade, xestión da parte da rede e configuración do host como un todo e, como resultado, reducir os requisitos para novas "estrelas".
Apareceu unha cousa "marabillosa": docker. Por que marabilloso? Si, só porque a creación de illamento nun chroot ou cárcere, así como OpenVZ, requiría un coñecemento non trivial do SO, pola contra, a utilidade permítelle simplemente crear un ambiente de aplicación illado nun determinado host con todo o necesario dentro e a man. volve pasar ás rendas do desenvolvemento, e o administrador do sistema só pode xestionar cun só host, garantindo a súa seguridade e alta dispoñibilidade, unha simplificación lóxica. Pero o progreso non se detén e os sistemas volven ser cada vez máis complexos, cada vez hai máis compoñentes, un host xa non satisface as necesidades do sistema e é necesario construír clusters, volvemos aos administradores do sistema que están capaz de construír estes sistemas.
Ciclo tras ciclo, aparecen diversos sistemas que simplifican o desenvolvemento e/ou a administración, aparecen sistemas de orquestración que, ata que hai que desviarse do proceso estándar, son fáciles de usar. Tamén apareceu a arquitectura de microservizos co obxectivo de simplificar todo o descrito anteriormente: menos relacións, máis fácil de xestionar. Na miña experiencia, non atopei unha arquitectura de microservizos completamente, diría que entre o 50 e o 50 - 50 por cento dos microservizos, caixas negras, entraron, saíron procesados, os outros 50 son un monolito rasgado, os servizos non poden funcionar por separado doutros compoñentes. Todo isto volveu impoñer restricións ao nivel de coñecemento tanto de desenvolvedores como de administradores.
Os "oscilacións" similares no nivel de coñecemento experto dun recurso en particular continúan ata hoxe. Pero divagamos un pouco, hai moitos puntos que merecen destacar.
Enxeñeiro de construción/Enxeñeiro de lanzamento
Enxeñeiros moi especializados que xurdiron como un medio para estandarizar os procesos de compilación e versións de software. No proceso de introducir Agile xeneralizada, parece que deixaron de ser demandados, pero isto está lonxe de ser así. Esta especialización apareceu como un medio de estandarización da montaxe e entrega de software a escala industrial, é dicir. utilizando técnicas estándar para todos os produtos da empresa. Coa chegada de DevOps, os desenvolvedores perderon parcialmente as súas funcións, xa que foron os desenvolvedores os que comezaron a preparar o produto para a súa entrega e, dada a infraestrutura cambiante e o enfoque de entregar o máis rápido posible sen ter en conta a calidade, co paso do tempo convertéronse en un freo dos cambios, xa que o cumprimento dos estándares de calidade ralentiza inevitablemente as entregas. Entón, aos poucos, parte da funcionalidade dos enxeñeiros de compilación/liberación migrou aos ombreiros dos administradores do sistema.
As operacións son moi diferentes
Seguimos unha e outra vez a presenza dun amplo abano de responsabilidades e a falta de persoal cualificado empurranos cara a unha estrita especialización, como cogomelos despois da choiva, aparecen diversas Operacións:
- TechOps - administradores de sistemas enikey tamén coñecido como Enxeñeiro de HelpDesk
- LiveOps: administradores do sistema responsables principalmente dos ambientes de produción
- CloudOps: administradores de sistemas especializados en nubes públicas Azure, AWS, GCP, etc.
- PlatOps/InfraOps/SysOps - administradores de sistemas de infraestrutura.
- NetOps - administradores de rede
- SecOps - administradores de sistemas especializados en seguridade da información - conformidade con PCI, cumprimento CIS, parcheo, etc.
DevOps é (en teoría) unha persoa que entende de primeira man todos os procesos do ciclo de desenvolvemento: desenvolvemento, probas, entende a arquitectura do produto, é capaz de avaliar os riscos de seguridade, está familiarizado cos enfoques e ferramentas de automatización, polo menos a un alto nivel. nivel, ademais disto, tamén entende o soporte para o lanzamento do produto previo e posterior ao procesamento. Unha persoa capaz de actuar como defensor tanto de Operacións como de Desenvolvemento, que permita unha cooperación favorable entre estes dous piares. Comprende os procesos de planificación do traballo en equipos e xestión das expectativas dos clientes.
Para realizar este tipo de traballos e responsabilidades, esta persoa debe ter os medios para xestionar non só os procesos de desenvolvemento e probas, senón tamén a xestión da infraestrutura do produto, así como a planificación dos recursos. Neste sentido, DevOps non se pode localizar nin en TI, nin en I+D nin sequera no PMO; debe ter influencia en todas estas áreas: o director técnico da empresa, o director técnico xefe.
Isto é certo na súa empresa? - Dubido. Na maioría dos casos, trátase de TI ou I+D.
A falta de fondos e a capacidade de influír polo menos nunha destas tres áreas de actividade desprazará o peso dos problemas cara a onde estes cambios sexan máis fáciles de aplicar, como a aplicación de restricións técnicas ás versións en relación co código "sucio" segundo o estático. sistemas analizadores. É dicir, cando o PMO establece un prazo estrito para o lanzamento da funcionalidade, a I+D non pode producir un resultado de alta calidade dentro destes prazos e prodúceo como pode, deixando a refactorización para máis tarde, DevOps relacionado coas TI bloquea o lanzamento por medios técnicos. . A falta de autoridade para cambiar a situación, no caso dos empregados responsables, leva á manifestación de hiperresponsabilidade polo que non poden influír, especialmente se estes empregados entenden e ven erros, e como corrixilos - "A felicidade é a ignorancia", e como consecuencia ao burnout e perda destes empregados.
Mercado de recursos DevOps
Vexamos varias vacantes para postos de DevOps de diferentes empresas.
Estamos preparados para reunirnos contigo se:
- Vostede é o propietario de Zabbix e sabe o que é Prometeo;
- Iptables;
- BASH estudante de doutoramento;
- profesor Ansible;
- Linux Guru;
- Saber utilizar a depuración e atopar problemas de aplicacións xunto cos desenvolvedores (php/java/python);
- A ruta non te fai histérico;
- Preste moita atención á seguridade do sistema;
- Fai unha copia de seguranza de "todo e calquera cousa" e tamén restaura con éxito este "todo e calquera cousa";
- Sabe configurar o sistema de forma que saque o máximo do mínimo;
- Configure a replicación antes de durmir en Postgres e MySQL;
- Configurar e axustar CI/CD é tan necesario para ti como o almorzo, o xantar ou a cea.
- Ter experiencia con AWS;
- Listo para desenvolverse coa empresa;
Así:
- de 1 a 6 - administrador do sistema
- 7 - unha pequena administración de rede, que tamén encaixa no administrador do sistema, nivel medio
- 8 - un pouco de seguridade, que é obrigatorio para un administrador do sistema de nivel medio
- 9-11 – Administrador do sistema medio
- 12 — Dependendo das tarefas asignadas, xa sexa Administrador do sistema medio ou Enxeñeiro de construción
- 13 - Virtualización - Administrador do sistema medio, ou o chamado CloudOps, coñecemento avanzado dos servizos dun sitio de hospedaxe específico, para o uso eficiente dos fondos e reducindo a carga de mantemento.
Resumindo esta vacante, podemos dicir que para os mozos é suficiente o Administrador do Sistema Medio/Senior.
Por certo, non deberías dividir moito aos administradores en Linux/Windows. Por suposto, entendo que os servizos e os sistemas destes dous mundos son diferentes, pero a base para todos é a mesma e calquera administrador que se prece estea familiarizado tanto cun como co outro, e aínda que non estea familiarizado, non será difícil para un administrador competente familiarizarse con el.
Consideremos outra vacante:
- Experiencia na construción de sistemas de alta carga;
- Excelente coñecemento do sistema operativo Linux, software xeral do sistema e pila web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Experiencia con sistemas de virtualización (KVM, VMWare, LXC/Docker);
- Competencia en linguaxes de guión;
- Comprensión dos principios de funcionamento das redes de protocolo de rede;
- Comprensión dos principios de construción de sistemas tolerantes a fallos;
- Independencia e iniciativa;
Vexamos:
- 1 – Administrador superior de sistemas
- 2 - Segundo o significado que se poña nesta pila - Administrador do sistema medio/senior
- 3 - A experiencia laboral, incluíndo, pode significar: "O clúster non creou, pero creou e xestionou máquinas virtuais, había un host Docker, o acceso aos contedores non estaba dispoñible" - Administrador do sistema medio
- 4 - Administrador junior do sistema - si, un administrador que non sabe como escribir scripts de automatización básicos, independentemente do idioma, non un administrador - enikey.
- 5 - Administrador do sistema intermedio
- 6 – Administrador superior de sistemas
Para resumir - Administrador de sistema medio/sénior
Outro:
- experiencia Devops;
- Experiencia no uso dun ou máis produtos para crear procesos CI/CD. Gitlab CI será unha vantaxe;
- Traballar con contedores e virtualización; Se usaches docker, ben, pero se usaches k8s, xenial!
- Experiencia traballando nun equipo áxil;
- Coñecemento de calquera linguaxe de programación;
Vexamos:
- 1 - Hmm... Que queren dicir os rapaces? =) O máis probable é que eles mesmos non saiban o que se esconde detrás
- 2 - Enxeñeiro de obras
- 3 - Administrador do sistema intermedio
- 4 - Soft skill, non o consideraremos polo momento, aínda que Agile é outra cousa que se interpreta de forma conveniente.
- 5 - Demasiado detallado: pode ser unha linguaxe de script ou compilada. Pregúntome se escribir en Pascal e Basic na escola lles vai ben? =)
Tamén me gustaría deixar unha nota sobre o punto 3 para reforzar a comprensión de por que o administrador do sistema cubre este punto. Kubernetes é só unha orquestración, unha ferramenta que envolve comandos directos aos controladores de rede e aos anfitrións de virtualización/illamento nun par de comandos e permítelle facer que a comunicación con eles sexa abstracta, iso é todo. Por exemplo, tomemos 'build framework' Make, que, por certo, non considero un marco. Si, sei sobre a moda de empuxar Make en calquera lugar, onde sexa necesario e non necesario - envolver Maven en Make, por exemplo, en serio?
Esencialmente, Make é só un envoltorio sobre o shell, simplificando os comandos do contorno de compilación, ligazón e compilación, igual que k8s.
Unha vez, entrevistei a un rapaz que usaba k8s no seu traballo enriba de OpenStack, e falou sobre como implantou os servizos nel, sen embargo, cando preguntei sobre OpenStack, resultou que estaba administrado, así como que o xeraba o sistema. administradores. Realmente pensas que unha persoa que instalou OpenStack, independentemente da plataforma que use detrás del, non é capaz de usar k8s? =)
Este solicitante non é realmente un DevOps, senón un administrador do sistema e, para ser máis precisos, un administrador de Kubernetes.
Resumimos unha vez máis: o administrador do sistema medio/senior será suficiente para eles.
Canto pesar en gramos
O rango de soldos propostos para as prazas indicadas é de 90k-200k
Agora gustaríame facer un paralelismo entre as recompensas monetarias dos administradores de sistemas e dos enxeñeiros de DevOps.
En principio, para simplificar as cousas, podes espallar as notas en función da experiencia laboral, aínda que isto non será exacto, pero para os efectos do artigo será suficiente.
Unha experiencia:
- ata 3 anos – Junior
- ata 6 anos – Medio
- máis de 6 – Senior
O sitio de busca de empregados ofrece:
Administradores do sistema:
- Junior - 2 anos - 50k fregar.
- Medio - 5 anos - 70k fregar.
- Senior - 11 anos - 100k fregar.
Enxeñeiros de DevOps:
- Junior - 2 anos - 100k fregar.
- Medio - 3 anos - 160k fregar.
- Senior - 6 anos - 220k fregar.
Segundo a experiencia de "DevOps", utilizouse unha experiencia que polo menos afectou dalgunha forma ao SDLC.
Do anterior despréndese que de feito as empresas non necesitan DevOps, e tamén que poderían aforrar polo menos o 50 por cento dos custos inicialmente previstos mediante a contratación dun Administrador; ademais, poderían definir máis claramente as responsabilidades da persoa que buscan. e cubrir a necesidade máis rápido. Tampouco debemos esquecer que unha clara división de responsabilidades permite reducir as esixencias de persoal, así como crear un ambiente máis favorable no equipo, debido á ausencia de solapamentos. A gran maioría das vacantes están cheas de utilidades e etiquetas de DevOps, pero non se basean nos requisitos reais para un enxeñeiro de DevOps, só en solicitudes de administrador de ferramentas.
O proceso de formación dos enxeñeiros de DevOps tamén se limita só a un conxunto de traballos específicos, utilidades e non proporciona unha comprensión xeral dos procesos e das súas dependencias. Sen dúbida é bo cando unha persoa pode implementar AWS EKS usando Terraform, xunto co sidecar Fluentd neste clúster e a pila AWS ELK para o sistema de rexistro en 10 minutos, usando só un comando na consola, pero se non entende o principio de procesar os rexistros e para que son necesarios, se non sabe como recoller métricas sobre eles e rastrexar a degradación do servizo, entón seguirá sendo o mesmo enikey quen sabe como usar algunhas utilidades.
A demanda, con todo, crea oferta e vemos un mercado extremadamente superenriquecido para a posición de DevOps, onde os requisitos non se corresponden co papel real, senón que só permiten aos administradores do sistema gañar máis.
Entón, quen son? DevOps ou administradores de sistemas codiciosos? =)
Como seguir vivindo?
Os empresarios deberían formular os requisitos con máis precisión e buscar exactamente os que sexan necesarios, e non tirar etiquetas. Non sabes o que fan DevOps; nese caso non os necesitas.
Traballadores - Aprender. Mellora constantemente o teu coñecemento, mira a imaxe xeral dos procesos e fai un seguimento do camiño cara ao teu obxectivo. Podes converterte en quen queiras, só tes que probar.
Fonte: www.habr.com