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

Este artículo se publicó originalmente 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 circula actualmente por los departamentos de TI de las grandes organizaciones.

Muchos han identificado (correctamente) la necesidad de ciclos de vida de desarrollo de software más rápidos; un proceso más preciso que esté estrechamente alineado con los objetivos comerciales, permitiendo un flujo de trabajo y una colaboración más claros entre los equipos de desarrollo y operaciones. DevOps es, en esencia, el desarrollo "Agile" maduro y listo para asumir las necesidades de innovación constante y despliegue rápido de las empresas modernas. Para los profesionales de la seguridad, es una iniciativa fantástica: podemos integrar la seguridad en el proceso mucho antes, reduciendo el coste de corregir errores y evitando posibles catástrofes en el futuro.

El problema es que pocas empresas tienen éxito en su implementación de DevOps. Sin el apoyo, el fomento y la comprensión adecuados en toda la empresa, puede convertirse rápidamente en un elefante blanco... ya sabe, uno de esos proyectos de los que "mejor no hablar".

Entonces, ¿cuál es el problema? Es una discusión interesante, y hay varias formas de abordar DevOps que creo que facilitarán mucho las cosas. Un programa eficaz va más allá de unas cuantas herramientas, títulos y reuniones de equipo novedosas. No siempre será fácil, pero dedicar tiempo a arreglar una estrategia fallida (o implementarla correctamente desde el principio) será mucho menos doloroso a largo plazo. Y, en última instancia, dará como resultado un software de mayor calidad y más seguro.

Analicémoslo:

Suéltese de las faldas de "Agile".

Existe la idea errónea de que una organización debe elegir entre Agile o DevOps, tomando un camino u otro sin vuelta atrás.

La cuestión es que el proceso de desarrollo funciona mejor cuando ambos se consideran e implementan como uno solo. DevOps no es una reinvención del desarrollo Agile; más bien, es una extensión del mismo. Las cosas suelen torcerse cuando se espera que el proceso sea exactamente igual que Agile, o completamente diferente a Agile.

Agile apoya el principio de los equipos multifuncionales, reuniendo a diseñadores, evaluadores y desarrolladores desde el principio y comprometiéndose a mantener líneas de comunicación abiertas durante todo el proyecto. Su objetivo es detener la entrega aislada y reducir la duplicidad de tareas, ambos beneficios del proceso DevOps. Sin embargo, DevOps va un paso más allá al introducir sistemas, seguridad y operaciones en la mezcla para ofrecer un conjunto de habilidades sólido e integral que tiene como objetivo final la entrega de software funcional completo al cliente.

Durante los inevitables puntos críticos de la transición a un proceso más centrado en DevOps, el riesgo de un desarrollo aislado puede volver a surgir. A menudo, el equipo Agile original trabaja unido, mientras que las incorporaciones de seguridad y operaciones todavía están encontrando su lugar en el engranaje; nadie está seguro de cómo incluirlos, qué deben hacer o cuáles son sus objetivos generales.

DevOps no funciona sin objetivos claramente definidos, una integración multifuncional y una comunicación directa con todas las partes. Habrá un período de ajuste que requerirá una gestión del cambio cuidadosa, por supuesto, pero lograr que todos estén en sintonía con las mejoras que traerá la funcionalidad de DevOps es la mitad de la batalla.

Cada vez más (afortunadamente), DevOps también pone énfasis en las mejores prácticas de seguridad como parte del proceso, desmitificando ese paso y cerrando la brecha entre el equipo de seguridad y, bueno, todos los demás. Como he dicho antes, todavía nos queda un largo camino por recorrer para capacitar a los desarrolladores para que codifiquen de forma segura desde el principio, pero la implementación exitosa de las metodologías DevOps es una base excelente sobre la cual construir habilidades de seguridad dentro del equipo de desarrollo.

La automatización no lo es todo (y no es lo más seguro).

Otra característica de la metodología DevOps es, hasta cierto punto, la automatización del proceso de desarrollo de software. Los principios de integración continua y entrega continua (CI/CD) son las piedras angulares de este concepto y, como probablemente pueda imaginar, dependen mucho de las herramientas.

Las herramientas son increíbles, de verdad. Pueden aportar una velocidad 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 algún día nos quiten el trabajo y nos encarcelen, definitivamente aún no han llegado a ese punto. Una gran dependencia de las herramientas y la automatización deja una ventana abierta de par en par a los errores. Es posible que los escaneos y las pruebas no detecten todo, que el código no se revise y eso presenta enormes problemas de calidad (por no mencionar de seguridad) en el futuro. Un atacante solo necesita una puerta trasera para explotar y robar datos, y prescindir del factor humano en el control de calidad y seguridad puede tener consecuencias desastrosas.

El "punto medio" es asegurarse de tener un equilibrio entre personas y herramientas. Las herramientas deben servir como asistentes de un equipo en el que confía para cumplir los objetivos del proyecto. Usted debería:

• Asignar suficiente tiempo para que las personas se familiaricen con la cadena de herramientas DevOps elegida
• Centrarse en una colaboración eficaz (y en cómo las herramientas pueden apoyarla)
• Abordar cualquier brecha en el proceso, ya sea basada en habilidades/conocimientos o en herramientas.

En resumen, no se limite a adquirir herramientas y esperar que todo salga bien.

DevOps no es una palabra de moda, es una cultura. ¿Está cultivando la suya?

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

Verá, simplemente decir "hagamos DevOps" y hacer que el equipo de operaciones cambie de escritorio no implementará mágicamente un proceso exitoso. Muchos se sentirán confundidos y los miembros más veteranos del equipo terminarán descontentos. Comunicar las expectativas es crucial, 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 colaborativa e interdisciplinaria.

¿Cómo es una gran cultura DevOps?

• Se faculta a las personas para que aporten su experiencia al proceso, no solo a los líderes
• Comunicación abierta, honesta y respetuosa entre equipos
• Cada persona asume la responsabilidad del objetivo general de integrar calidad y seguridad en el proceso de desarrollo
• Todos están alineados con la definición de DevOps en la empresa, la hoja de ruta y el cómo, qué y porqué del rol de cada uno.

Durante años he enfatizado la importancia de construir culturas de seguridad positivas en los equipos de desarrollo, y DevOps no es la excepción.

Las herramientas, el conocimiento y el apoyo adecuados son fundamentales para lograr las mejores prácticas de seguridad, reducir las vulnerabilidades descubiertas y concienciar al equipo sobre la importancia de proteger nuestros datos. Con DevOps, debe sentar las bases culturales para un cambio positivo: asegúrese de que todos comprendan su rol, su valor y las expectativas, así como los objetivos generales del proyecto y los pasos del proceso.

¿Ya lo domina? Genial. Ahora, demos un paso más, intensifiquemos la seguridad y hagamos de DevSecOps el plan definitivo para la excelencia en software.