Por qué la implementación de DevOps a menudo no tiene éxito (y cómo puede solucionarlo)

Este artículo se publicó originalmente en DevOps.com. Se ha 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 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 empresariales, lo que permite un flujo de trabajo y una colaboración más claros entre los equipos de desarrollo y los basados en las operaciones. DevOps es, en esencia, un desarrollo «ágil», desarrollado y preparado para hacer frente a las necesidades de las empresas modernas, que están en constante innovación y se despliegan con rapidez. Para los profesionales de la seguridad, se trata de una iniciativa fantástica: podemos inyectar seguridad en el proceso mucho antes, lo que reduce el coste de corregir errores y evita posibles catástrofes en el futuro.

El problema es que pocas empresas tienen realmente éxito en su implementación de DevOps. Sin el apoyo, el cariño y la comprensión adecuados en toda la empresa, la empresa puede convertirse rápidamente en un saco sin fondo... ya sabes, uno de esos proyectos en los que «no hay que hablar de la guerra».

Entonces, ¿cuál es el problema? Es un debate interesante, y hay algunas maneras de abordar DevOps que creo que harán que la navegación sea mucho más fluida. Un programa eficaz va más allá de unas cuantas herramientas, títulos y reuniones de equipo nuevos y sofisticados. No siempre va a ser fácil, pero tomarse el tiempo para arreglar una estrategia que no funciona (o implementarla de la manera correcta desde el principio) va a ser mucho menos doloroso a largo plazo. Y, en última instancia, se traducirá en un software más seguro y de mayor calidad.

Vamos a desglosarlo:

Suelta las cuerdas del delantal «Agile».

Existe una idea un tanto errónea de que una organización debe elegir entre Agile o DevOps, estableciendo un camino u otro, para no mirar hacia 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 ágil, sino más bien una extensión del mismo. Las ruedas tienden a caerse cuando se espera que el proceso se lleve a cabo exactamente como Ágil, o completamente diferente de Agile.

Agile apoya el principio de los equipos interfuncionales, ya que reúne a diseñadores, evaluadores y desarrolladores desde el principio y se compromete a abrir líneas de comunicación a lo largo de un proyecto. Su objetivo es detener la entrega en silos y reducir la doble gestión, que también son beneficios del proceso de DevOps. Sin embargo, DevOps va un paso más allá e incorpora sistemas, seguridad y operaciones para ofrecer un conjunto de habilidades sólidas e integrales con el objetivo final de ofrecer un software completo y funcional al cliente.

Durante los inevitables puntos problemáticos de pasar a un proceso más centrado en DevOps, el riesgo de un desarrollo aislado puede volver a surgir. Con frecuencia, el equipo original de Agile trabaja en equipo, mientras que las incorporaciones de seguridad y operaciones siguen haciéndose un hueco en la máquina; nadie sabe muy bien cómo incluirlas, qué deberían hacer y cuáles son sus objetivos generales.

DevOps no funciona sin objetivos claramente definidos, una incorporación interfuncional y una comunicación directa con todas las partes. No cabe duda de que habrá un período de adaptación que requerirá una gestión cuidadosa de los cambios, pero conseguir que todos estén de acuerdo con las mejoras que aportará la funcionalidad de DevOps es la mitad de la batalla.

Cada vez más (gracias a Dios), DevOps también pone más énfasis en las mejores prácticas de seguridad como parte del proceso, desmitificando ese paso y reduciendo 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 que los desarrolladores puedan programar de forma segura desde el principio, pero la implementación exitosa de las metodologías de DevOps es una base excelente sobre la que se pueden desarrollar las habilidades de seguridad del equipo de desarrollo.

La automatización no lo es todo (y no es la 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 la integración continua y la entrega continua (CI/CD) son las piedras angulares de este concepto y, como se puede imaginar, dependen en gran medida de las herramientas. ¡

Las herramientas son increíbles, de verdad. Pueden aportar una velocidad sin precedentes al proceso de entrega de software, ya que administran el repositorio de código, las pruebas, el mantenimiento y los elementos de almacenamiento con una facilidad relativamente fluida.

Sin embargo, aunque los robots podrían quitarnos todos nuestros trabajos y encarcelarnos algún día, definitivamente aún no lo han hecho. La gran dependencia de las herramientas y la automatización deja una ventana abierta a los errores. Es posible que los escaneos y las pruebas no lo detecten todo, que el código no se verifique y eso presente enormes problemas de calidad (sin mencionar los de seguridad) en el futuro. Un atacante solo necesita una puerta trasera para aprovecharla y robar datos, y renunciar al elemento humano en el control de calidad y seguridad puede tener consecuencias desastrosas.

El «punto medio» es asegurarse de tener un equilibrio entre las personas y las herramientas. Las herramientas deben servir de asistente a un equipo en el que confíes para cumplir los objetivos del proyecto. Deberías:

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

En resumen, no te limites a «prepararte» y esperar lo mejor.

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

La gestión del cambio es difícil 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á, simplemente decir «hagamos DevOps» y hacer que el equipo de operaciones cambie de escritorio no va a implementar mágicamente un proceso exitoso. Muchos se sentirán confundidos y los miembros del equipo que llevan mucho tiempo trabajando se sentirán descontentos. La comunicación de las expectativas es crucial, al igual que «dar ejemplo». DevOps representa tanto un movimiento cultural como una metodología de desarrollo, y un equipo debe vivir y respirar una mentalidad interfuncional y colaborativa.

¿Qué aspecto tiene una gran cultura de DevOps?

• Las personas tienen el poder de aportar su experiencia a un proceso, no solo a los líderes.
• Comunicación abierta, honesta y respetuosa entre los equipos
• Cada persona asume la responsabilidad del objetivo general de incorporar la calidad y la seguridad en el proceso de desarrollo.
• Todos están de acuerdo con la definición de DevOps en la empresa, la hoja de ruta y cómo, qué y por qué del rol de cada persona.

Durante años he hecho hincapié en la importancia de crear culturas de seguridad positivas en los equipos de desarrollo, y DevOps no es diferente.

Las herramientas, el conocimiento y el soporte adecuados son imprescindibles para lograr las mejores prácticas de seguridad, observar una disminución en las vulnerabilidades descubiertas y hacer que el equipo comprenda la importancia de proteger nuestros datos. Con DevOps, debes sentar las bases culturales para un cambio positivo: asegurarte de que todos entiendan su función, valor y expectativas, los objetivos generales del proyecto y los pasos del proceso.

¿Lo has dominado? Genial. Ahora cambiemos el enfoque, realicemos el aspecto de la seguridad y hagamos de DevSecOps el plan definitivo para la excelencia del software.