ITSM — SLA, Escalación y Runbooks

Qué es

Capa de gestión de servicios de TI que envuelve cada AIInsight generado por CNS. Proporciona temporizadores de SLA, canales de notificación, escalación automática por niveles, agrupación de incidentes correlacionados, ventanas de mantenimiento programadas, knowledge base de problemas conocidos y biblioteca de runbooks. Organizado en 11 fases implementadas incrementalmente sobre AIInsight.

Por qué existe

Los insights en bruto son insuficientes para operar una red en producción. Hace falta saber si alguien los atiende, cuándo escalar, qué dispositivos están en mantenimiento y cómo resolverlos de forma reproducible. Sin ITSM, cada incidente requeriría intervención manual para urgencia, destinatario y procedimiento. El módulo automatiza con reglas configurables por organización y nivel de riesgo.

Componentes

SLAPolicy (fase 1): define ack_minutes y resolve_minutes por nivel. Defaults: HIGH 15/60, MEDIUM 30/240, LOW 60/480. sla_service.calculate_deadlines() estampa sla_ack_deadline/sla_resolve_deadline en el insight. Tarea Huey cada minuto ejecuta check_sla_breaches() con bulk-update y marca flags sla_*_breached.

NotificationChannel (fase 2): 4 tipos — webhook, email, slack, teams — config arbitraria en JSONField. Filtrado por risk_levels. Registra envíos en NotificationLog con estado sent/failed/retrying.

EscalationPolicy / EscalationLevel (fase 3): política multi-nivel por riesgo. Cada nivel con delay_minutes y canal. escalation_service.check_escalations() cada 2 min; busca insights pending/executing y promueve si minutes_since_creation >= level.delay_minutes para el primer nivel no alcanzado. Al escalar, actualiza insight.escalation_level, crea AIInsightAuditLog y despacha vía notification_service.dispatch_notification().

IncidentGroup (fase 4): agrupa insights con misma causa raíz. correlation_service.correlate_new_insight() aplica 3 reglas: mismo target + mismo anomaly_trigger en 30 min, misma subred + mismo root_cause en 15 min, o 3+ insights con mismo root_cause en 10 min. Endpoint POST /sentinel/itsm/groups/{id}/acknowledge-all para bloque.

MaintenanceWindow (fase 5): suprime creación de insights y/o notificaciones en intervalos planificados. Aplica a toda la org o subset via M2M. sla_service.is_in_maintenance_window(target) verifica en tiempo real.

Runbook (fase 10): procedimiento de remediación con pasos JSON ([{"step": 1, "action": "...", "commands": [...]}]), filtrable por applicable_triggers y vendor. POST /sentinel/itsm/runbooks/{id}/apply/{insight_id} asigna y incrementa usage_count.

KnownIssue (fase 7, knowledge base): problema documentado con resolución y match_keywords para auto-match. correlation_service.match_known_issue() tokeniza summary + root_cause del insight y puntúa coincidencias; si >2 keywords, vincula el KI y actualiza occurrence_count, last_seen. Creación directa desde insight: POST /sentinel/itsm/known-issues/from-insight/{insight_id}.

RecurringPattern (fase 11): patrón recurrente con tipo (daily/weekly/hourly), confianza 0-1 y timestamps. Expuesto en GET /sentinel/itsm/patterns.

Flujos

Creación insight → SLA stamped: sla_service.calculate_deadlines() busca SLAPolicy para (organization, risk_level) y añade plazos. Si target en MaintenanceWindow con suppress_insights=True, no se crea.

Breach detectado: check_sla_breaches (cada minuto) bulk-update flags breach. check_escalations (cada 2 min) evalúa delay_minutes del siguiente EscalationLevel; si supera, escalate_insight() persiste nivel, registra audit log, envía notificación.

Correlación automática: cada insight pasa por correlate_new_insight(), se añade a grupo existente o crea nuevo si 3+ incidentes con misma causa en 10 min. Knowledge base se consulta en paralelo para vincular KnownIssue con resolución inmediata.

Resolución: operador acknowledge (acknowledged_at), aplica runbook si procede, cierra. Métricas MTTA/MTTR via get_sla_metrics() como medias sobre acknowledged_at - created_at y resolved_at - created_at, con tasa cumplimiento SLA.

Related

• entity--monitoring--model--slapolicy
• entity--monitoring--model--aiinsight
• concept--monitoring--cns

Véase también

• [[entity—monitoring—model—slapolicy]]
• [[entity—monitoring—model—aiinsight]]
• [[concept—monitoring—cns]]