SRE: alertas de correo con evidencia útil

Una alerta de CI que dice «falló la verificación de email» puede despertar a alguien a las tres de la mañana y, aun así, no ayudarle a resolver nada. Falta saber qué ejecución falló, qué buzón estaba involucrado y si el problema fue del producto, del proveedor o del propio pipeline. En ese momento, el equipo de guardia empieza a buscar a tientas.

En sistemas con muchas pruebas paralelas, una alerta útil no es un mensaje más. Es una pequeña evidencia empaquetada. El objetivo de este patrón es que una ejecución que usa un correo de prueba, incluso al generar correo desechable para un escenario aislado, deje una historia corta y verificable para quien recibe el aviso.

La alerta que llega demasiado tarde

El síntoma habitual es sencillo: el test falla, el job se marca en rojo y llega una notificación con un enlace genérico al pipeline. Cuando el ingeniero abre el enlace, ya no sabe si debe mirar el pod, la API de correo, el navegador o la aplicación bajo prueba.

El incidente se vuelve mas dificil cuando varias ejecuciones comparten una bandeja. Un mensaje atrasado puede parecer una respuesta válida. Un reintento puede pasar y ocultar que el primer job dejó datos sueltos. La alerta no necesita contar toda la historia, pero sí debe identificar el primer estado que no encaja.

Yo separaría tres preguntas desde el principio:

• ¿Qué esperaba la prueba y qué observó realmente?
• ¿Qué recurso y qué ejecución produjeron esa observación?
• ¿Qué siguiente comprobación puede hacer la persona de guardia?

Si el aviso no responde esas preguntas, solo traslada el trabajo de diagnóstico a otra pantalla.

Qué evidencia debe acompañar al fallo

Una notificación de un pipeline debería llevar un conjunto pequeño de campos estables. Por ejemplo:

email_check:
  run_id: "build-1842-e2e-07"
  fixture_id: "inbox-7f2c"
  expected: "verification_link"
  observed: "timeout_after_45s"
  provider_state: "message_received"
  pod: "checkout-e2e-2xk9p"
  next_check: "revisar latencia entre proveedor y worker"

El run_id conecta el aviso con los logs del pipeline. El fixture_id identifica el buzón sin exponer una dirección completa. expected y observed hacen visible la diferencia que disparó la alerta. Finalmente, next_check ofrece una acción concreta, no un consejo generico como «revisar logs».

Estos campos son más valiosos que copiar el cuerpo entero del mensaje. El equipo necesita saber que llegó un correo y qué transición faltó; normalmente no necesita guardar el token de verificación en cada sistema de observabilidad. La evidencia tiene que ser suficiente para investigar, pero no tan grande que aumente el riesgo.

Diseñar una identidad por ejecución

Cada prueba paralela debe tener una identidad propia. Puede ser un buzón aislado, un prefijo de asunto o ambos. Lo importante es que el consumidor filtre por run_id y no por «el último email recibido».

Una convención sencilla evita muchas confusiones:

fixture_id = <pipeline_id>-<job_id>-<scenario>
subject    = [<fixture_id>] verify checkout

El productor registra cuándo creó la fixture y cuándo deja de ser válida. El consumidor registra cuándo vio el mensaje y qué retraso midió. Así, una alerta puede distinguir entre «el proveedor nunca recibió el mensaje» y «el worker lo recibió, pero el test consultó demasiado pronto».

Esto también ayuda cuando alguien busca términos de prueba poco consistentes en documentación vieja, como fake e mail com. Es mejor conservar esos términos como texto de búsqueda, pero no usarlos como identidad técnica ni como nombre estable del recurso.

Coordinar CI, Kubernetes y el equipo de guardia

Kubernetes puede ejecutar el test y su recolector de evidencia, pero no debe ser la única fuente de verdad. Si el clúster se reinicia justo al terminar el job, los logs locales pueden desaparecer. Publica un resumen pequeño como artefacto del run y envía a la alerta solo sus campos principales.

Una secuencia operativa razonable es:

1. Crear la fixture y guardar run_id, fixture_id y caducidad.
2. Ejecutar la prueba filtrando únicamente por esa identidad.
3. Registrar la primera transición fallida, no solo el estado final.
4. Emitir una alerta con causa probable, enlaces y siguiente comprobación.
5. Intentar la limpieza y dejar constancia de si terminó correctamente.

El job de limpieza debe poder reintentarse sin borrar una fixture que todavía pertenece a una ejecución activa. Un reconciliador periódico cubre el caso en que CI se corta antes del bloque final. Si ese reconciliador falla, la alerta debe decirlo claramente; esperar mas tiempo no corrige un permiso IAM ausente.

Para los equipos que validan el formulario desde el navegador, conviene separar el estado visual de la evidencia operativa. Este artículo sobre probar un signup sin un inbox real explica una preocupación relacionada: la interfaz debe mostrar espera y error sin mezclarlos.

Cómo evitar ruido y datos sensibles

No toda anomalía merece despertar al equipo. Un timeout aislado puede agruparse si la tasa de éxito sigue normal, mientras que una caída simultánea del proveedor y del worker sí merece una alerta inmediata. Define ventanas y umbrales antes de que llegue el primer incidente.

También evita incluir direcciones completas, tokens, cookies o cuerpos de mensajes. Un identificador hash de la fixture, el proveedor y la edad del mensaje suelen bastar. Para investigar problemas de riesgo del correo, es útil revisar señales de riesgo desde el correo, pero la alerta de CI debe mantener el mínimo contexto necesario.

Los resultados llega mejor agrupados por run_id, escenario y causa probable. Esa agrupación permite ver si el fallo se repite en un solo cluster o si aparece en todas las regiones. También evita abrir una página distinta para cada reintento.

Checklist para alertas accionables

• Cada prueba tiene run_id y fixture_id propios.
• La alerta muestra expected, observed y la primera transición fallida.
• El aviso incluye una siguiente comprobación concreta.
• CI conserva un resumen aunque el pod desaparezca.
• La limpieza es idempotente y tiene un reconciliador de respaldo.
• Los umbrales separan ruido de una degradación real.
• No se envían tokens ni cuerpos completos a los logs.
• Se puede enlazar el aviso con el run y con el recurso exacto.

Una alerta SRE no tiene que ser larga para ser buena. Tiene que reducir la distancia entre el síntoma y la primera hipótesis comprobable. Cuando cada prueba lleva su identidad, Kubernetes conserva el trabajo reproducible y CI publica evidencia pequeña pero suficiente, el equipo deja de adivinar qué ocurrió y puede volver al servicio mas rapido.