Crear la estructura de equipo de DevOps ideal

Una plataforma de DevOps sólida necesita una estructura de equipo de DevOps sólida para lograr la máxima eficiencia.

Crear una estructura de equipo de DevOps sólida no se trata solo de reunir a un grupo de personas con habilidades técnicas, sino de fomentar una cultura de DevOps que enfatice la colaboración, la mejora continua y la eficiencia en todo el ciclo de vida del producto.

A medida que las organizaciones buscan optimizar su proceso de desarrollo de software, es vital comprender los roles de un ingeniero de DevOps, el equipo de desarrollo y cómo las herramientas de automatización pueden mejorar la productividad. Esta visión holística ayuda a dar forma a una estructura de DevOps que se alinea con los objetivos generales de una entrega de software confiable y un entorno de trabajo productivo.

Hay varios factores que entran en juego para la estructura del equipo:

• Silos existentes: ¿hay conjuntos/equipos de producto que trabajen de forma independiente?
• Liderazgo técnico: ¿los gerentes de grupo están preparados para lograr los objetivos de DevOps?
• Cambio de roles: las tareas de operaciones (Ops) se han convertido en roles de desarrollo (Dev), los equipos de seguridad trabajan con todos y la tecnología está cambiando. Espere volver a evaluar todo con regularidad.
• Mejora continua: el equipo de DevOps nunca será algo estático; requiere iteración.

La división de Dev y Ops en equipos separados a menudo genera desafíos en el proceso de implementación. Sin embargo, adoptar una cultura de DevOps donde se integren herramientas comunes puede cerrar estas brechas.

El consultor de gestión Matthew Skelton escribe sobre varios escenarios de DevOps diferentes con gran detalle, pero analizaremos solo algunos de los silos que menciona específicamente y cómo afectan a una organización.

Skelton se refiere a esto como una estructura de equipo clásica en la que las tareas de pasan de un equipo a otro sin comunicación o colaboración efectiva, y no es la estrategia de DevOps más efectiva. Ambos equipos trabajan en sus burbujas y carecen de visibilidad del flujo de trabajo del otro equipo. Esta separación completa carece de colaboración, visibilidad y comprensión, componentes vitales de lo que debería ser la metodología DevOps efectiva. En esta situación es un juego de quién tiene la culpa: “No sabemos lo que están haciendo, hicimos nuestra parte y ahora depende de ellos completarlo”, y así sucesivamente.

En esta estructura de equipo los equipos de Devs y Ops también están separados, pero tiene un equipo de «DevOps» que se encuentra entre ellos, como una especie de facilitador. Esto no es necesariamente algo malo, y Skelton insiste que esta organización tiene algunos casos de uso. Por ejemplo, si esta es una solución temporal con el objetivo de hacer que los equipos de Devs y Ops sean más cohesivos en el futuro, podría ser una buena estrategia provisional.

En este escenario, los equipos de Dev y DevOps se fusionan mientras que el de Ops permanece aislado. Las organizaciones como esta consideran que el equipo de operaciones sirve de apoyo para las iniciativas del desarrollo de software, pero que no aporta valor por sí mismo. Las organizaciones como esta sufren de errores operativos básicos y podrían tener mucho más éxito si entienden el valor que aportan las operaciones.

Para romper los silos del equipo de DevOps, se requiere liderazgo en todos los niveles. Comience pidiendo a cada grupo que muestre las principales áreas de fricción y luego identifique a los líderes en cada grupo: desarrollo, operaciones, seguridad y prueba. Cada líder debe trabajar individualmente y en conjunto en todos los puntos de fricción.

Nunca se insistirá lo suficiente en la importancia de la comunicación: los equipos necesitan recibir comentarios periódicos sobre todos los aspectos de sus roles.

También podría ser útil insertar «promotores» en los grupos con dificultades que modelen comportamientos y lenguaje que faciliten la comunicación y colaboración.

Los avances tecnológicos desde la multinube hasta los microservicios y contenedores también desempeñan un papel importante a la hora de definir la estructura de equipo de DevOps adecuada. En nuestra Encuesta Global 2020 de DevSecOps, el 83 % de los encuestados dijeron que sus equipos lanzan código más rápidamente, pero también dijeron que sus roles estaban cambiando, en algunos casos, de forma drástica.

Los desarrolladores de hoy crean, supervisan y dan mantenimiento a infraestructuras; roles que tradicionalmente eran competencia de los equipos de operaciones. Los equipos de operaciones dedican más tiempo que nunca a gestionar los servicios en la nube, mientras que los miembros del equipo de seguridad trabajan en equipos multifuncionales con equipos de desarrollo y operaciones.

Evidentemente, el ciclo de desarrollo de software actual está lleno de partes móviles, lo que significa que definir la estructura adecuada para un equipo de DevOps seguirá siendo algo fluido y necesitará reevaluarse de forma periódica.

En GitLab, la iteración es uno de nuestros valores fundamentales, y es algo que hacemos con gran frecuencia para nuestra propia estructura de equipo de DevOps. Dado que GitLab es una plataforma de DevOps completa que se entrega como una aplicación única, nuestros equipos de desarrollo están organizados en etapas (por ejemplo, Verificación, etc.) porque estos serían productos separados en cualquier otra empresa y requerirían su propia autonomía. También tenemos otros grupos de DevOps funcionales además de «Dev» que administran otros aspectos de nuestro producto.

Tenemos un grupo de confiabilidad que administra el tiempo de actividad y la confiabilidad de GitLab.com, un departamento de calidad y un equipo de distribución, entre varios otros. La forma en que hacemos que todas estas piezas encajen es seguir nuestro compromiso con la transparencia y visibilidad a través de todo el SDLC, pero también ajustamos (es decir, iteramos) esta estructura de forma periódica para que todo funcione.

En resumen: planifique crear su equipo de DevOps y vuelva a evaluarla más tarde. Los beneficios en forma de lanzamientos de código más rápidos y miembros del equipo más felices harán que valga la pena.

El recorrido hacia la optimización de la estructura de un equipo de DevOps es iterativo, lo que refleja los continuos avances en los procesos y las herramientas de DevOps. Cada elemento tiene un rol crucial en el éxito del equipo. Al romper los silos tradicionales e integrar los roles dentro de los equipos de DevOps, las organizaciones pueden fomentar un entorno más cohesionado y eficiente.

En última instancia, la clave para la mejora sostenida radica en reevaluar y ajustar regularmente la estructura de DevOps para seguir el ritmo de la rápida evolución de las demandas de producción e implementación de software. Este compromiso no solo acelera el proceso de desarrollo de software, sino que también crea una organización más resiliente y receptiva.