Volver a la wiki

Concepto: Calibración del motor (signal vs. noise)

Descripción

El motor de integridad F1 detecta divergencias entre plano y realidad (Device ↔ DeviceProfile). Pero su precisión depende de heurísticas (IP matching, MAC resolution, freshness windows) que pueden ser imperfectas.

La calibración es el proceso de medir qué proporción de detecciones son reales (SEÑAL) vs. errores del detector (RUIDO), y ajustar heurísticas hasta que signal % sea > 85%.

El problema: Precisión limitada

Sin calibración

Un motor sin tuning puede:

  1. Falsos positivos (noise):

    • Plan: “Device A en U10” (IP 10.0.1.5).
    • Red: DHCP reassignó 10.0.1.5 a un printer (temporal).
    • Motor: “IP conflict!” (falso — el printer es diferente, el Device sigue siendo el mismo).

  2. Falsos negativos (missed signal):

    • Device realmente se retiró del rack.
    • Red: Última vez visto hace 8 días.
    • Motor: “stale, no puedo confirmar” (correcto, pero ¿debería bajar fresh_days de 7 a 5?).

  3. Tipo de cambio no identificado:

    • Device A y Device B intercambiaron posiciones (U10 ↔ U12).
    • Matching heurística asume “mismo nombre = mismo device” (falla).
    • Motor: “No ve cambio, todo ok” (missed).

Resultado: Si el usuario ve muchos falsos en /integrity/, desconfía y abandona la feature.

La solución: Feedback humano

Veredictos de la cola

Cuando el usuario ve un hallazgo en /integrity/, elige:

┌────────────────────────────────────────────────┐
│ Device 'Switch-A' stale en Rack-3 (U10)        │
│ Última vez visto hace 9 días                   │
├────────────────────────────────────────────────┤
│ [Plan updated] [Real change] [False alarm]     │
└────────────────────────────────────────────────┘

El datapoint

Cada veredicto alimenta la métrica de calibración:

signal = count(plan_updated) + count(real_change)
noise = count(false_alarm)
total = signal + noise
signal_pct = 100 * signal / total

Casos de uso

Escenario 1: Motor bien calibrado

Beta org (CreaRack interna) corre el motor 6 semanas:

Semana 1-2: 50 veredictos → 40 señal (80%), 10 ruido.
Semana 3-4: 100 veredictos → 88 señal (88%), 12 ruido.
Semana 5-6: 150 veredictos → 128 señal (85%), 22 ruido.

Estadísticas: signal_pct = 85% sostenido. ✅ Go to production.

Acción: Activar módulo en Plan 4 (Professional) o superior. Clientes ven /integrity/ en v1.61.0.

Escenario 2: Motor sobre-sensible

Semana 1-2: 30 veredictos → 18 señal (60%), 12 ruido.

Demasiado ruido → Heurísticas muy estrictas.

Análisis: Muchos IP_CONFLICT falsos por DHCP. FreshDays muy bajo.

Acción: Tuning.

# racks/services/integrity.py
DEFAULT_FRESH_DAYS = 7  # → 14 (DHCP TTL típico)

# O mejorar matching heurística (resolver por MAC, no solo IP).

Resultado: Retest 2 semanas → signal_pct → 80%+ → Go.

Escenario 3: Motor insuficiente

Semana 1-6: 200 veredictos → 170 señal (85%), pero 90% son "plan_updated"
            (clientes actualizando planos) vs. 10% "real_change" (verdaderos cambios).

Motor es preciso (85%) pero no detecta CAMBIOS REALES, solo inconsistencias estáticas.

Implicación: Feature es útil para “auditar plano”, no para “monitorear cambios”.

Acción: Reframe marketing. O conectar con Change Management subsystem (cuando RAID o CMDB reporta cambio, correlacionar con hallazgo).

Cómo los veredictos cambian el cálculo

Sin veredictos

fidelity_pct = 100 * matched_alive / (total - unobservable)
            = 100 * 198 / (200 - 2)
            = 99.0%

Con veredictos (false alarm = cuarentena)

Usuario hace click false_alarm en device A (que estaba en stale):

# Antes: Device A era "stale" → contaba como hallazgo
counts["matched_stale"] = 1
counts["matched_alive"] = 198

# IntegrityAck creado:
# verdict="false_alarm", muted_until=now+30d

# Después (en siguiente compute_integrity):
acks = _load_active_acks(org, now)
ack_A = acks.get(("device", device_A_id, "matched_stale"))
if ack_A and ack_A.verdict == "false_alarm":
    counts["muted"] = 1  # Device A entra en cuarentena
    counts["matched_stale"] = 0  # No lo contamos

fidelity_pct = 100 * matched_alive / (total - unobservable - muted)
            = 100 * 198 / (200 - 2 - 1)
            = 99.5%

Efecto: Device A falso positivo no castiga fidelity. La métrica permanece honesta.

Duración: 30 días. Pasado ese tiempo, si el motor vuelve a verlo como stale, reaparece en cola (el usuario tuvo oportunidad de corregir plano; si no lo hizo, es real).

Integración con el gate #202

Gate #202 es la decisión de Go/NoGo: ¿es la feature lista para clientes?

Métricas:

gate_stats(org) = {
    "signal": 128,           # plan_updated + real_change
    "noise": 22,             # false_alarm
    "total": 150,
    "signal_pct": 85.3
}

Criterio: signal_pct > 85% sostenido 2+ semanas.

Variantes por tier (futuro):

Filosofía: Por qué false_alarm NO castiga

Muchos sistemas penalizan todos los hallazgos por igual. Pero en CreaRack:

Falso positivo = error del sensor, no del plano.

Si Device A muestra stale y el usuario confirma “falso, Device A está bien”, no es problema del usuario. Es problema del motor (heurística de matching falló, DHCP reasignó IP, etc.).

Consecuencia: No debería penalizar fidelity el usuario que operó correctamente (manttuvo plano actualizado).

Analogía: Sensor de temperatura dice “99°C” pero termómetro manual dice “37°C”. El paciente está sano; el sensor es incorrecto. No castigar al paciente por tener un sensor roto.

Mejora iterativa (futuro)

Con suficientes veredictos, podemos:

  1. Análisis de distribuciones: ¿Qué tipos de dispositivo tienen más false alarms? (Printers, IoT, switches temporales).
  2. Machine learning: Entrenar modelo predictivo “¿es falso?” basado en {device_type, last_seen_age, match_confidence, …}.
  3. Descubrimiento de anti-patterns: “Cada 2do lunes, DHCP causa 5 IP_CONFLICT. Ignorar ese día”.
  4. Ajuste automático: fresh_days se modula por device_type (printers: 14 días, servers: 7 días).

Véase también

Subir