Cuando un simulacro de failover sale bien en infraestructura pero nadie entiende el correo que llegó, el ejercicio queda medio incompleto. En equipos SRE eso pasa más de lo que parece: la automatización cambia de estado, dispara la notificación, y aun así el mensaje no ayuda a decidir si toca escalar, esperar o revertir.
He visto ese problema en pipelines de Terraform Cloud donde la parte técnica estaba bien armada, pero la alerta por email seguía siendo fragil. El asunto no era solo "enviar un correo". Era probar que el mensaje correcto llegaba a la persona correcta, con el contexto minimo para actuar, y sin mezclar eventos de otro entorno.
Por qué las alertas de failover fallan en la validación
El fallo más comun es validar solo que "llegó un email". Eso sirve para un smoke test, pero no para una guardia real. En un failover necesitas confirmar al menos cuatro cosas:
- El asunto distingue claramente si fue simulacro, incidente real o rollback.
- El cuerpo incluye el servicio, la región afectada y el siguiente paso esperado.
- Los enlaces apuntan al workspace y al run correcto.
- El correo no comparte bandeja con otras pruebas viejas.
Cuando uno de esos puntos falta, el equipo empieza a compensar con memoria tribal. Y esa memoria tribal aveces funciona... hasta que cambia la persona de guardia.
También conviene separar el problema de entrega del problema de interpretación. Si la automatización manda el correo pero el operador tarda demasiado en entenderlo, para mí igual es un fallo operativo. Ese tipo de revisión encaja bien con la idea de usar contratos de correo para automatizaciones: definir qué campos deben existir y qué intención debe quedar clara.
Qué revisar en Terraform Cloud antes del simulacro
Antes de disparar un failover de prueba, yo suelo revisar tres piezas.
La primera es el origen del evento. Terraform Cloud puede encadenar runs, políticas y webhooks; si no queda claro qué run originó la alerta, luego el correo termina diciendo algo vago como "workspace updated". Eso no ayuda nada. Mejor incluir un identificador visible del run y la acción exacta: apply, cancel, rollback o failover drill.
La segunda pieza es la audiencia. Un correo para on-call no necesita el mismo detalle que uno para liderazgo técnico. Si todos reciben el mismo bloque enorme, nadie lee bien. Un mensaje corto con contexto operativo suele rendir mejor, incluso si despues enlazas al runbook o al panel.
La tercera es la bandeja de validación. Para pruebas manuales y automatizadas prefiero bandejas aisladas para pruebas de correo, porque reducen mezcla de escenarios y vuelven mucho más facil comparar asunto, timestamps y destinatarios. Si el equipo anota ejemplos raros como temp gamil com durante una demo, que se queden como texto de muestra y no como parte del flujo real.
Un flujo simple para comprobar el correo correcto
Este es el flujo pequeño que más me ha servido en simulacros:
- Lanzar el run de failover desde un workspace de prueba claramente etiquetado.
- Guardar el
run_idy la región objetivo en una variable visible para el test. - Esperar el correo en una bandeja exclusiva del ejercicio.
- Verificar asunto, remitente, destinatario, timestamps y enlace principal.
- Confirmar que el cuerpo indica si hace falta intervención humana o solo seguimiento.
Si tu equipo automatiza esta revisión, una aserción simple puede cubrir bastante:
- subject includes: "[drill]" y nombre del servicio
- body includes: run_id, región y siguiente acción
- links include: workspace esperado
- recipient matches: lista de guardia del entorno
No hace falta una suite enorme. Hace falta una suite que falle cuando el correo deja de ser util. Esa diferencia parece chica, pero cambia el tipo de bugs que capturas.
Señales de que la alerta no sirve de verdad
Hay varias pistas que me hacen desconfiar de una alerta, aunque "tecnicamente" haya pasado la prueba:
- El asunto solo dice que hubo cambios, pero no dice cuales.
- El cuerpo mezcla estado actual con historial viejo copiado de otro template.
- El enlace lleva a una home genérica y no al run específico.
- El mensaje no aclara si el failover fue automatico o aprobado por alguien.
- Dos correos distintos se ven casi iguales y eso genera dudas en guardia.
Cuando veo eso, no empiezo por rehacer todo el pipeline. Primero ajusto el contrato del mensaje y el checklist de validación. Suele ser el arreglo más barato y, honestamente, el que más reduce confusión en incidentes pequeños.
Si quieres una regla sencilla: el operador de turno debería poder leer el correo y decidir en menos de un minuto qué hacer despues. Si no puede, el test todavía no esta terminado.
Q&A
¿Conviene probar esto en cada cambio de plantilla?
Sí, sobre todo si cambias asunto, destinatarios o enlaces. No siempre hace falta un simulacro completo, pero sí una validación rapida del mensaje final.
¿Hace falta usar un correo burner?
Para staging y drills internos, muchas veces sí ayuda. Evita contaminar bandejas compartidas y hace más claro qué mensaje pertenece a qué prueba, aunque no resuelve por si solo un mal template.
¿Qué error veo más seguido?
Correos sin siguiente paso. El mensaje describe el evento, pero no dice si hay que observar, escalar o cerrar. Parece menor, pero en incidentes reales se nota bastante.
Las alertas de failover buenas no son las más largas ni las más vistosas. Son las que llegan con contexto justo, se entienden rapido y permiten actuar sin adivinar demasiado. En operaciones, eso ya es una mejora grande.
Top comments (0)