¿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 «cadena de bloques», «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.

Muchas personas ya han reconocido (correctamente) la necesidad de un ciclo de vida de desarrollo de software más rápido; un proceso más preciso y estrechamente relacionado con los objetivos empresariales, que permita un flujo de trabajo y una colaboración más claros entre los equipos de desarrollo y operaciones. DevOps es, en esencia, desarrollo «ágil», en el que todos los desarrolladores crecen y están preparados para responder a las necesidades de innovación y rápida implementación de las empresas modernas. Para los profesionales de la seguridad, se trata de una iniciativa formidable: podemos incorporar la seguridad en el proceso desde el principio, lo que reduce el coste de corregir errores y evita posibles desastres.

El problema es que muy pocas empresas logran implementar DevOps con éxito. Sin el apoyo, la formación y la comprensión adecuados de toda la empresa, pronto se convierte en un elefante blanco... Ya sabes, uno de esos proyectos de los que «no se debe hablar».

Entonces, ¿cuál es el problema? Es un debate interesante, y creo que hay varias formas de implementar DevOps que facilitarán el proceso. Una planificación eficaz no consiste solo en nuevas herramientas sofisticadas, títulos y reuniones de equipo. No siempre es fácil, pero a largo plazo, dedicar tiempo a corregir una estrategia que no funciona (o implementarla correctamente desde el principio) es mucho menos doloroso. Al final, se obtendrá un software de mayor calidad y más seguro.

Analicemos esto:

Soltar el cordón del delantal «ágil».

Existe un malentendido según el cual las organizaciones deben elegir entre agilidad o DevOps, establecer un camino u otro y no mirar atrás nunca.

El problema es que el proceso de desarrollo funciona mejor cuando se considera e implementa como un todo. DevOps no es una reinvención del desarrollo ágil; por el contrario, es una extensión del desarrollo ágil. Cuando se espera que el proceso cambie, las cosas suelen salirse de control, ya sea de forma totalmente similar a la agilidad o totalmente diferente de ella.

Agile apoya el principio de equipos multifuncionales, reuniendo desde el principio a diseñadores, probadores y desarrolladores, y comprometiéndose a mantener abiertos los canales de comunicación durante todo el proyecto. El objetivo es poner fin a las entregas aisladas y reducir la duplicación de tareas, dos de las ventajas del proceso DevOps. Sin embargo, DevOps va más allá e integra sistemas, seguridad y operaciones para ofrecer un sólido conjunto de habilidades de extremo a extremo, con el objetivo final de entregar al cliente un software con todas las funciones.

En el inevitable proceso de transición hacia un enfoque más centrado en DevOps, puede reaparecer el riesgo de un desarrollo aislado. Por lo general, se puede hacer que el equipo ágil inicial trabaje en conjunto, mientras que el personal de seguridad y operaciones recién incorporado sigue buscando su lugar en el sistema informático; nadie sabe con certeza cómo incluirlos, qué deben hacer y cuáles son sus objetivos generales.

DevOps no puede funcionar sin objetivos claros, una incorporación multifuncional y una comunicación directa con todas las partes. Por supuesto, habrá un período de adaptación que requerirá una gestión cuidadosa del cambio, pero lograr que todos lleguen a un consenso sobre las mejoras que aporta la funcionalidad de DevOps es la mitad del camino hacia el éxito.

(Gracias a Dios), DevOps también está prestando cada vez más atención a las mejores prácticas de seguridad, incorporándolas como parte del proceso, desvelando el misterio que rodea a este paso y cerrando la brecha entre el equipo de seguridad y el resto. Como he dicho antes, aún nos queda un largo camino por recorrer para dotar a los desarrolladores de la capacidad de programar de forma segura desde el principio, pero la implementación exitosa del enfoque DevOps es una base excelente para fomentar las habilidades de seguridad dentro del equipo de desarrollo.

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

En cierta medida, otra característica del enfoque DevOps es la automatización del proceso de desarrollo de software. Los principios de integración continua y entrega continua (CI/CD) son la piedra angular de este concepto y, como se puede imaginar, dependen en gran medida de las herramientas. Las herramientas de

son excelentes, sin duda. Aportan una velocidad sin precedentes al proceso de entrega de software y gestionan de forma relativamente fluida el repositorio de código, las pruebas, el mantenimiento y los elementos de almacenamiento.

Sin embargo, aunque algún día los robots puedan quitarnos todos nuestros trabajos y encerrarnos, todavía no lo han hecho. La gran dependencia de las herramientas y la automatización abre la puerta a los errores. Es posible que los escaneos y las pruebas no detecten todo, que el código no se revise, lo que puede provocar grandes problemas de calidad (por no hablar de la seguridad). Los atacantes solo necesitan una puerta trasera para robar datos, y dejar de lado el factor humano en el control de calidad y seguridad puede tener consecuencias desastrosas.

El «punto de equilibrio» es una herramienta que garantiza el equilibrio entre las personas. La herramienta debe actuar como asistente de su equipo de confianza para alcanzar los objetivos del proyecto. Usted debe:

• Asignar tiempo suficiente para que las personas se familiaricen con la cadena de herramientas DevOps seleccionada.
• Centrarse en la colaboración eficaz (y en cómo las herramientas pueden facilitarla).
• Cubrir cualquier laguna en el proceso, ya sea en materia de habilidades/conocimientos o de herramientas.

En resumen, no basta con «animarse» y esperar obtener los mejores resultados.

DevOps no es una palabra de moda, sino una cultura. ¿Estás creciendo?

Incluso en el mejor de los casos, la gestión del cambio es difícil. El miedo a lo desconocido puede impedir que incluso los mejores miembros del equipo mejoren sus habilidades y amplíen sus horizontes.

Verás, decir simplemente «vamos a hacer DevOps» y hacer que el equipo de operaciones se mude de oficina no va a hacer que, por arte de magia, se produzca un proceso exitoso. Muchos se sentirán confundidos y los miembros del equipo con más antigüedad se sentirán descontentos. La comunicación esperada es fundamental, al igual que «ponerse en marcha». DevOps es tanto un método de desarrollo como un movimiento cultural, y el equipo debe vivirlo y respirarlo con una mentalidad colaborativa e interfuncional.

¿Cómo es una cultura DevOps excelente?

• Las personas tienen derecho a aportar sus conocimientos especializados al proceso, y no solo los líderes.
• Comunicación abierta, honesta y respetuosa entre los equipos.
• Todos son responsables de integrar la calidad y la seguridad en el objetivo general del proceso de desarrollo.
• Todos están de acuerdo con la definición de DevOps en la empresa, la hoja de ruta y el papel, contenido y motivos de cada persona.

Durante muchos años, he insistido en la importancia de crear una cultura de seguridad positiva en los equipos de desarrollo, y DevOps no es una excepción.

Las herramientas, los conocimientos y el apoyo adecuados son fundamentales para implementar las mejores prácticas de seguridad, reducir las vulnerabilidades detectadas y concienciar al equipo sobre la importancia de proteger los datos. Con DevOps, es necesario sentar las bases culturales para un cambio positivo: asegurarse de que todos comprendan su función, su valor y sus expectativas, así como los objetivos generales del proyecto y los pasos del proceso.

¿Lo tienes claro? Estupendo. Ahora, cambiemos el enfoque y mejoremos la seguridad para que DevSecOps se convierta en el plan definitivo para lograr un software excelente.