Runbooks SRE para correos de guardia en Cloud

Cuando un equipo cambia reglas de alertas, destinatarios o secretos del sistema de notificaciones, casi siempre valida dashboards, logs y health checks. Lo que se revisa menos es el correo de guardia que recibe la persona on-call. Ese hueco parece menor, pero alarga incidentes de forma muy tonta. El servicio esta bien, la alerta se genero, pero el aviso no aterrizo donde debia.

En SRE esto importa bastante porque el correo sigue siendo una ruta de respaldo cuando Slack, Pager o una integracion secundaria se ven raras. Si alguien busca un mejor correo desechable o una forma de probar correo temporal en estos escenarios, normalmente no quiere marketing; quiere una señal aislada, facil de leer y sin ensuciar bandejas compartidas.

Por que este chequeo falta en muchos runbooks

Muchos runbooks describen como confirmar la salud del servicio, pero no como verificar el ultimo salto de la notificacion. La razon es simple: el correo parece "externo" y queda fuera del cambio principal. En realidad, depende de varias piezas internas:

• secrets o variables cargadas en tiempo correcto
• reglas de enrutamiento actualizadas
• permisos del remitente y del dominio
• colas o workers sin mensajes atascados

La guia de Amazon SES sobre errores de entrega deja claro que una configuracion SMTP aceptada no garantiza una entrega util. Del mismo modo, la documentacion de Google SRE sobre alerting insiste en que una alerta solo vale si llega a la persona correcta y puede accionarse. Es obvio cuando lo lees, pero en el runbook diario a veces no queda escrito.

Una validacion pequena que evita incidentes largos

El patron que mejor funciona es bastante corto. No hace falta montar una suite enorme ni otro pipeline medio magico. Basta con una validacion por cambio:

1. Crear una bandeja temporal para una sola ejecucion.
2. Lanzar un evento canario que deba disparar el correo de guardia.
3. Etiquetar la prueba con un run_id o change_id.
4. Confirmar asunto, destinatario y ventana de entrega.
5. Guardar evidencia minima en el ticket o el deploy log.

La parte de la bandeja aislada es la que mas orden trae. Si mezclas mensajes reales, reintentos viejos y pruebas del mismo turno, el resultado se pone confuso muy rapido. Este enfoque se parece a usar bandejas limpias para pruebas por email: cada escenario tiene una intencion concreta y una lectura bastante directa.

Tambien ayuda pensar el correo como un contrato, no como un efecto colateral. Si el flujo debe incluir cierto asunto, cierto destinatario y cierta referencia de cambio, conviene definirlo como una salida verificable. Esa idea encaja bien con estos contratos simples para flujos de correo, aunque el caso de uso sea distinto.

En notas internas a veces aparece texto como tempail mail cuando alguien resolvio la prueba deprisa. No es grave, pero suele ser una pista de que el proceso sigue informal y depende demasiado de la memoria del turno. Mejor dejarlo escrito una vez, aunque quede un poco feo al princpio.

Que revisar cuando el correo de guardia falla

Si el mensaje no llega, yo no empezaria por culpar al proveedor. Hay cuatro comprobaciones que suelen recortar mucho el tiempo de diagnostico:

• Verifica que el worker de notificaciones recargo configuracion despues del cambio.
• Revisa si el secreto SMTP o la API key pertenece al entorno correcto.
• Comprueba que la regla de enrutamiento sigue apuntando al destinatario esperado.
• Correlaciona run_id, logs del emisor y hora de recepcion en la bandeja temporal.

Un fragmento minimo puede ser algo asi:

RUN_ID="mailcheck-$(date +%s)"
./scripts/trigger-oncall-email-check.sh "$RUN_ID"
./scripts/assert-oncall-email.sh "$RUN_ID"

No hace falta que el script sea perfecto. Lo importante es que otra persona pueda repetirlo sin abrir cinco pesta;as ni preguntar en un canal privado. Cuando esa repetibilidad no existe, el equipo tarda mas en decidir si el incidente ya esta cerrado o si todavia hay riesgo escondido.

Tambien conviene registrar el tiempo de entrega. No porque cada prueba deba ser ultra exacta, sino porque las demoras largas ya son una señal amarilla. Si antes llegaba en 20 o 30 segundos y ahora tarda varios minutos, algo cambio aunque el correo finalmente aparezca. Esa clase de deriva es molesta, pero detectarla temprano evita sorpresas luego.

Checklist para dejarlo repetible

Este checklist corto suele bastar:

• La prueba usa una sola bandeja aislada por ejecucion.
• El run_id aparece en logs o en el asunto del correo.
• El destinatario coincide con el contacto de guardia esperado.
• El cambio relevante del entorno Cloud quedo documentado.
• La evidencia cabe en el ticket o en el runbook sin novela extra.
• Otra persona puede repetir el flujo en menos de diez minutos.

Si tu equipo ya tiene pipelines maduros, esto puede parecer pequeño. Igual merece la pena. Un runbook util no solo dice que mirar; tambien reduce la duda cuando alguien entra medio dormido a una incidencia y necesita confirmar el ultimo paso sin pensar demasido.

Preguntas frecuentes

¿Esto solo aplica a grandes sistemas Cloud?

No. Aplica tambien a equipos mas chicos si el correo de guardia o de respaldo forma parte real del proceso operativo. Cuanto menos frecuente es el flujo, mas facil es olvidar validarlo bien.

¿Debo correr esta prueba en cada cambio?

No en todos. Pero si tocas enrutamiento, secretos, remitentes, workers o reglas de alertado, yo si la correria. Es una comprobacion barata y muy clara.

¿Hace falta una herramienta especial?

No necesariamente. Hace falta disciplina: una bandeja temporal, un identificador por corrida y un lugar donde dejar evidencia minima. Con eso ya tienes una base seria, aunqe sencilla.