Cómo diagnosticar problemas con una página web / servicio

Esta guía busca darle las herramientas de diagnóstico al equipo de soporte de red (NOC) de tu organización, para que así cuando reciban reclamos de un usuario o un grupo de usuarios sobre un problema con una página Web o servicio Web en particular puedan entregarle una mejor respuesta a los clientes, y en caso de ser necesario escalar de mejor manera el incidente a su proveedor aguas arriba (upstream). Si bien pueden haber otras metodologías de diagnóstico, esta metodología la hemos implementado en varios ISPs desde pequeños hasta grandes con muy buenos resultados.

Esta guía NO explica el procedimiento de pruebas para un usuario final, para esto es recomendable ver este artículo https://www.xataka.com/basics/como-comprobar-problemas-tu-conexion-internet-tuyos-operador

Primero tratar de replicar el problema desde nuestro NOC

Como buena práctica siempre es bueno probar si podemos abrir esta página o servicio Web desde los dispositivos en nuestro NOC. Si podemos abrir el servicio en nuestro NOC es un indicador que con una alta probabilidad es un problema en el dispositivo del usuario (ahi podemos revisar los DNS del cliente, es recomendable usar servidores DNS resolvers públicos como el 1.1.1.1, 8.8.8.8 o 9.9.9.9).

En caso que no podamos abrir la página Web o servicio con problemas desde nuestro NOC deberemos seguir el procedimiento de troubleshooting WAN.

Troubleshooting WAN

1. Revisar si hay ping al dominio del servicio (esto es un buen primer paso pero dada la arquitectura de los sistemas Web actuales no garantiza en ningún caso el correcto funcionamiento del servicio, pero nos sirve para diagnosticar si puede ser un tema de nuestro DNS, más sobre esto en la sección Arquitectura CDNs). La mayoría de los servicio Web responden a las consultas ICMP, sin embargo, hay algunos que los tienen bloqueados por motivos de “seguridad”. ¿Hay pérdida de paquetes? ¿Cómo está la latencia?
   
2. Si no responde, es recomendable probar otro servidor DNS resolver. En caso que el problema siga es recomendable hacer un traceroute hacia el destino y ver donde “muere” la traza. Esta información es extremadamente útil cuando escalamos el caso a nuestro proveedor aguas arriba, o para probar enrutando el tráfico por otro proveedor de IP transit.
   
3. Si ya hemos comprobado estos pasos es recomendable revisar si hay reportes de problemas con el servicio o página Web en www.downdetector.pe, este es un servicio, creado por el equipo de Ookla, relativamente nuevo que nos muestra los auto-reportes de usuarios en Perú de problemas con diferentes tipos de servicios. Lamentablemente al ser un servicio bastante nuevo, algunas veces no hay suficientes reportes para tener significancia estadística, por lo que también es recomendable ir a www.downdetector.com (sitio de reportes de usuarios de Estados Unidos y global) y ver si hay incidencias con los servicios a nivel mundial.
   

Arquitectura CDNs

Las CDNs actuales tienen una arquitectura de múltiples capas, en las cuales los servicios como el DNS se sirven desde servicios especializados como Cloudflare, Amazon Route 53, Google Cloud DNS, etc… Luego esta la capa de control (las páginas y base de datos, no el contenido) y luego la capa del contenido (ejemplo los archivos con los vídeos). Un ejemplo es el caso de Netflix que utiliza Amazon para las perimeras dos capas, pero utiliza su propia infraestructura para el contenido, es decir, la entrega de los archivos de vídeo. Por lo que si falla tu acceso a Amazon no podrás ver el contenido aunque tengas conectividad al servidor de contenido.

Disclaimer: no soy experto en arquitectura de CDNs, si hay algo que quieran complementar o si hay algun error por favor me pueden enviar un correo a [email protected] y con gusto mejoramos el artículo.