En el contexto
de este post feedback o retroalimentación significa: recoger datos de la
ejecución de las tareas realizadas en el área de Tecnologías de la Información,
analizar estos datos para obtener conclusiones objetivas sobre el resultado de
las actividades y en base a estos datos planificar maneras de mejorar.
Por otro lado
el canal DevOps es el conjunto de procesos y actividades que se realizan en una
instalación para cubrir el ciclo de vida del software, desde su concepción
hasta su puesta en producción
Sentando las bases
La Real
Academia Española de la Lengua define retroalimentación cómo “el retorno
de parte de la energía o de la información de salida de un circuito o un
sistema a su entrada”.
Wikipedia define retroalimentación cómo “un mecanismo
por el cual una cierta proporción de la salida de un sistema se redirige a la
entrada, con señales de controlar su comportamiento”.
Un ejemplo, se dispone de una web
de comercio electrónico de venta de libros. Se planifica mejorar la web con el
objetivo de vender más libros. Para ello:
- Se realiza el conteo de libros vendidos cada día.
- Se calcula el número medio de libros vendidos a la semana.
- Se aplica algún cambio sobre la web. Por ejemplo se decide incorporar descuentos para los mejores clientes.
- Se compara el número medio de libros vendidos en las semanas anteriores y posteriores a la mejora.
- Si se han vendido más libros después del cambio, podemos en general sacar la conclusión de que el cambio ha sido un éxito.
En esencia esta es la base.
Viendo la retroalimentación desde este punto de vista, esta puede ayudar a
mejorar el canal DevOps o cualquier otro proceso en las organizaciones.
¿Qué sé puede hacer para mejorar el canal DevOps?
En el libro “The DevOps handbook” publicado por IT Revolution Press en 2016
proponen tres formas para mejorar el canal DevOps. La primera forma está
comentada en el post “Cómo mejorar el canal DevOps. Primeros pasos.” de este blog. La segunda forma consiste en manejar
adecuadamente la retroalimentación. Para realizar una correcta gestión de la
retroalimentación, el libro la enfoca desde distintos puntos de vista:
Crear telemetría para permitir encontrar y después resolver problemas
Un hecho real es que pequeños
cambios pueden desestabilizar un sistema y conducir a caídas o fallos globales.
No es fácil que alguien tenga suficiente conocimiento para tener una visión
global de la instalación y poder saber donde se encuentra el problema. Los
sistemas suelen ser complejos y el fallo puede estar en muchos sitios
distintos. Para resolver el problema es necesario tener información y esta
información está disponible si se han previsto los mecanismos necesarios para guardarla.
Uno de los descubrimientos del
informe “State of DevOps” de 2015 fue que los equipos de operaciones que consiguen
solucionar los problemas más rápidamente, emplean dos técnicas: el uso de un
sistema de control de versiones y otra haciendo mediciones y monitorizándolas
proactivamente en el entorno de producción.
Analizar la telemetría para anticiparse a los problemas y alcanzar los objetivos
Es deseable prever los problemas para evitar que se
produzcan. Esto se puede conseguir monitorizando el funcionamiento de los
sistemas y produciendo alertas cuando se detecte alguna anomalía.
Se pueden usar medias, desviaciones estándar, patrones de
comportamiento de los datos, cualquier mecanismo puede ser bueno para detectar
si se está produciendo una anomalía e intentar resolverla antes de que provoque
caídas o efectos no deseados.
Habilitar feedback para que desarrollo y operaciones puedan desplegar código de forma segura
Es necesario que los equipos de
desarrollo sepan las consecuencias del despliegue de los cambios que efectúan en
el código. Para ello es conveniente que los desarrolladores participen en las
tareas de puesta en marcha.
Se pueden establecer medios para
que los desarrolladores puedan desplegar en producción los sistemas por sí
mismos. La clave está en la automatización, hay muchas herramientas disponibles
para poder controlar automáticamente múltiples aspectos del código antes de desplegarlo:
pruebas automatizadas a todos los niveles, cobertura de pruebas, análisis
estático de código, gestión de dependencias, etc. Todas estas herramientas
contribuyen a qué la puesta en producción pueda estar en manos de los equipos
de desarrollo.
Integrar desarrollo conducido por la hipótesis y A/B testing en el trabajo diario
Hay funcionalidades que se ponen en producción y nadie las utiliza. Poner en producción código que no es útil a los usuarios es negativo,
porque es trabajo inútil y porque además es un código que sin ser útil hay que
mantener.
El A/B testing puede minimizar esta problemática. A/B
testing consiste en poner en producción distintas versiones de una misma
funcionalidad. Cada versión se le ofrece a un grupo de usuarios diferente.
Luego se estudia que versión funcionó mejor y es la que se implanta.
Un paso más allá es el desarrollo conducido por la
hipótesis. Este consiste en partiendo de una necesidad detectada por los
expertos en negocio, realizar un experimento de implementación (no completa) y
ponerlo en producción de forma controlada. Con la aceptación o no aceptación de
los usuarios de las funcionalidades suministradas en el experimento, se valida
si la hipótesis es una necesidad real o no. En función del resultado del
experimento se actúa continuando con la implementación o abandonando la
hipótesis.
Crear procesos de coordinación y revisión que incrementen la calidad del trabajo
Con el objetivo de anticiparse a los problemas que un cambio
puede producir en producción, es adecuado establecer los medios de revisión y
coordinación necesarios.
Ahora bien, no se
trata de implantar burocráticos procesos realizados por terceras partes, ajenas
al proceso de construcción y despliegue del código. Los procesos realizados por
terceros tienden a alargar los procesos de despliegue y a no ser efectivos. Es difícil
averiguar los problemas que tiene un código al que se es ajeno.
Es más útil preparar procesos de revisión entre compañeros o
iguales (peer review). Un ejemplo de revisión entre compañeros es el pair
programming, en esta técnica dos desarrolladores trabajan sobre el mismo
código. De esta forma el código cuando está terminado ya está revisado y
validado por dos programadores.
Conclusiones
Se ha abordado la retroalimentación desde distintos puntos
de vista:
- Retroalimentación recogiendo datos sobre ejecución de tareas y análisis de los mismos para mejorar
- Retroalimentación a los equipos de desarrollo no ajenos a las consecuencias de la implantación de su código en producción
- Retroalimentación sobre los efectos de un cambio con A/B testing
- Retroalimentación para asegurar hipótesis antes de implementar mediante desarrollo dirigido por la hipótesis
- Retroalimentación partiendo de revisiones para obtener información de las consecuencias de la implantación
Todas estas formas de aprovechar las ventajas de la
retroalimentación pueden ser fuente de inspiración para la mejora del canal
DevOps.
No hay comentarios:
Publicar un comentario