Get best of the week

Profesión DevOps-engineer: una vista del administrador del sistema



Trabajo como ingeniero DevOps en Parallels. Apoyo el desarrollo de varios servicios, escribo scripts para su implementación automática, me comunico estrechamente con el equipo de desarrollo. Te diré cómo se organiza el trabajo, cuánto pagan y para qué sirve el enfoque de DevOps para el desarrollo de software.

Todo comenzó con el hecho de que me resultaba aburrido trabajar como administrador del sistema, quería algo nuevo. Traté de desarrollar 1C, pero rápidamente me di cuenta de que esto no era mío. Aprendió Python, mejoró sus habilidades en sistemas Unix y fue a una entrevista en Parallels. Entonces no supe casi nada sobre DevOps, solo vine y dije: Quiero trabajar para ti. Dos meses después me llevaron.

¿Qué es DevOps?


Si le preguntas a 5 personas qué es DevOps, obtienes 5 respuestas diferentes. Para los evangelistas, esta es una cultura, o incluso más bien una transformación del pensamiento. Para los ingenieros, un conjunto de soluciones y herramientas. Para los gerentes, una metodología. Para los reclutadores: una profesión. Y para todos los demás, probablemente sea solo una palabra de moda.

La verdad, como siempre, está en algún punto intermedio. DevOps es todo lo anterior, en conjunto. Su tarea principal es acelerar la entrega del producto de la empresa al consumidor. El término en sí fue acuñado por el consultor independiente de TI Patrick Debois hace unos doce años. Quería romper el muro metafórico entre los desarrolladores (dev) y los administradores de sistemas (ops), combinarlos en una unidad efectiva, que pueda crear software más rápido, implementar lanzamientos con más frecuencia y con menos errores.

Por lo tanto, la base de DevOps es la idea de responsabilidad compartida, no hay división de poderes. El programador puede participar en la configuración si sabe mejor cómo escribir la configuración de su servicio, y el administrador del sistema en desarrollo. Cuando surge un problema, no se transfiere de un empleado a otro, como una pelota de ping-pong, sino que se vuelve común. Todos están involucrados en su eliminación.



Un minuto de estadísticas aburridas. Según la investigación de DORA (DevOps Research and Assessment), los equipos interfuncionales que utilizan el enfoque DevOps:

  • 208 veces más a menudo implementan código;
  • 106 veces reducen el tiempo desde el compromiso hasta la implementación;
  • Sistemas de restauración 2.604 veces más rápidos después de fallas;
  • 7 veces menor la posibilidad de falla como resultado de los cambios.

Por supuesto, combinar solo dev y ops no conduce a tal eficiencia. El enfoque de DevOps incluye el uso de muchas nuevas herramientas de desarrollo, prueba e implementación para organizar CI \ CD (el concepto de integración y entrega continua). Entre los más famosos:

  • Git y GitHub - sistemas de gestión de código fuente;
  • Jenkins: un servidor de automatización para crear canalizaciones de CI / CD;
  • Docker: software para automatizar la implementación y la administración de aplicaciones en entornos con soporte para contenedorización;
  • Kubernetes: un sistema de orquestación de contenedores abiertos;
  • Chef, Puppet and Ansible: herramientas para configuración e implementación automáticas;
  • Selenium - solución de automatización de prueba;
  • Prometheus y Nagios - software de monitoreo del servidor;
  • Grafana es una solución para recopilar y analizar métricas.

Al mismo tiempo, no existe un conjunto universal de herramientas adecuadas para todas las empresas, ni existe un camino único para DevOps. Solo hay lo que funciona o, por el contrario, no funciona en su infraestructura. Asisto regularmente a conferencias y varios eventos, me comunico con colegas de otras compañías y puedo decir que el 80% de las cosas que usan en Parallels no son particularmente aplicables.

Cada organización tiene su propio producto, su propia pila de tecnología y sus cuellos de botella. Por lo tanto, el enfoque de la optimización es muy diferente. A veces hay que cambiar la arquitectura de los servicios en sí, algunos son tan complejos o inflexibles que es difícil transferirles el enfoque de DevOps.

La esencia del ingeniero DevOps


En un nivel básico, un ingeniero de DevOps es un especialista técnico que comprende todas las etapas principales del ciclo de vida del desarrollo de software, corrige los cuellos de botella en los procesos y ajusta el entorno:

  • Escribe código para la implementación automatizada de aplicaciones
  • parcialmente responsable de su disponibilidad, no personalmente como administrador del sistema, sino con su equipo;
  • conlleva un deber sobre su infraestructura (comprende los errores, a veces junto con un programador).

La automatización es lo que recae sobre los hombros de un ingeniero DevOps en primer lugar. La creación de un producto de TI con el enfoque tradicional es la siguiente: el programador escribe su código, lo compila en algún formato y se lo entrega al administrador del sistema. Él va al servidor, instala y configura todo con sus manos. Al mismo tiempo, luchan por diferentes cosas: el administrador del sistema, por la estabilidad, el programador, por sus cambios, lo que, por supuesto, complica el trabajo de cada uno de ellos.

En DevOps, esto funciona un poco diferente. La aplicación se implementa mediante scripts. El ingeniero de DevOps establece una cierta secuencia de acciones que lleva el código escrito por el programador, primero al servidor de prueba y luego al servidor de batalla (si se decide que los cambios se pueden liberar). Por lo tanto, el desarrollador tiene la oportunidad de verificar su código al menos cada 15 minutos y hacerlo incluso a las tres de la mañana con un simple clic de un botón.

Las responsabilidades específicas, así como las habilidades necesarias, dependen en gran medida del lugar de trabajo. Nosotros, en Parallels, tenemos una gran parte de nuestra infraestructura, las partes más críticas no están en las nubes públicas, sino en nuestros propios servidores físicos en varios centros de datos. Y a veces hay actualizaciones importantes sobre hardware y software en estos servidores, y se requiere la migración periódicamente.

Este es también mi trabajo.


Intento automatizar todo al máximo para que el proceso sea menos doloroso. La última vez, en el marco de pruebas de copias de seguridad cruzadas y tolerancia a fallas de infraestructura, fue posible transferir servicios de los EE. UU. A Suiza en 10 minutos y actualizar todo lo que se requería en el camino. Para la tecnología moderna, esto, por supuesto, no es un gran logro. Pero para nosotros, un gran paso adelante.

Legacy también es un desafío definitivo para los ingenieros de DevOps. Incluso en empresas con flujos de trabajo bien construidos, hay servicios que se han escrito durante mucho tiempo, y nadie recuerda completamente cómo se configuraron, porque a menudo se realizaba manualmente, y las personas que trabajaban en ellos ya no trabajan en la organización. Si se trata de un servicio importante, se lleva a cabo una gran cantidad de investigación: debe averiguar hasta el mínimo detalle cómo funciona, escribir código para la implementación, cubrirlo con monitoreo y métricas.

Vale la pena hacerlo, incluso si el código de la aplicación no cambia de manera muy activa. ¿Por qué, si todo funciona así? Para poder reproducirlo en caso de falla, instale actualizaciones de seguridad, encuentre y solucione problemas que, tal vez, nadie sepa. Recientemente, acabo de escribir guiones para un servicio de este tipo con una larga historia. Se requirieron cambios en su código, el trabajo aún no ha terminado, pero el progreso es grande. Es muy interesante recopilar una imagen completa de la aplicación de piezas dispares, es bueno ver el resultado más adelante.

Y, por supuesto, la implementación del enfoque DevOps está estrechamente relacionada con la medición. ¿Cuánto ha cambiado el tiempo de respuesta? ¿Con qué frecuencia ocurren los errores previstos? Antes, un administrador del sistema a menudo no tenía idea de cómo medir estas cosas. Las aplicaciones eran cajas negras, solo quedaban las características más básicas: carga del procesador, consumo de memoria, tráfico. Y cuando se implementó la nueva versión, ni el administrador del sistema ni el programador pudieron determinar rápidamente que todo no salió exactamente como estaba planeado. Quedaba por esperar llamadas enojadas al soporte técnico.

Con el enfoque DevOps, esto es cosa del pasado. Puede configurar la recopilación de métricas de aplicaciones reales, compararlas con el consumo de recursos y, debido a esto, es mejor y más rápido encontrar problemas, optimizar, mejorar la calidad de los productos y no solo el tiempo de actividad del servidor.

¿Cuánto ganan los ingenieros de DevOps?


El salario de un ingeniero de DevOps depende de las habilidades, el lugar de trabajo y la región de residencia. El salario de un especialista que trabaja en Moscú es el más alto en Rusia, 130-350 mil rublos al mes. Las compañías de San Petersburgo ofrecen entre 100 y 300 mil rublos en esta posición. En otras regiones de nuestro país, están listos para pagar entre 70 y 120 mil rublos.

El ingreso anual promedio en los Estados Unidos, como dicen algunos recursos humanos, oscila entre 100 y 125 mil dólares estadounidenses, según los datos publicados por Puppet. En Australia y Nueva Zelanda: 75-100 mil dólares estadounidenses. En Europa: 50-75 mil dólares estadounidenses. En Asia, los ingenieros de DevOps no reciben más de 25 mil dólares por año.

More articles:


All Articles