Mean time to innocence: cómo demostrar que no es el WiFi

Hable en inglés británico con un tono seguro, autoritario y conversacional, como un consultor de redes senior informando a un cliente durante un café. Ritmo pausado, dicción clara, humor seco ocasional. No es una conferencia. No es un discurso de ventas. Solo una charla directa de alguien que ha visto este problema cien veces: Bienvenido al informe técnico de Purple. Hoy les voy a hablar de algo que todo administrador de red conoce a fondo, incluso si nunca han escuchado el término formal para ello. Tiempo medio para la inocencia. O MTTI. [pausa breve] El tiempo que pasa demostrando que no es su culpa. 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 revise el router. El equipo del router dice que revise los puntos de acceso. El proveedor del punto de acceso dice que revise los dispositivos cliente. Y en medio de todo eso, han pasado cuarenta y cinco minutos y nadie ha solucionado nada. Eso, justo ahí, es el tiempo medio para la inocencia en acción. [pausa breve] Y le está costando más de lo que cree. Permítame definirlo correctamente. El tiempo medio para la inocencia es el tiempo promedio transcurrido entre que se detecta un problema y el momento en que cualquier equipo dado puede demostrar, con evidencia, que su dominio no es la causa raíz. No es lo mismo que el tiempo medio para identificar, que es la métrica de toda la organización para encontrar la causa raíz real. El MTTI es aislado. Es personal. Es el equipo de red diciendo: aquí están los datos, no somos nosotros, ahora busquen en otra parte. El problema es que, sin las herramientas adecuadas, esa prueba lleva tiempo. Y cada minuto de MTTI es un minuto que se suma directamente a su tiempo medio de resolución, su MTTR. Ambos son inseparables. Entonces, ¿por qué siempre se culpa primero al WiFi? [pausa breve] Tres razones. Primero, el WiFi es visible. Cuando algo falla, la gente mira lo que puede ver, y las barras de señal de WiFi en su teléfono son el indicador más visible de conectividad. Segundo, el WiFi es el último salto antes del dispositivo, por lo que es lo primero que parece sospechoso cuando un dispositivo no puede conectarse a Internet. Tercero, y esta es la parte incómoda, los equipos de WiFi a menudo no pueden demostrar su inocencia rápidamente porque carecen de la telemetría adecuada. Si no puede mostrar un estado de salud impecable para la capa inalámbrica en menos de dos minutos, pasará la siguiente hora defendiéndose. Ahora bien, en un entorno empresarial de inquilino único, esto resulta molesto. En un entorno multi-tenant, es genuinamente perjudicial. Piense en un hotel como Premier Inn, o en un edificio residencial de alquiler, o en un centro de convenciones que organiza eventos de forma consecutiva. Tiene un administrador de la propiedad que no es dueño 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 interno del edificio, ni de los dispositivos del 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 le paga la renta. Y el proveedor de WiFi tiene que exonerar a la red rápidamente, o la relación se deteriora. [pausa corta] El MTTI no es sólo una métrica técnica en este contexto. Es una métrica comercial. Así que 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 genere cualquier ticket, debería tener sondas automatizadas ejecutándose desde la propia red, probando la resolución de DNS, la accesibilidad HTTP, la latencia a endpoints 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 fue la última vez que la capa WiFi tuvo una 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 confirma que el WiFi estaba en buen estado, o confirma que no lo estaba, y deja de discutir al respecto. Capa dos: visibilidad de la ruta salto por salto. Aquí es donde la mayoría de los equipos fallan. 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 multi-tenant, a menudo hay saltos que no le pertenecen. La red de distribución interna del edificio, el switch central del arrendador, el punto de demarcación con el ISP. Necesita datos de seguimiento de ruta que crucen esos límites. No sólo 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 brindan una vista 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 está más adelante, esa es su evidencia. 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 dirigida para un cliente o VLAN específico sin tocar el hardware. Esa es su capa forense. La usa con moderación, pero cuando la necesita, es definitiva. Capa cuatro: topología y mapeo de dependencias. En un entorno multi-inquilino, necesita un mapa en vivo que muestre qué puntos de acceso atienden a qué inquilinos, a qué switches se conectan esos AP, qué enlaces ascendentes usan esos switches y qué circuito de ISP atiende a cada enlace ascendente. Cuando ocurre un incidente, puede identificar de inmediato el radio de impacto. ¿Esto afecta a un inquilino o a todos los inquilinos? ¿A un piso 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 involucrar 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 energía y las quejas de los usuarios deben estar en la misma línea de tiempo. Cuando superpone un pico en las fallas de asociación de clientes con una actualización de firmware que ocurrió doce minutos antes, tiene su causa raíz. Cuando superpone un pico de latencia con una ventana de mantenimiento del ISP que no se le comunicó, tiene su evidencia para el escalamiento. La correlación de eventos no es glamorosa, pero es la diferencia entre un juego de culpas de cuarenta y cinco minutos y una exoneración de 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 terminar con el juego de las culpas por completo. [pausa corta] La evidencia compartida cambia la dinámica. Cuando el proveedor de WiFi puede enviarle al administrador de la propiedad un enlace a un tablero que muestra verde en la capa inalámbrica, ámbar en el switch del edificio y rojo en el circuito del ISP, la conversación deja de ser confrontativa. 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 ellos fueron quienes encontraron el problema. Ese es el caso comercial para invertir en herramientas de observabilidad. No solo una resolución de problemas más rápida, sino mejores 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 estilo Premier Inn comienzan a reportar que el WiFi de la habitación está lento. Recepción registra un ticket con el proveedor de WiFi administrado. Con los análisis sintéticos en ejecución, el proveedor puede ver que los tiempos de resolución DNS aumentaron de doce milisegundos a cuatrocientos milisegundos a las siete cuarenta y tres de la mañana. La capa de WiFi está funcionando de manera óptima. 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 le 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 del análisis sintético que muestra que la capa de WiFi estuvo limpia en todo momento. Se contacta al ISP. El ISP confirma un problema de enrutamiento de su lado. Tiempo total desde la queja hasta la exoneración de la capa de WiFi: seis minutos. El MTTR para el incidente completo: veintidós minutos, porque la solución del ISP tomó dieciséis minutos. Sin las herramientas de observabilidad, esa exoneración de seis minutos habría tomado cuarenta minutos de comunicación de ida y vuelta, y el MTTR habría sido de más de una hora. Escenario dos: una cadena de tiendas de retail. Un minorista nacional con WiFi en doscientas tiendas nota que las terminales de punto de venta en una región pierden intermitentemente la conectividad con el procesador de pagos. De inmediato se culpa al equipo de red. Los datos de flujo muestran que el tráfico hacia el rango de IP del procesador de pagos está saliendo de la red de la tienda de forma limpia. El problema no es la red. Una captura de paquetes en la VLAN del procesador de pagos muestra un aumento en las 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 de su lado. 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. Muy bien. Permítame darle la versión rápida de las preguntas clave que me hacen sobre este tema. ¿Es el WiFi o el dispositivo? Ejecute un análisis sintético 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, el problema está arriba del dispositivo. ¿Es el WiFi o el ISP? Realice un rastreo de ruta hacia Internet. Si la latencia o la pérdida se introducen en un salto fuera del límite 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? Empieza con lo que ya tienes. La mayoría de las plataformas de puntos de acceso empresariales, incluyendo Cisco Meraki, HPE Aruba y Juniper Mist, tienen pruebas sintéticas y diagnóstico de clientes integrados. Úsalos. Documenta tu topología. Construye un panel de control compartido que el administrador de la propiedad o el equipo de operaciones puedan ver. La transparencia es la herramienta de reducción de MTTI más barata disponible. Para concluir. El tiempo medio para demostrar la inocencia es el impuesto oculto en cada incidente de red. En entornos multi-inquilino, donde la responsabilidad está fragmentada entre proveedores, propietarios e ISPs, es la métrica que determina si retienes los contratos o los pierdes. La metodología para reducirlo no es complicada: comprobaciones sintéticas, visibilidad de ruta, datos de flujo, mapeo de topología y correlación de eventos. El objetivo no es ganar el juego de las culpas. Es reemplazar el juego de las culpas con evidencia compartida, para que cada equipo pueda concentrarse en solucionar el problema en lugar de defender su terreno. [pausa corta] Porque cada minuto dedicado a demostrar la inocencia es un minuto que se suma al tiempo que tus residentes, huéspedes o compradores pasan sin conectividad. Y ese es el número que realmente importa. Gracias por escuchar. Si quieres ver cómo la plataforma de Multi-Tenant WiFi de Purple muestra este tipo de datos de observabilidad en más de 80,000 establecimientos activos, dirígete a purple dot ai.