DevOps se ha convertido en un tema muy popular en los últimos años. Mucha gente sueña con unirse a él, pero, como muestra la práctica, a menudo sólo por el nivel de los salarios.
Algunas personas incluyen DevOps en su currículum, aunque no siempre conocen o comprenden la esencia del término. Algunas personas piensan que después de estudiar Ansible, GitLab, Jenkins, Terraform y similares (la lista puede continuar según sus gustos), inmediatamente se convertirá en un "devopsis". Por supuesto que esto no es cierto.
Durante los últimos años, he estado involucrado principalmente en la implementación de DevOps en varias empresas. Antes de eso, trabajó durante más de 20 años en puestos que iban desde administrador de sistemas hasta director de TI. Actualmente ingeniero líder de DevOps en Playgendary.
¿Quién es DevOps?
La idea de escribir un artículo surgió tras otra pregunta: “¿quién es DevOps?” Aún no hay un término establecido sobre qué o quién es. Algunas de las respuestas ya están en este . Primero, resaltaré los puntos principales y luego compartiré mis observaciones y pensamientos.
DevOps no es un especialista que se pueda contratar, ni un conjunto de utilidades, ni un departamento de desarrolladores con ingenieros.
DevOps es una filosofía y metodología.
En otras palabras, es un conjunto de prácticas que ayudan a los desarrolladores a interactuar activamente con los administradores del sistema. Es decir, conectar e integrar los procesos de trabajo entre sí.
Con la llegada de DevOps, la estructura y los roles de los especialistas siguieron siendo los mismos (hay desarrolladores, hay ingenieros), pero las reglas de interacción han cambiado. Los límites entre departamentos se han desdibujado.
Los objetivos de DevOps se pueden describir en tres puntos:
- El software debe actualizarse periódicamente.
- El software debe realizarse rápidamente.
- El software debe implementarse de forma cómoda y en poco tiempo.
No existe una herramienta única para DevOps. Configurar, entregar y estudiar varios productos no significa que DevOps haya aparecido en la empresa. Hay muchas herramientas y todas se utilizan en diferentes etapas, pero tienen un propósito común.
Y esto es sólo una parte de las herramientas DevOps
He estado entrevistando a personas para el puesto de ingeniero de DevOps durante más de 2 años y me he dado cuenta de lo importante que es comprender claramente la esencia del término. He acumulado experiencias, observaciones y pensamientos específicos que quiero compartir.
Por experiencia de entrevista, veo la siguiente imagen: Los especialistas que consideran DevOps como un puesto de trabajo suelen tener malentendidos con sus colegas..
Hubo un ejemplo sorprendente. Un joven llegó a una entrevista con muchas palabras inteligentes en su currículum. En sus últimos tres trabajos, tenía entre 5 y 6 meses de experiencia. Dejé dos startups porque “no despegaron”. Pero sobre la tercera empresa, dijo que allí nadie lo entiende: los desarrolladores escriben código en Windows, y el director obliga a que este código sea "envuelto" en Docker normal e integrado en el proceso CI/CD. El tipo dijo muchas cosas negativas sobre su lugar de trabajo actual y sus colegas. Yo sólo quería responder: "Entonces no venderás ni un elefante".
Luego le hice una pregunta que ocupa un lugar destacado en mi lista para cada candidato.
— ¿Qué significa DevOps para usted personalmente?
- ¿En general o cómo lo percibo?
Me interesaba su opinión personal. Conocía la teoría y el origen del término, pero estaba totalmente en desacuerdo con ellos. Creía que DevOps era un título de trabajo. Aquí es donde reside la raíz de sus problemas. Así como otros especialistas con la misma opinión.
Los empleadores, después de haber oído hablar mucho de la “magia de DevOps”, quieren encontrar una persona que venga y cree esta “magia”. Y los solicitantes de la categoría "DevOps es un trabajo" no entienden que con este enfoque no podrán cumplir con las expectativas. Y, en general, escribieron DevOps en su currículum porque es tendencia y pagan mucho por ello.
Metodología y filosofía DevOps
La metodología puede ser teórica y práctica. En nuestro caso, es el segundo. Como mencioné anteriormente, DevOps es un conjunto de prácticas y estrategias que se utilizan para lograr los objetivos establecidos. Y en cada caso, dependiendo de los procesos comerciales de la empresa, puede diferir significativamente. Lo cual no lo hace mejor ni peor.
La metodología DevOps es solo un medio para lograr objetivos.
Ahora sobre cuál es la filosofía DevOps. Y ésta es probablemente la pregunta más difícil.
Es bastante difícil formular una respuesta breve y concisa, porque aún no se ha formalizado. Y dado que los partidarios de la filosofía DevOps están más comprometidos con la práctica, simplemente no hay tiempo para filosofar. Sin embargo, este es un proceso muy importante. Además, está directamente relacionado con las actividades de ingeniería. Incluso existe un área de conocimiento especializada: .
En mi universidad no existía tal materia, tuve que estudiar todo por mi cuenta usando los materiales que pude encontrar en los años 90. El tema es opcional para la educación en ingeniería, de ahí la falta de formalización de la respuesta. Pero aquellas personas que están seriamente inmersas en DevOps empiezan a sentir un cierto “espíritu” o “integralidad inconsciente” de todos los procesos de la empresa.
Utilizando mi propia experiencia, intenté formalizar algunos de los “postulados” de esta filosofía. El resultado es el siguiente:
- DevOps no es algo independiente que pueda separarse en un área separada de conocimiento o actividad.
- Todos los empleados de una empresa deben guiarse por la metodología DevOps a la hora de planificar sus actividades.
- DevOps afecta a todos los procesos dentro de una empresa.
- DevOps existe para reducir los costos de tiempo de cualquier proceso dentro de una empresa para garantizar el desarrollo de sus servicios y la máxima comodidad del cliente.
- DevOps, en lenguaje moderno, es la posición proactiva de cada empleado de una empresa, orientada a reducir los costos de tiempo y mejorar la calidad de los productos TI que nos rodean.
Creo que mis “postulados” son un tema de discusión aparte. Pero ahora hay algo sobre lo que construir.
¿Qué hace DevOps?
La palabra clave aquí es comunicación. Hay muchas comunicaciones cuyo iniciador debería ser exactamente el mismo ingeniero de DevOps. ¿Porqué es eso? Porque esto es filosofía y metodología, y sólo entonces conocimiento de ingeniería.
No puedo hablar con un 100% de confianza sobre el mercado laboral occidental. Pero sé bastante sobre el mercado de DevOps en Rusia. Además de cientos de entrevistas, durante el último año y medio participé en cientos de preventas técnicas del servicio "Implementación de DevOps" para grandes empresas y bancos rusos.
En Rusia, DevOps es todavía un tema muy joven, pero ya está de moda. Hasta donde yo sé, sólo en Moscú la escasez de estos especialistas en 2019 ascendió a más de 1000 personas. Y la palabra Kubernetes para los empleadores es casi como un trapo rojo para un toro. Los partidarios de esta herramienta están dispuestos a utilizarla incluso cuando no sea necesaria y económicamente rentable. El empleador no siempre comprende en qué casos es más apropiado usar y, con una implementación adecuada, mantener un clúster de Kubernetes cuesta entre 2 y 3 veces más que implementar una aplicación utilizando un esquema de clúster convencional. Úselo donde realmente lo necesite.
Implementar DevOps es costoso en términos de dinero. Y sólo se justifica cuando aporta beneficios económicos en otras áreas, y no por sí solo.
Los ingenieros de DevOps son, de hecho, pioneros: son ellos los que deberían ser los primeros en implementar esta metodología en la empresa y construir procesos. Para que esto tenga éxito, el especialista debe interactuar constantemente con empleados y colegas de todos los niveles. Como suelo decir, todos los empleados de la empresa deberían participar en el proceso de implementación de DevOps: desde la señora de la limpieza hasta el CEO. Y este es un requisito previo. Si el miembro más joven del equipo no sabe ni comprende qué es DevOps y por qué se realizan ciertas acciones organizacionales, entonces la implementación exitosa no funcionará.
Además, un ingeniero de DevOps necesita utilizar un recurso administrativo de vez en cuando. Por ejemplo, para superar la "resistencia ambiental", cuando el equipo no está preparado para aceptar las herramientas y la metodología DevOps.
El desarrollador sólo debe escribir código y pruebas. Para hacer esto, no necesita una computadora portátil superpoderosa en la que implementará y brindará soporte local a toda la infraestructura del proyecto. Por ejemplo, un desarrollador front-end guarda todos los elementos de la aplicación en su computadora portátil, incluida la base de datos, el emulador S3 (minio), etc. Es decir, dedica mucho tiempo a mantener esta infraestructura local y lucha él solo con todos los problemas de tal solución. En lugar de desarrollar código para el frente. Estas personas pueden resistirse mucho a cualquier cambio.
Pero hay equipos que, por el contrario, están felices de introducir nuevas herramientas y métodos y participar activamente en este proceso. Aunque incluso en este caso no se canceló la comunicación entre el ingeniero de DevOps y el equipo.
Cuando no se necesita DevOps
Hay situaciones en las que no se necesita DevOps. Esto es un hecho: es necesario comprenderlo y aceptarlo.
En primer lugar, esto se aplica a cualquier empresa (especialmente a las pequeñas) cuando sus ganancias no dependen directamente de la presencia o ausencia de productos de TI que brinden servicios de información a los clientes. Y aquí no estamos hablando de la web de la empresa, ya sea una “tarjeta de visita” estática o con bloques de noticias dinámicos, etc.
DevOps es necesario cuando la satisfacción de su cliente y su deseo de volver a usted dependen de la disponibilidad de estos servicios de información para la interacción con el cliente, su calidad y orientación.
Un ejemplo sorprendente es el de un banco muy conocido. La empresa no cuenta con oficinas de clientes tradicionales, el flujo de documentos se realiza por correo o mensajería y muchos empleados trabajan desde casa. La empresa dejó de ser solo un banco y, en mi opinión, se convirtió en una empresa de TI con tecnologías DevOps desarrolladas.
En las grabaciones de reuniones y conferencias temáticas se pueden encontrar muchos otros ejemplos y conferencias. Visité algunos de ellos personalmente; esta es una experiencia muy útil para aquellos que quieran desarrollarse en esta dirección. Aquí hay enlaces a canales de YouTube con buenas conferencias y materiales sobre DevOps:
Ahora mire su negocio y piense en esto: ¿En qué medida dependen su empresa y sus ganancias de los productos de TI para permitir la interacción con el cliente?
Si su empresa vende pescado en una tienda pequeña y el único producto de TI son dos configuraciones 1C: Enterprise (Contabilidad y UNF), entonces no tiene sentido hablar de DevOps.
Si trabaja en una gran empresa comercial y de fabricación (por ejemplo, produce rifles de caza), entonces debería pensar en ello. Puede tomar la iniciativa y transmitir a su dirección las perspectivas de implementación de DevOps. Bueno, y al mismo tiempo, lidera este proceso. Una posición proactiva es uno de los principios importantes de la filosofía DevOps.
El tamaño y el volumen de la facturación financiera anual no es el criterio principal para determinar si su empresa necesita DevOps.
Imaginemos una gran empresa industrial que no interactúa directamente con los clientes. Por ejemplo, algunos fabricantes de automóviles y empresas fabricantes de automóviles. No estoy seguro ahora, pero según mi experiencia pasada, durante muchos años toda la interacción con el cliente se realizaba por correo electrónico y por teléfono.
Sus clientes son una lista limitada de concesionarios de automóviles. Y a cada uno se le asigna un especialista por parte del fabricante. Todo el flujo de documentos internos se produce a través de SAP ERP. Los empleados internos son esencialmente clientes del sistema de información. Pero este SI se controla mediante medios clásicos de gestión de sistemas de clúster. Lo que excluye la posibilidad de utilizar prácticas DevOps.
De ahí la conclusión: para este tipo de empresas, la implementación de DevOps no es algo de importancia crítica, si recordamos los objetivos de la metodología del principio del artículo. Pero no descarto que hoy utilicen algunas herramientas DevOps.
Por otro lado, existen muchas pequeñas empresas que desarrollan software utilizando la metodología, filosofía, prácticas y herramientas DevOps. Y creen que el costo de implementar DevOps es el costo que les permite competir efectivamente en el mercado de software. Se pueden ver ejemplos de este tipo de empresas. .
El criterio principal para comprender si se necesita DevOps: qué valor tienen sus productos de TI para la empresa y los clientes.
Si el principal producto de la empresa que genera ganancias es el software, necesita DevOps. Y no es tan importante si ganas dinero real con otros productos. Esto también incluye tiendas online o aplicaciones móviles con juegos.
Todos los juegos existen gracias a la financiación: directa o indirecta de los jugadores. En Playgendary desarrollamos juegos móviles gratuitos con más de 200 personas directamente involucradas en su creación. ¿Cómo utilizamos DevOps?
Sí, exactamente igual a lo descrito anteriormente. Me comunico constantemente con desarrolladores y evaluadores, y realizo capacitación interna para empleados sobre metodología y herramientas DevOps.
Ahora estamos utilizando activamente Jenkins como herramienta de canalización de CI/CD para ejecutar todas las canalizaciones de ensamblaje con Unity y su posterior implementación en App Store y Play Market. Más del conjunto de herramientas clásico:
- Asana - para la gestión de proyectos. Se ha configurado la integración con Jenkins.
- Google Meet: para videoconferencias.
- Slack: para comunicaciones y diversas alertas, incluidas notificaciones de Jenkins.
- Atlassian Confluence: para documentación y trabajo en grupo.
Nuestros planes inmediatos incluyen la introducción del análisis de código estático utilizando SonarQube y la realización de pruebas de interfaz de usuario automatizadas utilizando Selenium en la etapa de Integración Continua.
En lugar de una conclusión
Me gustaría terminar con la siguiente reflexión: para convertirte en un ingeniero DevOps altamente calificado, es vital aprender a comunicarte en vivo con las personas.
Un ingeniero de DevOps trabaja en equipo. Y nada más. La iniciativa en la comunicación con los compañeros debe venir de él y no bajo la influencia de determinadas circunstancias. Un especialista en DevOps debe ver y proponer la mejor solución para el equipo.
Y sí, la implementación de cualquier solución requerirá mucha discusión y, al final, puede cambiar por completo. Al desarrollarse de forma independiente, proponer e implementar sus ideas, una persona así tiene un valor cada vez mayor tanto para el equipo como para el empleador. Lo cual, en última instancia, se refleja en el monto de su remuneración mensual o en forma de bonificaciones adicionales.
Fuente: habr.com