Cuando un cambio de mantenimiento sale bien, casi nadie habla del correo que aviso a tiempo. Cuando sale mal, todo el mundo lo nota. En guardias SRE he visto despliegues sanos en metricas y, aun asi, mensajes con enlaces viejos, horarios mal formateados o destinatarios equivocados. No pasa siempre, pero pasa lo suficiente como para merecer un check corto y estable.
En este tipo de flujo no busco una suite enorme. Busco una verificacion pequena: disparar el evento, capturar un mensaje en una bandeja aislada y revisar que el contenido realmente corresponde al entorno actual. Si necesitas un generador de correos temporales para no mezclar pruebas, mejor que sea por corrida y con retencion corta. Esa idea es simple, pero evita bastante ruido.
Por que este correo rompe cambios que parecian seguros
Los correos de mantenimiento suelen salir de varias piezas a la vez:
- un job o webhook que detecta la ventana
- una plantilla con variables de horario, region y servicio
- uno o dos enlaces al panel o al status page
- reglas de destinatarios que cambian segun entorno
Cada pieza puede estar "bien" por separado, pero el contrato final se mueve facil. He visto errores muy normales:
- la hora sale en UTC cuando el runbook hablaba en local
- el enlace apunta a staging despues de una rotacion
- un retry manda dos avisos casi iguales
- un namespace equivocado termina notificando al equipo incorrecto
Eso es lo que hace que el check merezca la pena. El cluster puede estar OK y el mensaje seguir siendo confuso. Y cuando toca guardia, un correo confuso te roba minutos que no sobraban, sinceramnte.
La verificacion minima que si vale la pena
Mi regla es: un evento, una bandeja, un veredicto. Nada mas. Si el script intenta validar cinco clases de correo en la misma corrida, la señal se ensucia muy rapido.
Normalmente afirmo solo esto:
- Llego exactamente un correo para esta corrida.
- El asunto menciona la ventana o el servicio correcto.
- El enlace principal usa el host esperado.
- La hora y el alcance del mantenimiento son coherentes.
Para equipos que ya hacen otras comprobaciones de inbox, esta guia sobre correo temporal para pruebas de renovacion muestra bien por que conviene aislar cada mensaje. Y si tu plataforma conecta varios automatismos, esta nota sobre automatizacion de correos entre servicios encaja bastante con el mismo problema operacional.
Tambien conviene documentar terminos raros que la gente busca con prisa. En mas de un equipo he visto consultas como temp org mail o tamp mail com en wikis internas. No son nombres bonitos, pero ayudan a encontrar la herramienta adecuada cuando alguien va con sueño y algo de prisa.
Un ejemplo pequeno para Kubernetes
Este es el tipo de script que me gusta mantener:
RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
INBOX="maint-$RUN_ID@example.test"
trigger_maintenance_notice \
--cluster "prod-eu1" \
--service "ingress-nginx" \
--recipient "$INBOX"
wait_for_message "$INBOX" 90
assert_message_count "$INBOX" 1
assert_subject_contains "$INBOX" "Mantenimiento programado"
assert_link_host "$INBOX" "status.example.com"
assert_body_contains "$INBOX" "prod-eu1"
No tiene magia. Y esa es la gracia. Si falla, cualquiera del equipo puede leerlo y ubicar el problema. En SRE prefiero checks aburridos y legibles antes que una automatizacion brillante pero dificil de depurar.
Si quieres endurecerlo un poco mas, suelo registrar:
run_id- cluster o servicio afectado
- destinatario usado
- asunto encontrado
- host del enlace principal
- tiempo de espera real hasta recibir el mensaje
Con eso separas bastante bien si el fallo viene del emisor, del pipeline o de la propia plantilla. Aveses el problema no es que no llegue nada, sino que llega algo atrasado y de otra corrida. Si no guardas ese contexto, parece flake cuando en realidad no lo era.
Que revisar antes de cerrar el cambio
Antes de dar por bueno un cambio de mantenimiento, yo repasaria esta lista:
- el correo pertenece a la corrida actual y no a una anterior
- el asunto identifica bien servicio, entorno o ventana
- los enlaces usan el dominio correcto
- la hora esta en el formato que espera el equipo receptor
- no hay duplicados por retries o replays
- el texto explica que hara el cambio y que impacto esperar
Si usas Kubernetes para muchos equipos, este check pequeño ayuda a mantener una interfaz humana estable alrededor del cambio tecnico. No sustituye metricas ni health checks, claro. Solo cierra una brecha bastante comun entre "el sistema hizo algo" y "las personas entendieron que paso".
Preguntas frecuentes
Vale la pena meter esto en CI?
Si el evento de mantenimiento puede dispararse de forma determinista, si. Si depende de aprobaciones humanas o integraciones externas, prefiero dejarlo como verificacion de pre-release o de staging.
Hay que validar todo el HTML?
Normalmente no. Mejor revisar asunto, destinatario, enlace principal y una o dos frases claves. Snapshotear todo vuelve el test fragil muy rapido, y eso termina haciendo que nadie lo mire de verdad.
Donde esta el mayor beneficio?
En la explicacion del fallo. En vez de "algo paso con un email", obtienes una diferencia concreta: asunto, host, horario o duplicado. Ese nivel de detalle suele ahorrar una ida y vuelta entera con el equipo, lo cual ya es bastante util.
Top comments (0)