Cómo reducir el tiempo hasta la primera visibilidad de una infraestructura

Poca angustia como la de Aliens, cuando los detectores de los marines coloniales pitan alertando de que se aproximan xenomorfos, pero sin poder ubicarlos bien mientras avanzan en la penumbra de pasillos, disparando como pueden a sombras fantasmales. Lo parezca o no, la visibilidad de activos en la gestión IT se parece un poco.
Solemos tener (espero) herramientas para buscar a esos activos, pero una vez lanzado el escaneo, nos quedamos mirando una barra de progreso que avanza como la tortuga del cuento, hasta que el sistema decide mostrarnos qué tenemos entre manos.
Pero eso tampoco basta para una gestión óptima.
Detectar aliens no garantizaba un buen disparo, igual que detectar activos no es visibilidad, simplemente se trata de una lista de la compra. Por eso, vamos a ver cómo reducir ese tiempo muerto entre el «he encontrado algo» y el «entiendo qué es y puedo operarlo», apoyándonos en las mejoras que hemos implementado en Pandora FMS 800 LTS Aquarius.

El problema: descubrir activos no garantiza la visibilidad operativa

Hay una diferencia de calidad fundamental entre el discovery de red y la visibilidad de infraestructura. Eso sucede porque la mayoría de herramientas de monitorización de red son excelentes encontrando cosas. Lanzamos un ping, barremos un rango de IPs y se nos devuelve un listado de dispositivos que responden.
«Enhorabuena, tienes 450 activos nuevos que gestionar».
Gracias, ¿y ahora qué?
Saber que una IP responde no nos dice si ese equipo es el cerebro de nuestra red, una impresora ancestral en el sótano o un servidor crítico de base de datos a punto de explotar, porque no queda espacio.
El hallazgo sin contexto es ruido.
Y el ruido, en un entorno de operaciones, es lo que usa el desastre para acercarse camuflado como un xenomorfo.
La visibilidad operativa real ocurre cuando ese hallazgo se convierte en algo accionable.
Cuando el sistema no solo nos dice que el dispositivo existe, sino que muestra cómo se conecta con los demás, qué servicios corre y cuál es su estado de salud.
Por eso el valor real reside en reducir el tiempo hasta que un equipo puede ver, entender y empezar a operar con criterio, no solo hasta que algo hace bip mostrando un punto confuso que nos hace disparar derrochando munición.

Qué suele retrasar la primera visibilidad de una infraestructura

Si alguna vez has intentado hacer onboarding de una infraestructura nueva, o de un cliente en tu empresa de servicios gestionados (MSP), sabrás que la primera fase es un campo de minas de fricciones técnicas.
Los sistemas a gestionar nunca son fáciles y, para colmo, las herramientas para hacerlo parecen diseñadas para ponérnoslo difícil desde el minuto uno.
Por eso, las causas habituales de este retraso suelen ser:

• Demasiados parámetros al arrancar: Muchas herramientas de network discovery exigen que seamos expertos en su configuración antes de empezar siquiera. Si tenemos que definir manualmente cada protocolo, cada comunidad SNMP y cada puerto de escaneo antes de ver el primer resultado, ya hemos perdido la mañana.
• Falta de feedback durante el escaneo: Con el que sufrimos un síndrome de «caja negra». Lanzamos la tarea y esperamos. ¿Está funcionando? ¿Se ha colgado el proceso? ¿Ha encontrado ya algo importante? Encogimiento de hombros y a esperar. No saber qué está pasando genera ansiedad e impide reaccionar si algo va mal.
• Resultados difíciles de interpretar: Cuando por fin acaba, he ahí una tabla con 1.000 filas de direcciones IP y nombres DNS escritos en klingon, de modo que, lo que tenía que ser un mapa de red, resulta un jeroglífico que hay que descifrar manualmente.
• Mapas tardíos o poco útiles: En muchos sistemas, los mapas de red solo se generan al final de todo el proceso. Si el escaneo tarda tres horas, he ahí tres horas de ceguera técnica.
• Necesidad de rehacer la topología: Una vez que tenemos el mapa, si el sistema no ha entendido las relaciones entre nodos, ¿a quién le toca delinear los vínculos? (la respuesta es a ti). Hora de mover cajitas y tirar líneas para que el escaneo sirva de algo. Ese es un trabajo de artesano que no escala.

Qué debe ofrecer hoy un sistema de discovery realmente útil

Para que el discovery de red sea más que un trámite administrativo y se convierta en una ventaja competitiva, debe cumplir tres premisas básicas:

• Velocidad de arranque.
• Profundidad evolutiva.
• Continuidad operativa.

Examinemos más a fondo esas tres columnas que sostienen la casa.
Un sistema moderno debe permitirnos un arranque rápido y no deberíamos necesitar un manual de 400 páginas para lanzar nuestro primer escaneo.
El software debe ser lo suficientemente inteligente como para proponer valores sensatos por defecto y empezar a trabajar con la mínima fricción posible.
Sin embargo, esa rapidez mostrando xenomorfos en el detector no basta y no debe sacrificar la posibilidad de profundizar después.
La visibilidad es un proceso que va por capas.

• Primero debemos saber qué hay.
• Después, qué hace cada cosa.
• Finalmente, querremos saber cómo de sano está cada elemento.

Un buen descubrimiento debe facilitar esa labor y no tener que borrarlo todo empezando de cero cuando queramos añadir un nivel de detalle mayor.
Por último, está la tercera cuestión de continuidad entre descubrimiento y operación.
Si el equipo que acabamos de encontrar no se integra automáticamente en el flujo de monitorización, con sus alertas y gráficas, el descubrimiento es un proceso estéril.

Por qué ver el progreso del escaneo cambia la experiencia de uso

Viajemos hasta la Enterprise porque para algo es mi obsesión. Si el capitán Picard pide un escaneo de largo alcance y Data le responde: «Lo tendré listo en tres horas, mientras tanto, mire esta pantalla en blanco», Picard se tomaría un té (Earl Grey, caliente), pero probablemente estaría bastante tenso y con cara de tonto mirando esa pantalla en la que no hay nada.
En la versión 800 LTS Aquarius de Pandora FMS, se ha atacado frontalmente el enervante problema de la «caja negra» que comentaba al principio.
Ahora, el proceso de descubrimiento es modular y transparente, dividido en fases visibles.
¿Por qué es importante esto?
Primero, por el feedback que proporciona al operador.
Saber que el sistema está en la fase de «barrido de red» y que luego pasará a la de «detección de servicios» te da una referencia temporal. Sabes dónde estás y el camino que te queda, pudiendo planear otras cosas si este todavía es largo.
Segundo, por la validación del proceso.
Si la fase de detección de equipos se completa en segundos pero no encuentra nada, podemos oler enseguida que algo falla en la configuración o en el acceso a la red, sin tener que esperar a que termine toda la tarea.
Tercero, porque elimina la sensación de incertidumbre.
La visibilidad comienza por la propia herramienta, y un sistema que te dice qué está haciendo es un sistema en el que puedes confiar.

El valor de los mapas provisionales antes de terminar el análisis

Esta es, quizás, una de las mejoras más potentes que hemos realizado para reducir el tiempo de visibilidad.
Tradicionalmente, la generación de mapas era un evento final. En Pandora FMS 800 LTS, se introduce la capacidad de visualizar un mapa de red provisional mientras el escaneo está todavía en marcha.
Esto cambia las reglas del juego por varias razones:

• Revisión temprana: De modo que podemos empezar a validar los equipos a medida que aparecen. Si estamos buscando un servidor concreto y lo vemos aparecer en el mapa a los dos minutos, ya podemos empezar a trabajar con él sin esperar a que termine el escaneo de los otros 300 equipos que no son urgentes ahora mismo.
• Priorización: El equipo de Network Operations Center (NOC) puede identificar zonas críticas de la red que ya han sido descubiertas y empezar a asignarles políticas de monitorización, por ejemplo.
• Detección rápida de anomalías: Si el mapa provisional empieza a mostrar una topología sin sentido, podemos detener el escaneo, ajustar los parámetros y relanzarlo. El ahorro de tiempo será notable.
• Comunicación entre equipos: De modo que podemos mostrar resultados parciales a otros departamentos (o a clientes), sin tener que pedirles «un poco de paciencia mientras termina el proceso».

Qué hace que un mapa de red sea realmente útil en nuestras operaciones

A lo largo de estos más de veinte años en la brecha, en Pandora hemos visto cientos de mapas topológicos que parecen obras de arte moderno.
Círculos perfectos, líneas de colores, sombras degradadas… Precioso para proyectarlos en una pantalla gigante en recepción e impresionar a las visitas (que no tengan ni idea). Pero para un técnico que tiene un problema a las tres de la mañana, eso es basura. Bonita, pero basura.
Un mapa de red útil debe ser, ante todo, claro y manejable.
La versión 800 LTS Aquarius de Pandora introduce mejoras sustanciales en este sentido. Por ejemplo, la inclusión de un minimapa y áreas delimitadas para mapas de gran escala.
Si gestionamos una infraestructura con miles de nodos, no queremos ver una nube de puntos, sino navegar por ella con fluidez, hacer zoom en las zonas críticas y, a la vez, no perder el contexto global y la perspectiva a vista de pájaro.
Pero el verdadero valor de un mapa operativo es su capacidad de actualización sin romper el trabajo previo.
Para ello, hemos introducido dos funciones clave aquí:

• Cargar nuevos nodos.
• Redistribuir elementos.

Imagina que has pasado dos horas personalizando la posición de tus servidores críticos en un mapa, a fin de que sea intuitivo para el equipo y se adapte a vuestra forma concreta de trabajar. Si mañana descubres tres equipos nuevos y el sistema, al añadirlos, te desordena todo el mapa y te obliga a empezar de cero, querrás tirar el servidor por la ventana y con razón.
Pero con Pandora 800 Aquarius esas prestaciones de cargar nodos respetan tus personalizaciones, permitiendo añadir lo nuevo sin destruir lo útil.

Cuándo aporta más valor este enfoque de visibilidad rápida que no impide la gestión

Reducir el tiempo hasta la primera visibilidad es una necesidad de negocio cuando se dan varios escenarios críticos:

• Onboarding de nuevos clientes en un MSP: En el mundo de los servicios gestionados, no tenemos una segunda oportunidad de dar una excelente primera impresión. Si podemos proporcionarle a nuestro cliente un mapa detallado de su red en la reunión inicial, demostramos un control y profesionalidad que justificarán el precio que negociemos luego. Y lo haremos basándonos en motivos, no en promesas.
• Auditorías rápidas: Ante un incidente de seguridad o una auditoría de cumplimiento, precisamos saber qué hay en la red ahora mismo. No tenemos dos días para configurar un sistema complejo.
• Entornos distribuidos y dinámicos: En redes que cambian constantemente como metamorfos, la visibilidad debe ser casi en tiempo real. Un descubrimiento lento ya nace obsoleto.
• Equipos con poco tiempo: Que en realidad, no sé si existen equipos con mucho tiempo, yo desde luego no he visto ninguno, pero hay leyendas para todo. Cualquier herramienta que nos ahorre pasos manuales y dé información útil desde el minuto dos es una bendición para la productividad.

Qué mejora Pandora FMS 800 LTS Aquarius en cuanto a descubrimiento y mapas

Toda esta filosofía sobre descubrimiento, rapidez y gestión no es teoría para quedar bien, es lo que hemos tratado de llevar a tierra con nuestra nueva release.
Por eso, las mejoras que hemos implementado se resumen en una obsesión por eliminar la fricción y hacer realidad la filosofía óptima de gestión que he planteado.
¿Y cuáles han sido esas mejoras?

• Tareas de discovery con menos fricción: Por ejemplo, simplificando la interfaz para que crear una tarea no requiera un máster en ingeniería. El sistema es ahora más inteligente y ofrece más información por defecto.
• Fases visibles: Para abrir esa caja negra y arrojar luz, viendo el progreso real y sabiendo en qué etapa se encuentra el escaneo.v
• Mapas provisionales: La capacidad de ver los hallazgos en un mapa mientras se descubren es un salto cualitativo en la agilidad operativa.
• Mejoras en la gestión de nodos: Las nuevas funciones del menú contextual para cargar nodos y redibujar posiciones permiten mantener los mapas vivos y organizados sin un esfuerzo manual constante.
• Marketplace integrado: Los paquetes de discovery (.disco) se gestionan de forma centralizada y ligera, permitiendo que el sistema crezca modularmente solo con lo que necesitas, sin añadir peso a esa gestión ágil y al avance por pasillos siniestros plagados de bichos.

Nada más común que perdernos en métricas de rendimiento, logs infinitos e informes de disponibilidad, olvidando que la base de todo es la visión.
Si no podemos observar nuestra infraestructura como Saruman con su Palantir, no podemos entenderla.
Y si no la entendemos, no la gestionaremos, solo reaccionaremos a sombras y sonidos sin saber qué son exactamente… O descubriéndolo cuando Alien ya nos está babeando.
Por eso el verdadero valor de una herramienta como Pandora FMS 800 LTS Aquarius no es solo su potencia para recolectar datos, sino también su capacidad para entregarlos con contexto y rapidez.
El objetivo del descubrimiento de red es reducir el tiempo que transcurre desde que un dispositivo se conecta hasta que un humano puede tomar una decisión informada sobre él. Si lo único disponible es esa lista de compra de la que hablaba al principio, solo tenemos otra pantalla que no sirve para casi nada.
Pero con el discovery de la nueva versión de Pandora sabremos dónde se esconde cada xenomorfo, qué está haciendo y por dónde acecha el posible peligro. De ese modo, lo atajaremos de manera anticipada, en lugar de correr como pollos sin cabeza apagando incendios y cerrando brechas.