¿Quiénes son DevOps?

Por el momento, esta es casi la posición más cara del mercado. El revuelo en torno a los ingenieros de “DevOps” está más allá de todos los límites imaginables, y es aún peor con los ingenieros senior de DevOps.
Trabajo como jefe del departamento de integración y automatización, adivina la decodificación en inglés: DevOps Manager. Es poco probable que la transcripción en inglés refleje nuestras actividades diarias, pero la versión rusa en este caso es más precisa. Debido a la naturaleza de mi actividad, es natural que necesite entrevistar a los futuros miembros de mi equipo, y durante el año pasado pasaron por mí unas 50 personas y el mismo número se cortó en la preselección con mis empleados.

Seguimos buscando compañeros, porque detrás de la etiqueta DevOps se esconde una capa muy grande de ingenieros de distintos tipos.

Todo lo escrito a continuación es mi opinión personal, no tienes por qué estar de acuerdo con ella, pero admito que agregará algo de color a tu actitud hacia el tema. A pesar del riesgo de caer en desgracia, publico mi opinión porque creo que tiene un lugar para estar.

Las empresas tienen diferentes ideas sobre quiénes son los ingenieros de DevOps y, con el fin de contratar rápidamente un recurso, les ponen esta etiqueta a todos. La situación es bastante extraña, ya que las empresas están dispuestas a pagar remuneraciones poco realistas a estas personas, recibiendo, en la mayoría de los casos, un administrador de herramientas para ellas.

Entonces, ¿quiénes son los ingenieros de DevOps?

Comencemos con la historia de su aparición: las Operaciones de Desarrollo aparecieron como un paso más hacia la optimización de la interacción en equipos pequeños para aumentar la velocidad de producción del producto, como consecuencia esperada. La idea era fortalecer el equipo de desarrollo con conocimientos 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 en determinadas condiciones, debe comprender cómo implementar su producto, qué características del entorno se pueden ajustar para mejorar el rendimiento. Entonces, desde hace algún tiempo, aparecieron desarrolladores con un enfoque DevOps. Los desarrolladores de DevOps escribieron scripts de compilación y empaquetado para simplificar sus actividades y el rendimiento del entorno de producción. Sin embargo, la complejidad de la arquitectura de la solución y la influencia mutua de los componentes de la infraestructura a lo largo del tiempo comenzaron a deteriorar el rendimiento de los entornos; con cada iteración, se requería un conocimiento cada vez más profundo de ciertos componentes, reduciendo la productividad del desarrollador debido al trabajo adicional. Costos de entender los componentes y sistemas de ajuste para una tarea específica. El costo del propio desarrollador creció, junto con él el costo del producto, los requisitos para los nuevos desarrolladores en el equipo aumentaron drásticamente, porque también necesitaban cubrir las responsabilidades de la "estrella" del desarrollo y, naturalmente, las "estrellas" se hicieron menos. y menos disponible. También vale la pena señalar que, según mi experiencia, pocos desarrolladores están interesados ​​en los aspectos específicos 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 esto y asignarle responsabilidades similares, lo que, gracias a su experiencia, permitió lograr los mismos indicadores a un costo menor en comparación con el costo de un desarrollo “estrella”. Estos administradores se ubicaban en un equipo y su tarea principal era gestionar los entornos de prueba y producción, de acuerdo con las reglas de un equipo específico, con recursos asignados a este equipo en particular. De hecho, así apareció DevOps en la mente 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 del desarrollo, cómo hacer la vida más fácil a los desarrolladores y evaluadores, cómo implementar una actualización y no tener que pasar la noche en la oficina. el viernes, corrigiendo errores de implementación. Pasó el tiempo y ahora las “estrellas” eran los administradores de sistemas que entendían lo que querían los desarrolladores. Para minimizar el impacto, comenzaron a surgir utilidades de administración, todos recordaron los métodos antiguos y confiables de aislamiento a nivel del sistema operativo, que permitieron minimizar los requisitos de seguridad, administración de la parte de la red y la configuración del host como un en su conjunto y, como resultado, reducir los requisitos para nuevas "estrellas".

Ha aparecido algo "maravilloso": Docker. ¿Por qué maravilloso? Sí, solo porque crear aislamiento en un chroot o jail, así como en OpenVZ, requería un conocimiento no trivial del sistema operativo; por el contrario, la utilidad le permite simplemente crear un entorno de aplicación aislado en un determinado host con todo lo necesario dentro y a mano. vuelve a tomar las riendas del desarrollo y el administrador del sistema sólo puede gestionar con un solo host, garantizando 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 complejos, cada vez hay más componentes, un host ya no satisface las necesidades del sistema y es necesario construir clústeres, nuevamente volvemos a los administradores de sistemas que son capaz de construir estos sistemas.

Ciclo tras ciclo, aparecen diversos sistemas que simplifican el desarrollo y/o la administración, aparecen sistemas de orquestación que, a menos que sea necesario desviarse del proceso estándar, son fáciles de usar. La arquitectura de microservicios también apareció con el objetivo de simplificar todo lo descrito anteriormente: menos relaciones, más fácil de administrar. En mi experiencia, no encontré una arquitectura completamente de microservicios, diría que entre el 50 y el 50: el 50 por ciento de los microservicios, cajas negras, entraron y salieron procesados, los otros 50 son un monolito roto, los servicios no pueden funcionar por separado de otros. componentes. Todo esto volvió a imponer restricciones al nivel de conocimiento tanto de los desarrolladores como de los administradores.

Hasta el día de hoy continúan “cambios” similares en el nivel de conocimiento experto de un recurso en particular. Pero nos desviamos un poco, hay muchos puntos que vale la pena destacar.

Ingeniero de construcción/Ingeniero de lanzamiento

Ingenieros muy especializados que surgieron como un medio para estandarizar los procesos de construcción y lanzamientos de software. En el proceso de introducción generalizada de Agile, parecería que dejaron de tener demanda, pero esto está lejos de ser el caso. Esta especialización apareció como un medio para estandarizar el montaje y entrega de software a escala industrial, es decir. utilizando técnicas estándar para todos los productos de la empresa. Con la llegada de DevOps, los desarrolladores perdieron 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 entregar lo más rápido posible sin importar la calidad, con el tiempo se convirtieron en un freno a los cambios, ya que el cumplimiento de los estándares de calidad inevitablemente ralentiza las entregas. Entonces, gradualmente, parte de la funcionalidad de los ingenieros de compilación/lanzamiento migró a los administradores de sistemas.

Las operaciones son tan diferentes

Seguimos adelante y nuevamente la presencia de un amplio abanico de responsabilidades y la falta de personal calificado nos empuja hacia una estricta especialización, como hongos después de la lluvia, aparecen diversas Operaciones:

• TechOps: administradores de sistemas enikey, también conocidos como ingeniero de soporte técnico
• LiveOps: administradores de sistemas principalmente responsables de los entornos de producción.
• CloudOps: administradores de sistemas especializados en nubes públicas 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 es (en teoría) una persona que comprende de primera mano todos los procesos del ciclo de desarrollo: desarrollo, pruebas, comprende la arquitectura del producto, es capaz de evaluar los riesgos de seguridad, está familiarizado con los enfoques y las herramientas de automatización, al menos en un nivel alto. El nivel, además de esto, también comprende el soporte de lanzamiento del producto previo y posterior al procesamiento. Una persona capaz de actuar como defensor tanto de Operaciones como de Desarrollo, lo que permita una cooperación favorable entre estos dos pilares. Entiende los procesos de planificación del trabajo por equipos y gestión de las expectativas del cliente.

Para realizar este tipo de trabajo y responsabilidades, esta persona debe tener los medios para gestionar no sólo los procesos de desarrollo y pruebas, sino también la gestión de la infraestructura del producto, así como la planificación de recursos. En este sentido, DevOps no puede ubicarse ni en TI, ni en I+D, ni siquiera en la PMO; debe tener influencia en todas estas áreas: el director técnico de la empresa, el director técnico.

¿Es esto cierto en su empresa? - Yo dudo. En la mayoría de los casos, se trata de TI o I+D.

La falta de fondos y de capacidad para influir en al menos una de estas tres áreas de actividad desplazará el peso de los problemas hacia donde estos cambios sean más fáciles de aplicar, como la aplicación de restricciones técnicas a las publicaciones relacionadas con código "sucio" según estándares estáticos. sistemas analizadores. Es decir, cuando la PMO establece un plazo estricto para el lanzamiento de la funcionalidad, I+D no puede producir un resultado de alta calidad dentro de estos plazos y lo produce lo mejor que puede, dejando la refactorización para más adelante, DevOps relacionado con TI bloquea el lanzamiento por medios técnicos. . La falta de autoridad para cambiar la situación, en el caso de los empleados responsables, conduce a la manifestación de una hiperresponsabilidad por aquello en lo que no pueden influir, especialmente si estos empleados comprenden y ven los errores y cómo corregirlos: "La bienaventuranza es la ignorancia". y como consecuencia al agotamiento y pérdida de estos empleados.

Mercado de recursos de DevOps

Veamos varias vacantes para puestos de DevOps de diferentes empresas.

Estamos listos para reunirnos con usted si:

1. Eres dueño de Zabbix y sabes qué es Prometheus;
2. Iptables;
3. Estudiante de doctorado de BASH;
4. Profesor Ansible;
5. Gurú de Linux;
6. Saber utilizar la depuración y encontrar problemas de aplicaciones junto con los desarrolladores (php/java/python);
7. El enrutamiento no te pone histérico;
8. Preste especial atención a la seguridad del sistema;
9. Haga una copia de seguridad de "todo y cualquier cosa" y también restaure con éxito este "todo y cualquier cosa";
10. Sabe configurar el sistema de forma que se obtenga el máximo de lo mínimo;
11. Configure la replicación antes de acostarse en Postgres y MySQL;
12. Configurar y ajustar CI/CD es tan necesario para usted como el desayuno/almuerzo/cena.
13. Tener experiencia con AWS;
14. Listo para desarrollarse con la empresa;

Por lo tanto:

• del 1 al 6 - administrador del sistema
• 7 - una pequeña administración de red, que también encaja en el administrador del sistema, nivel medio
• 8 - un poco de seguridad, que es obligatoria para un administrador de sistema de nivel medio
• 9-11 – Administrador del sistema medio
• 12 — Dependiendo de las tareas asignadas, ya sea Administrador Intermedio del Sistema o Ingeniero de Construcción
• 13 - Virtualización - Administrador del sistema medio, o el llamado CloudOps, conocimiento avanzado de los servicios de un sitio de alojamiento específico, para el uso eficiente de los fondos y la reducción de la carga de mantenimiento.

Resumiendo esta vacante, podemos decir que Administrador de Sistemas Medio/Senior es suficiente para los muchachos.

Por cierto, no deberías dividir demasiado a los administradores en Linux/Windows. Por supuesto, entiendo que los servicios y sistemas de estos dos mundos son diferentes, pero la base para todos es la misma y cualquier administrador que se precie está familiarizado tanto con uno como con el otro, y aunque no lo esté, lo hará. No será difícil para un administrador competente familiarizarse con él.

Consideremos otra vacante:

1. Experiencia en la construcción de sistemas de alta carga;
2. Excelente conocimiento del sistema operativo Linux, software general del sistema y pila web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Experiencia con sistemas de virtualización (KVM, VMWare, LXC/Docker);
4. Dominio de lenguajes de programación;
5. Comprensión de los principios operativos de las redes de protocolos de red;
6. Comprensión de los principios de la construcción de sistemas tolerantes a fallos;
7. Independencia e iniciativa;

Miremos a:

• 1 – Administrador superior del sistema
• 2 - Dependiendo del significado puesto en esta pila - Administrador del sistema medio/superior
• 3 - Experiencia laboral, incluida, puede significar - "El clúster no generó, pero creó y administró máquinas virtuales, había un host Docker, el acceso a los contenedores no estaba disponible" - Administrador del sistema intermedio
• 4 - Administrador de sistemas junior: sí, un administrador que no sabe escribir scripts de automatización básicos, independientemente del idioma, no un administrador: enikey.
• 5 - Administrador del sistema medio
• 6 – Administrador superior del sistema

En resumen: administrador del sistema medio/senior

Uno mas

1. Experiencia en DevOps;
2. Experiencia en el uso de uno o más productos para crear procesos CI/CD. Gitlab CI será una ventaja;
3. Trabajar con contenedores y virtualización; Si usaste Docker, bien, pero si usaste k8s, ¡genial!
4. Experiencia trabajando en un equipo ágil;
5. 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 lo que se esconde detrás de esto.
• 2 - Ingeniero de construcción
• 3 - Administrador del sistema medio
• 4 - Soft Skill, no lo consideraremos por ahora, aunque Agile es otra cosa que se interpreta de forma conveniente.
• 5 - Demasiado detallado: podría ser un lenguaje de programación o uno compilado. Me pregunto si escribir en Pascal y Basic en la escuela les convendrá. =)

También me gustaría dejar una nota sobre el punto 3 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, tomemos Make 'construir marco', que, por cierto, no considero un marco. Sí, conozco la moda de enviar Make a cualquier lugar, donde sea necesario y no necesario: envolver Maven en Make, por ejemplo, ¿en serio?
Básicamente, Make es solo un contenedor sobre el shell, que simplifica los comandos de compilación, vinculación y entorno de compilación, al igual que k8s.

Una vez entrevisté a un tipo que usaba k8s en su trabajo sobre OpenStack y habló sobre cómo implementaba servicios en él, sin embargo, cuando le pregunté sobre OpenStack, resultó que era administrado y generado por el sistema. administradores. ¿De verdad crees que una persona que ha instalado OpenStack, independientemente de la plataforma que utilice detrás de él, no es capaz de utilizar k8s? =)
Este solicitante no es en realidad un DevOps, sino un administrador del sistema y, para ser más precisos, un administrador de Kubernetes.

Resumamos una vez más: el administrador del sistema medio/senior será suficiente para ellos.

Cuánto colgar en gramos

El rango de salarios propuestos para las vacantes indicadas es 90k-200k
Ahora me gustaría establecer un paralelo entre las recompensas monetarias de los administradores de sistemas y los ingenieros de DevOps.

En principio, para simplificar las cosas, puedes dispersar las calificaciones en función de la experiencia laboral, aunque esto no será exacto, pero a los efectos del artículo será suficiente.

Experiencia:

1. hasta 3 años – Junior
2. hasta 6 años – Medio
3. más de 6 – Senior

El sitio de búsqueda de empleados ofrece:
Administradores del sistema:

1. Junior - 2 años - 50k frotar.
2. Mediano - 5 años - 70k frotar.
3. Senior - 11 años - 100k frotar.

Ingenieros de DevOps:

1. Junior - 2 años - 100k frotar.
2. Mediano - 3 años - 160k frotar.
3. Senior - 6 años - 220k frotar.

Según la experiencia de “DevOps”, se utilizó experiencia que al menos de alguna manera afectó al SDLC.

De lo anterior se desprende que en realidad las empresas no necesitan DevOps, y además podrían ahorrar al menos el 50 por ciento de los costos inicialmente planificados contratando a un Administrador; además, podrían definir más claramente las responsabilidades de la persona que buscan. y cubrir la necesidad más rápido. Tampoco debemos olvidar que una clara división de responsabilidades nos permite reducir los requisitos de personal, así como crear un ambiente más favorable en el equipo, debido a la ausencia de superposiciones. La gran mayoría de las vacantes están llenas de utilidades y etiquetas DevOps, pero no se basan en requisitos reales para un ingeniero DevOps, solo solicitudes para un administrador de herramientas.

El proceso de formación de ingenieros de DevOps también se limita únicamente a un conjunto de trabajos y utilidades específicos y no proporciona una comprensión general de los procesos y sus dependencias. Ciertamente es bueno cuando una persona puede implementar AWS EKS usando Terraform, junto con el sidecar 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 de procesamiento de registros en sí y para qué se necesitan, si no sabe cómo recopilar métricas sobre ellos y rastrear la degradación del servicio, seguirá siendo el mismo enikey quien sepa cómo usar algunas utilidades.

Sin embargo, la demanda crea oferta y vemos un mercado extremadamente sobrecalentado para el puesto DevOps, donde los requisitos no corresponden al rol real, sino que sólo permiten a los administradores de sistemas ganar más.

Entonces ¿quiénes son? ¿DevOps o administradores de sistemas codiciosos? =)

Como vivir

Los empleadores deberían formular los requisitos con mayor precisión y buscar exactamente aquellos que se necesitan, y no tirar etiquetas. No sabes lo que hacen los DevOps; en ese caso, no los necesitas.

Trabajadores - Aprenda. Mejore constantemente sus conocimientos, observe el panorama general de los procesos y siga el camino hacia su objetivo. Puedes convertirte en quien quieras, sólo tienes que intentarlo.

Fuente: habr.com