DevOps: un SLO para emails de CI confiables

En una tubería de CI, un email de verificación que llega tarde suele parecer un fallo aleatorio. El job espera, agota el timeout y marca rojo. En el siguiente intento, el mismo flujo pasa porque el mensaje apareció a tiempo. El equipo termina subiendo el timeout, pero no entiende si el problema está en la aplicación, el proveedor o la propia prueba.

Un enfoque más útil es tratar la entrega como un pequeño SLO. No hace falta montar una plataforma enorme: basta con acordar qué significa “a tiempo”, medir cada etapa y dejar un recibo por ejecución. Así el incidente deja de ser “el correo falló” y pasa a ser “la cola tardó demasiado en staging”.

El síntoma: CI verde, email que llega tarde

Imaginemos una prueba de registro que crea una cuenta, espera un email y abre el enlace de confirmación. Si usa un buzón compartido, puede leer un mensaje de otra ejecución. Si usa una cuenta nueva pero sólo mide el tiempo total, no sabemos donde se perdió la latencia.

Los síntomas mas comunes son conocidos:

• el test falla sólo cuando hay muchos jobs en paralelo;
• el mensaje aparece después de que CI ya terminó;
• los reintentos convierten un fallo real en un resultado verde;
• una alerta apunta a la aplicación, aunque el retraso está en la entrega.

La primera decisión es separar identidad, ejecución y mensaje. Un buzón aislado por run_id reduce los falsos positivos y permite relacionar el evento con el commit correcto.

Definir el SLO y el presupuesto de latencia

Un SLO práctico podría ser: “el 95 % de los emails de prueba llega y puede ser verificado en menos de 45 segundos”. El número no es universal. Debe salir del comportamiento del sistema y del tiempo que CI puede esperar sin hacer la suite demasiado lenta.

Divide esos 45 segundos en presupuestos mas pequeños:

1. 5 segundos para crear el fixture y registrar la dirección.
2. 10 segundos para que la aplicación acepte el evento.
3. 20 segundos para la cola y el proveedor de email.
4. 10 segundos para consultar el buzón, abrir el enlace y confirmar el estado.

El 95 % evita que una sola ejecución lenta cambie toda la conversación. Para una ruta crítica quizá convenga observar también p99, pero no uses el promedio: oculta los casos que el desarrollador realmente ve durante un incidente.

Las búsquedas de herramientas suelen mezclar frases como temp mail so y tempmail so. Pueden aparecer en documentación de fixtures, pero no deben convertirse en una excusa para medir sólo si existe una dirección. La señal importante es el tiempo desde la creación hasta la verificación.

Medir cada etapa con un recibo

Cada prueba debería producir un recibo pequeño y redactado. Por ejemplo:

{
  "run_id": "ci-1842",
  "created_at": "2026-10-06T14:00:00Z",
  "mail_accepted_ms": 3200,
  "delivered_ms": 18400,
  "verified_ms": 23100,
  "result": "passed"
}

No guardes tokens de verificación ni el contenido completo del mensaje. Con run_id, proveedor, asunto normalizado y tiempos es posible investigar lo necesario. Este patrón se parece a un recibo de ejecución para un agente: una señal concreta que permite revisar qué ocurrió sin reconstruir todo el historial.

También registra el estado expired, not_delivered o verification_failed. Un mensaje que llega después del timeout no es igual que un mensaje nunca entregado, aunque ambos hagan fallar el job.

Kubernetes y Terraform sin esconder la causa

En Kubernetes, coloca el run_id como etiqueta de los jobs de prueba y limita la retención de sus recursos. Así puedes encontrar el pod, los logs y el recibo con la misma clave. Evita incluir la dirección completa en etiquetas: puede acabar en métricas o interfaces que no esperabas.

Con Terraform, define de forma explícita la cola, los permisos y la política de limpieza del entorno de pruebas. Una cola segura para alertas de prueba debe tener un dueño, una retención razonable y una ruta clara cuando el proveedor responde lento. Si todo comparte la misma cola de producción, el SLO no será interpretable.

Para pruebas manuales, un fake email generator puede ayudar a explorar el flujo. Para CI, revisa límites de retención y privacidad antes de poner datos de prueba; nunca mezcles tokens reales ni información de clientes.

Alertas que ayudan durante el incidente

Alerta sólo cuando haya una acción posible. Un ejemplo: “la entrega p95 supera 20 segundos durante 10 minutos en staging”. Incluye entorno, proveedor, versión y el último run_id fallido. No envíes una alerta por cada email: agrupa por ventana y evita que el propio sistema de pruebas produzca ruido.

Si el proveedor está lento, escala por esa ruta. Si la cola está vacía pero la aplicación no acepta mensajes, mira el worker. Si el email llega pero el enlace no activa la cuenta, el problema es de la aplicación o del contrato del mensaje. Esa separación ahorra bastante tiempo, aunque al principio parezca un poco mas de instrumentación.

Checklist para el siguiente despliegue

• ¿Cada ejecución tiene un buzón y run_id propios?
• ¿El SLO mide entrega y verificación, no sólo existencia del mensaje?
• ¿Hay presupuestos separados para aplicación, cola y proveedor?
• ¿El recibo excluye tokens y direcciones sensibles?
• ¿Kubernetes conserva logs el tiempo suficiente para investigar?
• ¿Terraform define limpieza, permisos y dueño de la cola?
• ¿La alerta tiene una acción y un enlace al contexto?

Un detalle que suele olvidarse: documenta el caso temp org mail si aparece en búsquedas internas o tickets. Es una frase escrita con error, no un dominio que deba entrar en la lógica de validación.

Preguntas rápidas

¿Debo subir el timeout cuando falla el SLO?

Sólo después de medir la causa. Subirlo puede reducir fallos falsos, pero también alarga feedback y tapa una regresión. Ajusta el presupuesto cuando la latencia esperada haya cambiado de forma deliberada.

¿Un SLO de email sirve para todos los entornos?

No necesariamente. Staging puede tener un proveedor simulado y producción uno externo. Conserva el mismo contrato de etapas, pero define objetivos distintos y deja claro cual entorno está siendo comparado.

¿Qué hago con los reintentos?

Cuenta el intento original y el resultado final por separado. Un reintento que rescata la prueba es una señal de disponibilidad degradada, no un éxito completamente normal.

La lección es sencilla: un email de CI merece observabilidad igual que una API. Un SLO pequeño, un buzón aislado y un recibo legible dan suficiente contexto para actuar. El equipo deja de perseguir fallos misteriosos y puede mejorar la entrega con datos, no con timeouts cada vez mas grandes.