SRE: runbooks cortos para incidentes de email

Cuando un flujo de email falla en produccion, el problema rara vez es "solo correo". Lo que se rompe de verdad es una cadena: evento, cola, proveedor SMTP, plantilla, tracking y a veces una dependencia externa que nadie miro en el standup. En varios equipos he visto el mismo patron: demasiada informacion suelta y muy poca secuencia operativa. Un runbook corto suele ganar frente a una wiki enorme que nadie abre durante el incidente.

Si trabajas en SRE o Cloud, este tipo de runbook te ahorra minutos que luego parecen horas. Tambien deja evidencia util para la retro. Y si tu producto usa buzones de prueba o un correo desechable en entornos no productivos, conviene separar ese contexto desde el inicio para no mezclar sintomas.

Por que un runbook corto cambia la respuesta

En incidentes de entrega, el primer error comun es empezar por el dashboard favorito del turno. El segundo es saltar a logs sin definir la pregunta. Yo prefiero un runbook de una pagina con checks ordenados por probabilidad y costo de validacion.

No hace falta que sea sofisticado. De hecho, cuanto mas elegante lo haces, menos usable queda a las 3 AM. Un runbook util responde tres cosas:

1. Que ve el usuario.
2. Que sistema pudo romperse.
3. Que prueba reduce incertidumbre mas rapido.

Ese tercer punto es el que suele faltar, y ahi se pierde muchisimo tiempo.

La senal minima que siempre reviso primero

Antes de abrir trazas detalladas, reviso una vista minima con cuatro datos:

• tasa de aceptacion del proveedor
• tiempo entre evento y enqueue
• tiempo entre enqueue y send attempt
• porcentaje de rebotes o rechazos por ventana corta

Si no tienes esa vista, construyela. No necesitas una plataforma nueva; con logs estructurados y un panel simple ya puedes detectar si el cuello esta en tu app, en la cola o en el proveedor. Segun Google SRE Workbook, los equipos responden mejor cuando las alertas llevan contexto accionable en vez de solo volumen bruto. No es una idea nueva, pero sigue siendo donde mas se nota la diferencia.

Tambien intento responder una pregunta bien aburrida pero muy potente: "fallan todos los emails o solo un tipo?" Password reset, onboarding y magic links no tienen el mismo impacto ni el mismo camino interno. Suena obvio, pero en incidentes reales eso a veces se descubre tarde.

Un runbook de 15 minutos para fallos de entrega

Este es el esquema que mas me funciona cuando el equipo necesita bajar ruido rapido:

Minuto 0 a 3: confirmar alcance

Busca tres ejemplos concretos con timestamp, tenant o user id y tipo de email. Evita frases vagas como "no sale nada". Si puedes, compara con un envio sano de la misma hora. Parece basico, pero evita una investigacion medio rota desde el arranque.

Minuto 3 a 6: aislar la etapa rota

Comprueba:

• el evento de negocio existe
• la cola recibio el mensaje
• hubo intento de envio
• el proveedor devolvio accepted, deferred o rejected

Si el evento no existe, no estas ante un problema de email. Si la cola crece, mira consumidores. Si hay accepted pero no entrega final, entra soporte del proveedor o revisa reputacion/dominio. Es una ruta simple, pero evita discusiones largas y algo inutiles.

Minuto 6 a 10: revisar cambios cercanos

Los cambios que mas rompen estos flujos no siempre son "grandes deploys". Muchas veces son:

• rotacion de secretos
• cambio de plantilla con variable faltante
• regla nueva de rate limit
• ajuste DNS o proveedor secundario

Por eso me gusta enlazar en el runbook referencias a trabajos previos como validar correos despues de cambios de infraestructura. No para leer un ensayo completo en plena guardia, sino para recordar patrones de falla que ya vimos.

Minuto 10 a 15: dejar recibos

Si ya sabes el punto roto, deja evidencia antes de correr a arreglarlo:

• query usada
• ids de ejemplo
• metrica que empezo a caer
• hipotesis descartadas

Ese recibo vale oro para la retro y para el siguiente turno. Tambien evita el clasico "yo pense que ya estaba claro".

Donde entra el correo desechable sin romper el enfoque

En bastantes equipos, el incidente se mezcla con pruebas internas hechas con inboxes temporales. No es malo usar esos buzones; al contrario, pueden servir para verificar rapidez de entrega y contenido. El error aparece cuando el equipo no distingue pruebas controladas, QA y trafico real.

Mi recomendacion es sencilla:

• etiqueta el origen del email de prueba
• separa metrica de staging y produccion
• guarda run ids para correlacion
• no uses un caso de tempail como prueba unica del incidente

Si haces testing de signup o onboarding, una referencia como pruebas reales de signup ayuda a alinear producto y operacion. Los equipos de frontend suelen detectar antes los sintomas de experiencia, mientras SRE mira el pipeline de entrega. Juntarlo temprano va mejor, incluso si al principio paresca que hablan idiomas distintos.

Preguntas frecuentes del equipo

Conviene abrir incidencia con el proveedor de inmediato?

Solo si ya confirmaste que tu evento, tu cola y tu intento de envio estan sanos. Abrir ticket demasiado pronto mete espera sin reducir incertidumbre.

Cuantas metricas debe tener este runbook?

Pocas. Las suficientes para aislar etapa y severidad. Si el panel tiene veinte graficas, en la practica nadie sabe por donde empezar.

Vale la pena probar con muestras manuales?

Si, pero con disciplina. Una muestra manual sirve para confirmar comportamiento, no para reemplazar observabilidad. El runbook debe seguir siendo la fuente principal, aunque el equipo este cansado o con prisas.

Al final, un buen runbook de email no presume complejidad. Hace algo mas valioso: vuelve repetible una investigacion que antes dependia demasiado de quien estaba de guardia ese dia.