Decisión
Reconocer (ACK) y aplicar un fix con éxito escriben resolved_at; la expiración por timeout NO.
Decidido con Edu el 14-08-2026 durante la sesión de cierre de task #222.
Problema que resolvía
El campo AIInsight.resolved_at existía desde la Fase 1 (junio 2026) pero ningún código lo escribía (0 de 8.663 insights en PROD). Consecuencias:
- MTTR = 0 estructuralmente → las tarjetas de “tiempo medio de resolución” mentían.
- Tasa de resolución = 0% → aunque miles de insights llevaban meses reconocidos o arreglados.
- SLA Compliance rojo perpetuo → 8.515 de 8.663 insights marcados como “incumplimiento” automáticamente porque el sistema nunca veía un cierre real.
Semántica elegida
El producto no tiene un acto de cierre independiente. La apertura ocurre con el diagnóstico; el cierre ocurre con:
| Evento | Escribe resolved_at | Razonamiento |
|---|---|---|
| ACK (reconocimiento manual) | ✅ | Intervención humana → resolución iniciada. El ticket está cerrado para el usuario. |
| Auto-resolución (conectividad recuperada) | ✅ | Sistema detecta recuperación → equivalente a ACK automático. |
| Fix aplicado con éxito | ✅ | Cambio confirmado como funcional → issue resuelto. |
| Fix aplicado y FALLA | ❌ | Intento fallido. Queda abierto hasta ACK o nueva tentativa. |
| Expiración (timeout) | ❌ | Abandono, no resolución. Nadie lo atendió. |
Implicación para métricas
Con esta semántica:
- MTTR = (resolved_at - created_at) ahora mide tiempo real de intervención, no 0.
- Tasa de resolución =
COUNT(resolved_at != NULL) / COUNT(*)distingue atendidos de abandonados.- En histórico: 8.513 resueltos (reconocimiento/aplicación), 150 abandonados (expiración), algunos aún abiertos.
- SLA Compliance = “¿se cerró antes del deadline?” Ahora tiene datos reales.
Por qué no caducar
Caducar = “pasó el tiempo de espera, nadie lo miró, se marca como expirado”. No es intervención.
Si contáramos expiración como resolución:
- Métricas dirían “resolvimos el problema en 4 horas” cuando en realidad “nadie lo vio”.
- La tasa de resolución sería 100% aunque la mitad de incidentes se abandonen.
- El Compliance de SLA sería falso: “el 95% se resolvió dentro del deadline” cuando la mitad se fue por timeout.
Conclusión: expiración es observabilidad (cuántos se ignoran) pero no resolución.
Nota: revierte sa4 M13
El criterio anterior (sa4 del Milestone 13, agosto) decía “acknowledgement ≠ resolution”. Esto se revierte: en el contexto de un producto SaaS sin segunda capa de “cierre administrativo”, reconocer = cerrar el ticket para el usuario. Eso sí cuenta.
Implementación
Véase [[feature—monitoring—itsm-ciclo-cierre]] para detalles de cómo se escribe resolved_at en cada caso.
Véase también
- [[feature—monitoring—itsm-ciclo-cierre]]
- [[entity—monitoring—service—close-group-if-done]]
- [[concept—saas—multi-tenancy]]
Referenciado desde
- Ciclo de cierre ITSM — resolved_at con escritor y auto-resolución de grupos
- Cola de auditoría C (task #286): ITSM, SLA, notificaciones y tareas de fondo — marcar y notificar en una sola transacción, ventanas de mantenimiento con fail-open, secretos en el log
- Los diagnósticos dicen quién los firma — proveedor de IA visible y arreglo del gráfico MTTA/MTTR
- Migración 0029 — Backfill del ciclo de cierre ITSM: resolved_at, grupos, patrones
- Servicio close_group_if_done — Auto-cierre de grupos cuando no quedan insights abiertos
- Servicio reopen_group — Reapertura de grupos resueltos por correlación nueva