Tiempo medio hasta la inocencia: cómo demostrar que el problema no es el WiFi

Hable en inglés británico con un tono seguro, autoritario y conversacional, como un consultor sénior de redes que informa a un cliente mientras toman un café. Con un ritmo pausado, una dicción clara y un toque ocasional de humor seco. Sin sermones. Sin discursos de ventas. Solo una charla directa de alguien que ha visto este problema un centenar de veces: Bienvenido a la sesión técnica de Purple. Hoy voy a hablarle de algo que todo responsable de red conoce en lo más profundo de su ser, aunque nunca haya oído el término formal para referirse a ello. El tiempo medio hasta la inocencia. O MTTI. [breve pausa] El tiempo que pasa demostrando que no es culpa suya. Este es el escenario. Son las nueve de la mañana. Los residentes de un bloque de viviendas de alquiler empiezan a llamar a la recepción. El WiFi no funciona. El administrador de la propiedad llama al proveedor de WiFi gestionado. El proveedor de WiFi gestionado llama al ISP. El ISP dice que comprueben el router. El equipo del router dice que comprueben los puntos de acceso. El fabricante de los puntos de acceso dice que comprueben los dispositivos de los clientes. Y en medio de todo eso, han pasado cuarenta y cinco minutos y nadie ha solucionado nada. Eso, justo ahí, es el tiempo medio hasta la inocencia en acción. [breve pausa] Y le está costando más de lo que cree. Permítame definirlo correctamente. El tiempo medio hasta la inocencia es el tiempo medio transcurrido entre el momento en que se detecta un problema y el momento en que un equipo concreto puede demostrar, con pruebas, que su dominio no es la causa de raíz. No es lo mismo que el tiempo medio de identificación, que es la métrica de toda la organización para encontrar la causa de raíz real. El MTTI es estanco. Es personal. Es el equipo de redes diciendo: aquí están los datos, no somos nosotros, busquen en otra parte. El problema es que sin las herramientas adecuadas, esa demostración requiere tiempo. Y cada minuto de MTTI es un minuto que se añade directamente a su tiempo medio de resolución, su MTTR. Ambos son inseparables. Entonces, ¿por qué siempre se culpa primero al WiFi? [breve pausa] Por tres razones. Primero, el WiFi es visible. Cuando algo se estropea, la gente mira lo que puede ver, y las barras de señal WiFi de su teléfono son el indicador de conectividad más visible. Segundo, el WiFi es el último salto antes del dispositivo, por lo que es lo primero que resulta sospechoso cuando un dispositivo no puede conectarse a internet. Tercero, y esto es lo más incómodo, los equipos de WiFi a menudo no pueden demostrar su inocencia rápidamente porque carecen de la telemetría adecuada. Si no puede demostrar que la capa inalámbrica funciona correctamente en menos de dos minutos, se pasará la siguiente hora defendiéndose.Ahora bien, en un entorno empresarial de inquilino único, esto es molesto. En un entorno multiinquilino, es realmente perjudicial. Piense en un hotel como Premier Inn, un bloque residencial de alquiler de obra nueva o un centro de conferencias que organiza eventos consecutivos. Tiene un administrador de la propiedad que no es propietario de la red. Tiene residentes o huéspedes que no entienden la red. Y tiene un proveedor de WiFi gestionado que es responsable de la capa inalámbrica, pero no del circuito del ISP, ni del cableado del edificio, ni de los dispositivos cliente. Cuando algo falla, el administrador de la propiedad culpa al proveedor de WiFi porque ese es el contrato al que puede apelar. El residente culpa al edificio porque es a quien paga el alquiler. Y el proveedor de WiFi tiene que exonerar a la red rápidamente, o la relación se deteriorará. [short pause] El MTTI no es solo una métrica técnica en este contexto. Es una métrica comercial. Por tanto, hablemos de la metodología que realmente lo reduce. Hay cinco capas, y necesita las cinco. Capa uno: comprobaciones sintéticas continuas. Antes de que se cree cualquier incidencia, debería tener sondas automatizadas ejecutándose desde la propia red, probando la resolución DNS, la accesibilidad HTTP, la latencia a puntos de conexión conocidos y los flujos de autenticación. Herramientas como Marvis de Juniper Mist, o las pruebas sintéticas integradas en plataformas como ThousandEyes, ejecutan estas comprobaciones cada pocos minutos. Cuando ocurre un incidente, puede extraer un gráfico y mostrar exactamente cuándo la capa WiFi tuvo la última comprobación sintética limpia, y si estaba limpia o degradada en el momento de la queja. Eso por sí solo reduce drásticamente el MTTI, porque o bien confirma que la WiFi estaba en buen estado, o bien confirma que no lo estaba, y deja de discutir al respecto. Capa dos: visibilidad de la ruta salto a salto. Aquí es donde fallan la mayoría de los equipos. Puede demostrar que el punto de acceso está en buen estado. Puede demostrar que el switch está en buen estado. Pero ¿puede demostrar que la ruta desde el switch hasta la entrega del ISP está en buen estado? En un edificio multiinquilino, a menudo hay saltos que no son de su propiedad. La red de distribución interna del edificio, el switch principal del propietario, el punto de demarcación con el ISP. Necesita datos de traza de ruta que crucen esos límites. No solo un ping a ocho-ocho-ocho-ocho. Visibilidad real de tipo traceroute que le muestre cada salto, su latencia y si está perdiendo paquetes. Cuando puede mostrar que los saltos del uno al cuatro están limpios y el salto cinco, que es el router perimetral del ISP, muestra un cuarenta por ciento de pérdida de paquetes, la conversación cambia de inmediato. Capa tres: datos de flujo con captura de paquetes bajo demanda. NetFlow e IPFIX le ofrecen una visión a nivel de conversación de qué se está comunicando con qué en la red. Cuando un residente dice que el servicio de streaming no funciona, los datos de flujo le indican si el tráfico hacia los rangos de IP de ese servicio está siquiera saliendo de la red. Si sale de la red limpio y el problema es posterior, esa es su prueba. Si no sale de la red en absoluto, ya sabe dónde buscar. La captura de paquetes bajo demanda, disponible en plataformas como Cisco Meraki y HPE Aruba, le permite obtener una captura específica para un cliente o VLAN en particular sin necesidad de tocar el hardware. Esa es su capa forense. La utilizará con moderación, pero cuando la necesite, será definitiva. Capa cuatro: mapa de topología y dependencias. En un entorno multiinquilino, necesita un mapa en vivo que muestre qué puntos de acceso dan servicio a qué inquilinos, a qué switches se conectan esos AP, qué enlaces ascendentes utilizan esos switches y qué circuito de ISP da servicio a cada enlace ascendente. Cuando se produce un incidente, puede identificar de inmediato el radio de impacto. ¿Afecta esto a un inquilino o a todos? ¿A una planta o a todo el edificio? ¿A una VLAN o a todas las VLAN? Esa pregunta de alcance, respondida en treinta segundos desde un mapa de topología, le indica si el problema está en la capa WiFi, en la red del edificio o en la WAN. También le indica a quién más debe incluir y a quién puede excluir de inmediato. Capa cinco: correlación de eventos. Esta es la que une todo. Los registros de cambios, las alertas de mantenimiento del ISP, las actualizaciones de firmware de los dispositivos, los eventos de alimentación y las quejas de los usuarios deben estar en la misma línea de tiempo. Cuando superpone un pico de fallos de asociación de clientes con una actualización de firmware que se produjo doce minutos antes, ya tiene la causa raíz. Cuando superpone un pico de latencia con una ventana de mantenimiento del ISP que no se le comunicó, ya tiene las pruebas para la reclamación. La correlación de eventos no es glamurosa, pero marca la diferencia entre un juego de culpas de cuarenta y cinco minutos y una exoneración en cuatro minutos. Ahora, unas palabras sobre la dimensión cultural, porque aquí es donde muchos equipos se equivocan. El objetivo de reducir el MTTI no es ganar el juego de las culpas más rápido. Es acabar por completo con el juego de las culpas. [breve pausa] Las pruebas compartidas cambian la dinámica. Cuando el proveedor de WiFi puede enviar al administrador de la propiedad un enlace a un panel de control que se muestra en verde en la capa inalámbrica, en ámbar en el switch del edificio y en rojo en el circuito del ISP, la conversación deja de ser conflictiva. Se vuelve colaborativa. El administrador de la propiedad llama al ISP. El ISP repara el circuito. Los residentes recuperan la conectividad. Y el contrato del proveedor de WiFi se renueva porque fue quien encontró el problema. Ese es el argumento comercial para invertir en herramientas de observabilidad. No se trata solo de resolver problemas más rápido, sino de mejorar las relaciones con las personas que le pagan. Permítame repasar un par de escenarios rápidos para concretar esto. Escenario uno: un hotel de 350 habitaciones. Los huéspedes de una propiedad al estilo de Premier Inn comienzan a informar que el WiFi de las habitaciones es lento. La recepción registra un ticket con el proveedor de WiFi gestionado. Con las comprobaciones sintéticas en funcionamiento, el proveedor puede ver que los tiempos de resolución DNS aumentaron de doce milisegundos a cuatrocientos milisegundos a las siete y cuarenta y tres de la mañana. La capa WiFi está sana. El rastreo de ruta muestra que la latencia se introduce en el tercer salto, que es el router de agregación del ISP. El proveedor envía al gerente del hotel una captura de pantalla del rastreo de ruta con el salto degradado resaltado en rojo, junto con el gráfico de comprobación sintética que muestra que la capa WiFi estuvo limpia en todo momento. Se llama al ISP. El ISP confirma un problema de enrutamiento por su parte. Tiempo total desde la queja hasta la exoneración de la capa WiFi: seis minutos. MTTR para el incidente completo: veintidós minutos, porque la solución del ISP tardó dieciséis minutos. Sin las herramientas de observabilidad, esa exoneración de seis minutos habrían sido cuarenta minutos de idas y venidas, y el MTTR habría superado la hora. Escenario dos: una cadena de tiendas. Un distribuidor nacional con WiFi en doscientas tiendas nota que los terminales de punto de venta de una región pierden intermitentemente la conectividad con el procesador de pagos. Se culpa de inmediato al equipo de red. Los datos de flujo muestran que el tráfico hacia el rango de IP del procesador de pagos está saliendo limpiamente de la red de la tienda. El problema no es la red. Una captura de paquetes en la VLAN del procesador de pagos muestra picos de retransmisiones TCP, lo que apunta a un problema del lado del servidor en el procesador de pagos. El equipo de red comparte los datos de flujo y el resumen de la captura con el equipo de soporte del procesador de pagos. El procesador de pagos identifica un equilibrador de carga mal configurado por su parte. El MTTI del equipo de red: ocho minutos. Tiempo de solución del procesador de pagos: treinta y cinco minutos. Sin los datos de flujo, el equipo de red habría pasado esos treinta y cinco minutos reaprovisionando VLANs y reiniciando switches que funcionaban perfectamente. Bien. Permítame ofrecerle la versión rápida de las preguntas clave que me suelen hacer sobre este tema. ¿Es el WiFi o el dispositivo? Realice una comprobación sintética desde el propio AP. Si el AP puede acceder a internet limpiamente y el dispositivo no, es el dispositivo. Si el AP no puede acceder a internet, está por encima del dispositivo. ¿Es el WiFi o el ISP? Realice un rastreo de ruta a internet. Si la latencia o la pérdida se introducen en un salto fuera de los límites de su red, es el ISP. ¿Cuál es la diferencia entre MTTI y el tiempo medio de identificación? El MTTI es el tiempo que tarda su equipo en demostrar su inocencia. El tiempo medio de identificación es el tiempo que tarda la organización en encontrar al verdadero culpable. El MTTI es un subconjunto del tiempo medio de identificación. ¿Cómo reduzco el MTTI sin comprar nuevas herramientas? Empiece con lo que ya tiene. La mayoría de las plataformas de puntos de acceso empresariales, como Cisco Meraki, HPE Aruba y Juniper Mist, incorporan pruebas sintéticas y diagnóstico de clientes. Utilícelas. Documente su topología. Cree un panel de control compartido que el gestor de la propiedad o el equipo de operaciones puedan ver. La transparencia es la herramienta de reducción de MTTI más barata que existe. Para resumir. El tiempo medio hasta la inocencia es el impuesto oculto en cada incidente de red. En entornos multi-inquilino, donde la responsabilidad está fragmentada entre proveedores, propietarios e ISP, es la métrica que determina si se conservan los contratos o se pierden. La metodología para reducirlo no es complicada: comprobaciones sintéticas, visibilidad de rutas, datos de flujo, mapas de topología y correlación de eventos. El objetivo no es ganar el juego de las acusaciones. Es sustituir el juego de las acusaciones por pruebas compartidas, de modo que cada equipo pueda centrarse en solucionar el problema en lugar de defender su terreno. [pausa breve] Porque cada minuto dedicado a demostrar la inocencia es un minuto que se suma al tiempo que sus residentes, invitados o compradores pasan sin conectividad. Y esa es la cifra que realmente importa. Gracias por escucharnos. Si desea ver cómo la plataforma de WiFi multi-inquilino de Purple muestra este tipo de datos de observabilidad en más de 80.000 espacios en directo, visite purple dot ai.