Por qué la implementación de DevOps suele fracasar (y cómo solucionarlo)

Este artículo se publicó inicialmente en DevOps.com. Ha sido actualizado y modificado.

Al igual que «blockchain», «big data» y «disrupción digital», el término «DevOps» es otra palabra de moda que se utiliza actualmente en los servicios informáticos de las grandes empresas.

Muchos han identificado (correctamente) la necesidad de acelerar el ciclo de vida del desarrollo de software; un proceso más preciso, estrechamente alineado con los objetivos comerciales, que permite un flujo de trabajo más claro y la colaboración entre los equipos encargados del desarrollo y las operaciones. DevOps es esencialmente un desarrollo «ágil», desarrollado y listo para responder a las necesidades de innovación constante y despliegue rápido de las empresas modernas. Para los profesionales de la seguridad, se trata de una iniciativa fantástica: podemos integrar la seguridad en el proceso mucho antes, lo que reduce el coste de la corrección de errores y evita posibles catástrofes en el camino.

El problema es que pocas empresas logran realmente implementar DevOps. Sin el apoyo, el estímulo y la comprensión adecuados dentro de la empresa, esta puede convertirse rápidamente en un elefante blanco... ya sabes, uno de esos proyectos «no se habla de la guerra».

Entonces, ¿cuál es el problema? Es una discusión interesante, y hay varias maneras de abordar DevOps que, en mi opinión, facilitarán la navegación. Un programa eficaz no se limita a unas pocas herramientas nuevas, títulos y reuniones de equipo sofisticadas. No siempre será fácil, pero dedicar tiempo a corregir una estrategia fallida (o a implementarla correctamente desde el principio) será mucho menos doloroso a largo plazo. Al final, esto se traducirá en un software de mejor calidad y más seguro.

Descompongámoslo:

Suelte los cordones del delantal «Ágil».

Existe una idea errónea de que una organización debe elegir entre Agile o DevOps, fijándose un camino u otro, para no volver nunca atrás.

El hecho es que el proceso de desarrollo funciona mejor cuando ambos se consideran y se implementan como uno solo. DevOps no es una reinvención del desarrollo ágil, sino más bien una extensión del mismo. Las cosas tienden a fallar cuando se espera que el proceso sea exactamente igual que Agile o completamente diferente de Agile.

Agile apoya el principio de los equipos multifuncionales, reuniendo a los diseñadores, probadores y desarrolladores desde el principio y comprometiéndose a abrir líneas de comunicación a lo largo de todo el proyecto. Su objetivo es poner fin a la entrega compartimentada y reducir la doble gestión, dos ventajas del proceso DevOps. Sin embargo, DevOps va aún más allá al integrar los sistemas, la seguridad y las operaciones en la mezcla para ofrecer un conjunto de competencias sólidas de principio a fin, cuyo objetivo final es proporcionar al cliente software completo y funcional.

Durante las inevitables dificultades relacionadas con la transición a un proceso más centrado en DevOps, puede reaparecer el riesgo de un desarrollo compartimentado. A menudo, el equipo ágil original trabaja en conjunto, mientras que los elementos adicionales relacionados con la seguridad y las operaciones siguen encontrando su lugar en la máquina; nadie sabe realmente cómo incluirlos, qué deben hacer y cuáles son sus objetivos generales.

DevOps no funciona sin objetivos claramente definidos, una integración interfuncional y una comunicación directa con todas las partes. Habrá un período de adaptación que requerirá una gestión minuciosa del cambio, por supuesto, pero poner a todos en sintonía gracias a las mejoras aportadas por las funcionalidades de DevOps representa la mitad de la batalla.

Cada vez más (gracias a Dios), DevOps también hace hincapié en las mejores prácticas de seguridad como parte del proceso, desmitificando esta etapa y cerrando la brecha entre el equipo de seguridad y, finalmente, los demás. Como ya he dicho, aún nos queda un largo camino por recorrer para que los desarrolladores puedan programar de forma segura desde el principio, pero la implementación exitosa de las metodologías DevOps constituye una excelente base sobre la que se pueden reforzar las competencias en materia de seguridad dentro del equipo de desarrollo.

La automatización no lo es todo (y no es la solución más segura).

Otra característica de la metodología DevOps es, en cierta medida, la automatización del proceso de desarrollo de software. Los principios de integración continua y entrega continua (CI/CD) son los pilares de este concepto y, como probablemente ya habrás adivinado, dependen en gran medida de las herramientas.

Las herramientas son geniales, realmente lo son. Pueden aportar una rapidez sin precedentes al proceso de entrega de software, gestionando el repositorio de código, las pruebas, el mantenimiento y los elementos de almacenamiento con una facilidad relativamente fluida.

Sin embargo, aunque los robots puedan quitarnos todos nuestros puestos de trabajo y aprisionarnos algún día, sin duda aún no han llegado a ese punto. La fuerte dependencia de las herramientas y la automatización deja la puerta abierta a los errores. Los escaneos y las pruebas pueden no detectar todo, el código puede no verificarse, lo que a la larga provoca enormes problemas de calidad (por no hablar de seguridad). Un atacante solo necesita una puerta trasera que explotar para robar datos, y renunciar al elemento humano en el control de calidad y seguridad puede tener consecuencias desastrosas.

El «justo medio» consiste en asegurarse de que existe un equilibrio entre las personas y las herramientas. Las herramientas deben servir de ayuda a un equipo en el que confía para alcanzar los objetivos del proyecto. Debe:

• Prevea tiempo suficiente para que los usuarios se familiaricen con la cadena de herramientas DevOps elegida.
• Concéntrese en una colaboración eficaz (y en cómo las herramientas pueden contribuir a ello).
• Cubra todas las lagunas del proceso, ya sean relacionadas con las competencias, los conocimientos o las herramientas.

En resumen, no se conforme con «equiparse» y esperar que todo salga bien.

DevOps no es una palabra de moda, es una cultura. ¿Cultivas la tuya?

La gestión del cambio es difícil incluso en el mejor de los casos. El miedo a lo desconocido puede impedir que incluso los miembros más brillantes del equipo desarrollen sus habilidades y amplíen sus horizontes.

Verán, el simple hecho de decir «Hagamos DevOps» y trasladar las oficinas del equipo de operaciones no bastará para implementar un proceso exitoso como por arte de magia. Muchos se sentirán confundidos y los miembros más antiguos del equipo estarán descontentos. La comunicación de las expectativas es fundamental, al igual que «predicar con el ejemplo». DevOps representa un movimiento cultural tanto como una metodología de desarrollo, y un equipo debe vivir y respirar una mentalidad interfuncional y colaborativa.

¿Cómo es una buena cultura DevOps?

• Las personas están capacitadas para aportar su experiencia a un proceso, y no solo los dirigentes.
• Comunicación abierta, honesta y respetuosa entre los equipos.
• Cada persona asume la responsabilidad del objetivo global que consiste en integrar la calidad y la seguridad en el proceso de desarrollo.
• Todo el mundo está en sintonía en lo que respecta a la definición de DevOps en la empresa, la hoja de ruta y el cómo, el qué y el porqué del papel de cada uno.

Hace años que destaco la importancia de crear una cultura de seguridad positiva dentro de los equipos de desarrollo, y DevOps no es una excepción a la regla.

Las herramientas, los conocimientos y el apoyo adecuados son esenciales para aplicar las mejores prácticas en materia de seguridad, reducir las vulnerabilidades detectadas y hacer comprender al equipo la importancia de proteger nuestros datos. Con DevOps, debe sentar las bases culturales para un cambio positivo: asegurarse de que todos comprendan su función, su valor y sus expectativas, los objetivos generales del proyecto y las etapas del proceso.

¿Lo ha dominado? Genial. Ahora cambiemos las cosas, mejoremos la seguridad y hagamos de DevSecOps el plan definitivo en materia de excelencia en software.