¿Quiénes son los DevOps?

En este momento, esta es sin duda una de las posiciones más caras del mercado. La agitación en torno a los ingenieros de 'DevOps' supera todos los límites imaginables, y todavía es peor con los ingenieros Senior DevOps.
Trabajo como líder del departamento de integración y automatización; adivinen la traducción al inglés: DevOps Manager. ¿Refleja realmente esta traducción nuestra actividad diaria? Dudo que lo haga, pero la variante en ruso es más precisa en este caso. Debido a mi trabajo, es natural que deba entrevistar a los futuros miembros de mi equipo, y en el último año, he revisado alrededor de 50 personas, y tantas más fueron eliminadas en la preselección con mis empleados.

Todavía estamos buscando colegas, ya que detrás del sello de DevOps se esconde una gran variedad de ingenieros de diferentes tipos.

Todo lo que se escribe a continuación es mi opinión personal; no están obligados a estar de acuerdo, sin embargo, admito que podría influir en su perspectiva sobre el tema. A pesar del riesgo de desagrado, publico mi opinión porque creo que tiene su lugar.

Las empresas entienden de diversas maneras quiénes son los ingenieros de DevOps, y para una contratación rápida, otorgan esta etiqueta a todos. La situación es bastante extraña, ya que las empresas están dispuestas a pagar recompensas desorbitadas a estas personas, recibiendo a menudo, en la mayoría de los casos, a un administrador con herramientas.

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

Comencemos con la historia de su aparición: Development Operations surgió 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 resultado esperado. La idea era fortalecer al equipo de desarrollo con conocimientos sobre los procedimientos y enfoques en la gestión del entorno del producto. En otras palabras, un desarrollador debe entender cómo funciona su producto en diferentes condiciones, debe saber cómo desplegar su producto y qué características del entorno ajustar para mejorar el rendimiento. Así, durante un tiempo, aparecieron desarrolladores con un enfoque DevOps. Los desarrolladores DevOps escribían scripts de construcción y empaquetado para facilitar sus actividades y el funcionamiento del entorno productivo. Sin embargo, la complejidad de la arquitectura de las soluciones y la interacción mutua de los componentes de la infraestructura empezaron a deteriorar el rendimiento de los entornos con el tiempo; cada iteración requería una comprensión más profunda de ciertos componentes, reduciendo así la productividad del propio desarrollador debido a los costos adicionales de entender los componentes y ajustar los sistemas para tareas específicas. El costo propio del desarrollador aumentó, el costo del producto junto con él, y las demandas a los nuevos desarrolladores en el equipo se dispararon, ya que era necesario cubrir también las responsabilidades de la 'estrella' del desarrollo, y, naturalmente, estas 'estrellas' se volvieron cada vez menos accesibles. También cabe destacar que, en mi experiencia, poco interesaba a los desarrolladores las especificidades del procesamiento de paquetes por el núcleo del sistema operativo, las reglas de enrutamiento de paquetes y los aspectos de seguridad del host. Un paso lógico fue atraer a un administrador, que es precisamente quien está familiarizado con esto, y asignarle dichas responsabilidades, lo que, gracias a su experiencia, permitió alcanzar los mismos indicadores a un costo menor en comparación con el costo de la 'estrella' del desarrollo. Tales administradores se integraron en el equipo y su tarea principal era gestionar los entornos de prueba y productivos, según las reglas del equipo específico, con recursos asignados a ese equipo. Así, en realidad, es como surgieron los DevOps en la percepción de la mayoría.

Con el tiempo, estos administradores de sistemas comenzaron a comprender las necesidades de este equipo específico en el área de desarrollo, cómo facilitar la vida a los desarrolladores y probadores, y cómo desplegar actualizaciones sin tener que quedarse en la oficina el viernes por la noche corrigiendo errores de despliegue. A medida que pasaba el tiempo, los "estrellas" comenzaron a ser los administradores de sistemas que entendían lo que los desarrolladores deseaban. Para minimizar el impacto, empezaron a adoptar herramientas de gestión, y todos recordaron viejos y confiables métodos de aislamiento en el nivel del sistema operativo, que permitían minimizar los requisitos de seguridad, la gestión de la parte de red, así como la configuración del host en general, lo que a su vez redujo las exigencias a las nuevas "estrellas".

Apareció una "maravillosa" cosa: docker. ¿Por qué es maravillosa? Porque crear un aislamiento en chroot o jail, así como en OpenVZ, requería conocimientos no triviales del sistema operativo. Con esta herramienta, se permitía crear fácilmente un entorno aislado para aplicaciones en algún host, con todo lo necesario dentro, y devolver las riendas del desarrollo, mientras que el administrador de sistemas solo debía gestionar un host, asegurando 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, con más y más componentes; un solo host ya no satisface las necesidades del sistema y es necesario construir clústeres. Volvemos a depender de los administradores de sistemas que son capaces de construir estos sistemas.

Ciclo tras ciclo, aparecen diversos sistemas que simplifican el desarrollo y/o la administración, surgen sistemas de orquestación que, hasta que no se requiere desviarse del proceso estándar, son fáciles de usar. La arquitectura de microservicios también surgió con el objetivo de simplificar todo lo mencionado anteriormente: menos interconexiones, más fácil de gestionar. En mi experiencia, no he vivido una arquitectura de microservicios completamente establecida; diría que es un 50 a 50: el 50 por ciento son microservicios, cajas negras, lo que entra se procesa y sale; el otro 50 por ciento es un monolito desgarrado, servicios incapaces de funcionar independientemente de otros componentes. Todo esto volvió a imponer limitaciones en el nivel de conocimientos tanto de desarrolladores como de administradores.

Las «oscilaciones» en el nivel de conocimientos de expertos de un recurso determinado continúan hasta el día de hoy. Pero nos hemos desviado un poco, hay muchos aspectos que vale la pena abordar.

Ingeniero de Construcción / Ingeniero de Lanzamiento

Son ingenieros altamente especializados, surgidos como un medio para estandarizar los procesos de construcción de software y de sus lanzamientos. En el marco de la implementación masiva de Agile, pareciera que su demanda había disminuido, sin embargo, esto está lejos de ser cierto. Esta especialización surgió como un medio para estandarizar la construcción 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 han perdido en parte estas funciones, ya que ellos mismos empezaron a preparar el producto para su entrega, y considerando la cambiante infraestructura y el enfoque en una entrega lo más rápida posible sin tener en cuenta la calidad, con el tiempo se convirtieron en un freno para los cambios, ya que adherirse a estándares de calidad inevitablemente ralentiza las entregas. Así, gradualmente, parte de las funciones de los ingenieros de Build/Release han recaído sobre los administradores de sistemas.

Ops diversos

Avanzamos y nuevamente la amplia gama de responsabilidades y la falta de personal cualificado nos empujan a una especialización estricta; como setas después de la lluvia, surgen diversas Operaciones:

• TechOps — administradores de sistemas de tipo HelpDesk
• LiveOps — administradores de sistemas, principalmente responsables de entornos productivos
• CloudOps — administradores de sistemas especializados en «nubes» públicas como Azure, AWS, GCP, etc.
• PlatOps / InfraOps / SysOps — administradores de sistemas de infraestructura.
• NetOps — administradores de redes
• SecOps — administradores de sistemas especializados en seguridad de la información — cumplimiento PCI, cumplimiento CIS, parches, etc.

DevOps — (en teoría) una persona que entiende todos los procesos del ciclo de desarrollo — desarrollo, pruebas, comprende la arquitectura del producto, capaz de evaluar los riesgos de seguridad, familiarizada con los enfoques y herramientas de automatización, al menos a un alto nivel, además, también entiende el soporte previo y posterior al lanzamiento del producto. Una persona capaz de abogar tanto por las operaciones como por el desarrollo, lo que permite construir una colaboración favorable entre estos dos pilares. Comprende los procesos de planificación del trabajo por parte de los equipos y la gestión de las expectativas del cliente.

Para llevar a cabo este tipo de trabajos y responsabilidades, esta persona debe contar con herramientas de gestión no solo para los procesos de desarrollo y pruebas, sino también para la gestión de la infraestructura del producto y la planificación de recursos. DevOps, en este entendimiento, no puede estar en IT, ni en I+D, ni siquiera en PMO, debe tener influencia en todas estas áreas: ser director técnico de la empresa, Chief Technical Officer.

¿Es así en su empresa? — Dudo. En la mayoría de los casos, es solo IT o I+D.

La falta de recursos y la capacidad de influir en al menos una de estas tres áreas de actividad producirá un desplazamiento del peso de los problemas hacia donde sea más fácil aplicar esos cambios, como por ejemplo, la imposición de limitaciones técnicas en los lanzamientos debido al 'código sucio' según los datos de los sistemas de análisis estático. Es decir, cuando PMO establece un plazo rígido para el lanzamiento de la funcionalidad, I+D no puede entregar un resultado de calidad en esos plazos y lo entrega como puede, dejando el refactorizado para después, DevOps que se relaciona con IT, mediante medios técnicos bloquea el lanzamiento. La falta de autoridad para cambiar la situación, en el caso de los empleados responsables lleva a una hiperresponsabilidad por algo sobre lo que no pueden influir, especialmente si estos empleados entienden y ven los errores, y cómo corregirlos — 'La felicidad está en la ignorancia', y como consecuencia, al agotamiento y la pérdida de estos empleados.

Mercado de recursos DevOps

Veamos algunas ofertas de trabajo para la posición de DevOps de varias empresas.

Estamos listos para reunirnos con usted si usted:

1. Domina Zabbix y sabe qué es Prometheus;
2. Iptables;
3. Estudiante de BASH;
4. Profesor de Ansible;
5. Guru de Linux;
6. ¿Sabes usar el depurador y trabajar junto con los desarrolladores para encontrar problemas en aplicaciones (php/java/python)?
7. El enrutamiento no te causa pánico;
8. Dedicas una atención significativa a la seguridad del sistema;
9. Haces copias de seguridad de "todo y de todos", y también restauras con éxito eso "todo y de todos";
10. ¿Sabes configurar el sistema para sacar el máximo provecho del mínimo?
11. Configuras réplicas antes de dormir en Postgres y MySQL;
12. La configuración y ajuste de CI/CD es para ti una necesidad como el desayuno/comida/cena.
13. Tienes experiencia trabajando con AWS;
14. Estás dispuesto a desarrollarte junto con la empresa;

Así que:

• del 1 al 6 — administrador de sistemas
• 7 — un poco de administración de redes, lo cual también se incluye en el nivel de administrador de sistemas, nivel Medio
• 8 — un poco de seguridad, que es obligatoria para un administrador de sistemas de nivel Medio
• 9-11 — Administrador de Sistemas Medio
• 12 — Dependiendo de las tareas asignadas, o Administrador de Sistemas Medio, o Ingeniero de Construcción
• 13 — Virtualización — Administrador de Sistemas Medio, o el llamado CloudOps, con conocimientos avanzados específicamente de los servicios de la hosting plataforma, para un uso efectivo de los recursos financieros y reducción de la carga en el mantenimiento

Resumiendo sobre esta vacante, se puede decir que para ellos basta con un Administrador de Sistemas Medio/Senior.

Por cierto, no hay que dividir demasiado a los administradores en Linux/Windows. Entiendo que los servicios y sistemas de estos dos mundos son diferentes, pero la base es la misma y cualquier administrador que se respete a sí mismo está familiarizado con ambos, y aunque no lo esté, para un buen administrador no será difícil familiarizarse con esto.

Consideremos otra vacante:

1. Experiencia en la construcción de sistemas de alta carga;
2. Excelentes conocimientos de sistemas operativos Linux, software de sistema general y stack web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Experiencia trabajando con sistemas de virtualización (KVM, VMWare, LXC/Docker);
4. Dominio de lenguajes de scripting;
5. Entendimiento de los principios de funcionamiento de redes y protocolos de red;
6. Entendimiento de los principios para la construcción de sistemas tolerantes a fallos;
7. Autonomía e iniciativa;

Desglosamos:

• 1 — Administrador de Sistemas Senior
• 2 — Dependiendo del sentido que se le dé a este stack — Administrador de Sistemas Medio/Senior
• 3 — La experiencia laboral también puede significar — "No levanté el clúster, pero creé y gestioné máquinas virtuales, había un host de Docker único, el acceso a los contenedores lo configuré" — Administrador de Sistemas Medio
• 4 — Administrador de Sistemas Junior — sí, un administrador que no puede escribir scripts básicos de automatización, independientemente del lenguaje, no es un administrador — es un simple técnico.
• 5 — Administrador de Sistemas Intermedio
• 6 — Administrador de Sistemas Senior

Resumiendo — Administrador de Sistemas Intermedio/Senior

Otra más:

1. Experiencia en devops;
2. Experiencia con uno o varios productos para la formación de procesos CI/CD. Gitlab CI será una ventaja;
3. Trabajo con contenedores y virtualización; Si usaron Docker – está bien, ¡y si usaron k8s – excelente!
4. Experiencia trabajando en un equipo ágil;
5. Conocimiento de algún lenguaje de programación;

Veamos:

• 1 — Hmm… ¿Qué quieren decir los chicos? =) Probablemente ellos mismos no saben lo que hay detrás de esto.
• 2 — Ingeniero de Construcción
• 3 — Administrador de Sistemas Intermedio
• 4 — Soft skills, no los consideraremos por ahora, aunque Agile es otra cosa que se interpreta como conviene.
• 5 — Es demasiado vago — puede ser un lenguaje de scripting o uno compilado. Me pregunto, ¿les bastará si escribí en Pascal y Basic en la escuela? =)

También me gustaría hacer un comentario sobre el punto 3, para reforzar la comprensión de por qué este punto lo cubre un administrador. Kubernetes es simplemente una orquestación, una herramienta que envuelve comandos directos a los controladores de red y a los hosts de virtualización/aislamiento en un par de comandos y permite que la comunicación con ellos sea abstracta, eso es todo. Por ejemplo, tomemos el ‘framework de construcción’ Make, que no considero un verdadero framework. Sí, sé de la moda de poner Make en todas partes donde no se necesita — ¿envolver Maven en Make, por ejemplo, en serio?
En esencia, Make es solo un envoltorio sobre shell, simplificando los comandos de compilación, vinculación y entorno de compilación, al igual que k8s.

Una vez, entrevisté a un chico que usaba k8s en su trabajo sobre OpenStack, y él contaba cómo desplegaba servicios en él, sin embargo, cuando pregunté precisamente sobre OpenStack, resultó que era administrado y levantado por administradores de sistemas. ¿Realmente creen que una persona que levantó OpenStack, independientemente de la plataforma que use detrás, no puede usar k8s? =)
Este solicitante en realidad no es DevOps, sino un simple Administrador de Sistemas y, para ser más preciso, Administrador de Kubernetes.

Resumiendo una vez más — un Administrador de Sistemas Intermedio/Senior será suficiente para ellos.

¿Cuánto colgar en gramos?

Rango de salarios propuestos para los puestos indicados — 90k-200k
Ahora me gustaría hacer una comparación entre las recompensas monetarias de los Administradores de Sistemas y los Ingenieros DevOps.

En principio, para simplificar, se podría clasificar los niveles según la experiencia laboral, aunque esto no será preciso; para los fines del artículo es suficiente.

Experiencia:

1. hasta 3 años — Junior
2. hasta 6 años — Middle
3. más de 6 años — Senior

El sitio de búsqueda de empleados ofrece:
Administradores de Sistemas:

1. Junior — 2 años — 50k rub.
2. Middle — 5 años — 70k rub.
3. Senior — 11 años — 100k rub.

Ingenieros DevOps:

1. Junior — 2 años — 100k rub.
2. Middle — 3 años — 160k rub.
3. Senior — 6 años — 220k rub.

Para la experiencia de los 'DevOps', se utilizó la experiencia que de alguna manera cubre el SDLC.

De lo anterior se deduce que, en realidad, las empresas no necesitan DevOps, y que podrían ahorrar al menos el 50 por ciento de los costos inicialmente previstos al contratar un Administrador. Además, podrían definir con mayor claridad las responsabilidades de la persona buscada y cubrir la necesidad más rápido. También es importante no olvidar que una clara división de responsabilidades permite reducir los requisitos al personal y crear un ambiente más favorable en el colectivo, debido a la falta de intersecciones. En la abrumadora mayoría de las ofertas de trabajo, abundan las herramientas y las etiquetas de DevOps, aunque no tengan un verdadero fundamento en los requisitos de un Ingeniero DevOps, sino que se parecen más a una solicitud para un administrador de herramientas.

El proceso de formación de los ingenieros DevOps también está limitado a un conjunto de trabajos específicos y herramientas, y no proporciona una comprensión general de los procesos y sus dependencias. Es bueno, por supuesto, cuando una persona puede desplegar AWS EKS usando Terraform, en combinación con un sidecar de Fluentd en este clúster y un stack AWS ELK para el sistema de logging en 10 minutos con solo un comando en la consola, pero si no entiende el principio de procesamiento de logs y para qué son necesarios, si no sabe cómo recoger métricas de ellos y vigilar la degradación del servicio, seguirá siendo el mismo 'enikey', capaz de usar algunas herramientas.

Sin embargo, la demanda genera la oferta, y vemos un mercado extremadamente caliente para la posición de DevOps, donde los requisitos no corresponden al verdadero rol y solo permiten que los administradores de sistemas ganen más.

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

¿Cómo seguir adelante?

Empleadores: definir mejor los requisitos y buscar exactamente a quienes se necesitan, sin dispersarse con etiquetas. Si no sabe qué hacen los DevOps, entonces no los necesita en este caso.

Empleados: aprender. Mejorar constantemente sus conocimientos, observar el panorama general de los procesos y seguir el camino hacia el objetivo establecido. Puedes convertirte en lo que quieras, solo necesitas esforzarte.

Fuente: habr.com