Por el momento, esta es casi la posición más cara del mercado. El ajetreo y el bullicio de los ingenieros de DevOps supera todos los límites imaginables, y mucho menos con los ingenieros de DevOps.
Trabajo como jefe del departamento de integración y automatización, adivina el descifrado en inglés: DevOps Manager. Es poco probable que la decodificación en inglés refleje exactamente nuestras actividades diarias, pero la versión rusa en este caso es más precisa. Por la naturaleza de mi actividad, es natural que necesite entrevistar a futuros miembros de mi equipo y, durante el año pasado, unas 50 personas pasaron por mí, y la misma cantidad se cortó en la pantalla con mis empleados.
Todavía estamos buscando colegas, porque detrás de la etiqueta DevOps hay una capa muy grande de varios tipos de ingenieros.
Todo lo escrito a continuación es mi opinión personal, no está obligado a estar de acuerdo con él, pero admito que le dará un toque a su actitud sobre el tema. A pesar del riesgo de caer en desgracia, publico mi opinión, porque creo que tiene un lugar para estar.
Las empresas entienden de manera diferente quiénes son los ingenieros de DevOps y, en aras de contratar rápidamente un recurso, cuelgan esta etiqueta para todos. La situación es bastante extraña, porque las empresas están dispuestas a pagar recompensas poco realistas a estas personas, recibiendo, en la mayoría de los casos, una herramienta de administración para ellas.
Entonces, ¿quiénes son los ingenieros de DevOps?
Comencemos con la historia: las operaciones de desarrollo aparecieron como un paso más hacia la optimización de la interacción en pequeños equipos para aumentar la velocidad de producción del producto, como consecuencia esperada. La idea era fortalecer el equipo de desarrollo con conocimiento de procedimientos y enfoques en la gestión del entorno del producto. En otras palabras, el desarrollador debe comprender y saber cómo funciona su producto bajo ciertas condiciones, debe comprender cómo implementar su producto, qué características ambientales debe ajustar para aumentar la productividad. Entonces, durante algún tiempo, los desarrolladores aparecieron con el enfoque DevOps. Los desarrolladores de DevOps escribieron scripts de compilación y empaquetado para simplificar sus actividades y el rendimiento de un entorno productivo. Sin embargo, la complejidad de la arquitectura de decisión y la influencia mutua de los componentes de la infraestructura a lo largo del tiempo comenzaron a empeorar el rendimiento de los entornos, con cada iteración, se requería una comprensión cada vez más profunda de ciertos componentes, reduciendo la productividad del propio desarrollador debido al costo adicional de comprender los componentes y los sistemas de ajuste para una tarea específica. . El costo del propio desarrollador estaba creciendo, el costo del producto junto con él, los requisitos para los nuevos desarrolladores en el equipo aumentaron bruscamente, porque también tenían que cubrir las responsabilidades de la "estrella" del desarrollo y, naturalmente, la "estrella" se hizo menos accesible. También vale la pena señalar que, en mi experiencia, pocos desarrolladores están interesados en los detalles del procesamiento de paquetes por parte del núcleo del sistema operativo, las reglas de enrutamiento de paquetes y los aspectos de seguridad del host. El paso lógico fue atraer a un administrador que esté familiarizado con esta responsabilidad particular y asignarle la responsabilidad de un formato similar, lo que, gracias a su experiencia, hizo posible lograr los mismos indicadores a un costo menor en comparación con el costo de la "estrella" del desarrollo. Dichos administradores se colocaron en un equipo y su tarea principal era administrar entornos de prueba y productivos, basados en las reglas de un equipo en particular, con recursos asignados a este equipo en particular. Entonces, de hecho, DevOps apareció en la opinión de la mayoría.
Parcial o completamente, con el tiempo, estos administradores de sistemas comenzaron a comprender las necesidades de este equipo en particular en el campo de desarrollo, cómo simplificar la vida de los desarrolladores y evaluadores, cómo implementar la actualización y no pasar la noche en la oficina el viernes, reparando los errores de implementación. Con el paso del tiempo, ahora los administradores de sistemas que entienden lo que quieren los desarrolladores se están convirtiendo en las "estrellas". Para minimizar el impacto, las utilidades de administración comenzaron a ponerse al día, todos recordaron los métodos antiguos y confiables de aislar el nivel del sistema operativo, que permitieron minimizar los requisitos de seguridad, administrar la parte de la red y la configuración del host en su conjunto y, como resultado, reducir los requisitos para las nuevas "estrellas".
Ha aparecido una cosa "maravillosa": acoplador. ¿Por qué maravilloso? Sí, solo porque crear aislamiento en chroot o en la cárcel, así como OpenVZ, requería un conocimiento no trivial del sistema operativo, en una utilidad de contador que le permite simplemente crear un entorno de aplicación aislado en un determinado host con todo lo que necesita dentro y transferir las riendas al desarrollo nuevamente, y solo administrar al administrador del sistema solo un host, lo que garantiza su seguridad y alta disponibilidad, una simplificación lógica. Pero el progreso no se detiene y los sistemas se vuelven cada vez más complicados, cada vez más componentes, un host ya no satisface las necesidades del sistema y es necesario construir clusters, nuevamente volvemos a los administradores de sistemas que pueden construir estos sistemas.
Ciclo a ciclo, aparecen varios sistemas que simplifican el desarrollo y / o la administración, aparecen sistemas de orquestación que, hasta que necesite alejarse del proceso estándar, son fáciles de usar. La arquitectura de microservicios también pareció simplificar todo lo descrito anteriormente: menos relaciones, más fácil de administrar. En mi experiencia, no encontré una arquitectura de microservicio completo, diría que 50 a 50 - 50 por ciento de los microservicios, cajas negras, entraron, procesaron, los otros 50 - un monolito roto, servicios que no pueden funcionar por separado de otros componentes. Todo esto nuevamente impuso restricciones en el nivel de conocimiento de los desarrolladores y administradores.
"Cambios" similares del nivel de conocimiento experto de un recurso en particular continúan hasta nuestros días. Pero estábamos un poco distraídos, hay muchos puntos que vale la pena destacar.
Ingeniero de construcción / ingeniero de lanzamiento
Ingenieros muy altamente especializados que aparecieron como un medio para estandarizar los procesos de ensamblaje de software y sus lanzamientos. En el proceso de introducir el Agile a granel, parecería que dejaron de tener demanda, pero esto está lejos de ser el caso. Esta especialización ha aparecido como un medio de estandarización del ensamblaje y entrega de software a escala industrial, es decir. utilizando técnicas estándar para todos los productos de la empresa. Con el advenimiento de DevOps, los desarrolladores han perdido parcialmente sus funciones, ya que fueron los desarrolladores quienes comenzaron a preparar el producto para la entrega, y dada la infraestructura cambiante y el enfoque para la entrega más rápida sin importar la calidad, con el tiempo se convirtieron en un obstáculo para los cambios, ya que el cumplimiento de los estándares de calidad ralentiza inevitablemente las entregas. Entonces, gradualmente, parte de la funcionalidad de Build / Release de los ingenieros migró a los hombros de los administradores del sistema.
Ops es muy diferente
Avanzamos y nuevamente la presencia de una amplia gama de responsabilidades y la falta de personal calificado nos empuja a una especialización difícil, como los hongos después de la lluvia, aparecen varias Operaciones:
- TechOps: administradores de sistemas enike, también conocidos como ingeniero de soporte técnico
- LiveOps: los administradores del sistema son los principales responsables de los entornos productivos
- CloudOps: administradores de sistemas especializados en "nubes" públicas de Azure, AWS, GCP, etc.
- PlatOps / InfraOps / SysOps: administradores de sistemas de infraestructura.
- NetOps - Administradores de red
- SecOps: administradores de sistemas especializados en seguridad de la información: cumplimiento de PCI, cumplimiento de CIS, parches, etc.
DevOps: (en teoría) una persona que conoce de primera mano todos los procesos del ciclo de desarrollo: el desarrollo, las pruebas, la comprensión de la arquitectura del producto, es capaz de evaluar los riesgos de seguridad, está familiarizado con los enfoques y medios de automatización, al menos a un alto nivel, y también comprende el pre y el post Soporte de lanzamiento del producto. Una persona puede abogar tanto por Operaciones como por Desarrollo, lo que permite construir una cooperación favorable entre los dos pilares. Comprender los procesos de planificación del equipo y gestionar las expectativas del cliente.
Para realizar este tipo de trabajo y responsabilidades, esta persona debe tener los medios para controlar no solo el desarrollo, las pruebas, sino también la gestión de la infraestructura del producto, así como la planificación de recursos. DevOps en este sentido no puede ubicarse ni en TI, en I + D, ni siquiera en PMO, debería tener influencia en todas estas áreas: el director técnico de la compañía, el Oficial Técnico Jefe.
¿Es esto así en su empresa? Lo dudo. En la mayoría de los casos, esto es TI o I + D.
La falta de fondos y la posibilidad de influir en al menos una de estas tres líneas de negocio desplazará el peso de los problemas al lado en el que estos cambios son más fáciles de aplicar, como la aplicación de restricciones técnicas en las liberaciones en relación con el código "sucio" de acuerdo con los datos de los sistemas analizadores estáticos. Es decir, cuando la PMO establece un plazo estricto para el lanzamiento de la funcionalidad, la I + D no puede dar un resultado de alta calidad dentro de estos plazos y lo da como puede, dejando la refactorización para más tarde, DevOps relacionado con TI, por medios técnicos bloquea el lanzamiento. La falta de autoridad para cambiar la situación, en el caso de los empleados responsables, lleva a la manifestación de hiperresponsabilidad por lo que no pueden influir, además, si estos empleados entienden y ven los errores, y cómo solucionarlos es "Felicidad en la ignorancia", y como resultado agotamiento y pérdida de estos empleados.
Recursos de Market DevOps
Veamos algunas vacantes de DevOps de diferentes compañías.
Estamos listos para reunirnos con usted si usted:
- Poseer Zabbix y saber qué es Prometeo;
- Iptables;
- Estudiante de Posgrado BASH;
- Profesor Ansible;
- Gurú de Linux
- Sepa cómo usar la depuración y encuentre problemas de aplicación junto con los desarrolladores (php / java / python);
- El enrutamiento no te causa berrinches;
- Prestar mucha atención a la seguridad del sistema;
- Copia de seguridad de "todo y todo", y también restaurar con éxito este "todo y todo";
- Usted sabe cómo configurar el sistema para exprimir un mínimo - máximo;
- Configurar la replicación a la hora de acostarse en Postgres y MySQL;
- Configurar y ajustar CI / CD para usted es una necesidad como desayuno / almuerzo / cena.
- Tener experiencia con AWS;
- Listo para desarrollar con la empresa;
Entonces
- 1 a 6 - administrador del sistema
- 7 - un poco de administración de red, que también encaja en el administrador del sistema, nivel medio
- 8 - un poco de seguridad, que es obligatorio para un administrador del sistema de nivel medio
- 9-11 - Administrador del sistema medio
- 12 - Dependiendo del conjunto de tareas, Administrador del sistema medio o Ingeniero de construcción
- 13 - Virtualización: administrador del sistema intermedio, o CloudOps, conocimiento avanzado de los servicios de una plataforma de alojamiento particular, para el uso eficiente de fondos y reducir la carga en el servicio
Resumiendo esta vacante, podemos decir que el Administrador del Sistema Medio / Superior es suficiente para los chicos.
Por cierto, no separe fuertemente a los administradores en Linux / Windows. Por supuesto, entiendo que los servicios y sistemas de estos dos mundos son diferentes, pero todos tienen una base y cualquier administrador que se respete a sí mismo está familiarizado con uno u otro, e incluso si no está familiarizado, no será difícil que un administrador competente se familiarice con esto.
Considere otra vacante:
- Experiencia en la construcción de sistemas altamente cargados;
- Excelente conocimiento del sistema operativo Linux, el software de todo el sistema y la pila web (Nginx, PHP / Python, HAProxy, MySQL / PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
- Experiencia con sistemas de virtualización (KVM, VMWare, LXC / Docker);
- Conocimiento de lenguajes de script;
- Comprender los principios de operación de redes de protocolos de red;
- Comprender los principios de la construcción de sistemas tolerantes a fallas;
- Independencia e iniciativa;
Parse:
- 1 - Administrador principal del sistema
- 2 - Dependiendo del significado invertido en esta pila - Administrador del sistema medio / superior
- 3 - La experiencia, incluida, puede significar: "El clúster no se levantó, sino que creó y administró máquinas virtuales, había un host Docker, el acceso a los contenedores fue forzado" - Administrador del sistema intermedio
- 4 - Administrador del sistema junior: sí, el administrador no puede escribir scripts de automatización elementales, independientemente del idioma, no de la administración.
- 5 - Administrador del sistema medio
- 6 - Administrador principal del sistema
Resumiendo - Administrador del sistema medio / superior
Otro:
- Experiencia devops;
- Experiencia en el uso de uno o más productos para formar procesos de CI / CD. Gitlab CI será una ventaja;
- Trabajar con contenedores y virtualización; Si usó docker, bien, pero si k8s, ¡genial!
- Experiencia en un equipo ágil;
- Conocimiento de cualquier lenguaje de programación;
A ver:
- 1 - Hmm ... ¿qué quieren decir los chicos? =) Lo más probable es que ellos mismos no sepan qué hay detrás
- 2 - Ingeniero de construcción
- 3 - Administrador del sistema medio
- 4 - Soft-skill, aún no lo consideraremos, aunque Agile es una cosa más que se interpreta como conveniente.
- 5 - Demasiado voluminoso: puede ser un lenguaje de script o compilado. Curiosamente, ¿escribió en la escuela sobre Pascal y Basic? =)
También me gustaría dejar un comentario sobre 3 puntos para fortalecer la comprensión de por qué este punto está cubierto por el administrador del sistema. Kubernetes es solo una orquestación, una herramienta que envuelve comandos directos a controladores de red y hosts de virtualización / aislamiento en un par de comandos y le permite hacer que la comunicación con ellos sea abstracta, eso es todo. Por ejemplo, tome la marca 'build framework', que, por cierto, no considero como un marco. Sí, conozco la moda de empujar Make en cualquier lugar, donde es necesario y no necesario: envolver Maven en Make, por ejemplo, ¿en serio?
En esencia, Make es solo un contenedor sobre el shell, que simplifica la compilación, el enlace, el entorno de compilación, así como los k8.
Una vez, entrevisté a un tipo que usaba k8s en su trabajo además de OpenStack, y habló sobre cómo implementar servicios en él, sin embargo, cuando le pregunté sobre OpenStack, resultó que estaba siendo administrado, además de ser criado por los administradores del sistema. ¿Realmente crees que la persona que creó OpenStack, independientemente de la plataforma que use detrás de él, no puede usar k8s? =)
Este solicitante no es DevOps, sino el mismo administrador del sistema y, para ser más precisos, el administrador de Kubernetes.
Resumimos nuevamente: el administrador del sistema intermedio / superior será suficiente para ellos.
Cuánto colgar en gramos
La distribución de los salarios ofrecidos para las vacantes indicadas es 90k-200k
Ahora me gustaría establecer un paralelismo entre las recompensas monetarias de los Administradores del sistema y los Ingenieros DevOps.
En principio, para simplificar, puede dispersar grados de experiencia, aunque esto no será preciso, para los fines del artículo es suficiente.
Experiencia:
- menores de 3 años - Junior
- menores de 6 años - Medio
- más de 6 - Senior
El sitio de búsqueda de empleados ofrece:
Administradores del sistema:
- Junior - 2 años - 50k rub.
- Medio - 5 años - 70k rublos.
- Senior - 11 años - 100k rublos.
Ingenieros DevOps:
- Junior - 2 años - 100k rub.
- Medio - 3 años - 160k rub.
- Senior - 6 años - 220k rub.
Según la experiencia de "DevOps", utilizamos la experiencia, al menos de alguna manera afectando el SDLC.
De lo anterior se deduce que, de hecho, las empresas no necesitan DevOps, y también que podrían ahorrar al menos el 50 por ciento de los costos originalmente planificados al contratar al Administrador, además, podrían determinar más claramente las responsabilidades de la persona y cerrar rápidamente la necesidad. No olvide que una división clara de responsabilidades le permite reducir los requisitos de personal, así como crear una atmósfera más favorable en el equipo, debido a la ausencia de intersecciones. La gran mayoría de las vacantes están llenas de utilidades y etiquetas de DevOps, sin embargo, en realidad no tienen los requisitos para DevOps Engineer, solo son solicitudes del administrador administrador.
El proceso de capacitación de ingenieros de DevOps también está limitado solo por un conjunto de trabajos específicos, utilidades, no proporciona una comprensión general de los procesos y sus dependencias. Sin duda, es bueno cuando una persona puede usar Terraform para implementar AWS EKS, junto con el auto lateral Fluentd en este clúster y la pila AWS ELK para el sistema de registro en 10 minutos, usando solo un comando en la consola, pero si no comprende el principio del procesamiento registros y por qué son necesarios, para no saber cómo recopilar métricas sobre ellos y rastrear la degradación del servicio, entonces será la misma enikey, capaz de usar algunas utilidades.
Sin embargo, la demanda crea oferta, y vemos un mercado extremadamente sobrecalentado para la posición de DevOps, donde los requisitos no corresponden al rol real, sino que solo permiten que los administradores del sistema ganen más.
¿Quiénes son ellos? ¿DevOps o administradores codiciosos del sistema? =)
¿Cómo vivir más?
Para los empleadores: es más preciso formular requisitos y buscar exactamente a los que se necesitan, y no dispersar las etiquetas. No sabe lo que hace DevOps; no los necesita en este caso.
Trabajadores - Aprender. Mejore constantemente su conocimiento, mire la imagen general de los procesos y rastree el camino hacia la meta. Puedes convertirte en lo que quieras, solo tienes que intentarlo.