El tema de DevOps se ha vuelto muy popular en los últimos años. Muchos sueñan con integrarse, pero, como muestra la práctica, a menudo solo lo hacen debido a los salarios.
Algunos incluyen DevOps en sus currículos, aunque no siempre comprenden el significado del término. Algunos piensan que al aprender Ansible, GitLab, Jenkins, Terraform y similares (la lista puede continuar a su antojo), se convertirán inmediatamente en 'DevOps'. Esto, por supuesto, no es cierto.
Durante los últimos años he estado principalmente implementando DevOps en varias empresas. Antes de eso, trabajé más de 20 años en posiciones que van desde administrador de sistemas hasta director de TI. Ahora soy DevOps Lead Engineer en Playgendary.
¿Quién es un DevOps?
La idea de escribir este artículo surgió después de una pregunta frecuente: '¿quién es DevOps?'. Hasta ahora, no hay un término establecido que defina qué o quién es. Parte de las respuestas ya están en este . Primero, resaltaré los puntos clave de él y luego compartiré mis observaciones y pensamientos.
DevOps no es un especialista que se puede contratar, no es un conjunto de utilidades y no es un departamento de desarrolladores con ingenieros.
DevOps es una filosofía y metodología.
En otras palabras, es un conjunto de prácticas que ayuda a facilitar la interacción entre desarrolladores y administradores de sistemas. Es decir, vincular e integrar los flujos de trabajo entre sí.
Con la aparición de DevOps, la estructura y los roles de los especialistas permanecieron igual (hay desarrolladores, hay ingenieros), pero las reglas de interacción cambiaron. Se difuminaron las fronteras entre departamentos.
Los objetivos de DevOps se pueden describir en tres puntos:
- El software debe actualizarse regularmente.
- El software debe hacerse rápidamente.
- El software debe ser fácil de implementar y en poco tiempo.
No hay una única herramienta para DevOps. Configurar, instalar y aprender varios productos no significa que la empresa tenga DevOps. Hay muchas herramientas y todas se utilizan en diferentes etapas, pero sirven a un propósito común.
Y eso es solo una parte de las herramientas de DevOps.
Llevo más de 2 años entrevistando personas para el puesto de ingeniero DevOps y ha surgido en mí la conciencia de lo importante que es comprender claramente el significado del término. He acumulado experiencia específica, observaciones y pensamientos que quiero compartir.
Por mi experiencia en entrevistas, veo esta imagen: los especialistas que consideran DevOps como un puesto generalmente tienen malentendidos con sus colegas..
Fue un ejemplo claro. A la entrevista llegó un joven con un montón de palabras inteligentes en su currículum. En sus últimos tres empleos tuvo una duración de 5-6 meses. De dos startups se fue porque "no despegaron". Y en cuanto a la tercera empresa, dijo que allí nadie lo entendía: los desarrolladores escriben código para Windows, y el director lo obliga a "envolver" ese código en Docker común y a integrarlo en el pipeline de CI/CD. El chico contó muchas cosas negativas sobre su actual lugar de trabajo y sus colegas; daban ganas de responderle: "Así no podrás vender un elefante".
Luego le hice una pregunta, que en mi lista es una de las primeras para cada candidato.
— ¿Qué significa DevOps para ti en lo personal?
— ¿En general o como yo lo percibo?
Me interesaba su opinión personal. Sabía la teoría y el origen del término, pero estaba categóricamente en desacuerdo con ellos. Creía que DevOps era un puesto. Aquí radica la raíz de sus problemas. Al igual que otros especialistas con la misma opinión.
Los empleadores, después de escuchar sobre la "magia de DevOps", quieren encontrar a alguien que venga y cree esa "magia". Y los solicitantes que piensan que "DevOps es un puesto" no entienden que con ese enfoque no podrán cumplir con las expectativas. Y, en general, lo pusieron en su currículum como DevOps porque es una tendencia y paga bien.
Metodología y filosofía de DevOps
La metodología puede ser teórica y práctica. En nuestro caso, es lo segundo. Como mencioné antes, DevOps es un conjunto de prácticas y estrategias aplicadas para lograr los objetivos establecidos. Y en cada caso, dependiendo de los procesos empresariales de la compañía, puede diferir significativamente. Lo que no lo hace mejor o peor.
La metodología DevOps es solo un medio para alcanzar los objetivos establecidos.
Ahora, sobre lo que es la filosofía de DevOps. Y probablemente esta sea la pregunta más difícil.
Formular una respuesta breve y concisa es bastante complicado, porque aún no se ha formalizado. Y, dado que los adeptos a la filosofía de DevOps se dedican más a la práctica, simplemente no hay tiempo para filosofar. No obstante, es un proceso muy importante. De hecho, está directamente relacionado con la actividad ingenieril. Existe incluso un área de conocimiento especializada — .
En mi universidad no había esa materia, así que tuve que estudiar todo por mi cuenta con el material que pude encontrar en los años 90. El tema no es obligatorio para la educación en ingeniería, de ahí la falta de formalización de la respuesta. Pero aquellas personas que se han sumergido seriamente en DevOps comienzan a sentir un cierto 'espíritu' o 'una omnipresencia inconsciente' de todos los procesos de la empresa.
He intentado formalizar algunos 'postulados' de esta filosofía a partir de mi experiencia. Lo que he llegado a es lo siguiente:
- DevOps no es algo independiente que se pueda destacar como un área separada de conocimiento o actividad.
- Todos los empleados de la empresa deben regirse por la metodología DevOps al planificar su actividad.
- DevOps abarca todos los procesos dentro de la empresa.
- DevOps existe para reducir el tiempo dedicado a cualquier proceso dentro de la empresa con el fin de asegurar el desarrollo de sus servicios y la máxima comodidad para el cliente.
- DevOps, en términos modernos, es la posición proactiva de cada empleado de la empresa, enfocada en disminuir los costos de tiempo y mejorar la calidad de los productos de TI que nos rodean.
Creo que mis 'postulados' son un tema separado para discusión. Pero ahora hay de qué partir.
Qué hace DevOps
La palabra clave aquí es comunicación. Hay muchas comunicaciones, de las cuales el iniciador debe ser precisamente ese ingeniero de DevOps. ¿Por qué es así? Porque es una filosofía y metodología, y solo después un conocimiento ingenieril.
No puedo hablar con un 100% de certeza sobre el mercado laboral occidental. Pero sé bastante sobre el mercado de DevOps en Rusia. Además de cientos de entrevistas, en los últimos año y medio he participado en una centena de presales técnicas para el servicio 'Implementación de DevOps' para grandes empresas y bancos rusos.
En Rusia, DevOps aún es un tema muy joven, pero ya está en tendencia. Según tengo entendido, solo en Moscú, la escasez de tales especialistas durante 2019 fue de más de 1000 personas. Y la palabra Kubernetes es para los empleadores casi como un trapo rojo para un toro. Los adeptos a esta herramienta están listos para usarla incluso donde no es necesaria y no resulta económicamente viable. El empleador no siempre entiende en qué casos es más apropiado usarla, y con un despliegue adecuado, el costo de mantener un clúster de Kubernetes es de 2 a 3 veces más elevado que el despliegue de una aplicación mediante un esquema de clúster convencional. Úsala donde realmente se necesite.
La implementación de DevOps desde el punto de vista económico es costosa. Y solo se justifica donde aporta beneficios económicos en otras áreas, y no por sí misma.
Los ingenieros de DevOps son, de hecho, pioneros; son ellos los que deben implementar esta metodología en la empresa y establecer procesos. Para que esto sea exitoso, el especialista debe interactuar constantemente con empleados y colegas en todos los niveles. Como suelo decir, en el proceso de implementación de DevOps deben estar involucrados todos los empleados de la empresa: desde el limpiador hasta el CEO. Y esto es un requisito indispensable. Si el miembro más joven del equipo no sabe y no comprende qué es DevOps y por qué se llevan a cabo ciertas acciones organizativas, la implementación exitosa no se logrará.
Además, el ingeniero de DevOps necesita, de vez en cuando, utilizar recursos administrativos. Por ejemplo, para superar la 'resistencia del entorno' —cuando el equipo no está dispuesto a aceptar las herramientas y la metodología de DevOps.
El desarrollador solo debe escribir código y pruebas. Para esto, no necesita un portátil superpotente en el que estará desplegando y manteniendo toda la infraestructura del proyecto de forma local. Por ejemplo, un frontend debe tener en su portátil todos los elementos de la aplicación, incluido el base de datos, emulador de S3 (minio) y demás. Es decir, gasta mucho tiempo manteniendo esta infraestructura local y lucha solo con todos los problemas que surge de esta solución. En lugar de desarrollar código para el frontend. Estas personas pueden resistirse fuertemente a cualquier cambio.
Pero hay equipos que, por el contrario, están encantados de implementar nuevas herramientas y métodos, y participan activamente en este proceso. Aunque incluso en este caso, la comunicación entre el ingeniero de DevOps y el equipo sigue siendo fundamental.
Cuándo no se necesita DevOps
Hay situaciones en las que no se necesita DevOps. Este es un hecho que hay que comprender y aceptar.
En primer lugar, esto se refiere a cualquier empresa (especialmente a las pequeñas), cuando sus ganancias no dependen directamente de la existencia o ausencia de productos de TI que ofrezcan servicios de información a los clientes. Y aquí no se trata del sitio web de la empresa, ya sea una 'tarjeta de presentación' estática o con bloques de noticias dinámicas, etc.
Se requiere DevOps cuando la disponibilidad de estos servicios de información para la interacción con el cliente, su calidad y enfoque, afectan la satisfacción de su cliente y su deseo de regresar a usted.
Un ejemplo claro es un banco conocido. La empresa no tiene oficinas de atención al cliente tradicionales, la documentación se maneja a través del correo o mensajeros, y muchos empleados trabajan desde casa. La empresa ha dejado de ser solo un banco y, en mi opinión, se ha convertido en una empresa de TI con tecnologías DevOps desarrolladas.
Se pueden encontrar muchos otros ejemplos y conferencias en las grabaciones de meetups y conferencias temáticas. Parte de ellas las he asistido personalmente; es una experiencia muy útil para quienes desean desarrollarse en esta dirección. Aquí están los enlaces a canales de YouTube con buenas conferencias y materiales sobre DevOps:
Ahora mire su negocio y piense en lo siguiente: ¿qué tanto dependen su empresa y sus ganancias de los productos de TI que facilitan la interacción con el cliente?
Si su empresa vende pescado en una pequeña tienda y el único producto de TI son dos configuraciones de 1C: Enterprise (Contabilidad y Gestión), difícilmente tenga sentido hablar de DevOps.
Sin embargo, si trabaja en una gran empresa comercial y de fabricación (por ejemplo, üretir escopetas), vale la pena reflexionar. Puede tomar la iniciativa y comunicar a su gestión las perspectivas de implementar DevOps. Y, de paso, liderar este proceso. Una postura proactiva es uno de los postulados importantes de la filosofía DevOps.
El tamaño y el volumen de la facturación anual no son 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 compañías automotrices. En este momento no estoy seguro, pero, según mi experiencia pasada, durante muchos años toda la interacción con los clientes se realizó por correo electrónico y teléfono.
Sus clientes son una lista limitada de concesionarios de automóviles. Y a cada uno se le asigna un especialista del fabricante. Todo el intercambio interno de documentos ocurre a través de ERP SAP. En esencia, los empleados internos son los clientes del sistema de información. Pero la gestión de este SI se lleva a cabo mediante herramientas clásicas de gestión de sistemas en clúster, lo que excluye la posibilidad de usar prácticas DevOps.
De aquí se deduce que, para tales empresas, la implementación de DevOps no es algo críticamente importante, si recordamos los objetivos de la metodología desde el principio del artículo. Pero no descarto que algunas herramientas de DevOps se utilicen hoy en día.
Por otro lado, hay muchas pequeñas empresas que desarrollan software utilizando la metodología, filosofía, prácticas y herramientas de DevOps. Y consideran que los costos de implementar DevOps son gastos que les permiten competir de manera efectiva en el mercado de software. Ejemplos de tales empresas se pueden observar .
El criterio principal para entender si necesita DevOps es: ¿qué importancia tienen sus productos de TI para la empresa y los clientes?
Si el producto principal de la empresa, que genera ganancias, es software, necesita DevOps. Y no es tan importante si realmente gana dinero con otros productos. También se pueden incluir aquí las tiendas en línea o las aplicaciones móviles con juegos.
Cualquier juego existe gracias al financiamiento: directo o indirecto por parte de los jugadores. En Playgendary desarrollamos juegos móviles gratuitos, en cuya creación participan más de 200 personas. ¿Cómo usamos DevOps?
De la misma manera que se describe arriba. Estoy en constante comunicación con desarrolladores y testers, y organizo formación interna para los empleados en metodología y herramientas de DevOps.
Actualmente utilizamos activamente Jenkins como herramienta para pipelines CI/CD para ejecutar todos los flujos de trabajo con Unity y el posterior despliegue en App Store y Play Market. Además, de un conjunto clásico de herramientas:
- Asana — para la gestión de proyectos. Integración configurada con Jenkins.
- Google Meet — para realizar videoconferencias.
- Slack — para comunicaciones y diversas alertas, incluidas notificaciones de Jenkins.
- Atlassian Confluence — para la documentación y el trabajo en equipo.
En el futuro cercano, se planea implementar un análisis estático de código con SonarQube y realizar pruebas automatizadas de UI utilizando Selenium en la etapa de Integración Continua.
En conclusión
Quiero finalizar con este pensamiento: para convertirse en un ingeniero DevOps altamente calificado, es vital aprender a comunicarse efectivamente con las personas.
El ingeniero DevOps es un jugador de equipo. Y no podría ser de otra manera. La iniciativa en la comunicación con los colegas debe provenir de él mismo, y no bajo la influencia de circunstancias externas. Un especialista en DevOps debe identificar y proponer la mejor solución para el equipo.
Y sí, implementar cualquier solución requerirá muchas discusiones y al final puede cambiar por completo. Al desarrollarse de manera independiente, proponiendo y llevando a cabo sus ideas, tal persona representa un valor cada vez mayor tanto para el equipo como para el empleador. Lo que, en última instancia, se refleja en el tamaño de su recompensa mensual o en la forma de bonificaciones adicionales.
Fuente: habr.com
