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 sénior que informa a un cliente mientras toman un café. Un ritmo pausado, una dicción clara y un ingenio seco ocasional. No es una conferencia. No es un discurso de ventas. Solo es una charla franca de alguien que ha visto este problema un centenar de veces: Bienvenido al resumen técnico de Purple. Hoy voy a hablarle de algo que todo administrador de redes conoce en lo más profundo de su ser, incluso si nunca ha oído el término formal para referirse a ello. Tiempo medio hasta la inocencia. O MTTI. [pausa breve] 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 compruebe el router. El equipo del router dice que compruebe los puntos de acceso. El proveedor de los puntos de acceso dice que compruebe los dispositivos de los clientes. Y en algún momento en medio de todo eso, han pasado cuarenta y cinco minutos y nadie ha solucionado nada en realidad. Eso, justo ahí, es el tiempo medio hasta la inocencia en acción. [pausa breve] 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 cualquier equipo de trabajo puede demostrar, con pruebas, que su dominio no es la causa 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 raíz real. El MTTI está aislado. Es personal. Es el equipo de redes diciendo: aquí están los datos, no somos nosotros, ahora 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 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] Por tres razones. En primer lugar, el WiFi es visible. Cuando algo falla, 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. En segundo lugar, 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. En tercer lugar, 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 demostrar un estado de salud impecable de la capa inalámbrica en menos de dos minutos, va a pasar la próxima hora defendiéndose. Ahora bien, en un entorno de gran empresa mono-inquilino (single-tenant), esto es molesto. En un entorno multi-inquilino (multi-tenant), resulta verdaderamente perjudicial. Piense en un hotel como Premier Inn, o en un bloque residencial de alquiler (build-to-rent), o en un centro de conferencias que organiza eventos consecutivos. Cuenta con un gestor de la propiedad que no es propietario de la red. Cuenta con residentes o huéspedes que no entienden de redes. Y cuenta con 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 gestor de la propiedad culpa al proveedor de WiFi porque ese es el contrato al que puede aferrarse. 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 de lo contrario la relación se deteriora. [breve pausa] En este contexto, el MTTI no es solo una métrica técnica. Es comercial. Por tanto, hablemos de la metodología que realmente lo reduce. Consta de cinco capas, y necesita las cinco. Capa uno: comprobaciones sintéticas continuas. Antes de que se registre cualquier incidencia, debería disponer de sondas automatizadas que se ejecuten 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 se produce una incidencia, puede extraer un gráfico y mostrar exactamente cuándo se realizó la última comprobación sintética limpia en la capa WiFi, y si estaba limpia o degradada en el momento de la queja. Eso por sí solo reduce el MTTI drásticamente, porque o bien confirma que el WiFi estaba sano, 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á sano. Puede demostrar que el conmutador está sano. Pero ¿puede demostrar que la ruta desde el conmutador hasta la entrega del ISP está sana? En un edificio multi-tenant, a menudo hay saltos que no son de su propiedad. La red de distribución interna del edificio, el conmutador central del propietario, el punto de demarcación con el ISP. Necesita datos de traza de ruta que crucen esos límites. No basta con un simple ping a ocho-ocho-ocho-ocho. Requiere una visibilidad real de tipo traceroute que le muestre cada salto, su latencia y si está perdiendo paquetes. Cuando puede demostrar que los saltos del uno al cuatro están limpios y el salto cinco, que es el router de borde 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 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á saliendo siquiera de la red. Si sale de la red limpio y el problema está aguas abajo, 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 dirigida para un cliente o VLAN específicos sin tocar el hardware. Esa es su capa forense. La utilizará con moderación, pero cuando la necesite, será definitiva. Capa cuatro: topología y mapeo de 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. ¿Está afectando a un inquilino o a todos? ¿A una planta o a todo el edificio? ¿A una VLAN o a todas? 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 involucrar y a quién puede excluir de inmediato. Capa cinco: correlación de eventos. Esta es la que lo 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 en los 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 derivación. La correlación de eventos no es glamurosa, 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 se equivocan muchos equipos. El objetivo de reducir el MTTI no es ganar el juego de las culpas más rápido. Es acabar con él por completo. [pausa corta] Las pruebas compartidas cambian la dinámica. Cuando el proveedor de WiFi puede enviar al gestor de la propiedad un enlace a un panel de control 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 de confrontación. Se vuelve colaborativa. El gestor de la propiedad llama al ISP. El ISP soluciona 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 solucionar 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 de estilo Premier Inn empiezan a informar de que el WiFi de las habitaciones es lento. Recepción registra un ticket con el proveedor de WiFi gestionado. Con las comprobaciones sintéticas en ejecución, el proveedor puede ver que los tiempos de resolución DNS se dispararon de doce milisegundos a cuatrocientos milisegundos a las siete y cuarenta y tres de la mañana. La capa de 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 la comprobación sintética que muestra que la capa de 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 de WiFi: seis minutos. MTTR para el incidente completo: veintidós minutos, porque la solución del ISP tardó dieciséis minutos. Sin la herramienta 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 minorista nacional con WiFi en doscientas tiendas nota que los terminales de punto de venta de una región pierden de forma intermitente 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 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 que las retransmisiones TCP se están disparando, 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. El tiempo de resolució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 aprovisionando de nuevo las VLAN 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? Ejecute 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, el problema está aguas arriba 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 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 culpable real. 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, cuentan con pruebas sintéticas y diagnóstico de clientes integrados. Utilícelas. Documente su topología. Diseñe 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 terminar: el "Mean time to innocence" es el impuesto oculto en cada incidente de red. En entornos multi-inquilino, donde la responsabilidad se fragmenta entre proveedores, propietarios e ISP, es la métrica que determina si usted conserva los contratos o los pierde. La metodología para reducirlo no es complicada: comprobaciones sintéticas, visibilidad de rutas, datos de flujo, mapeo de topología y correlación de eventos. El objetivo no es ganar el juego de las culpas. Es sustituir dicho juego por pruebas compartidas, de modo que cada equipo pueda centrarse en solucionar el problema en lugar de defender su terreno. [breve pausa] 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 quiere ver cómo la plataforma de Multi-Tenant WiFi de Purple muestra este tipo de datos de observabilidad en más de 80.000 espacios en directo, visite purple dot ai.