Adaptarse al trabajo híbrido: mejorar la experiencia digital recopilando datos de todos los lugares adecuados

Con la aparición del trabajo híbrido, la mala experiencia del usuario se ha convertido en algo demasiado común: las quejas de los usuarios por la lentitud de las aplicaciones, las interrupciones de la red y las interrupciones de las máquinas son ahora algo cotidiano. Pero se da por supuesto que la gran mayoría de estos problemas se resuelven porque desaparecen y no porque se haya encontrado la causa raíz del problema.

El análisis de causa raíz requiere datos (muchos datos) recopilados de manera puntual, contextualizada y que sea lo suficientemente amplia como para identificar (o descartar) posibles culpables. El problema es que estos datos no son fáciles de recopilar y analizar utilizando técnicas de supervisión tradicionales. Además, no ayuda el hecho de que los problemas de rendimiento afecten a usuarios y aplicaciones que pueden estar en cualquier lugar, lo que dificulta aún más la recopilación de los datos correctos de los lugares adecuados.

En mi trabajo anterior como analista de Gartner, el principal desafío al que se enfrentaban mis clientes no era la falta de datos de rendimiento, sino la incapacidad de utilizar varios silos de datos de rendimiento no correlacionados para solucionar un problema. Las herramientas de supervisión en silo que se centraban en un área se utilizaban para que los equipos se culpasen entre sí; por ejemplo, los equipos de aplicaciones señalaban a los equipos de red que, a su vez, señalaban a la seguridad o a la informática del usuario final. Y eso en el caso de que existieran herramientas en absoluto. En algunos entornos cliente, había una completa falta de visibilidad.

Figura 1: La supervisión de la experiencia digital requiere que se recopilen, correlacionen y visualicen diversos datos de telemetría de rendimiento para obtener información estratégica de todos los usuarios que permita actuar

Cualquier ejercicio de diagnóstico completo recoge tanto los datos de series temporales como de eventos en tres áreas principales de causas potenciales: la aplicación, la red y el dispositivo de punto final. Este enfoque permite obtener suficientes pruebas para señalar con seguridad dónde está el problema y poder resolverlo. 

Como sabemos, los datos pueden ser confusos y rara vez hay pruebas irrefutables para resolver cualquier problema. Por ejemplo, una llamada desvirtuada de Microsoft Teams o una aplicación lenta se pueden deber a varias causas subyacentes. Las soluciones de supervisión de la experiencia digital se crearon para ayudar con este problema, pero necesitan recoger una auténtica experiencia de usuario final y también analizar todas las posibles causas subyacentes, como el punto final, la red, la aplicación y la seguridad, para llegar a determinar la raíz del problema. 

Como se ve en la Figura 2, comenzar con una medición objetiva de la experiencia del usuario final (carga lenta de la página, mala calidad de las llamadas) es clave. Luego se trata de correlacionar la mala experiencia del usuario con las diversas causas potenciales subyacentes.

Figura 2: El análisis de la causa raíz requiere recoger una variedad de puntos de datos para poder distinguir con éxito la señal del ruido

Como ejemplo, hace unas semanas, un empleado de Zscaler de repente comenzó a experimentar degradaciones graves del rendimiento que afectaban a todas las aplicaciones, pero especialmente a Zoom. Al ser Zoom una aplicación en tiempo real, las fluctuaciones en la conectividad son especialmente notables. Tras el examen en ZDX, se verificó un problema de Zoom, ya que su puntuación de ZDX había disminuido y mostraba una serie de caídas en el transcurso del día.
 

Figura 3: Zoom con caídas de rendimiento

El primer paso fue mirar los tiempos de resolución del servidor y del DNS para ver si esas caídas podían estar correlacionadas. Este no era el problema.

Figura 4: Los tiempos de respuesta del servidor y del DNS eran planos

El siguiente paso fue observar la latencia de red de extremo a extremo y, aunque iba ligeramente a ráfagas, la latencia total era inferior a 25 ms y probablemente no era la causa que originaba problema.

Figura 5: La latencia era relativamente plana y estuvo por debajo de los 25 ms todo el tiempo.

Por último, era hora de echar un vistazo al dispositivo del usuario final en sí. Los indicadores del estado del dispositivo parecían estar bien y la utilización de la CPU, la memoria y el disco estaban dentro de los límites aceptables.

Figura 6: El estado del dispositivo, en términos de uso de la CPU, la memoria y el disco estaba bien.

Si bien los indicadores del dispositivo parecían correctos, los eventos del dispositivo del usuario destacaban los cambios en los atributos del dispositivo. Esto demostró que la dirección Gateway_MAC_Address estaba cambiando entre un valor válido y nulo; un valor nulo significaría que el dispositivo perdería temporalmente la conexión con su siguiente salto. Dado que esta cadena de acontecimientos indicaba un problema de capa 2 entre el punto final y la pasarela, el usuario reinició su pasarela (lo que no ayudó) y finalmente sustituyó su dispositivo de pasarela, lo que llevó a la resolución del problema.

Figura 7: Los eventos del dispositivo destacaban los cambios en los atributos del dispositivo, lo cual muestra un problema de capa 2 entre el punto final y la puerta de enlace.

Cuando se trata de encontrar la causa raíz de los problemas de rendimiento, es preciso tener todos los datos correctos de todos los lugares correctos. 

Si desea más información sobre cómo Zscaler y ZDX proporcionan este nivel de visibilidad para permitir el análisis de la causa raíz, haga clic aquí.

(La Figura 2 está inspirada en el excelente trabajo del analista de Gartner, Greg Murray, que se encuentra aquí. Para verla, se requiere suscripción a Gartner).