Cuando un despliegue sale mal, el primer correo de rollback suele llegar tarde y con poca sustancia. Dice que hubo un problema, que se revirtio el cambio y que el equipo sigue mirando. Eso calma un poco, pero no orienta casi nada. La guardia siguiente todavia tiene que abrir dashboards, comparar logs y perseguir el contexto por varios lados.
En equipos de SRE eso pasa mas de lo que admitimos. No es falta de capacidad; es que el mensaje se escribe con presion, aveces desde el movil, y termina siendo una mezcla de disculpa, estado parcial y promesa de revisar despues. Mi regla es simple: si el correo no ayuda a decidir la siguiente accion en menos de un minuto, entonces no esta listo.
El problema aparece cuando el rollback solo dice que fallo algo
He visto correos con frases como "rollback ejecutado sin novedades" justo despues de una degradacion de latencia que aun no estaba clara. El error ahi no es tecnico, es de estructura. El mensaje resume una accion, pero no deja evidencia suficiente para saber si el riesgo bajo de verdad o solo cambio de forma.
Un correo operativo de rollback deberia responder estas preguntas:
- Que cambio exacto se revirtio.
- Que sintoma forzo la decision.
- Que indicadores mejoraron y cuales siguen bajo observacion.
- Que debe revisar la siguiente persona y en cuanto tiempo.
Cuando falta una de esas piezas, la organizacion vuelve a depender de memoria oral. Eso es fragil, sobre todo en Cloud, donde varios cambios pequenos pueden coincidir dentro de la misma ventana. Tambien vuelve mas dificil separar un fallo de aplicacion de uno de configuracion o de red.
En ese punto me ayuda pensar el correo como una entrega minima de evidencia, no como un resumen bonito. Algo parecido a los recibos async para correos operativos: no basta con decir "se envio", hay que dejar trazas que otra persona pueda seguir sin inventar el resto.
La evidencia minima que pongo en cada correo
Mi plantilla mental para estos mensajes tiene seis bloques:
- servicio afectado
- version o change set revertido
- sintoma que disparo el rollback
- evidencia actual despues del rollback
- riesgo residual
- siguiente punto de verificacion
No necesita mucha prosa. De hecho, cuanto mas delicada fue la noche, mas me conviene escribir corto y preciso. Una linea como "p95 volvio a rango en 12 min, 5xx sin crecimiento, cola de trabajos estable" vale mucho mas que "parece resuelto". Esa segunda frase suena tranquila, pero es poco operable.
Tambien intento dejar una referencia al historial del intento para que otro ingeniero no reconstruya todo desde cero. El enfoque de registrar intentos de email sin perder contexto me gusta porque aplica bien a incidentes: cada mensaje deberia apuntar a un hecho verificable, no solo a una impresion del turno.
Si ademas hubo una alerta a clientes internos o a otro equipo, anoto si el correo salio desde una cuenta de correo desechable de laboratorio o desde el flujo real. Esa distincion evita malentendidos cuando alguien revisa capturas, headers o rebotes unas horas despues.
Como valido el mensaje antes de abrir la ventana
Antes de una ventana de mantenimiento yo no pruebo estos correos en la misma bandeja de siempre. Prefiero una cuenta de correo desechable aislada para confirmar asunto, enlaces, orden del cuerpo y tiempos de entrega. No es un truco raro; es solo separar escenarios para no mezclar evidencia real con pruebas.
Para esa validacion rapida me sirve tempmailso cuando quiero una bandeja limpia por cada intento. Si alguien del equipo busca una opcion tipo temp mail com, yo le diria que mire tres cosas: expiracion clara, lectura veloz del mensaje y cero friccion para repetir pruebas. Lo importante no es la marca; es que la prueba deje un rastro util y facil de descartar despues.
Tambien suelo insertar cadenas controladas como temp mailid o tempail en entornos de prueba. Son terminos feos, si, pero me ayudan a detectar validaciones demasiado agresivas, sanitizadores mal ajustados o reglas que disparan falsos positivos. Es una comprobacion pequena, aunque me salvo varias veces de un bug tonto antes de tocar produccion.
Si quieres sumar una referencia objetiva a tu checklist, la guia de Google SRE sobre comunicacion y coordinacion en incidentes insiste en dejar estado observable y accion siguiente, no solo narracion general. Vale la pena releer ese enfoque cuando el equipo empieza a escribir correos demasiado blandos.
Una plantilla corta para cambios con riesgo real
Esta es la estructura minima que suelo recomendar:
Asunto: [ROLLBACK] api-gateway tras degradacion en prod-eu
Estado actual: estable con observacion
Cambio revertido: release 2026.08.10-3
Sintoma inicial: aumento de 5xx y p95 fuera de rango
Evidencia actual: errores estabilizados, cola normal, CPU sin picos
Riesgo residual: revisar latencia en prox 30 min
Siguiente accion: validar canary a las 02:40 UTC
Enlaces: dashboard, logs, change set, runbook
No es una plantilla elegante, pero resiste bien la presion. Y eso importa mas que sonar brillante. Si el correo sale con evidencia minima, la guardia siguiente puede decidir rapido si basta observar o si conviene escalar. Si sale lleno de frases vagas, el trabajo se duplica y el cansancio pega peor.
Preguntas frecuentes
Conviene mandar un correo si ya hay alertas en Slack?
Si, porque el correo deja un hilo facil de buscar cuando revisas una semana despues por que cierto rollback se ejecuto. Slack sirve para coordinar, pero no siempre conserva una historia clara del cambio.
Cuanto detalle tecnico deberia poner?
Solo el que ayude a verificar estado y siguiente accion. Si pegas demasiados logs, nadie ve el dato importante. Si pegas cero evidencia, obligas a rehacer la investigacion y eso no escala bien.
Cual es el error mas comun?
Escribir "rollback completado" como si eso cerrara el incidente. El rollback es una accion, no un veredicto. Todavia queda confirmar si el sistema de verdad recupero sus senales normales.
Si tu equipo todavia discute estos correos mensaje por mensaje, yo empezaria por fijar una plantilla minima y probarla antes de cada ventana. Parece poca cosa, pero ordena bastante el trabajo real y reduce ese caos chico que luego se vuelve incidente grande.
Top comments (0)