Por qué DevOps no se integra bien en los negocios rusos y quién tiene la culpa

Qué es DevOps y qué tareas realiza un ingeniero de DevOps

El término DevOps (Operaciones de Desarrollo u operaciones dentro de

desarrollo - "Alta tecnología") se utilizó por primera vez en2009 Consultor de TI Patrick Debois. En esencia, esto significa no solo una vacante, sino toda una metodología que le permite crear productos digitales de manera más eficiente y rápida. Un conjunto relacionado de herramientas de desarrollo, gestión de productos, ingeniería de software y otras especialidades garantiza un proceso continuo de creación de software.

Un rico arsenal de prácticas acerca DevOps a otrospopular en la esfera de TI utilizando el método ágil. Es un enfoque de diseño iterativo que le permite adaptarse a los requisitos cambiantes. En consecuencia, el especialista en DevOps intenta mejorar el producto y hacer que los procesos comerciales sean más predecibles y transparentes. También mejora las métricas comerciales, como acortar el tiempo de comercialización. Este es el período de tiempo desde el inicio del desarrollo del producto hasta el lanzamiento al mercado. Conocer los factores que estiran el tiempo para crear software y un enfoque de sistemas permiten al ingeniero de DevOps hacer que la producción sea continua y rápida. Para hacerlo más claro, puede dibujar una analogía con una cinta transportadora para ensamblar automóviles. Todas las piezas están diseñadas de antemano para que encajen perfectamente durante el montaje. Los ingenieros que diseñan un motor piensan en cómo funciona junto con las ruedas, los frenos, etc. DevOps hace lo mismo: se responsabiliza de más producto que el desarrollador, se asegura de que todos los equipos colaboren.

Pink Pony World: Carrera por la filosofía de la moda

Sin embargo, no todas las empresas necesitan DevOps.Por ejemplo, en equipos sin departamentos de TI preexistentes que no estén involucrados en la producción de un producto digital, la filosofía DevOps no se aplica en absoluto. Estas áreas incluyen empresas cuyos beneficios no dependen directamente de la satisfacción de los clientes con el producto de TI con el que interactúan. Además, a menudo no es adecuado para pequeñas empresas. La metodología requiere cambios en muchos procesos comerciales establecidos e incluso en la cultura corporativa. Es posible que las pequeñas empresas simplemente no toleren tales cambios desde el punto de vista de la economía del proyecto.

La enfermedad de moda de la transformación digital es a menudose refiere a los directores de dichas empresas. En busca de una optimización sin fin, se olvidan de otros factores que afectan al negocio. Como resultado, las empresas pierden dinero, eficiencia y, en el peor de los casos, los procesos de negocio que se han construido a lo largo de los años, los gigantes de TI, los bancos, los grandes eventos comerciales e industriales son otro asunto. Para ellos, DevOps puede ser muy beneficioso. Así, según el informe anual de Alfa-Bank de 2017, la introducción de la metodología nos permitió acelerar el desarrollo e implementación en 60 veces.

Stakhanovite-mnogostanochnik en lugar de un taller

Por supuesto, una funcionalidad tan amplia es difícilpor empleado, lo ideal es que todo un equipo multifuncional esté involucrado en DevOps. Incluye profesionales en roles y gerentes de procesos y productos, desarrollador de código de infraestructura, ingeniero y muchos otros roles. Sin embargo, en la práctica rusa, un especialista en DevOps a menudo puede convertirse en una forma moderna de ahorrar dinero en la creación de productos. Normalmente, esta situación se produce después de que el máximo responsable de la empresa decide que ha llegado el momento de la transformación digital. La empresa contrata urgentemente nuevos especialistas o amplía la lista de responsabilidades de los desarrolladores y administradores de sistemas existentes. Como resultado, los servicios de contratación no crean vacantes para ingenieros de DevOps, sino para empleados de varias estaciones.

Dicho empleado puede ser obligado individualmenteconfigurar servidores, instalar sistemas de cableado y luego rastrear errores, configurar bases de datos y hospedaje de proyectos, etc. Este ejemplo es extremo, pero real. Como resultado, los empleados se agotan rápidamente y falla la implementación de la metodología en el trabajo de la empresa. Tratar a un especialista en DevOps como un mago que puede manejar simultáneamente una gran cantidad de tareas, junto con el monitoreo del funcionamiento de todo el sistema, no generará ganancias para el negocio.

Otro problema común está relacionado condividir al equipo en dos grupos que no pueden llevarse bien entre sí. Imagine que una empresa de TI tiene un departamento de DevOps, al que se le permite cambiar los procedimientos de trabajo habituales. Sin embargo, estas reglas siguen siendo vinculantes para otros desarrolladores. Por supuesto, en este caso no es necesario hablar de cooperación y "fluidez" del trabajo. Los dos equipos comienzan a chocar y la productividad cae.

Un barril de pólvora en la bodega: DevOps no son solo habilidades

Una de las tareas del departamento de DevOps es establecercomunicación entre diferentes especialistas en TI de la empresa. Los ingenieros de DevOps no solo deben implementar tecnologías y procesos de depuración, sino también sumergir al equipo de desarrollo en el curso del negocio: compartir responsabilidades y ayudar a aumentar las competencias. Sin embargo, estos especialistas suelen ocuparse de tareas puramente técnicas, normalmente debido a la banal falta de tiempo, tanto para ellos como para aquellos cuyas competencias necesitan ser incrementadas.

Como resultado, debido al hecho de que la moda introducidaTodo el mundo utiliza tecnologías, y el conocimiento y las habilidades se concentran en un solo departamento, surgen situaciones problemáticas, incluidas las catastróficas. Las nuevas soluciones creadas por ingenieros de DevOps, sin el trabajo coordinado de diferentes departamentos, pueden traer tantos problemas como deberían haber resuelto inicialmente, lo que no significa que los especialistas de DevOps deban crear una cultura corporativa desde cero, como suelen pensar los nacionales. líderes. La unidad del pipeline de producción digital y el fomento de la transferencia de nuevas habilidades y comunicación deben provenir de los líderes de la empresa. Sin esto, incluso el equipo de DevOps se desarrollará mal y no compartirá conocimientos con el equipo.

Ni la subcontratación de DevOps niconsultar con un especialista del exterior. En el primer caso, el equipo externo se guía no por las necesidades de la empresa cliente, sino por el conjunto estándar de tecnologías que se cotizan en el mercado. Para el cliente, esto es una lotería: los empleados subcontratados utilizan una comprensión vaga de DevOps en el mercado. Como resultado, los procesos comerciales se vuelven cada vez más complejos, pero esto no aporta ningún beneficio al negocio. A menudo, las propias empresas fomentan este enfoque, por ejemplo, pidiéndoles que no cambien sus procesos de desarrollo. Está claro que esto es contrario al concepto mismo de DevOps.

Largo, costoso, problemático: DevOps duro en ruso

En lugar de aplicar la filosofía DevOps aPara todos los procesos comerciales, las empresas nacionales a menudo prefieren trabajar con herramientas que no afecten la velocidad del trabajo. Uno de los resultados, por ejemplo, es la "pared de ladrillos": las operaciones, es decir, el equipo de administradores de sistemas, permanece aislado y los desarrolladores simplemente les lanzan aplicaciones. Por supuesto, la caja de herramientas sigue mejorando como resultado. Sin embargo, no se están produciendo cambios fundamentales, la transparencia no aumenta y la colaboración del equipo de TI no mejora.

Otro inconveniente con el que se topangerentes al implementar DevOps: falta de bases de conocimiento corporativas. Según el informe DORA de 2019, los equipos que utilizaron fuentes de información internas de la empresa fueron 1,73 veces más efectivos que otros. Este problema se debe nuevamente a la cultura cerrada de muchas empresas rusas, en las que el equipo no comparte conocimientos. Debido a este carácter cerrado, las empresas comienzan a acumular deuda técnica. Las herramientas se están volviendo obsoletas, los artefactos no se eliminan y la documentación no se actualiza.

La necesidad objetiva empresarial de estabilidad de la producción y, por tanto, de beneficios, junto con una base tecnológica obsoleta y una deuda técnica, conducen al uso fallido de DevOps.

Todo esto a menudo conduce al hecho de que, después de un largo tormento, las nuevas soluciones ofrecidas por el equipo de DevOps simplemente se descartan y los procesos se “deshacen”.

Cada empresa tiene su propio camino de transformación digital.En la mayoría de los casos, realmente cambia la forma en que se desarrolla e implementa su código para mejor. Esto significa que DevOps todavía existe en Rusia: todos los meses aparecen en el mercado muchas vacantes relacionadas con esta metodología. Otra cosa es que hay diferentes definiciones de una especialidad y tareas prácticas detrás de ellas. Sin embargo, las empresas deberían dejar de perseguir sistemas de TI ideales fantasmales y ser críticas con la adopción de una filosofía moderna pero no necesariamente rentable, priorizando sus propias necesidades.

Ver tambien

Puede haber universos en agujeros negros. Te contamos el nuevo descubrimiento

En el día 3 de la enfermedad, la mayoría de los pacientes con COVID-19 pierden el sentido del olfato y a menudo sufren de secreción nasal.

Investigación: 15 millones de toneladas de microplásticos encontrados en el fondo del océano