Rescatemos al “Troubleshooting”.

Aparentemente hablar de troubleshooting no parece nada innovador, pero llegados a este punto donde todo gira alrededor del agilismo, considero importante y necesario rescatar este concepto.

Ciertamente no se trata de la invención de la rueda, pero es una práctica, desde mi punto de vista, muy adecuada y útil en la gestión de incidencias. Pero, ¿cómo puede ayudarnos el troubleshooting?

Para nadie es secreto que ningún software que sea desarrollado por humanos está exento de fallos, y que aunque sigamos buenas prácticas tanto en la codificación, como en el desarrollo de pruebas (teniendo incluso un altísimo porcentaje de cobertura en nuestros tests), simplemente siempre puede haber algo que se escape de nuestras manos.

La verdad es que es muy normal que esto pueda ocurrir, bien sea porque haya casuísticas que son más complejas de reproducir en entornos de prueba, o bien porque el juego de datos con el que operamos no estaba contemplado. O sencillamente porque nuestro sistema tiene un bug.

La cuestión está en que una vez que ocurre el fallo, si no se hace un correcto reporte y/o seguimiento del mismo, es mucho más complicado para el equipo encargado de solventar el error hallar una solución adecuada.

En muchas ocasiones los equipos reciben el reporte de las incidencias no son los encargados de dar solución a la misma.

De hecho, y para ir un poco más lejos, en ocasiones puede que incluso dichos equipos pertenezcan a distintas organizaciones o empresas, con lo cual recobra mayor importancia el tener definido un procedimiento de seguimiento de incidencias para ser más ágiles en la resolución de las mismas.

A continuación os contaré un poco acerca del troubleshooting según mi criterio.

¿En qué consiste?

Se conoce como troubleshooting al proceso de diagnóstico del origen de un problema. Normalmente es usado para solucionar problemas de hardware, software y otros muchos productos.

La teoría básica del troubleshooting es que se comienza con los problemas más generales (y, a menudo, los más obvios), para luego, mediante descarte, llegar a los problemas más específicos.

Personalmente lo defino también como una cultura, ya que por más que los pasos a seguir se encuentren muy bien definidos, al final siempre dependerá de cada persona el llevarlos a la práctica.

Muchas veces son las prisas y/o circunstancias los motivos por los que nos saltamos estos pasos previos de recolección y verificación, que a la larga pueden marcar la diferencia en cuanto a tiempos y eficacia en la resolución de incidencias.

¿Cómo nos ayuda?

A medida que vayamos aportando más información al momento de reportar una incidencia o fallo, más ágiles podremos ser en el momento de investigar la causa y, por consiguiente, hallar su solución.

Esto se refleja claramente en flujos de trabajo donde los tiempos de respuesta a los errores se encuentran muy bien definidos.

Diagnóstico

El diagnóstico es el paso inicial cuando buscamos solución a una incidencia, el cual consiste en recopilar y tratar información relevante con el fin de comprender el problema y sus posibles causas, de hecho lo considero un paso crítico e incluso casi el más importante dentro en el proceso de gestión de fallos.

Como en cualquier tipo de investigación, la fase de recolección de datos es elemental para su posterior análisis.

Es muy importante y será de gran ayuda suministrar la mayor cantidad de datos como fuese posible al momento de reportar una incidencia, por ejemplo:

1. Entorno en el que se ha producido el fallo.
2. Juego de datos de entrada.
3. Operación realizada.
4. Secuencia de pasos hasta reproducir el fallo.
5. Rango horario en el cual se produjo el error.
6. Captura de logs (en caso de tener acceso a las mismas).
7. Pantallazo con el código del error o mensaje recibido (siempre que fuese posible).
8. En ocasiones puede recolectarse la evidencia a través de un vídeo.

Cuanta más información aportemos,, el equipo encargado de tratar el problema tendrá un mejor contexto y una mayor visibilidad de lo que puede estar ocurriendo.

Además, será más efectivo al momento de replicar el error en los entornos de prueba, así como dar con la solución.

Debemos tener en cuenta que cuando reportamos un fallo, el “...no funciona, me da un error, por favor mirarlo...” por si solo y sin más, hace mucho más complicado el proceso de análisis, diagnosis y solución del mismo.

De hecho puede ser tan complejo que en algunos casos podría asemejarse a buscar una aguja en un pajar. Esto también sería como ir al médico a decir que te sientes mal y necesitas que te cure, pero no le dices nada más.

Un correcto diagnóstico nos puede guiar en la selección las herramientas más adecuadas y/o los pasos a seguir para dar solución a un problema, de otra manera puede ser tan duro como desvelar quién ha sido el asesino en una serie de misterio.

En muchos casos de uso lo mejor es definir un conjunto de preguntas, las cuales sirvan para determinar qué está ocurriendo y con ello poder decidir qué solución tomamos.

Documentación

Finalmente cuando todo ha terminado y se ha conseguido dar solución a una incidencia, es muy útil e importante definir/documentar el conjunto de pasos que se han seguido para solucionar un problema.

De esta manera se simplificará la labor de quienes se encargan del tratamiento de los fallos, por si por alguna razón se produjera nuevamente.

Para algunos casos el uso de bitácoras puede ser bastante conveniente y, de esta manera, registrar todas las fases por las que ha pasado la incidencia: desde que ha sido reportada pasando por el diagnóstico hasta llegar a la solución.

También sería recomendable implementar casos de prueba a nivel de código (tests) que garanticen que el problema no vuelve presentarse. Por ejemplo, hay equipos que suelen tener como política que cada bug (incidencia) resuelto debe ir acompañado por una batería de pruebas sobre el error corregido, bien sea mediante la implementación de tests unitarios o bien de tests de integración.

Caso de ejemplo

Escenario

Tenemos una aplicación web (consumiendo servicios REST) la cual produce un fallo en pantalla.

Reportar el error

En este lo suyo sería recolectar una captura de la pantalla donde se muestre el mensaje de recibido, describir la secuencia de pasos seguida hasta generarse el error, proveer los datos introducidos (en caso de que los hubiera), trazas de logs si estuvieran a nuestro alcance .

Perseguir el error

Teniendo en cuenta los datos suministrados al momento de reportar la incidencia, es posible reproducir el error incluso en entornos no productivos y siguiendo la secuencia de pasos descrita en el reporte.

También sería posible obtener una captura de los logs del backend hasta dar con el punto de fallo, por ejemplo, que la información que devuelve la base de datos no es correcta (una columna que es nula y que no debería serlo, pero que no tiene un constraint definido).

Solucionar

Un vez detectada la causa del problema, la solución pasaría por añadir las diferentes validaciones (constraints) tanto a nivel de código como a nivel de base de datos, para así evitar que se inserten datos nulos en columnas donde no está permitido (por lógica de negocio).

Adicionalmente, podría ser necesario identificar qué otros registros (o documentos, si hablamos de una base de datos NoSQL) se encuentran bajo la misma condición, y estudiar la necesidad de elaborar una rutina que encargue de limpiar los datos incorrectos, en este caso sería incluir un valor por defecto en el campo que no está informado.

En esta misma fase de solución deberán incluirse los tests pertinentes y el respectivo control del error en la parte front.

Finalmente, una vez resuelto el problema acabaríamos documentando, qué ha sido lo que ha originado el error y cómo ha sido solventado.

Conclusión

Aunque el troubleshooting es una técnica frecuentemente usada en el ámbito de soporte de sistemas y departamentos de gestión de fallos, puede ser aplicada perfectamente en otras áreas como desarrollo, operaciones y mantenimiento.

Es hora de rescatar este tipo de técnicas, al final se trata de un tema de cultura como todo lo que nos rodea. Podemos ser más eficaces y ágiles en cuanto a la resolución de incidencias.