Obervability
Servicios AudiTrace Recursos▾ Contacto
ES ▾
Solicitar una auditoría gratuita
De la auditoría · Alerting

1,617 ventanas de mantenimiento: el alerting se apaga sin que nadie lo decida

La supresión crece una decisión legítima por vez. En un tenant: 1,617 ventanas permanentes o vencidas y 106 excepciones por entidad con detección apagada.
Publicado el 16 de septiembre de 2026
El silencio no tiene síntomas
El alerting falla en una sola dirección. Una alerta ruidosa la reporta en menos de una hora la persona a la que despertó; una alerta suprimida no la reporta nadie, nunca, porque un problema suprimido no es un problema silencioso — no es un problema en absoluto. No se registra nada que una persona lea, ninguna tarjeta del dashboard se pone en ámbar y la siguiente revisión de incidentes no tiene ningún artefacto que señalar.
Así, la configuración se desvía hacia el silencio de una forma en que nunca se desvía hacia el ruido. Esa asimetría, y no el descuido, es lo que produce un conteo de cuatro cifras de ventanas de mantenimiento abiertas.
Cómo se llega a 1,617
Una ventana por release, por servicio, abierta por un pipeline de despliegue que no tiene un paso para cerrarla. Una abierta a mano durante un incidente a las 02:00, con un alcance generoso porque nadie quería discutir de alcance a las 02:00. Una abierta para una migración con una fecha de fin que ya pasó — que, según cómo se configuró, o venció limpiamente o siguió suprimiendo.
Cada una de ellas fue una decisión correcta en su momento. Ninguna fue nunca la decisión de dejar de alertar sobre ese servicio indefinidamente, que es sin embargo lo que el tenant hace ahora.
El segundo mecanismo: excepciones por entidad
Las ventanas de mantenimiento al menos se ven en una lista. Las excepciones de detección de anomalías son peores: viven en la entidad, son invisibles desde las pantallas de configuración global y apagan la detección en lugar de enrutarla a otro lado. En el mismo tenant había 106.
El patrón detrás de ellas es conocido — un host o un servicio hacía ruido durante un incidente, alguien le desactivó la detección para pasar la noche y la reactivación nunca ocurrió porque nunca fue un ticket.
La forma de la consulta
El inventario de ventanas con su programación, que basta para separar “termina el viernes” de “no termina nunca”:
DQL
fetch dt.settings.maintenance_window | fields name, enabled, scheduleType = schedule.type, end = schedule.end, scope | filter enabled == true and (scheduleType == "PERMANENT" or end < now())
Qué hacer, y en qué orden
No reactive todo. Un tenant que lleva dos años en silencio va a producir un muro de problemas el primer día, la mayoría reales, y el equipo lo apagará todo otra vez para el viernes — un resultado peor que el punto de partida.
Ordene por radio de impacto: primero las ventanas que cubren servicios de producción que despiertan a alguien, después las excepciones sobre entidades que llevan tráfico de clientes, y al final la cola larga. Reactive en lotes lo bastante pequeños como para que los problemas resultantes se puedan clasificar y no solo hojear, y corrija el ruido de fondo sobre la marcha. En el tenant auditado esta fue la primera remediación, porque cambia si un incidente llega a una persona y no cuesta nada revertirla.
El hallazgo detrás de este artículo

Ventanas de mantenimiento permanentes o expiradas

Escala
1,617
Impacto
Alerting suprimido en silencio
La conclusión
Nadie decidió dejar de alertar. 1,617 personas decidieron algo razonable, una vez cada una, y nada en el producto preguntó si el total seguía teniendo sentido.
Más de la serie
La pregunta de $91,576: hosts Full-Stack que no monitorean nada De la auditoría · FinOps El bucket de Grail que nadie eligió: 462 días de retention De la auditoría · Grail Datos personales en logs: 50 fuentes, unos 30.7 millones de registros al día De la auditoría · Pipelines Qué llega realmente a una factura de DPS De la auditoría · FinOps
Descubra qué dice su propio tenant.
Una sola ejecución read-only, 71 verificaciones y el origen detrás de cada hallazgo. El reporte es suyo en cualquier caso.
Solicitar una auditoría gratuita AudiTrace

Descubra qué está haciendo realmente su Obervability.

Una auditoría toma una ejecución. Los hallazgos toman una reunión. Qué hacer con ellos depende de usted.
Expertos certificados en Dynatrace
+1
Enviar
Obervability
Implementación, servicios gestionados y soporte de Dynatrace. Cada hallazgo llega con el origen detrás de él.
Servicios
Servicios AudiTrace Caso de estudio
Guías
Auditoría de Dynatrace Optimización de costos Dynatrace Caso de estudio Artículos
Contacto
© 2026 Obervability · Todos los derechos reservados.
Privacidad Términos de uso Accesibilidad