The DevOps Handbook: Principio de Feedback (3/4)

Tercera parte del libro The DevOps Handbook

Este principio nos habla de la necesidad de tener un buen sistema de información y herramientas que nos den feedback inmediato de todo lo que está ocurriendo en nuestra cadena de valor y nuestro sistema. Con estos datos podremos reaccionar rápido y mitigar las posibles consecuencias de un error durante nuestro trabajo. También la oportunidad de aprender cómo se desenvuelve nuestro sistema y evitar cometer los mismos errores.

Esta información debe obtenerse fácilmente, ser rápida, precisa y frecuente para no llegar demasiado tarde o darnos pereza en la búsqueda. Idealmente nuestro cliente ni debe enterarse de nuestros problemas con el despliegue de una nueva funcionalidad. El peor escenario es que tenga que ser él quien nos alerte de que nuestra cosa no funciona, con las consecuencias que eso conlleva.

Si detectamos en fases tempranas el problema, más sencillo y barato será arreglarlo. Cuanta más granularidad y relación tengamos entre toda la información recopilada, más directa, rápida y precisa será la solución que haya que aplicar, y menores las consecuencias del error que haya que reparar.

El feedback no solo es a nivel de errores técnicos o de diseño, sino también información de cómo está funcionando nuestro flujo de trabajo. Una información clave por ejemplo es detectar un cuello de botella o fallos en un punto concreto, si no se resuelve rápidamente hará que toda la cadena se resienta. Y cuanto más tardemos más complicado será solucionarlo pues habrá ido avanzando por todo el flujo.

Trabajar con seguridad en sistemas complejos

Una de las características típicas de los sistemas con los que trabajamos es que suelen ser complejos. Con tantos componentes y todos los posibles caminos que pueden tomar, los fallos se vuelven inevitables por dicha complejidad. Es difícil para alguien conocer el detalle suficiente para poder prever todos los posibles puntos de fallo. Esto hace que los errores sean desgraciadamente habituales, especialmente en el momento de los cambios.

Un buen diseño de una telemetría de las aplicaciones y de los sistemas es fundamental, si nos permite alertas tempranas de los problemas hará que podamos trabajar con mucha mayor confianza y seguridad.

Ver los problemas a medida que ocurren

Tenemos que poder validar nuestras decisiones de implementación o diseño lo más pronto posible. Esto solo ocurre si disponemos de ese feedback inmediato y automatizado del sistema. Debemos construir un flujo bidireccional entre nuestro trabajo y la información obtenida al integrarlo, actuando con la nueva información en mejorar de iterativamente el trabajo hasta obtener el resultado esperado.

En contraposición tenemos el waterfall en el cual después de muchas semanas o meses de trabajo, en la primera integración los problemas son más difíciles de abordar por su tamaño y por el tiempo que hace que se decidieron e implementaron las cosas, haciendo todo mucho más costoso.

Es también importante tener una alta calidad en la información obtenida en todas las fases de nuestro flujo de trabajo, los defectos y desviaciones del objetivo se encuentran así fácil y rápidamente. Solo con información completa y fiable podremos realmente aprender y conseguir mejorar nuestro trabajo.

Parada de emergencia

Cuando algo va mal y aparecen errores o problemas importantes en nuestro value stream, debemos parar y ponernos todos a investigar las causas y aplicar las mejoras necesarias para solventarlo. Esto permite un aprendizaje global inmediato del problema, sus implicaciones y posibles relaciones con otros procesos, y lo que es fundamental es que se aborda en sus fases más tempranas y el problema no va avanzando por la cadena.

Es un error, por ejemplo, aparcar una solución (deuda técnica) hasta un momento en el que ya es más complicado solucionar, donde se han integrado encima más cosas y donde el tiempo ha hecho mella en nuestro entendimiento del problema. Si lo dejamos pasar solo conseguiremos tener más adelante nuevas tareas y más complicadas.

Un ejemplo podemos verlo con la integración continua cuando rompemos los tests, si la solución no es obvia todo el equipo debe ponerse a trabajar codo con codo con el responsable de la rotura para solucionar el problema, permitiendo que emerja un nuevo aprendizaje, sobre todo para el responsable del error. Una parada necesaria de la cadena de trabajo para que luego todo vuelva a continuar con el ritmo esperado.

Aunque parezca poco intuitivo, detectar problemas importantes en fases tempranas y parar la maquinaria para resolver problemas es la manera más efectiva y barata de que los errores no vayan creciendo de manera incontrolada y oscura, así como una buena oportunidad para aprender cómo funciona realmente nuestro sistema.

Trabajar la calidad en la misma fuente

De poco sirve que solo un equipo de calidad revise nuestro trabajo semanas después, a la vuelta posiblemente hayamos olvidado información importante que nos permita entender el porqué se tomaron dichas decisiones. En su lugar debemos proporcionar todas las herramientas necesarias para comprobar la calidad del trabajo en el mismo sitio donde se produce.

Por ejemplo con tests automáticos profundos y feedaback inmediato de las pruebas que revisan que el nuevo código es correcto, se integra correctamente, es eficiente y no tiene problemas de seguridad. Con esta información el programador tiene la certeza de que su cambio no tiene implicaciones negativas, y si las tiene entonces consigue nuevo conocimiento del por qué para futuras decisiones. La inmediatez del feedback permite que los cambios que deba hacer sean minutos después, no dentro de varios días o semanas.

De poco sirve acabar una tarea sin tener completa certeza de que funcionará correctamente en un sistema más grande. Solo podríamos asegurar con tests unitarios y parciales que la nueva funcionalidad cumple con la salida esperada, pero poco más. También tiene poca utilidad preparar un elaborado informe de pruebas o documentación de implementación que otro equipo leerá tiempo después ya desfasado, y que posiblemente no haya tenido en cuenta otras funcionalidades adicionales que desconoce.

Es muy importante que el equipo conozca la motivación de una funcionalidad y no solo un resultado esperado, así el trabajo será mucho más certero y menos idas y vueltas tendrá la integración de los componentes, mejores pruebas de la funcionalidad por parte del desarrollador o integrador, y no meras pruebas del código. Soluciones hay muchas pero correctas para el negocio serán menos.