Saltar al contenido principal

Visor de Incidentes, buenas prácticas y puesta en marcha

Visor de Incidentes​

El Visor de Incidentes permite observar la relación entre eventos detectados por NetMonitor y plataformas externas de gestión de incidentes.

Información disponible por incidente:

  • Plataforma externa asociada
  • Ticket ID
  • Activos afectados
  • Estado del incidente
  • Marca de tiempo
  • Evolución del incidente

Workflow típico de incidentes​

  1. Detección — Evento detectado por NetMonitor y creación de ticket externo.
  2. Confirmación — Confirmación del ticket ID y actualización con información del evento.
  3. Toma de caso — Confirmación de lectura por operador y actualización del ticket con responsable asignado.
  4. Normalización — Normalización del evento y actualización del ticket como completado, cancelado o pendiente.
  5. Cierre — Cierre definitivo desde la plataforma externa por el responsable operativo.
Recomendación

En muchos casos es recomendable que NetMonitor no cierre automáticamente los tickets externos, sino que actualice el estado para que un responsable operativo realice el cierre dentro de la plataforma correspondiente.

[Imagen sugerida: visor de incidentes con ticket externo asociado]

Buenas prácticas​

Reglas de notificación​

  • Crear reglas específicas, no excesivamente amplias
  • Usar severidad, categoría y grupo como criterios principales
  • Separar eventos informativos de eventos críticos
  • Definir canales por equipo operativo
  • Configurar rangos horarios cuando corresponda
  • Usar canales distintos para horario laboral y guardia
  • Probar cada canal antes de asociarlo a reglas críticas
  • Evitar duplicidad innecesaria de notificaciones
  • Documentar el propósito de cada regla

Canales​

  • Crear canales por función operativa
  • Evitar canales genéricos que reciban todos los eventos
  • Usar nombres claros y descriptivos
  • Probar el canal luego de cada modificación
  • Separar canales de horario laboral y guardia
  • Usar Teams o Telegram para eventos que requieren reacción rápida
  • Usar correo para reportes o eventos de menor urgencia
  • Revisar periódicamente destinatarios obsoletos

Alarmas​

  • Priorizar eventos de disponibilidad
  • Confirmar lectura cuando un operador toma el caso
  • Usar notas para documentar causa y resolución
  • Revisar activos relacionados antes de escalar
  • Validar si existe causa raíz común
  • Evitar tratar síntomas independientes si comparten causa
  • Verificar si el evento tiene ticket externo asociado
  • Registrar acciones realizadas

Alertas​

  • Analizar tendencia antes de escalar
  • Validar si el umbral está correctamente configurado
  • Revisar si el comportamiento es recurrente
  • Identificar horarios de mayor carga
  • Ajustar umbrales cuando existan falsos positivos
  • Priorizar alertas que puedan transformarse en indisponibilidad
  • Revisar capacidad cuando existan alertas recurrentes
  • Utilizar la información para planificación de capacidad

TRAPs​

  • Limitar el envío de TRAPs innecesarios en los activos
  • Configurar solo los OIDs relevantes para operación
  • Ajustar la severidad según impacto real
  • Personalizar descripciones para que sean comprensibles
  • Utilizar absorción para eventos repetitivos
  • Guardar manualmente los eventos relevantes
  • Clasificar como críticos solo los que requieren prioridad
  • Revisar periódicamente los TRAPs más frecuentes

Uso operativo recomendado​

Flujo de trabajo diario para equipos de operación y supervisión:

  • Revisar diariamente el Gestor de Alarmas
  • Priorizar eventos críticos o de disponibilidad
  • Confirmar lectura de los eventos tomados
  • Verificar activos y emplazamientos afectados
  • Consultar historial y eventos similares
  • Analizar si existe causa raíz identificable
  • Adjuntar notas cuando el evento requiera documentación
  • Actualizar o revisar tickets externos asociados
  • Verificar normalización del evento
  • Revisar recurrencias para detectar problemas repetitivos
  • Ajustar reglas o canales si se detectan desvíos operativos
  • Revisar periódicamente TRAPs frecuentes

Casos de uso frecuentes​

Caída de activo de red​

  1. NetMonitor detecta que el activo no responde
  2. Se activa una alarma de disponibilidad con ID único
  3. Se notifica al canal correspondiente
  4. El operador confirma lectura y revisa activos relacionados
  5. Se documenta el tratamiento mediante notas
  6. El evento se normaliza cuando el activo vuelve a responder
  7. Se registra el cierre o actualización del incidente

CPU alta en firewall​

  1. NetMonitor detecta CPU por encima del umbral configurado
  2. Se emite una alerta y se notifica al equipo técnico
  3. El operador revisa tráfico, sesiones y reglas del firewall
  4. Se documenta el análisis en una nota
  5. Si el evento se repite, se evalúa capacity planning o ajuste de configuración

Corte de energía en sitio​

  1. NetMonitor detecta falla de alimentación eléctrica
  2. Se activa una alarma y se notifica al grupo de mantenimiento
  3. Si el activo es crítico, se ejecuta una acción adicional
  4. Se puede abrir un ticket externo automáticamente
  5. Se realiza seguimiento hasta normalización
  6. Se documenta el evento con causa y acciones tomadas

TRAP de cambio de configuración​

  1. Un activo envía un TRAP SNMP ante un cambio de configuración
  2. NetMonitor registra el evento e identifica el OID
  3. Se muestra descripción desde MIB o configuración local
  4. Según severidad, el evento puede requerir tratamiento
  5. El operador puede marcarlo como leído o guardarlo
  6. Si el cambio se relaciona con un incidente, se documenta en una nota

Evento recurrente en un mismo sitio​

  1. El operador detecta repetición de alarmas en el mismo emplazamiento
  2. Consulta estadísticas y eventos similares con filtro por emplazamiento
  3. Revisa notas anteriores relacionadas
  4. Identifica patrón horario o causa común
  5. Documenta hallazgos y propone acción correctiva

Puesta en marcha recomendada​

Checklist para configurar el módulo de Notificaciones en una nueva implementación:

  • Revisar activos cargados en Asset Manager
  • Definir SLA por tipo de activo
  • Marcar activos críticos
  • Revisar interfaces declaradas como enlaces
  • Definir grupos operativos
  • Crear canales de notificación
  • Probar cada canal de notificación
  • Crear reglas iniciales de notificación
  • Validar severidades configuradas
  • Revisar firmas activas
  • Ajustar umbrales según operación real
  • Habilitar recordatorios donde corresponda
  • Definir responsables de supervisión
  • Documentar procedimientos de tratamiento
  • Revisar resultados durante los primeros días de operación

Referencia cruzada​