Detectar cortes de fibra antes de la primera llamada del cliente
El rastreo automático con IA y el análisis de causa raíz dieron al NOC 30 minutos de ventaja frente a las incidencias, transformando la extinción reactiva de incendios en una garantía proactiva.
−47%
MTTR
−38%
Reclamaciones entrantes
−61%
Incumplimientos de SLA
Un proveedor de banda ancha metropolitano con 140.000 abonados FTTH en una de las regiones urbanas más densas del Golfo tenía un problema que empeoraba, no mejoraba, a medida que la red crecía. Se enteraban de los cortes por clientes enfadados. Cuando un ingeniero empezaba a mirar, el impacto al cliente ya se había difundido en las redes sociales.
Contexto
El operador gestiona un parque mixto de OLT Huawei y ZTE, con una fuerte dependencia de la fibra aérea en distritos antiguos y fibra subterránea en los más nuevos. Los eventos meteorológicos — en particular las raras pero intensas tormentas de arena — producían grupos de fallos que el NMS existente presentaba como miles de alarmas independientes. El NOC no estaba abrumado por los fallos, sino por el ruido.
El flujo de garantía existente era: el cliente llama, se abre un ticket, un ingeniero del NOC investiga en cinco herramientas, la causa raíz se identifica tras 12–25 minutos, se toma la acción y se cierra el ticket. El tiempo medio de reparación se situaba por encima de los 38 minutos. Los incumplimientos de SLA en circuitos empresariales eran de 8–12 al mes. La dirección quería mejoras que no requiriesen duplicar la plantilla.
Lo que nos propusimos
- Reducir el volumen visible de alarmas a señal accionable, sin perder fallos reales.
- Retrotraer cualquier nuevo fallo a su causa real en cuestión de segundos.
- Detectar cortes antes de que llamen los abonados, es decir, de forma proactiva, solo a partir de telemetría.
- Auto-remediar las categorías de fallo que sean seguras de resolver automáticamente (temperatura alta del CPE, oscilación de autenticación RADIUS, oscilaciones habituales inducidas por firmware).
Enfoque
Despliegue de seis meses, con controles de salud en cada fase
- Incorporación de todas las OLT a Netxol NMM (SNMP, SSH, APIs de fabricante).
- Envío de todas las alarmas al almacén de eventos de Netxol con el contexto de topología adjuntado en la ingesta.
- Establecimiento de volúmenes de base: alarmas/semana, reclamaciones/semana, distribución del MTTR.
- Activación del agrupado consciente de topología: las ONU hermanas que oscilan juntas se colapsan a un único evento de puerto OLT.
- La correlación por ventana temporal suprime las alarmas de réplica dentro de los 90 segundos posteriores a un evento padre.
- El volumen visible de alarmas cae un 86% en la primera ventana de medición; no se pierde ningún fallo real en el mismo periodo.
- Puesta en marcha del RCA en modo sombra durante 3 semanas. El NOC ve las conclusiones de la IA junto a las suyas.
- Muestra de calibración: 200 resultados con confianza ≥ 90%; 184 de 200 correctos (calibración aceptable).
- Promoción del RCA a modo activo: la conclusión de la IA se adjunta a cada ticket en el momento de apertura.
- Biblioteca de patrones para firmas de alerta temprana (deriva de potencia Rx, reinicios repetidos de hardware de ONU).
- El AI Auto-Crawler se ejecuta de forma continua sobre la red viva: abre sus propios tickets antes de las llamadas de clientes.
- Primer mes medido: 42% de los tickets de corte se abrieron antes de cualquier llamada de cliente.
- Biblioteca de políticas de Auto-Fix: temperatura alta del CPE → límite de QoS + notificación; ONU atascada en fase 4 → reinicio controlado.
- Límites de radio de impacto y puertas de verificación en cada acción.
- 57% de los tickets de fallo resueltos sin intervención humana en el primer mes de Auto-Fix.
La victoria inesperada: la calma ante tormentas de alarmas
El efecto más útil del despliegue no se había previsto. Históricamente, las tormentas de arena producían "tormentas de alarmas" — más de 4.000 eventos en 30 minutos, saturando por completo al NOC. Con la supresión consciente de topología y el manejo proactivo por IA, el mismo evento meteorológico en el mes 5 produjo 71 eventos para que el NOC actuara; el resto fueron suprimidos (relacionados con padres conocidos) o auto-resueltos (reinicios, reenvíos de perfil). El NOC lo describió como un "mal día manejable" en vez de un "turno perdido".
Fue posible una nueva categoría de SLA
Tras la Fase 4, el operador lanzó un nivel "Proactive Care" para clientes pyme, respaldado por un compromiso contractual de una ventana de notificación proactiva de 30 minutos. Solo pudieron vender ese nivel porque la plataforma ahora lo cumple de forma consistente.
Resultados
| Metric | Before | After | Δ |
|---|---|---|---|
| Alarmas visibles / día | 2.400 (media) | 230 | −90% |
| Tiempo medio de reparación | 38 min | 20 min | −47% |
| Llamadas entrantes de fallo / mes | 11.400 | 7.050 | −38% |
| Incumplimientos de SLA / mes | 10 (media) | 4 | −61% |
| Detección proactiva de cortes | 0% | 42% | nueva capacidad |
Stack tecnológico utilizado
- Netxol NMM — adaptadores Huawei + ZTE, SNMP, syslog, APIs de fabricante.
- Netxol AI RCA Engine — Bayesiano + grafo de topología + retrospectiva histórica.
- Netxol AI Auto-Crawler — detección continua de anomalías.
- Motor de políticas Netxol Auto-Fix con límites de radio de impacto.
- Almacén de eventos con supresión y agrupado consciente de topología.
Lecciones aprendidas
- Ejecuta el RCA en modo sombra al menos 3 semanas antes de promoverlo a activo. El NOC necesita verlo pensar.
- La calibración no es negociable: mide la precisión en cada banda de confianza y actúa solo sobre bandas por encima de tu umbral.
- Los límites de radio de impacto son la diferencia entre un sistema seguro y uno peligroso. Pon topes fijos a las acciones por unidad de tiempo.
- Comunica de forma agresiva a atención al cliente: necesitan saber que la plataforma ahora abre tickets antes que ellos.