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 actualmente circula en los departamentos de TI de las grandes empresas.

Muchos han reconocido (con razón) la necesidad de ciclos de desarrollo de software más rápidos; un proceso más preciso, estrechamente alineado con los objetivos empresariales y que permite un flujo de trabajo más claro y una colaboración más clara entre los equipos de desarrollo y operaciones. DevOps es, en esencia, un desarrollo «ágil» que ha madurado y está listo para satisfacer las necesidades en constante cambio y rápida evolución de la empresa moderna. Para los expertos en seguridad, se trata de una iniciativa fantástica: podemos integrar la seguridad mucho antes en el proceso y, de este modo, reducir los costes de corrección de errores y evitar posibles catástrofes en el futuro.

El problema es que solo unas pocas empresas tienen éxito realmente en la implementación de DevOps. Sin el apoyo, el cuidado y la comprensión adecuados en toda la empresa, puede convertirse rápidamente en un pozo sin fondo... Ya saben, uno de esos proyectos en los que no se menciona la guerra.

Entonces, ¿cuál es el problema? Es un debate interesante, y hay varias formas de abordar DevOps que, en mi opinión, garantizarán un proceso mucho más fluido. Un programa eficaz va más allá de unas cuantas herramientas nuevas y elegantes, títulos y reuniones de equipo. No siempre será fácil, pero dedicar tiempo a reparar una estrategia defectuosa (o implementarla correctamente desde el principio) será mucho menos doloroso a largo plazo. Y, en última instancia, esto dará lugar a un software de mayor calidad y más seguro.

Analicemos esto:

Suelta los cordones del delantal «Agile».

Existe un cierto malentendido de que una empresa debe elegir entre Agile y DevOps y, al hacerlo, debe seguir uno u otro camino sin mirar atrás.

La cuestión es que el proceso de desarrollo funciona mejor cuando ambos se consideran y se implementan como una unidad. DevOps no es una reinvención del desarrollo ágil, sino más bien una ampliación del mismo. Las ruedas tienden a caerse cuando se espera que el proceso sea exactamente igual que Agile o completamente diferente de Agile.

Agile apoya el principio de equipos multifuncionales, reúne a diseñadores, probadores y desarrolladores desde el principio y se compromete a mantener vías de comunicación abiertas durante todo el proyecto. El objetivo es acabar con el suministro aislado y reducir la duplicación del trabajo. Ambas son también ventajas del proceso DevOps. Sin embargo, DevOps va un paso más allá e incorpora sistemas, seguridad y operaciones a la mezcla para ofrecer unos conocimientos sólidos y continuos, con el objetivo final de proporcionar al cliente una entrega de software completa y funcional.

Durante los inevitables problemas que surgen al pasar a un proceso más orientado a DevOps, puede reaparecer el riesgo de un desarrollo aislado. A menudo, el equipo ágil original puede trabajar en conjunto, mientras que las ampliaciones de seguridad y operaciones siguen encontrando su camino hacia la máquina. Nadie está completamente seguro de cómo incorporarlas, qué deben 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 implicadas. Por supuesto, habrá una fase de adaptación que requerirá una gestión cuidadosa del cambio, pero poner a todos al mismo nivel con las mejoras que traerá consigo la funcionalidad DevOps es la mitad del camino.

Cada vez más (gracias a Dios), DevOps también valora las prácticas de seguridad probadas como parte del proceso, desmitifica este paso y salva la brecha entre el equipo de seguridad y todos los demás. Como ya he dicho, aún nos queda un largo camino por recorrer para capacitar a los desarrolladores para que programen de forma segura desde el principio, pero la implementación exitosa de los métodos DevOps es una base excelente sobre la que se pueden desarrollar las competencias 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 los pilares de este concepto y, como probablemente pueda imaginar, dependen en gran medida de las herramientas.

Las herramientas son fantásticas, realmente lo son. Pueden acelerar el proceso de implementación de software de una manera sin precedentes y gestionar el repositorio de código, así como los elementos de prueba, mantenimiento y almacenamiento con relativa facilidad.

Es cierto que los robots podrían quitarnos todos nuestros puestos de trabajo y encerrarnos algún día, pero definitivamente aún no han llegado a ese punto. La fuerte dependencia de las herramientas y la automatización deja una gran puerta abierta a los errores. Es posible que los escaneos y las pruebas no lo detecten todo, que el código quede sin revisar y que esto provoque posteriormente enormes problemas de calidad (por no hablar de los problemas de seguridad). Un atacante solo necesita una puerta trasera para aprovechar los datos, y prescindir del componente humano en el control de calidad y seguridad puede tener consecuencias catastróficas.

El «equilibrio ideal» consiste en garantizar que exista una proporción equilibrada entre las personas y las herramientas. Las herramientas deben servir como asistentes para un equipo en el que confía para alcanzar los objetivos del proyecto. Deben:

• Planifique el tiempo suficiente para que los empleados puedan familiarizarse con la cadena de herramientas DevOps seleccionada.
• Concéntrese en una colaboración eficaz (y en cómo las herramientas pueden contribuir a ello).
• Cierre todas las brechas en el proceso, independientemente de si se basan en habilidades, conocimientos o herramientas.

En resumen, no se limite a «equiparse» y esperar lo mejor.

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

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

Como pueden ver, limitarse a decir «vamos a implementar DevOps» y hacer que el equipo operativo cambie de escritorio no va a implementar mágicamente un proceso exitoso. Muchos se sentirán confundidos y los miembros más veteranos del equipo se sentirán molestos. Comunicar las expectativas es fundamental, al igual que «seguir su propio camino». DevOps es tanto un movimiento cultural como una metodología de desarrollo, y un equipo debe vivir y respirar una mentalidad colaborativa y multifuncional.

¿Cómo es una cultura DevOps excelente?

• Las personas individuales están capacitadas para aportar sus conocimientos especializados a un proceso, no solo los directivos.
• Comunicación abierta, honesta y respetuosa entre equipos
• Cada persona asume la responsabilidad del objetivo general de la calidad y la seguridad del edificio en el proceso de desarrollo.
• Todos están de acuerdo en cuanto 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 persona.

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

Las herramientas adecuadas, los conocimientos adecuados y el apoyo adecuado son esenciales para implementar prácticas de seguridad probadas, observar una disminución en las vulnerabilidades de seguridad detectadas 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 función, su valor y sus expectativas, así como los objetivos generales del proyecto y los pasos individuales del proceso.

¿Lo ha dominado? Estupendo. Ahora cambiemos de tema, profundicemos en el aspecto de la seguridad y hagamos de DevSecOps el plan definitivo para la excelencia del software.