Qué hacer cuando se activan las alertas de disponibilidad de Astrina durante un mantenimiento planificado
El mantenimiento planificado puede generar mucho ruido. Una alerta de disponibilidad de Astrina no siempre significa una caída inesperada, y la diferencia importa porque un caso lleva a responder a un incidente, mientras que el otro requiere coordinación cuidadosa y una transición limpia de vuelta al monitoreo normal.
Empieza con una pregunta: ¿esta alerta era esperada? Si la respuesta es sí, la alerta forma parte del proceso de mantenimiento, no de un fallo del servicio. Eso no significa que sea inocua. Significa que alguien debió definir la ventana, el alcance y las comprobaciones exactas que se activarían durante el trabajo.
¿Debes tratar esto como un incidente o como una señal esperada de mantenimiento?
Usa primero el plan de mantenimiento. Si el servicio está fuera de línea porque se programó un despliegue, una migración, un cambio de firewall o una actualización de base de datos, entonces la alerta puede estar cumpliendo su función. La alerta solo es esperada cuando la comprobación, el horario y el servicio afectado coinciden con las notas de mantenimiento aprobadas.
No asumas que todas las advertencias se pueden ignorar con seguridad. Un reinicio planificado todavía puede destapar un problema ajeno, como un fallo de DNS o un certificado incorrecto, y eso aparecerá al mismo tiempo que el trabajo de mantenimiento. Una mala suposición puede hacerte perder una hora.
Una regla práctica ayuda aquí. Si la alerta coincide con la ventana de cambio aprobada, el servicio correcto y el propósito documentado del trabajo, trátala como una señal esperada de mantenimiento. Si cualquiera de esas piezas no encaja, trátala como un incidente hasta demostrar lo contrario.
“Esperada” no significa “invisible”. El equipo sigue necesitando saber que las alertas de disponibilidad de Astrina se activaron durante el mantenimiento planificado, porque esas alertas confirman qué comprobaciones están afectadas y cuáles siguen sanas. Esa separación es útil. Muy útil.
¿Dónde se define la ventana de mantenimiento y sigue vigente?
Encuentra la fuente de verdad antes que nada. Algunos equipos la guardan en un ticket de cambio, otros en una página de estado y otros en un evento de calendario con un responsable identificado. El lugar importa menos que la regla: debe existir un único sitio donde se defina la ventana de mantenimiento actual.
Verifica la hora de inicio, la de fin y la zona horaria. Una ventana escrita para las 02:00 en una zona horaria puede no significar nada para un técnico de guardia en otra. Ese desajuste provoca escalados innecesarios, sobre todo cuando el trabajo empieza cerca de medianoche y la notificación llega en una mala hora.
Después comprueba si la ventana cambió. El trabajo planificado a menudo se alarga, se divide en dos fases o se desplaza porque un proveedor envía archivos tarde o una versión encuentra un problema de dependencia. Si la ventana se actualizó y Astrina sigue mostrando el horario anterior, la respuesta a las alertas puede ser incorrecta aunque el mantenimiento en sí esté bien.
La responsabilidad también importa. Alguien debe poder responder, en una sola frase, quién aprobó la ventana y quién puede ampliarla. Si esa persona no está disponible, el equipo puede silenciar las alertas demasiado o dejarlas activas demasiado pronto. Ambas cosas se pueden evitar.
Para los equipos que también supervisan el estado del sitio durante el mismo cambio, ayuda mantener visible el proceso de monitoreo en un solo lugar. Una referencia breve como cómo supervisar la disponibilidad del sitio web puede servir de base mientras avanza el mantenimiento.
¿Qué reglas de alerta conviene pausar o acotar antes de empezar el mantenimiento?
Ajusta las reglas de alerta directamente ligadas al trabajo planificado. Si la base de datos estará indisponible durante 20 minutos, pausa las comprobaciones que dependen de ella. Si solo se ve afectada una región, acota el alcance para que las demás sigan informando con normalidad.
No desactives todo. Ese es el error fácil, y crea un punto ciego. Mantén activas las comprobaciones de disponibilidad no relacionadas para que el sistema de alertas pueda seguir detectando un segundo problema, como una caída de CDN, un fallo de inicio de sesión o una dependencia rota que no tiene nada que ver con el mantenimiento.
Piensa en capas. Una comprobación de la página de inicio puede ser demasiado amplia durante un despliegue, mientras que una comprobación del estado de la API puede ser demasiado específica si la API solo enruta una parte del servicio. Una capa debe quedar en silencio; otra debe seguir sonando. Ese es el equilibrio.
Si tus reglas de alerta incluyen umbrales, considera ampliarlos solo para la comprobación específica de mantenimiento, no para toda la cuenta. Un tiempo de espera de dos minutos puede tener sentido para una comprobación en vivo, pero durante un reinicio controlado quizá sea demasiado sensible. Cambia la regla con el menor alcance posible.
En este punto, conviene recordar cómo ajustar alertas en mantenimiento: mantén activa la cobertura de monitoreo no relacionada. La frase suena obvia, pero aun así los equipos silencian todos los canales porque es más rápido. Más rápido no es más seguro.
¿Cómo silenciar temporalmente solo las alertas relacionadas con el mantenimiento?
Usa la opción de silencio más específica que ofrezca Astrina. Si la plataforma permite silenciar una sola comprobación, silencia una sola comprobación. Si permite silenciar por etiqueta, nombre de mantenimiento o alcance, elige eso en lugar de una pausa general para todas las alertas de disponibilidad.
Prefiere un silencio con límite de tiempo. Un silencio con una hora de fin clara reduce la posibilidad de que alguien olvide reactivar las alertas cuando cierre la ventana de mantenimiento. Un camino de alertas en silencio sin fin es un problema futuro esperando a que el turno de noche lo encuentre.
Si un mantenimiento afecta a un solo canal, silencia solo ese canal. Por ejemplo, podrías suprimir las notificaciones por correo de una comprobación concreta mientras mantienes activas las alertas por chat para comprobaciones no relacionadas. Así, el equipo sigue viendo las excepciones sin verse inundado por el ruido esperado.
Documenta la acción exacta realizada: qué comprobación se silenció, qué alcance se acotó y qué canal de alerta siguió activo. Ese registro ayuda más tarde si alguien pregunta por qué una señal estuvo en silencio durante 18 minutos o por qué una región siguió generando avisos y otra no.
Algunos equipos añaden la configuración del agente durante la misma ventana de cambio. Si eso forma parte de tu mantenimiento, ten a mano la referencia de instalación en * para que la parte de monitoreo siga vinculada al host correcto y a la configuración adecuada de comprobaciones.
¿Qué deberías documentar antes de suprimir alertas?
Escribe el propósito del mantenimiento en lenguaje claro. “Parche de base de datos”, “rotación de certificado” y “cambio en el balanceador de carga” son mejores que “trabajo rutinario”. Cuanto más concreta sea la nota, más fácil será para el siguiente respondedor saber por qué se ajustó la alerta.
Registra las horas de inicio y fin, además de la zona horaria. Incluye las comprobaciones afectadas, quién aprobó y el plan de reversión. Esa lista parece pequeña, pero evita la confusión más común: quién cambió qué y quién debe revertirlo.
Añade una línea más para las excepciones. Si una comprobación debe seguir activa porque la dependencia de un proveedor es inestable, indícalo explícitamente. Si una ruta de la aplicación no forma parte del mantenimiento, dilo también. Las excepciones claras evitan que los equipos silencien por costumbre lo que no deben.
Una nota breve de mantenimiento debería responder cuatro preguntas: qué cambia, cuándo empieza, cuándo termina y quién se encarga de reactivar todo. Si la nota no puede responder a eso, no está lista.
Mantén el registro cerca del propio cambio de alertas. Un ticket en un sistema y un silencio en otro sistema suelen desalinearse. Una nota, un cambio, un responsable.
¿Qué deberías verificar mientras el mantenimiento está en curso?
Vigila tres cosas. Primero, las alertas esperadas deberían permanecer en silencio. Segundo, las alertas no relacionadas deberían seguir activándose. Tercero, cualquier excepción debería ser visible para quienes la necesiten. Esas tres señales indican si el cambio de mantenimiento está funcionando como se pretendía.
Revisa el flujo de eventos en vivo o el registro de alertas durante la ventana. Si la comprobación objetivo sigue enviando avisos después de haberla silenciado, quizá el alcance del silencio sea incorrecto. Si las comprobaciones no relacionadas también quedan en silencio, el alcance es demasiado amplio. En ambos casos hay que corregirlo mientras el mantenimiento sigue en marcha.
Presta atención a las condiciones límite. Un servicio puede volver de forma parcial, lo que significa que un endpoint se recupera mientras otro sigue fallando. Ese es exactamente el tipo de caso que puede generar una falsa sensación de seguridad si el equipo solo observa una señal.
Haz que el mantenimiento sea visible para los responsables de respuesta. Una nota breve en el canal de incidentes, un banner en la página de estado o un comentario de cambio en Astrina pueden ahorrar tiempo cuando alguien vea una alerta y otra no. La claridad corta vale más que las explicaciones largas.
Si necesitas un ejemplo relacionado de cómo interpretar datos de monitoreo durante un cambio, cómo interpretar una caída muestra la misma disciplina: separar el movimiento esperado del problema real y luego verificar el alcance antes de reaccionar.
¿Cuándo y cómo deberías reactivar las alertas de disponibilidad después del cambio?
Reactiva las alertas en cuanto se cumpla la condición de fin del mantenimiento, no cuando alguien lo recuerde. Si el mantenimiento estaba previsto para 30 minutos y terminó en 22, el cambio de alertas no debería esperar hasta la hora final original, salvo que el plan diga lo contrario.
Usa una lista de verificación posterior al mantenimiento. Restaura la alerta normal, confirma que el silencio o la supresión estén desactivados y verifica que la comprobación haya vuelto a sus umbrales completos. Después vigila el flujo de alertas por si aparecen señales retrasadas, porque algunos sistemas emiten una notificación tardía después de que el servicio se recupera.
Confirma la reactivación en el mismo lugar donde se creó el silencio. Si el silencio se limitó a una comprobación, revisa esa comprobación. Si estaba asociado a una etiqueta, confirma que esa etiqueta ya no suprime las alertas relacionadas con el mantenimiento. No confíes en la memoria.
Vigila notificaciones perdidas durante los primeros minutos después de restaurar todo. Una comprobación que estuvo en silencio durante el mantenimiento puede necesitar un nuevo fallo antes de que el sistema vuelva por completo a su comportamiento normal de aviso. Eso no es raro, ni implica automáticamente un error. Es algo que hay que verificar.
Para los equipos que también siguen cambios de medición o analítica durante el mantenimiento, el comportamiento reciente de la plataforma puede importar. La nota sobre qué cambió recientemente en analítica centrada en la privacidad es útil cuando estás confirmando qué debía cambiar y qué no dentro de la misma ventana de mantenimiento.
Si el mantenimiento implicó una migración de producto o servicio, mantén la transferencia final breve y explícita. La persona que silenció la alerta debe indicar cuándo se restauró, qué se comprobó después y si alguna alerta se activó tarde. Ese último punto importa más de lo que parece.
Una última comprobación: pregunta si alguna alerta quedó pausada por accidente. Un solo silencio olvidado puede ocultar la siguiente caída real, y ese es el riesgo que ningún plan de mantenimiento debería dejar atrás.
