Existe una paradoja en el monitoreo: cuanto mejor es, más ruido hace durante un mantenimiento programado. Usted derriba un servicio a propósito a las 22:00 y, a las 22:01, llegan decenas de alertas como si el centro de datos estuviera en llamas. El Downtime Manager del Portal Nyverra ITSM existe para silenciar exactamente ese ruido.

Esta guía explica qué hace el módulo, cómo se integra con la gestión de cambios y cómo operar ventanas de mantenimiento sin enmascarar fallos reales.

Interfaz del módulo en el Portal Nyverra ITSM.

Qué es una ventana de downtime

Una ventana de downtime (o ventana de mantenimiento) es un período declarado en el que un servicio o activo estará indisponible de forma planificada. Durante la ventana, el monitoreo recibe la instrucción de suprimir las alertas del alcance definido — evitando incidentes falsos, tickets innecesarios y fatiga de alertas en el NOC.

Por qué es importante

• Reduce el ruido: el equipo no se ve interrumpido por alertas esperadas.
• Evita incidentes fantasma: los tickets abiertos automáticamente por algo planificado consumen SLA y atención.
• Mantiene la confianza en el monitoreo: una alerta que “siempre se dispara durante el mantenimiento” pierde credibilidad.
• Ofrece trazabilidad: queda registrado qué estaba en mantenimiento, cuándo y por qué.

Quién lo usa

Perfil	Uso típico
Infraestructura / NOC	Programar y dar seguimiento a las ventanas de mantenimiento
Gestor de cambios	Vincular el downtime al cambio correspondiente
Administrador	Configurar la integración de monitoreo (Zabbix)

Las funcionalidades del módulo

Ventanas de mantenimiento

Creación de ventanas con inicio y fin, alcance y motivo. Es el núcleo del módulo: declarar “este servicio/activo está en mantenimiento de X a Y”.

Supresión de alertas

Mientras la ventana está activa, las alertas de los hosts/ítems seleccionados se suprimen en el monitoreo — integrándose con Zabbix.

Lookup de hosts e ítems

Para definir el alcance sin memorizar IDs, el módulo ofrece lookup de hosts y de los ítems de cada host, lo que facilita seleccionar exactamente qué entra en la ventana.

Métricas y cancelación

Hay métricas de downtimes y la posibilidad de cancelar una ventana — útil cuando el mantenimiento se pospone o se completa antes de lo previsto.

Cómo usar: paso a paso

1. Planifique el mantenimiento (idealmente junto con un cambio).
2. Cree el downtime indicando la ventana (fechas/horas) y el motivo.
3. Seleccione los hosts/ítems afectados mediante lookup.
4. Vincule al cambio correspondiente, para trazabilidad.
5. Al finalizar, cierre (o cancele) la ventana y confirme que el monitoreo volvió a la normalidad.

Reglas de negocio

Regla	Explicación
Fechas locales	Las ventanas usan fechas/horas locales (sin offset) — siga el contrato de fechas del sistema.
Alcance preciso	Suprima solo lo que entra en el mantenimiento; un alcance excesivo oculta fallos reales.
Vínculo con cambio	Recomendado, para que la supresión no se convierta en un “agujero” sin explicación.
Cancelación	Si el mantenimiento no se lleva a cabo, cancele la ventana para restablecer las alertas.

Buenas prácticas

• Siempre vincule downtime ↔ cambio: la ventana pasa a tener una justificación registrada.
• Use ventanas cortas y bien definidas — no deje la supresión “abierta” durante horas más de lo necesario.
• Revise, después de la ventana, si alguna alerta real quedó oculta; ajuste el alcance si es necesario.
• Avise a los interesados antes de la ventana — la comunicación evita tickets “por precaución”.

Errores comunes

Situación	Qué hacer
Olvidar cerrar la ventana	Las alertas permanecen suprimidas más de lo necesario. Programe el cierre.
Alcance demasiado amplio	Puede ocultar fallos de otro servicio. Seleccione solo lo que está en mantenimiento.
Supresión sin vínculo	Queda sin justificación; asóciela a un cambio.

Preguntas frecuentes

¿El downtime sustituye al cambio?
No. El cambio es la alteración planificada; el downtime es la ventana de supresión de alertas asociada a él.

¿La ventana afecta el SLA de los tickets?
El downtime actúa en el monitoreo; las reglas de SLA de los tickets se gestionan en el módulo de Tickets/Configuración.

¿Cómo selecciono los hosts correctos?
Use el lookup de hosts e ítems para definir el alcance exacto.

Automatice mediante API

El módulo se expone mediante API (/api/downtimes, /downtimes/{id}/cancelar, /downtimes/metrics, /downtimes/lookup/hosts). Consulte la referencia en developer.nyverra.com.

Escenarios de uso: cuándo el downtime evita el caos

1. Actualización nocturna del ERP. El cambio derriba el ERP de 23:00 a 01:00. Sin downtime, el monitoreo dispara decenas de alertas y abre tickets. Con la ventana declarada y vinculada al cambio, el NOC permanece en silencio y enfocado.

2. Cambio de enlace de internet. La migración de operador exige una indisponibilidad breve. La ventana evita que el equipo se despierte por un falso positivo.

3. Mantenimiento de storage. El alcance se selecciona por host/ítem, suprimiendo solo lo necesario — y no todo el centro de datos.

KPIs de downtime

Indicador	Qué revela
Downtimes vinculados a cambios	Trazabilidad de las supresiones
Ventanas que excedieron el horario	Precisión de la planificación
Supresiones no cerradas	Riesgo de enmascarar fallos
Falsos positivos durante la ventana	Eficacia del alcance

Integración: el trípode del mantenimiento controlado

El Downtime Manager solo alcanza su máximo potencial cuando trabaja en conjunto: Cambio (la alteración planificada), Monitoreo/Zabbix (que respeta la ventana) y CMDB (que indica qué está en mantenimiento). Este trípode evita los dos extremos: una alerta falsa de mantenimiento planificado y un fallo real oculto por una supresión demasiado amplia. La regla de oro es alcance preciso + cierre puntual.

Checklist del Downtime Manager

1. Vincule cada downtime a un cambio.
2. Seleccione el alcance exacto (hosts/ítems).
3. Defina un inicio y fin realistas.
4. Avise a los interesados antes de la ventana.
5. Cierre o cancele la ventana al finalizar.
6. Revise si alguna alerta real quedó oculta.

Preguntas frecuentes adicionales

¿Y si el mantenimiento se retrasa?
Extienda la ventana o cree otra; lo importante es no dejar la supresión abierta más de lo necesario.

¿El downtime sirve para cualquier activo?
Sirve para los ítems monitoreados seleccionados en el alcance; no es un “silenciar general”.

¿Cómo sé que la supresión ha terminado?
El cierre/cancelación de la ventana restablece las alertas automáticamente.

Conclusión

El mantenimiento planificado es señal de madurez — siempre que no se convierta en ruido. Con el Downtime Manager del Portal Nyverra ITSM, las ventanas quedan documentadas, las alertas se silencian en el momento adecuado y el equipo mantiene el foco en lo que es real.