DevOps integra las tareas de desarrollo de software con las de operación con el fin de reducir el time-to-market de nuevos productos y funcionalidades, aumenta la disponibilidad del servicio, el uso más efectivo de la infraestructura, reduciendo el impacto y número de defectos en producción. Esto lo logra a través de un ambiente colaborativo entre el equipo de desarrollo y el de operación y la automatización de tareas de desarrollo, calidad, despliegue y monitoreo.
Retos Culturales y Procedimentales
Establecer dicho ambiente colaborativo exige la reconfiguración del equipo de TI con un nuevo propósito compartido y alineado con la misión de la organización, lo cual constituye el reto de romper aspectos culturales y procedimentales que se han consolidado en las organizaciones por décadas.
Ejemplo de Retos a Enfrentar
Si revisamos lo que sucede cuando un cambio en el negocio requiere de la adición de un nuevo atributo en una entidad especifica -ej: “..a partir de ahora se requiere capturar el website del cliente..”- vamos a observar que, a pesar que el equipo de desarrollo comprenda e implemente correctamente la necesidad del negocio a tiempo, es posible que la puesta a producción no sea oportuna debido a que la adición de una nueva columna exija una solicitud de cambio a la base de datos de producción que puede llegar a tomar una o más semanas para su aprobación. Esto se da por varios aspectos culturales y procedimentales inmersos en cómo están configuradas las organizaciones: el DBA nunca es invitado a participar en las reuniones de requerimientos y es el último en enterarse de que se debe afectar la estructura de la base de datos; el número de solicitudes de cambios y afinamientos sobre ellas es muy alto; el desarrollador siente que su responsabilidad va hasta la construcción de código y desprecia el impacto sobre la estructura y los datos de las bases de datos; el desarrollador cree que todo será obvio para el DBA (especificación de la columna a adicionar, valores a poblar inicialmente, etc); existen riesgos de efectos colaterales cada vez que se hace una cambio de estructura en una base de datos por lo cual los DBAs se protegen con procedimientos que los eximen de responsabilidad; entre otras.
Aspectos Culturales y Procedimentales por Enfrentar
A continuación, se presentan algunos de los tipos de retos a enfrentar en la adopción de una mentalidad organizacional de DevOps:
- Lenta retroalimentación
Los errores u omisiones por parte de los desarrolladores en el proceso de despliegue a producción no son informados oportunamente, pues estos surten un proceso de bug-tracking y, seguramente, la intervención/aprobación de un directivo -no para tomar acciones de mejora y soluciones de raíz, sino para que quede claro que la culpa no fue de Operaciones sino de Desarrollo-
- Comunicación focalizada en el proceso de desarrollo y despliegue
Muchas veces la comunicación directa entre desarrollo y operaciones no existe y solo se permite a través de tickets y solicitudes por email u otra herramienta. Pero aún peor, puede llegar a existir una tercera entidad o coordinador quien sirve de teléfono -muchas veces roto- entre los ellos.
Y cuando se da una discusión, no es acerca del producto y la calidad de este, sino acerca de las políticas, procedimientos y reglas que deben cumplirse para aceptar el cambio a producción. Igualmente, como se observó en el ejemplo, el Equipo de Operaciones no es involucrado de forma suficiente en actividades de comprensión de los requerimientos y diseño, lo cual dificulta la comunicación en términos del producto y del valor al negocio.
- Incentivos basados en el cumplimiento de tareas
Inclusive en los proyectos de desarrollo basados en ciclos ágiles, el Equipo de Desarrollo tiene como propósito culminar el código sin errores de las historias de usuario (funcionalidad) comprometidas en la planeación al inicio del sprint, pero no necesariamente asume el compromiso de llevarlo a producción.
Por otra parte, Operaciones tiene como meta que la infraestructura donde se ejecuta el código que implementa las historias de usuario esté disponible 24/7 con el desempeño adecuado, pero no asume ninguna responsabilidad de este código en caso de presentarse fallos.
De esta forma, no es claro quien de los dos (Desarrollo u Operaciones) asume la responsabilidad del producto de software como un servicio, que no solo satisface los requisitos originales, sino que le brinda una experiencia oportuna, efectiva, y porque no, deleitante al usuario.
- Respeto y escucha
Los profesionales de Desarrollo y de Operaciones deben entender que cada una de estas disciplinas es exigente, presentan grandes retos y tienen un conocimiento específico pero complejo. Por ende, deben estar dispuestos a escuchar y comprender los argumentos, dificultades y alternativas de las partes para llegar a soluciones orientadas a optimizar el resultado final (un producto que deleite al usuario) mas que una solución limitada por las políticas y barreras impuestas por cada una de las partes.
- Confianza
Los desarrolladores deben confiar que Operaciones ha establecido procedimientos y estándares, no para obstaculizar el proceso, sino por el contrario, para garantizar que el producto llegue al usuario sin incidentes y en el primer intento. Operaciones debe confiar que los requisitos de infraestructura por parte de Desarrollo no han sido sobrestimados y que no se solicitan para esquivar más tareas de desarrollo, sino para que se brinde una experiencia y desempeño adecuado al usuario.
Asimismo, los directivos deben confiar en el profesionalismo de Desarrollo y de Operaciones para que puedan llegar a acuerdos y a discusiones efectivas, sin intervenciones o arbitrajes de un tercero -que en muchas organizaciones es quien toma las decisiones y a la vez es quien posee menor información tanto del código como de la infraestructura-.
Conclusiones
La implementación de prácticas de DevOps, mas que herramientas, requiere un cambio cultural en la organización para llegar a un ambiente colaborativo donde se rompan los “silos” organizaciones al interior de TI, basado en el respeto, la confianza, la comunicación abierta, el trabajo en equipo, la responsabilidad y la integridad profesional.
Igualmente, se requiere un cambio de mentalidad donde se incentive el trabajo orientado al cumplimiento de los objetivos de negocio y no solo a la culminación de tareas.
REFERENCIAS
- Building a DevOps Culture; Mandi Walls
- Leading the transformation – Applying Agile and DevOps Principles at Scale; Gary Gruver, Tommy Mouser
- Shouldn’t DBAs Be Part of the DevOps Inner Circle?; https://devops.com/shouldnt-dbas-be-part-of-the-devops-inner-circle/
