En sencillo
CreaRack dibuja el plano de los racks; el programa que instalamos en la red del cliente (el Agente) ve qué equipos hay funcionando de verdad. La semana pasada construimos la Barra de Integridad: una nota de 0 a 100 por rack que dice cuánto se parece el plano a la realidad, y que baja sola cuando algo cambia en la red y nadie actualiza el dibujo. Cuando el sistema confirma que un cambio es real, abre una incidencia como las de red de toda la vida, con una explicación escrita en claro ("parece que sustituyeron el servidor del rack 3, ¿actualizo el plano?"). Al resolver la incidencia, el plano y la nota se ponen al día solos. Todo esto está apagado para los clientes: solo lo vemos nosotros, mientras medimos durante semanas si el detector acierta. Si en una red ajena acierta el 80% de las veces o más, se enciende y se vende; si no, se rediseña o se descarta. En este documento os cuento cómo funciona, y de paso el CNS y el ITSM — la parte de CreaRack que vigila la red y gestiona las incidencias — porque la novedad se apoya en ellos.
Edu decidió el 17 de julio construir la Barra entera en la ventana de Fable, con una condición: todo nace apagado — nada se enseña a clientes hasta pasar el examen de aciertos. Ese compromiso está cumplido: las tres fases de construcción están hechas, probadas y en producción.
| Fase | Qué es | Versión | Estado |
|---|---|---|---|
| F1 · Motor | El cruce plano↔realidad: clasifica cada equipo y calcula las dos notas. Foto automática cada madrugada (04:15). | v1.59.0 | ✔ En producción |
| F2 · Radar interno | La página Integrity: notas, histórico y la cola de revisión con evidencia y 3 veredictos. | v1.60.0 | ✔ En producción |
| F3 · CNS/ITSM | Un cambio confirmado como real abre una incidencia con explicación de la IA; resolverla re-verifica el plano. | v1.61.0 | ✔ En producción |
| Pulido | Textos en inglés + 4 arreglos de monitorización cazados al verificar el sensor (detalle en §7). | v1.60.1 · v1.61.1→.5 | ✔ En producción |
| F4 · Cara externa | Racha de días en verde por sitio + bloque de diligencia en el Project Report (lo que vería el cliente final). | — | ◌ Aparcada a propósito |
| Calibración | Foto diaria en la red de la oficina + veredictos nuestros para afinar umbrales. | — | ▶ En marcha |
| Validación | El mismo examen en una red ajena (design partner), contra el umbral pre-declarado. | — | ◷ Septiembre-octubre |
Es decir: el plan está concluido en todo lo que dependía de construir. F4 no es un retraso — se decidió dejarla para después del feedback de los MSP en septiembre, porque es la pieza con más papeletas de cambiar. Y la activación comercial espera al examen del §3, también por diseño.
La documentación de racks tiene un problema universal: se pudre en silencio. Alguien sustituye un servidor, apaga un switch o mueve un equipo, no actualiza el plano, y seis meses después el plano miente y nadie sabe cuánto. La Barra ataca exactamente eso: como el Agente ve la red de verdad, puede comparar continuamente "lo que el plano dice" con "lo que la red demuestra".
Un solo número mentiría, así que separamos dos preguntas distintas:
* Valores de ejemplo para ilustrar la idea — los reales de cada organización los calcula el motor cada madrugada.
Cada madrugada a las 04:15, el motor recorre todos los racks y clasifica cada equipo del plano (y también detecta lo contrario: equipos vivos en la red que no están en ningún plano):
El plano dice que está y la red confirma que vive. El caso feliz — suma nota.
Está en el plano pero lleva días sin dar señales de vida. Candidato a drift: ¿lo retiraron? ¿lo apagaron?
Dos equipos del plano comparten la misma IP de gestión. Huele a sustitución, mudanza o rack clonado.
El sensor no puede verlo (sin IP, sin perfil, sin monitorización). Va a cuarentena: no puntúa ni castiga.
Lo inverso: un equipo vivo en la red que no aparece en ningún plano. Se reporta a nivel de organización — "tienes cosas funcionando que nadie ha documentado".
La página /integrity/ (módulo SaaS integrity, hoy activado solo en nuestra
organización) enseña las dos notas, el histórico y lo importante: la cola de reconciliación. Cada aviso
llega con su evidencia al lado — qué vio el sensor y cuándo — y el técnico dicta uno de tres veredictos,
botones solo-texto como manda la casa:
"Era verdad, ya he corregido el plano." La nota sube en el próximo cálculo.
"Es un cambio real de la red." Abre incidencia con explicación de la IA (§4).
"Falsa alarma." El equipo pasa a cuarentena silenciada y deja de molestar.
Detalle importante: cada veredicto alimenta automáticamente el contador señal/ruido del examen del §3. Usar el producto ES calibrarlo — no hay que hacer trabajo extra para medir si acierta.
El consejo del roast (17-07) fue claro: un score de integridad que se equivoca mata la confianza en el producto entero. Así que declaramos el umbral por escrito antes de mirar ningún dato, para que nadie pueda racionalizar después:
Aquí está la jugada elegante de la fase 3: en vez de inventar un sistema nuevo de "tareas de reconciliación", la cola de la Barra desemboca en el sistema de incidencias que ya existe (el CNS/ITSM del §5). Cuando un técnico dicta "Real change", pasa esto:
CreaRack Network Sentinel (CNS) es la parte de CreaRack que vigila la red en tiempo real y, cuando detecta una anomalía (pérdida de paquetes, latencia disparada, errores en un puerto, desconexiones WiFi en cadena…), no lanza una alarma pelada: genera un Insight — un diagnóstico completo con causa raíz, nivel de riesgo, y comandos concretos para arreglarlo. Está en tres páginas, cada una con lo suyo:
Electrónica de red: switches, routers, firewalls y targets manuales.
Puntos de acceso WiFi y sus clientes.
Sistemas de alimentación ininterrumpida.
| Campo | Qué te dice |
|---|---|
| Summary | El diagnóstico en una frase: qué está pasando. |
| Root Cause | Por qué está pasando — la causa técnica que ha identificado la IA. |
| Confidence | 0-100%: cuánto confía la IA en su propio diagnóstico. Por encima de 80 es fiable; por debajo de 50, revisa a mano. |
| Risk Level | HIGH crítico · MEDIUM degradación · LOW informativo. Cada uno con su color en toasts y en el punto pulsante del sidebar. |
| Telemetry | Los datos de monitorización que dispararon la alerta (valores SNMP, latencias…). |
| Commands | Lista numerada de comandos SSH que el sistema puede ejecutar en el equipo — con su Rollback al lado para deshacer si algo sale mal. |
| Case | Número de caso (CNS-000127) para buscarlo, citarlo y exportarlo. |
Cada insight tiene un botón Explain para hacerle preguntas a la IA con todo el contexto del caso cargado (telemetría, diagnóstico, historial): "¿esto puede esperar a mañana?", "¿qué riesgo tiene aplicar estos comandos?", "¿hay una alternativa menos invasiva?". Las conversaciones se guardan en el insight — si otro operador lo abre en el siguiente turno, ve todo lo hablado. Y con Revise puedes devolverle feedback para que afine el diagnóstico.
Este criterio de filtrado señal/ruido es exactamente el que la Barra de Integridad aprovecha: el CNS ya sabía distinguir "molestar" de "informar" antes de que le enchufáramos el drift de los planos.
El CNS detecta y diagnostica; el ITSM pone la disciplina de gestión encima: tiempos de respuesta, avisos, escalado y conocimiento acumulado. Es la pestaña ITSM Settings, y su configuración vale para toda la organización.
| Riesgo | Acknowledgar en… | Resolver en… |
|---|---|---|
| HIGH | 15 min | 60 min |
| MEDIUM | 30 min | 4 h |
| LOW | 60 min | 8 h |
Valores por defecto, personalizables por organización. Si se exceden, el insight se marca "SLA Breached" y arranca el escalado.
Email, Slack, Microsoft Teams o webhook (para enchufar ServiceNow, PagerDuty…). Cada canal filtrable por riesgo — p. ej. solo HIGH al móvil del jefe. Botón Test para verificar antes de fiarte.
Qué pasa si nadie responde: nivel 1 avisa al canal del equipo, nivel 2 al responsable de turno, nivel 3 a dirección técnica. Cada nivel con su retraso configurable.
"Sábado 02:00-04:00, firmware de switches": durante la ventana no se crean insights ni se notifica. Adiós a los falsos positivos de los mantenimientos planificados.
Problemas recurrentes documentados ("el AP de la puerta 2 pierde clientes los martes por el microondas") y procedimientos paso a paso. Cuando un insight nuevo coincide, aparece el badge con el enlace — cualquier operador sabe qué hacer.
Al encender el sensor de verdad para calibrar, verificamos el efecto — no la señal — y salieron a la luz cuatro bugs encadenados de la monitorización que llevaban tiempo escondidos. Los cuatro quedaron arreglados y desplegados el mismo día:
| Versión | Qué estaba pasando | Arreglo |
|---|---|---|
| v1.61.1 | Las métricas que enviaba el Agente en bloque no contaban como "prueba de vida" — el motor era ciego a la monitorización. | El ingest bulk ya escribe la fecha del último chequeo. |
| v1.61.2 | Al reconectarse, el Agente re-enviaba 24 h de historia y esos replays machacaban el estado en vivo: 130 de 131 equipos aparecían caídos con la LAN viva. | Guard de frescura: un lote viejo ya no puede pisar el estado actual. |
| v1.61.3 | La lista de incidencias CNS salía en orden inverso — las nuevas quedaban en la última página (bug pre-existente que destapó el click-test). | Orden por fecha restaurado. |
| v1.61.4/.5 | Sin control del orden en la tabla y la paginación se salía de pantalla al 100% de zoom. | Botón Newest/Oldest + 22 filas por página. |
Moraleja que nos gusta contar: el motor de integridad se ganó el sueldo antes de estrenarse — su primera medición real detectó que el propio sensor estaba dormido, y de la verificación salieron cuatro arreglos que mejoran la monitorización para todo el mundo, tenga o no la Barra activada.
| Pendiente | Dueño / cuándo | Naturaleza |
|---|---|---|
| Gate señal/ruido (task #202): acumular veredictos y validar en red ajena contra el umbral del §3. | Edu · sept-oct | Decisión de activación — corre solo mientras usamos la página. |
| F4 cara externa (racha por sitio + Project Report). | tras feedback MSP | Aparcada a propósito: es la pieza con más papeletas de cambiar. |
| Task #203: que el Agente no re-envíe 24 h de historia en cada reconexión (el servidor ya está protegido; es ahorro de ancho de banda) + mirar por qué su conexión parpadea. | Edu · próximo .exe | Mejora del Agente, va con la tanda de release pendiente. |
| Hueco anotado: el campo "resuelto el" de las incidencias no lo rellena ningún flujo (las métricas de tiempos de resolución lo leen). | sin fecha | Decisión aparte, documentada — no bloquea nada. |
Fuentes: plan vivo barra-integridad/PLAN_BARRA_INTEGRIDAD.md · STATE.md s227-s229 ·
guía wiki crearack-tech--guides--cns-itsm-user-guide · tasks #202/#203 del Gestor · informes del
17-07 en /informes/{storm,roast}/barra-integridad-rack-2026-07-17.html. Versión del producto al
escribir: v1.61.5.