Seis errores empresariales de DevOps que hay que evitar

Puede que le sorprenda, pero DevOps existe desde hace casi dos décadas. Impulsado por el deseo de la comunidad de desarrollo de contar con más capacidades y controles a la hora de desplegar aplicaciones, DevOps cobró impulso en 2011 en la empresa con una perspectiva positiva de Gartner y en 2015 cuando el Scaled Agile Framework (SAFe) incorporó DevOps. El crecimiento sin precedentes de AWS durante este periodo también obligó a los CIO a aprender más sobre cómo las startups estaban innovando y operando eficientemente en la nube.

Por aquel entonces yo era un CIO centrado en el desarrollo que trabajaba en una empresa regulada de Fortune 100 con estrictos controles sobre la infraestructura de su centro de datos y sus prácticas de implementación. Me entusiasmaba la perspectiva de automatizar los despliegues y suavizar las tensiones entre los equipos de desarrollo y operaciones de TI. Pero DevOps me pareció demasiado centrado en el desarrollo en ese momento, y mis primeros artículos cuestionaban a quién pertenecía DevOps y cómo DevOps era un cambio importante en las prácticas.

DevOps ha evolucionado significativamente desde entonces, hasta el punto de que no existe un enfoque único para el éxito. Alejados de las operaciones diarias de DevOps, muchos CIO carecen de una perspectiva completa sobre qué prácticas priorizar y pueden ser engañados por cómo las startups, los proveedores o las organizaciones de servicios profesionales implementan DevOps en entornos excesivamente simplificados en comparación con lo que se requiere en empresas complejas y reguladas.

Arquitecturas multicloud, carteras de aplicaciones que abarcan desde mainframes hasta la nube, presión de la junta para acelerar la IA y los resultados digitales: los CIO de hoy se enfrentan a una serie de desafíos que pueden afectar a sus estrategias de DevOps. A continuación, se presentan seis errores comunes que los CIO todavía cometen al implementar DevOps, junto con recomendaciones para repensar su enfoque.

Adoptar una mentalidad de proyecto de TI en lugar de una de transformación cultural

DevOps requiere una alineación cultural entre dev y ops para mejorar las experiencias de los clientes, impulsar la agilidad empresarial y mejorar la resiliencia operativa. Pero al adoptar un enfoque de implementación que da prioridad a las herramientas, muchos CIO pasan por alto la importancia del cambio cultural.

“Los CIO pueden abordar erróneamente DevOps como una implementación estrecha de TI sin priorizar el cambio cultural necesario hacia la colaboración, la automatización y la mejora continua en toda la organización”, dice Naresh Duddu, AVP y jefe global de la práctica de Modernización de Infosys. “También pueden pasar por alto la importancia de alinear las prácticas DevOps con la entrega de valor de extremo a extremo, las perspectivas del cliente, las consideraciones de seguridad, la escalabilidad de la infraestructura y la capacidad de escalar DevOps a nivel empresarial más allá de equipos o proyectos aislados”.

Este también puede ser el caso cuando se trata de cumplimiento, operaciones y gobernanza también.

“Para implementar DevOps con éxito, los CIO deben centrarse en fomentar una cultura que enfatice el flujo de trabajo, integrando las prácticas DevOps con ITIL existente u otros marcos de gobierno para garantizar el cumplimiento junto con la agilidad”, dice Gabby Menachem, VP de producto, ITOM en ServiceNow.

Rick Boyce, director de Tecnología de AND Digital, subraya cómo una mentalidad típica de proyecto de TI hacia DevOps puede socavar la capacidad del CIO para cumplir los objetivos empresariales.

“Cuando DevOps se trata como un proceso de TI más o como la responsabilidad de un solo equipo, las organizaciones ven ciclos de productos más lentos y una falta de alineación entre los objetivos de desarrollo y de negocio”, afirma. “Al fomentar una cultura de colaboración y responsabilidad compartida, las empresas pueden acelerar su tiempo de comercialización, mejorar la calidad del producto y mejorar su adaptabilidad a las cambiantes condiciones del mercado”

Recomendación: Pregunte a los líderes por su comprensión de prácticas clave como agile, DevOps y gestión de productos, y las diferencias en los principios básicos, metodologías y herramientas saldrán a la superficie. Los CIO pueden alinear la cultura extrayendo las opiniones de la gente y forjando la visión de la organización para equilibrar la innovación y la resistencia de las operaciones, que es el núcleo de una cultura DevOps.

Dirigirse a la entrega continua sin las operaciones adecuadas

Algunos equipos de DevOps que desarrollan canalizaciones avanzadas de CI/CD se lanzan rápidamente al despliegue continuo, enviando cambios de código a la producción con frecuencia en calendarios de despliegue rápidos. Pero el despliegue continuo no siempre es apropiado para su negocio, las partes interesadas no siempre entienden los costes de implementar pruebas continuas robustas, y los usuarios finales no siempre toleran despliegues frecuentes de aplicaciones durante los picos de uso.

Los CIO también deben considerar si los equipos de DevOps tienen los requisitos de seguridad, observabilidad, AIops, y otras disciplinas para garantizar despliegues robustos que cumplan con los objetivos de nivel de servicio esperados.

“No todos los equipos DevOps tienen la misma disciplina y cultura necesarias para automatizar la integración y la entrega como una unidad correctamente”, dice Vikram Murali, vicepresidente de Modernización de Aplicaciones y Automatización de TI en IBM. “Los CIO necesitan asegurarse de que su comportamiento, cadenas de herramientas y estandarizaciones están configurando sus equipos para prácticas DevOps exitosas. Con demasiada frecuencia, vemos equipos que comprometen la calidad por la velocidad y toman atajos para desplegar código en producción debido a CI/CD”.

Jim Stratton, CTO de Workday, explica sucintamente por qué su organización sigue un calendario de despliegue semanal: “Para seguir evolucionando nuestra plataforma sin romper cosas, necesitamos probarlo todo”.

CrowdStrike fue noticia recientemente por un despliegue fallido que afectó a 8,5 millones de ordenadores con Microsoft Windows, provocó casi 10.000 cancelaciones de vuelos en todo el mundo y generó un importante impacto financiero. La crisis debería ser una advertencia para todos los CIO que facultan a los equipos DevOps para acelerar la entrega continua sin suficientes pruebas, reversión, monitoreo y otras mejores prácticas operativas.

Según el informe State of DevOps Report 2023, solo el 18% de las organizaciones alcanzaron un rendimiento de élite desplegando bajo demanda, teniendo una tasa de fallos de cambio del 5% y recuperándose de cualquier despliegue fallido en menos de una hora. Las organizaciones de altYTo rendimiento (31%) realizan despliegues entre una vez al día y una vez a la semana, registran tasas de fallos de cambios del 10% y se recuperan de un despliegue fallido en menos de un día. Tenga en cuenta estos puntos de referencia del mundo real.

Recomendación: Los CIO deben adoptar un enfoque basado en el riesgo, entendiendo los impactos en el negocio, los clientes y los empleados antes de establecer estrategias de despliegue continuo específicas para cada aplicación. Las aplicaciones autorizadas para despliegues frecuentes y continuos deben contar con pruebas continuas sólidas, mayor capacidad de observación y una estrategia de lanzamiento canaria para minimizar los riesgos.

Cortocircuitar las experiencias del usuario final y del desarrollador

Muchas prácticas DevOps se centran en la automatización, como CI/CD e infraestructura como código. Los CIO pueden equivocarse al invertir poco en prácticas que mejoren las experiencias de los usuarios, aumenten la alineación con las partes interesadas del negocio y promuevan una experiencia positiva de los desarrolladores.

Un ejemplo es cómo los equipos de DevOps utilizan las banderas de características, que pueden impulsar la experimentación ágil al permitir a los gestores de productos probar características y variantes de experiencia de usuario. Las banderas de características también pueden ayudar a los equipos de DevOps a reducir el miedo al fracaso controlando las características en función de los impactos en el rendimiento y automatizando las comunicaciones con las partes interesadas en torno a las implementaciones.

Pero demasiados equipos de DevOps utilizan las banderas de características sólo para controlar el acceso de los usuarios a las nuevas características, dice Claire Vo, jefe de producto de LaunchDarkly. “Son herramientas versátiles dentro de DevOps que permiten despliegues más seguros, facilitan las pruebas A/B y mejoran la resiliencia operativa”, dice.

Las funciones y responsabilidades de DevOps -especialmente cuando se ‘dejan’ funciones de automatización de infraestructuras, pruebas y seguridad a los desarrolladores- también pueden ser un problema. En algunos casos, colocar demasiadas responsabilidades sobre los hombros de los desarrolladores reduce su productividad y les obliga a desarrollar niveles de experiencia poco realistas.

Los CIO y los CTO deben evitar las trampas, afirma Rob Whiteley, CEO de Coder. “Aunque DevOps y DevSecOps pueden impulsar una enorme automatización y ahorro de tiempo, a menudo suponen un impuesto para el desarrollador. Desplazar las operaciones más temprano en el ciclo de vida de desarrollo de software aumenta la carga cognitiva y disminuye la productividad del desarrollador”.

Recomendación: Los CIO deben hacer preguntas y facilitar discusiones sobre cómo las prácticas DevOps impactan a las personas, incluidos los clientes, los usuarios finales, los empleados y los desarrolladores. Los directores de sistemas de información también deben opinar sobre las funciones y responsabilidades y supervisar la definición de un modelo de gobernanza para evitar sobrecargar a las personas o acabar con vacíos de responsabilidad.

Facultar a los equipos para seleccionar herramientas sin normas

Permitir que los equipos elijan sus plataformas, herramientas y tecnologías puede ayudar a obtener mejores resultados, pero esta práctica conlleva ciertas advertencias.

“Permitir que los equipos elijan las herramientas no significa que se dé rienda suelta a cada equipo para que elija la herramienta que quiera. Introducir tecnologías sin ningún tipo de restricciones puede aumentar la deuda técnica y la fragilidad”, afirma el programa de investigación DORA de Google Cloud sobre la posibilidad de que los equipos elijan herramientas.

Un enfoque para desarrollar estándares DevOps es establecer disciplinas de ingeniería de plataformas para crear componentes reutilizables, configurables y de autoservicio. Según el informe 2024 State of DevOps Report: The Evolution of Platform Engineering, el 78% de los encuestados trabaja en organizaciones que cuentan con grupos de ingeniería de plataformas desde hace al menos tres años. Los principales beneficios de la ingeniería de plataformas para los desarrolladores incluyen el aumento de la productividad, la mejora de la calidad del software, la reducción del tiempo de despliegue y la mayor estabilidad de las aplicaciones.

La ingeniería de plataformas es un método para crear normas y reforzar principios clave. Esto ayuda a los equipos a evitar centrarse demasiado en la tecnología, perder de vista los objetivos empresariales o introducir la deuda DevOps mediante la creación de capacidades que serán difíciles de mantener.

“Si bien la automatización es un componente crítico de DevOps, no es una panacea”, dice Lukas Gentele, cofundador y CEO de Loft, y agrega que puede conducir a problemas más significativos en el camino. “La automatización puede mostrar rápidamente mejoras en la velocidad y frecuencia de despliegue, pero si la arquitectura subyacente no está diseñada para soportar entornos escalables y multi-tenant, puede conducir a dolores de cabeza operativos y mayores costes”.

Recomendación: Los CIO deben encontrar un equilibrio con sus equipos de DevOps entre las prácticas de autoorganización, la experimentación con nuevas tecnologías, el establecimiento de plataformas y la creación de estándares. Más allá de la ingeniería de plataformas, los CIO deben considerar las funciones de los arquitectos empresariales y los líderes de entrega en sus organizaciones y cómo colaboran cuando surgen preguntas sobre plataformas y metodologías DevOps.

Esperar que los equipos definan estrategias de riesgo adecuadas

Si bien los equipos pueden aprender los principios de DevSecOpsy los CIO pueden seleccionar marcos de gestión de riesgos de TI, muchas organizaciones carecen de personal suficiente para revisar cómo los equipos priorizan la mitigación proactiva del riesgo e implementan medidas de seguridad sólidas cuando cambian a la izquierda.

“Muchos CIO creen que asegurar las aplicaciones de su organización implica simplemente gestionar una lista agregada de vulnerabilidades detectadas”, afirma Moti Gindi, director de Producto de Apiiro.

“La detección de vulnerabilidades y la priorización de las correcciones en el backlog del equipo de desarrollo ágil es reactiva y sólo aborda las vulnerabilidades conocidas y los posibles problemas de la cadena de suministro de software”.

Bill Murphy, director de Seguridad y Cumplimiento de LeanTaaS, dice que los equipos DevOps pueden no centrarse lo suficiente en la seguridad de los datos. “Las violaciones de la seguridad de los datos tienen consecuencias que van mucho más allá de notificar a las partes afectadas. Empañan gravemente la reputación de una organización, lo que lleva a la pérdida de oportunidades de negocio a través de la disminución de las renovaciones de clientes y una disminución en la adquisición de nuevos clientes”.

Una nueva área de preocupación es cómo los equipos de desarrollo utilizan la generación de código y los copilotos de IA. “La IA complementa el trabajo de desarrolladores e ingenieros, liberando tiempo para la innovación, el diseño de sistemas y la arquitectura”, afirma Andrea Malagodi, CIO de Sonar. “Preveo que los CIO centrarán los equipos en diseños sólidos, buenos patrones de arquitectura, pruebas de código rigurosas y análisis crítico del código para garantizar que cumple los estándares de calidad y seguridad”.

Recomendación: Los CIO deben exigir a los jefes de producto y a los líderes de entrega que definan sus hojas de ruta mostrando las prioridades en nuevas capacidades, deuda técnica y mitigación de riesgos. Incluso a medida que la automatización, las pruebas continuas y el aumento de las prácticas de observabilidad permiten a los equipos DevOps aumentar la frecuencia de despliegue, las organizaciones deben definir una estrategia de gestión de lanzamientos y establecer revisiones periódicas de cómo cada equipo prioriza y aborda los riesgos.

No definir el papel del CIO en DevOps

Una última área donde los CIO se equivocan es cuando saltan a DevOps sólo después de problemas importantes como interrupciones del sistema, despliegues fallidos, partes interesadas enojadas o brechas de seguridad.

“Para los CIO, el debate en torno a DevOps a menudo parece muy profundo, por lo que lo delegan a alguien dos o tres niveles por debajo en el desarrollo”, dice David Brooks, SVP de evangelización en Copado. “DevOps se trata de entregar valor al negocio de manera más rápida y confiable y está en el corazón de los esfuerzos de transformación digital”.

Debido a que DevOps ha estado madurando durante más de 15 años, los CIO deben esperar que sus compañeros de equipo tengan diferentes visiones y enfoques de implementación. Los CIO que lideran la transformación digital deben involucrarse proactivamente en la definición de la cultura DevOps, especificando cómo colaborarán con los equipos regularmente y promoviendo prácticas alineadas con las necesidades del negocio.