¡Hola a todos! Mi nombre es Timur Gilmullin, soy el subdirector del departamento de tecnologías y procesos de desarrollo de Positive Technologies, me dedico a la automatización y a implementar las ideas de DevOps. Hoy les contaré cómo ingresé a la profesión, cómo en nuestro departamento vemos la carrera de un ingeniero de DevOps, qué es un mapa de competencias y cómo ayuda a garantizar el crecimiento de los empleados.Descargo de responsabilidad
Este artículo no es un intento de describir la carrera profesional ideal de un ingeniero de DevOps. Nuestro objetivo es compartir experiencias y contar cómo funciona con nosotros. Hay empresas especializadas ( express 42 , flant ) y comunidades ( devops deflope ) que hacen una contribución significativa al desarrollo de ideas de DevOps en Rusia, y hemos seleccionado una pila de tecnologías y técnicas que son adecuadas para nosotros.Sobre cómo desarrollamos las ideas de DevOps en nuestro departamento y en la empresa, puede leer sobre Habré:Y ahora, vamos!¿Por qué necesitamos DevOps?
Cada compañía tiene sus propios detalles del departamento de automatización. Como regla general, las tareas que son difíciles o demasiado costosas de llevar a cabo a nivel de varios departamentos separados se transfieren a un grupo centralizado o departamento de automatización. En nuestra empresa, el objetivo global de implementar las ideas de DevOps es garantizar una reducción constante en el costo de producción y soporte del producto en términos cuantitativos (horas hombre o horas máquina, CPU, RAM).En función de este objetivo, se destaca el papel del departamento de automatización a nivel de toda la empresa: esto es minimizar el costo de realizar tareas en serie típicas en todas las etapas de producción.Cómo funciona
Las responsabilidades funcionales de los departamentos de automatización también dependen en gran medida de los detalles de una empresa en particular. Nuestra empresa es desarrolladora y vendedora de soluciones de seguridad de la información, y el departamento de automatización es responsable del transportador de producción, desde el ensamblaje de componentes individuales de los productos hasta su envío para pruebas y entrega de actualizaciones a la infraestructura del cliente. Ayudamos a automatizar los principales procesos de desarrollo en equipos y asegurar el rendimiento de nuestros sistemas (integración continua y entrega continua (CI / CD)).Nuestro trabajo se divide en varias áreas funcionales.. La dirección de la integración continua admite el montaje y las tuberías de prueba para desarrolladores y probadores. La dirección de la infraestructura se dedica a la operación y optimización del uso de todos los recursos "de hierro" del departamento, así como a la automatización de la implementación de máquinas virtuales y su entorno (infraestructura como código). La dirección de monitoreo proporciona control de la disponibilidad diaria de servicios. También proporcionamos monitoreo como servicio para desarrolladores (monitoreo como servicio).La dirección del flujo de trabajo proporciona a los equipos herramientas para administrar los procesos de desarrollo y prueba, analizar el estado del código y obtener análisis del proyecto. Y, por último, webdev proporciona publicaciones de publicación en servidores de actualización corporativos (GUS y FLUS), así como productos de licencia que utilizan el servicio License Lab.Para respaldar el proceso de producción, configuramos y mantenemos muchos servicios de soporte diferentes para desarrolladores. Se pueden escuchar historias sobre algunos de ellos en nuestros viejos mitaps: ¡Op! DevOps! 2016 y Op! DevOps! 2017 . También desarrollamos herramientas de automatización interna, incluido DevOpsHQ .
La experiencia de nuestros ingenieros.
Los muchachos de nuestro departamento de automatización (por simplicidad, informalmente llamado departamento de DevOps) tienen antecedentes completamente diferentes: hay ex testers, programadores, ingenieros y administradores de TI. Soy un profesor de diploma en matemáticas y ciencias de la computación. Al final resultó que, gracias a la diversidad de experiencia, pudimos hacer frente a las tareas de todas nuestras áreas.No hay un solo ingeniero en nuestro departamento que pueda resolver por sí solo todos los problemas en todas las áreas. Pero juntos, como unidad administrativa, somos SRE(simplemente no es un sitio, un ingeniero de confiabilidad de servicios, ya que apoyamos servicios para desarrolladores), que los especialistas en recursos humanos en la persona de un ingeniero buscan sin éxito. Creemos que una gran variedad de tareas de productos de la empresa solo se pueden resolver como parte de un equipo de ingenieros diversificados.Tenemos muchos casos técnicos para implementar la automatización. Pero lo principal es explicar a las personas por qué necesitan esta automatización. La forma más fácil es cuando la tarea técnica proviene del negocio, es decir, cuando las personas que aportan dinero a la empresa tienen una comprensión clara: qué, cómo y cuándo hacer u optimizar. Le sugiero que mire nuestros casos de automatización: " Experiencia personal: cómo se ve nuestro sistema de integración continua ".Sobre una carrera en nuestro departamento de DevOps
Me gustaría decir que todo estaba listo y planeado de antemano, pero esto no es así. Al principio, no teníamos nada en nuestros planes de crecimiento y desarrollo. En 2014, cuando me mudé al departamento de tecnología y procesos de desarrollo, el desarrollo de productos vivía en el espíritu de una startup: todo lo que hay que hacer aquí y ahora, no se aceptaron planes a largo plazo, había mucho "legado". Había cuatro ingenieros entonces, y teníamos muchas tareas técnicas: necesitábamos urgentemente hacer CI, escalar la línea de ensamblaje, antes de eso, por supuesto, crear esta línea y también construir interacción con nuestros clientes internos, programadores de los departamentos de desarrollo.Sin embargo, con el tiempo, los procesos mejoraron, el departamento creció. Junto con él, hubo una comprensión cada vez mayor de lo que nuestros ingenieros querían saber: ¿cuáles son sus perspectivas de desarrollo como especialistas, qué puede ofrecer el departamento a los nuevos ingenieros? Lo primero que se deduce lógicamente de esto es que necesitaremos una tabla de crecimiento para los puestos y categorías de ingenieros. Como dice el refrán: cuando la sociedad no tiene diferenciación de color de los pantalones, ¡entonces no hay ningún propósito! Y cuando no hay objetivo ...Hicimos todo lo más simple posible. La estructura organizativa interna de nuestro departamento consta de tres puestos de liderazgo (jefe de departamento, líder adjunto y líderes de grupo) y cuatro puestos ejecutivos (ingenieros de software junior, regular, senior y líder), que a su vez se dividen en tres categorías cada uno. El departamento de recursos humanos a menudo usa un título de trabajo similar, pero sin división en categorías. Para nuestro departamento, las categorías ayudaron a garantizar un crecimiento más uniforme y gradual de los empleados a medida que aumentaron sus áreas de responsabilidad y carga de trabajo.
Para cada categoría, desarrollamos documentos con descripciones de trabajo, donde se prescribieron las funciones y roles de los empleados, y también se indicaron las áreas de responsabilidad de los empleados para los servicios y áreas de trabajo.Pero como a nosotros, además de la ingeniería, también nos encanta programar, y a ninguno de nosotros le gusta leer documentos aburridos, aquí también simplificamos un poco nuestra vida. No escribimos cada instrucción en Word, sino en forma de texto sin formato, formateado por un lenguaje de marcado Markdown especial . Al mismo tiempo, su legibilidad por una persona en cualquier editor no se pierde. Después de eso, guardamos estos textos en nuestro repositorio de GitLab. GitLab en sí mismo puede mostrar muy bien varios formatos de documentos, incluidos los sorteos de Markdown para que no se pueda distinguir de Word. Y el cliente estándar de Git tiene muchas características adicionales, por ejemplo, puede mostrar diferencias (diferencias) entre dos documentos.Esto simplifica enormemente la vida de un ingeniero que quiere saber qué requisitos formales debe seguir para avanzar al siguiente paso (categoría) de crecimiento personal en nuestro departamento. Para descubrir la diferencia entre los requisitos formales de las dos descripciones de trabajo, debe realizar algunos pasos simples: descargue el repositorio con descripciones de trabajo de nuestro GitLab, busque documentos, ejecute el comando Git en la consola para mostrar una comparación de los dos archivos. Por ejemplo, puede ver la diferencia entre un ingeniero sénior de la segunda y primera categoría de la siguiente manera:git --no-pager diff --no-index
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md
En la consola, a la que están acostumbrados todos los ingenieros de software, el signo menos y el color rojo se destacan por los requisitos que han cambiado o se han eliminado, y las líneas agregadas se destacan con un signo más y un color verde: cada línea es más un nuevo requisito.Sí, somos un poco fanáticos de la tecnología, pero luego nos pareció una gran solución:
Mapa de competencia del ingeniero DevOps
A medida que nuestro departamento se desarrolló y aumentó el número de transportadores de productos respaldados por nosotros, nos dimos cuenta de que para cada una de las áreas de trabajo en las que estamos involucrados, no será posible describir un rol único y encontrar un ingeniero adecuado en el mercado. Tenemos nuestros propios detalles de trabajo y, por ejemplo, no necesitamos un desarrollador de software de programador mega experto para resolver problemas de CI, pero, sin embargo, un ingeniero de CI debe poder programar pequeños módulos y scripts en Python a un nivel aceptable. Del mismo modo, no necesitamos un administrador de Linux megacalificado, pero necesitamos una persona con suficiente conocimiento del sistema operativo Debian o Ubuntu para que pueda instalar los agentes de compilación GitLab CI, y aún mejor, automatizar estos trabajos a través de SaltStack, Ansible u otras herramientas.Entonces, ¿qué debe hacer un ingeniero de DevOps que trabaje en nuestro departamento? Para hacer esto, primero debe determinar qué conocimientos, habilidades y capacidades (abreviado ZUN ) en sentido general son.- El conocimiento son las principales leyes del área temática, lo que permite a una persona resolver problemas específicos de producción, científicos y de otro tipo, es decir, hechos, conceptos, juicios, imágenes, relaciones, estimaciones, reglas, algoritmos, heurística, así como estrategias de toma de decisiones en esta área. El conocimiento también son elementos de información conectados entre sí y con el mundo exterior.
- Habilidades : se entiende que las personas dominan cómo realizar una acción, con cierto conocimiento. La capacidad se expresa en la capacidad de aplicar conscientemente el conocimiento en la práctica.
- — , . , , , , .
Si definimos el ZUN más específicamente en relación con los productos desarrollados en la empresa, obtendremos una lista general de competencias. Sin dominar estas competencias, el ingeniero no podrá trabajar cualitativamente en nuestro departamento. La lista resultó ser muy larga, ya que tiene en cuenta los detalles específicos del trabajo de inmediato en todas las áreas, tecnologías y productos.Por lo tanto, llegamos a la necesidad de describir y clasificar todos nuestros requisitos para un ingeniero en forma de tabla, y tenemos un " Mapa de competencia de ingenieros de DevOps 1.0 ". Se ve así: la tabla se divide en cuatro grandes secciones:
- Descripción de las competencias generales de los empleados de nuestro departamento DevOps, necesarias para la solución exitosa de las tareas cotidianas.
- El conocimiento es el conocimiento específico orientado al producto de los ingenieros de DevOps.
- — ; .
- — ; , .
En las celdas de la tabla, se indican evaluaciones cualitativas: a qué nivel debe un ingeniero tener aproximadamente una u otra competencia. Desafortunadamente, no puedo imaginar la versión completa de la tabla aquí, pero esto no es necesario, ya que cada compañía y cada departamento deben crear su propia tabla similar, teniendo en cuenta los detalles del trabajo.En 2018, mis colegas y yo desarrollamos y creamos el llamado mapa tecnológico del proceso de producción (lea el artículo sobre Habr " Gestión del caos: ponemos las cosas en orden usando el mapa tecnológico "). Gracias a ella, nos hemos acercado a crear un vector de crecimiento y desarrollo de las competencias de los ingenieros de DevOps dependiendo del producto, las tecnologías utilizadas y las etapas del transportador de productos.
Dicho mapa describe todas las etapas y pasos que conforman el transportador tecnológico para la producción de nuestros productos. Lo principal, desde el punto de vista del producto, es comprender cuántos ingenieros, qué calificaciones y con qué competencias necesitamos para garantizar el funcionamiento continuo de este transportador. Mejor aún, planifique y asegure a las personas para que, a pesar del apoyo de los servicios críticos, puedan, por ejemplo, irse de vacaciones con calma, sabiendo que hay alguien en el departamento que tiene competencias cruzadas y que puede reemplazarlas.En conjunto, esto debería llevarnos al “Mapa de competencia de ingenieros de DevOps 2.0”, que describirá claramente el ZUN según el producto y las competencias necesarias para el trabajo de automatización en este producto. Es decir, debe aparecer cierta vinculación de las etapas en el mapa tecnológico con el mapa de las competencias de los ingenieros. En el próximo artículo intentaré contarte lo que surgió.PD: El artículo fue escrito en base a la historia de la reunión de enero, a la que colegas de Hays nos invitaron amablemente a intercambiar experiencias (puede ver la presentación y el texto ).Autor : Timur Gilmullin- diputado Jefe de Tecnología y Procesos de Desarrollo (DevOps), Tecnologías Positivas.