Los errores ocurren y son parte de la fase de servicio del ciclo de vida de toda aplicación. No hay ni que verlos de manera trágica, pues son las singularidades propias de la explotación de la aplicación, ni con excesiva indulgencia, porque son una medida clave de la calidad del servicio que estamos dando.

Pero lo que sí es relevante es que, desde el primer momento de la incidencia, tengamos información suficiente para disparar todos lo mecanismos de análisis y resolución del error. Es necesario que tengamos una recolección de datos automática y eficaz; y esa eficacia sobre todo va a depender, dado lo variado e impredecible de los errores, de lo completos que sean esos datos.

Más importante que la información recopilada para el análisis del problema, es la información y mensajes transmitidos al usuario de la aplicación que sufre el error. Factores como la usabilidad, funcionalidad, gestión del riesgo reputacional o la propia operativa de gestión de incidencias dependen fundamentalmente de este aspecto.

El proceso completo  de identificación, clasificación, investigación, resolución y cierre (pasos de la gestión de incidencias según ITIL) es especialmente elaborado y largo como para poder cubrirlo en una sola entrada. Esta entrada pretende solo abordar la primera etapa o paso en la gestión de las incidencias (Identification and Logging según ITIL), y en parte sólo, entrando más en aspectos prácticos que en los formalismos del proceso. El objetivo es cubrir cómo se identifica el incidente, cómo se informa de él y cómo se recopila información que sea útil para su resolución.

La dualidad de actores: usuario y operador

Cuando se produce el incidente hay dos actores interesados o relacionados: por un lado el usuario que no puede resolver de manera normal la operativa, y por otro, el equipo de soporte o de resolución de incidencias que tiene que darle una solución.

Ambos actores necesitan información muy distinta. Por un lado, el usuario no necesita información técnica de qué lo que ha pasado; de hecho, por motivos de seguridad se debería evitar que se revelase o fuese deducible. Por el otro, el soporte debe tener información detallada relativa a la incidencia, pero con un acceso muy limitado y controlado a la propia transacción, si esta tuviese información sensible o confidencial.

Afortunadamente, los canales por lo que se envía la información suelen ser distintos y solo tenemos que tener cuidado en recopilar toda la información necesaria a ambos y mostrar a cada uno la que le corresponde.

No conozco referencias relativas a este asunto, por lo que me he permitido llamar a una la visión del usuario, y a la otra la visión del técnico.

La visión del usuario

Cuando ocurre un error en la aplicación no hay que perder de vista lo más importante: que el usuario estaba intentando hacer algo que podría ser valioso o importante para él. Por eso la visión del usuario (sobre todo cuando estemos hablando de una actividad crítica, relevante o de valor para el usuario o cuando el nivel de calidad de servicio así lo exija) tiene que centrarse en trasmitir muy claramente:

• ¿Qué ha pasado con la operación que estaba haciendo? ¿En qué situación se ha quedado? ¿Qué consecuencias puede tener?
• ¿Qué puedo hacer ahora? ¿Cuáles son los pasos a seguir ahora que estamos en una situación anómala (o no) desde el punto de vista de la experiencia de usuario?

Por otro lado, las formas y el contenido en el que se comunica la información del error y de la situación al usuario es especialmente relevante para la usabilidad de la aplicación. Al ser, el error, una situación excepcional, a veces descuidamos esta usabilidad; pero es justamente esa excepcionalidad, la que nos obliga a tener especial cuidado en los mensajes y cómo se los transmitimos a los usuarios, así como el guiado para que puedan encauzar la operativa. Una buena opción es considerar los errores, al igual que las excepciones en el código, como vías de escape del flujo normal de navegación de la aplicación y considerarlas en su diseño. De esta manera ayudaremos a que en caso de error la aplicación esté en un estado y posición estables y conocidos (la pantalla de error «tal» dentro del proceso funcional «tal») y que sea más usable (el usuario puede utilizar los mismos criterios y flujos de navegación que en el resto de la aplicación).

Información relativa a la operación del usuario

Ya sea escribir un mail, hacer una transferencia o confirmar el pago del carrito de la compra; el usuario está haciendo una operación o transacción importante para él y lo primero de lo que tiene que informarse al usuario es de qué ha pasado con lo que estaba haciendo. Por eso en la información del error que se muestra al usuario se deberían tener en consideración los siguientes puntos:

• Si la transacción se ha finalizado correctamente: ¿se llegó a enviar el mail? ¿se efectúo la transferencia? ¿se ha cobrado en la tarjeta la compra?; o si por el contrario se canceló la operación: el mail no se envió y la transferencia y el pago no se hicieron efectivos
• En cualquier caso, si existe operativa de soporte o ticketing, debe definirse un identificador único que permita al usuario poder identificar su caso. Aunque esa identificación pueda y deba llevarse de manera interna por el procedimiento de soporte, en mi opinión, debe ser comunicada al usuario por motivos de transparencia
• Si la operación no es recuperable, es muy importante indicar al usuario qué va a pasar con la información que ha introducido. Por ejemplo: no he podido finalizar mi compra pero he introducido información sensible como es mi dirección o mi tarjeta. En este caso es conveniente:
  • Informar al usuario de qué información va a almacenarse y de cuál se va a eliminar
  • Indicar qué criterios se utilizarán para gestionarla. Como puede ser el almacenar dicha información por 30 días por si es necesaria para el equipo de soporte, por ejemplo
  • Si estamos obligados por imperativo legal o de cualquier otro tipo a mantenerla, no está de más mencionar estas exigencias u obligaciones
  • Informar al usuario de cómo puede verificar y eliminar esos datos. Desde su perfil o poniéndose en contacto con nosotros, por ejemplo

Pasos a tomar y opciones de resolución

Ahora que el usuario tiene ya una idea clara de qué ha pasado con su operación, es necesario indicarle cómo puede completar dicha operación

• Si no quedó claro o no se pudo verificar el estado en que quedó la operación, debemos informar al usuario de cómo puede verificar la operación o dónde o con quién puede ponerse en contacto, como puede ser el equipo de soporte
• Si tenemos cierta certeza de que el fallo es transitorio, podemos invitar a reintentar la operación al usuario pasado un tiempo o cuando podamos contrastar que el problema ha remitido
• Si es posible continuar la operación o recuperarla en un punto en concreto, debemos indicar al usuario cómo y cuándo (más tarde por mail, por ejemplo) hacerlo; facilitando lo máximo posible este reintento y evitando todo lo posible la repetición de pasos ya realizados. Este punto es importante por varios motivos estratégicos:
  • Porque mejoramos el servicio y funcionalidad ofrecida al usuario y con ello la percepción que tiene de nuestro producto y reducimos el daño reputacional del error
  • Porque evitamos el tedioso proceso de repetir toda la transacción mejorando la experiencia de usuario
  • Porque reducimos el impacto del fallo o caída de servicio habilitando el que de los servicios perdidos algunos se puedan recuperar
  • Porque evitamos que parte de los usuarios afectados migren a la competencia buscando el mismo servicio
• En la medida de lo posible debe ser parte del flujo normal de navegación y seguir los mismos criterios de navegación, forma y contenido de la información que en el resto de la aplicación. Esto transmite la sensación de ser un situación controlada al usuario, con lo que se limita la pérdida reputacional y se atenúa la sensación de gravedad; además de facilitar el guiado para la resolución del problema.

La visión del técnico

Los mecanismos de log pueden ser de gran ayuda, y son el referente normal en estos casos; pero para que puedan ser manejables desde el punto de vista operativo, suelen ser muy poco detallados. Lo singular e infrecuente del error nos permite que la recolección de información de incidencias pueda ser mucho más exhaustiva, elaborada y detallada. Esta información de mucho más volumen, pero de menor frecuencia.

Es muy importante recordar que esta información es altamente sensible y que su divulgación podría desvelar vulnerabilidades y patrones de ataque. De hecho, una parte fundamental que precede a los ataques informáticos, es el análisis de estas vulnerabilidades. El forzar situaciones de error puede permitir, si no se controla con cuidado, que se pueda obtener información muy sensible y relevante, vulnerabilidad, para luego poder ser explotada.

El siguiente es un checklist de información que puede ser útil recopilar para la visión del técnico:

• Entorno
  • Hora y fecha
  • Posición geográfica, en especial en entornos móviles o distribuidos
  • Conectividad, también cobra especial importancia en entornos móviles
  • Host o instancia de máquina, para entornos distribuidos
  • Servicio o contenedor de la aplicación
  • Hebra o proceso del sistema operativo
  • Paths y parámetros de configuración del servicio
  • Cliente
    • Navegador, a través de las cabeceras HTTP o recopilando esa información desde la ejecución de código en el mismo navegador
    • Dispositivo, sea un móvil, equipo informático clásico, smartwatch, sistema empotrado…
    • Periféricos de los que hagamos uso
• Usuario
  • Parametrizacion o personalización del usuario
  • Idioma, zona horaria y configuración regional
  • Credenciales, roles y autorizaciones
• Transacción
  • Tipo de operación
  • Parámetros de la operación
  • Estado actual de la transacción
• Aplicación
  • Componente software en el que se produjo el error o salida del flujo normal de ejecución
  • Stack trace de ejecución con los parámetros en el flujo de llamada
  • Variables de estado, de sesión, de ejecución, volcados de memoria, registros del micro…

Hay que tener especial cuidado cuando la información recabada sea relativa a sistemas que no son de nuestra propiedad y que lo puedan ser del usuario, como por ejemplo: la información del propio equipo del usuario, de su móvil o la obtenida relativa al navegador. En este caso, es ético y recomendable informar al usuario de qué información se obtiene de una manera explícita y concreta (aunque sin ser apabullante con detalles). Mejor si le permitimos, incluso, decidir si quiere compartirla con nosotros o no.

Referencias

La foto de cabecera ha sido tomada de https://www.flickr.com/photos/sissou/8432968631 y se está usando bajo licencia CC.

Esta entrada de Juan Francisco Adame Lorite está publicada bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.