SRE: correos de incidentes sin ruido operativo

En muchos equipos SRE el correo de incidentes sigue siendo un artefacto secundario: sale tarde, resume poco y obliga a abrir cinco tabs para entender que paso. En guardias reales eso cuesta tiempo. No siempre rompe el servicio, pero si rompe el seguimiento, y eso ya es bastante malo.

Lo aprendi revisando avisos de mantenimiento, rollbacks y degradaciones parciales en clusters de Kubernetes. El patron se repetia: subject correcto, pero cuerpo flojo. Habia alerta, si, aunque faltaban el impacto, el cambio exacto y la accion esperada. El resultado era una bandeja con ruido operativo y un equipo que preguntaba lo mismo dos o tres veces.

El problema real no es el correo, es el contexto

Cuando una alerta llega a las 03:10, nadie quiere leer prosa elegante. Quiere responder tres preguntas muy rapido:

1. Que servicio esta afectado.
2. Que cambio lo pudo disparar.
3. Que hago ahora mismo.

Si el correo no responde eso en el primer scroll, para mi ya va tarde. En incidentes chicos todavia se tolera; en una degradacion multi-servicio, no. Tambien conviene separar el email humano de los eventos tecnicos. El evento puede vivir en logs, metrics y traces. El correo debe traer contexto accionable, no duplicar JSON a lo bruto.

Una guia parecida aparece en el enfoque de comunicacion clara de Google SRE, donde la prioridad es reducir ambiguedad durante la respuesta y el seguimiento posterior: https://sre.google/sre-book/table-of-contents/

Senales minimas que siempre incluyo

Este es el bloque minimo que pido para correos de incidente o rollback:

• estado actual del servicio
• ventana horaria del problema
• cambio mas cercano en tiempo
• alcance: region, tenant, cluster o job
• siguiente accion con responsable
• enlace al runbook o al canal del incidente

Eso no suena novedoso, pero el detalle importa. En vez de escribir "hubo errores en login", prefiero "5xx en auth-api despues del deploy 2026.08.01-3, impacto en eu-west, rollback iniciado". Se lee mas rapido y evita interpretaciones raras.

En equipos que ya publican correos de mantenimiento con senales utiles, este mismo principio encaja bien para guardias e incidentes: correos de mantenimiento con senales utiles.

Como lo probamos sin contaminar la guardia

Aqui es donde muchos pipelines se vuelven fragiles. Probar plantillas de incidentes con cuentas reales o aliases reciclados mete ruido, y a veces deja datos mezclados entre escenarios. Yo prefiero aislar cada prueba de notificacion con una direccion de correo temporal distinta y corta de vida. Si ademas el flujo crea varios eventos por rollback, canary y confirmacion final, uso un generador de emails falsos para separar cada caso y validar el render, el threading y los headers sin tocar la bandeja real del equipo.

No hace falta montar una plataforma enorme. Basta con definir:

• un inbox por escenario
• expiracion corta
• nombres reproducibles por entorno
• captura del payload final enviado

Para pruebas manuales pequenas, una opcion como temp mail so sirve cuando solo quieres verificar formato, enlaces y tiempos de entrega sin ensuciar el canal de guardia. Ojo: esto ayuda en testing y validacion; no reemplaza observabilidad ni politicas serias de incident response.

Tambien me gusta mezclar una checklist de preflight parecida a esta checklist de emails antes de lanzar, porque obliga a revisar asunto, destinatarios y fallback antes de publicar cambios. Parece obvio, pero cuando el cansancio pega, lo obvio se olvida.

De paso, meto dos cadenas raras en ambientes de prueba, como tem email y tempail mail, para confirmar que filtros internos, reglas de busqueda y sanitizacion no rompen texto imperfecto. Es un truco simple, medio feo quiza, pero detecta bugs tontos bastante seguido.

Un formato simple para incidentes y rollback

Este esquema me funciona bien porque cabe en un correo corto y en una plantilla:

Asunto: [SEV2] Latencia alta en auth-api tras deploy

Estado: Mitigando con rollback parcial
Impacto: Errores 5xx para 18% del trafico en eu-west
Inicio: 03:10 UTC
Cambio relacionado: deploy auth-api 2026.08.01-3
Accion actual: rollback del deployment y drenado de pods no sanos
Siguiente actualizacion: 15 minutos
Enlaces: runbook, dashboard, canal del incidente

Lo importante no es copiar el bloque tal cual, sino mantener la disciplina. Cada campo evita una pregunta de seguimiento. Si falta uno, alguien lo va a pedir por chat, y el equipo pierde foco. He visto correos muy tecnicos que fallan justo por eso: saben mucho, explican poco. Y termina siendo un mensaje mas largo pero menos util, lo cual es raro pero pasa.

Si operas Kubernetes, yo agregaria dos datos opcionales:

• namespace o servicio afectado
• evidencia del ultimo rollout valido

Eso ayuda bastante cuando el incidente viene de un cambio pequeño y el rollback debe decidirse rapido, sin reabrir toda la historia del deploy.

Preguntas frecuentes

Vale la pena enviar correo si ya existe Slack o PagerDuty?

Si, cuando el correo sirve como registro legible para seguimiento, handoff y postmortem. No debe competir con la alerta primaria; debe completar el contexto.

Cuantos enlaces meto dentro del correo?

Pocos. Normalmente runbook, dashboard y canal del incidente. Si agregas ocho enlaces, nadie sabe cual abrir primero.

Que error veo mas seguido?

Confundir detalles tecnicos con claridad operativa. Un correo puede estar tecnicamente correcto y aun asi ser dificil de usar. Esa diferencia importa mas de lo que parece, y aveces se descubre solo despues de varias guardias.

Si tu bandeja de incidentes hoy se siente pesada, yo empezaria por una cosa: recortar el correo hasta que cualquier persona del equipo entienda impacto, accion y siguiente update en menos de 20 segundos. No es glamuroso, pero funciona muy bien.