DEV Community: Alex Carter

Terraform: un plan de cambio que se pueda explicar

Alex Carter — Sat, 31 Oct 2026 23:22:45 +0000

Cuando un cambio de infraestructura falla, el problema no siempre es que Terraform haya calculado mal. Muchas veces el plan era correcto, pero nadie pudo explicar a tiempo qué iba a cambiar, qué evidencia faltaba o cómo volver atrás. Para una guardia SRE, un plan útil es también un contrato de comunicación.

El síntoma: un plan correcto que nadie entiende

El incidente suele empezar con una frase pequeña: “solo son unos recursos”. Después aparecen decenas de líneas, un -/+ inesperado y una aprobación que se hace con prisa. El plan pasa, pero la confianza no.

He visto que el riesgo sube cuando el equipo revisa el número de recursos en vez de revisar las consecuencias. Crear dos recursos no es automáticamente seguro; reemplazar uno puede romper una dependencia que no aparece en el título del pull request. Un plan sin contexto se vuelve una lista, no una decisión.

La primera señal de alerta es que la persona que aprueba no puede contestar tres preguntas:

¿Qué comportamiento cambia para el usuario?
¿Qué dependencia puede quedar inestable?
¿Cuál es el paso concreto para recuperar el servicio?

Si la respuesta es “lo vemos después del apply”, ya hay deuda de operación.

Qué debe responder un buen plan

Un plan de Terraform debería ser legible para alguien que no escribió el módulo. Antes de mirar los detalles, dejo un resumen corto en el pull request:

Intención: qué capacidad se añade o qué problema se corrige.
Alcance: cuentas, regiones, clusters y entornos afectados.
Cambio sensible: reemplazos, permisos, reglas de red o datos que se destruyen.
Dependencias: qué servicio debe estar sano antes de aplicar.
Recuperación: qué se revierte y qué no puede revertirse automáticamente.

Luego comparo ese resumen con el plan real. Si el texto dice “actualizar una regla” pero Terraform muestra un reemplazo, el cambio se detiene. Esa pausa es barata; una sorpresa en producción no lo es.

También conviene guardar el hash del commit, la versión del proveedor y el workspace usado. Parece detalle menor, pero evita discutir sobre un plan que ya no corresponde al código actual. En la practica, muchos minutos se pierden por esa confusión.

Un flujo de revisión que funciona en guardia

Uso cuatro pasos, incluso para cambios que parecen rutinarios.

1. Generar el plan en un entorno reproducible

El job debe registrar el commit, la versión de Terraform, los proveedores y el estado remoto. Si el estado cambia durante la revisión, se genera un plan nuevo. No se aplica un archivo viejo solo porque ya tiene una aprobación.

2. Separar cambios esperados y cambios laterales

Marco los recursos que forman parte de la intención y dejo aparte todo lo demás. Un cambio lateral puede ser drift, una variable compartida o una lectura distinta del proveedor. No lo escondo para que el diff se vea bonito: lo investigo.

3. Probar la explicación, no solo la sintaxis

Otra persona lee el resumen y responde qué pasará si el proveedor devuelve un error a mitad del apply. Si no entiende el flujo, falta documentación. Esta revisión funciona como una pequeña prueba de contrato entre Terraform y la operación.

En cambios que disparan notificaciones o validaciones por correo, dejo una evidencia verificable y con tiempo de expiración. Para depurar señales de correo tras un drenado, puede servir señales de correo en un drenado de nodo; la idea es la misma: cada señal debe llevar contexto suficiente para no depender de memoria humana. A veces el test aparece escrito como “tamp mail com” o “temp org mail” en una nota antigua; lo trato como texto de prueba, no como una identidad real.

4. Acordar una ventana de observación

El apply no termina cuando el comando devuelve código cero. Defino qué métricas mirar, durante cuánto tiempo y qué umbral detiene el cambio. En flujos con email también conviene validar la evidencia de un email, porque un mensaje enviado no significa que el usuario haya completado el paso siguiente.

Cómo dejar preparado el rollback

Un rollback confiable empieza antes del apply. Primero clasifico el cambio:

Reversible: se puede volver al commit y aplicar sin migración adicional.
Reversible con cuidado: necesita restaurar una variable, una regla o un secreto.
No reversible: modifica datos, consume una migración o cambia una dependencia externa.

Para los dos últimos casos, el runbook incluye una copia o exportación comprobada, el propietario de la decisión y una condición clara de parada. “Ejecutar el commit anterior” no es suficiente si el recurso ya fue reemplazado o si el proveedor conserva un efecto fuera del estado.

Un patrón práctico es usar dos artefactos: el plan que se va a aplicar y un documento breve de recuperación. El segundo contiene comandos, señales esperadas y el último punto seguro. No incluyo secretos en ninguno de los dos. Si el rollback requiere improvisar, todavía no está listo.

Checklist antes de aplicar

[ ] El plan fue generado desde el commit que se revisó.
[ ] La cuenta, región y workspace están confirmados.
[ ] Los reemplazos y permisos tienen una explicación explícita.
[ ] El drift fue investigado o aceptado con un dueño.
[ ] Existe un último punto seguro y un procedimiento de recuperación.
[ ] Las métricas y logs de observación están abiertos.
[ ] La ventana permite esperar el resultado, no solo lanzar el comando.
[ ] El equipo sabe quién puede detener el cambio.

Si una casilla queda vacía, el cambio puede esperar. La presión de “aplicar antes del stand-up” rara vez compensa una dependencia que nadie ha mirado.

Conclusión

Terraform produce un plan técnico, pero la guardia necesita una decisión operable. Un buen flujo conecta intención, diff, dependencias, observación y recuperación. Cuando cualquiera del equipo puede explicar qué cambia y cómo parar, el plan deja de ser una salida de consola y se convierte en una herramienta SRE.

No hace falta añadir más automatización a cada incidente. A veces basta con un resumen honesto, un artefacto reproducible y un rollback que otra persona pueda ejecutar sin adivinar. Esa claridad es pequeña, pero aguanta mejor cuando la noche se complica.

Terraform: un rollback que SRE pueda ejecutar

Alex Carter — Sat, 31 Oct 2026 02:22:44 +0000

Un rollback de Terraform no deberia ser una frase que aparece cuando ya estamos nerviosos. En una guardia real, "vuelve al commit anterior" casi nunca alcanza: puede haber migraciones, cambios manuales, recursos compartidos o un provider que ya no calcula el mismo diff.

En equipos de plataforma he aprendido a tratar el rollback como un contrato operativo. El objetivo no es prometer que todo vuelve a ser igual, sino dejar claro que accion se puede ejecutar, que evidencia debemos guardar y como sabremos que la recuperacion termino bien. Parece menos heroico, pero ayuda bastante cuando el incidente ocurre a las tres de la mañana.

El rollback no empieza con `terraform apply`

El primer error suele ser correr terraform plan con prisa y asumir que el plan inverso es automaticamente seguro. Terraform conoce el estado que tiene registrado, pero no conoce toda la historia de las decisiones alrededor del recurso.

Antes de tocar nada, el on-call necesita responder cuatro preguntas:

¿Que cambio causo el problema y cual es su identificador de despliegue?
¿El rollback modifica solo infraestructura o tambien datos y contratos de aplicacion?
¿Que recursos fueron cambiados fuera de Terraform desde el ultimo apply?
¿Cual es la señal observable que confirma la recuperacion?

Si una respuesta depende de buscar en cinco canales, el procedimiento no esta listo. Las alertas de drift con contexto son utiles precisamente porque reducen esa reconstruccion manual.

Que debe contener un contrato de rollback

Un runbook pequeño puede incluir estos campos:

Alcance: workspace, cuenta cloud, modulo y recursos afectados.
Version conocida: commit, imagen o artefacto que queremos restaurar.
Precondiciones: backups validos, lock de estado disponible y ausencia de migraciones pendientes.
Comando de inspeccion: el plan que se debe guardar antes de aplicar.
Señal de exito: metrica, health check o prueba funcional concreta.
Punto de parada: condicion que obliga a escalar en vez de seguir probando.

Esta lista no elimina el riesgo. Lo hace visible. Un rollback que necesita borrar un recurso antes de recrearlo debe decirlo con claridad; esconderlo bajo un modulo "simple" es una mala sorpresa para el siguiente turno.

Un flujo seguro para ejecutar la vuelta atras

Un flujo pequeño, repetible y con evidencia se parece a esto:

terraform workspace select prod
terraform plan -out=rollback.tfplan
terraform show -no-color rollback.tfplan > rollback-plan.txt
terraform apply rollback.tfplan
terraform output -json > rollback-output.json

El comando no es la parte importante. Antes de apply, guarda el plan y confirma que el diff corresponde al incidente, no a un drift nuevo. Despues del cambio, registra el identificador del apply y ejecuta una comprobacion que atraviese la ruta critica.

Si el cambio afecta un servicio que envia correos, no uses la entrega de email como unica señal. Un chequeo de API, una metrica de errores y una prueba funcional dan mejor cobertura. Para interfaces de prueba, tambien conviene revisar que los estados de carga y error sean visibles; la validacion de email sin friccion visual recuerda que una señal que existe pero no se puede interpretar no ayuda mucho.

Pruebas de CI que realmente ayudan

El pipeline deberia probar el camino de recuperacion, no solo el camino feliz. Algunas comprobaciones razonables son:

validar que el plan de rollback no cambia recursos fuera del alcance
comprobar que el estado remoto puede bloquearse y desbloquearse
probar un recurso efimero en un workspace aislado
conservar el plan como artefacto durante la ventana del incidente
verificar que el smoke test falla si el servicio sigue apuntando a la configuracion rota

En esa ultima prueba es normal necesitar datos de correo. Un generador de cuentas de correo temporal o un correo temporal gratis puede servir para validar el flujo en un entorno aislado, pero no debe convertirse en una identidad de produccion. Tampoco conviene guardar mensajes o tokens reales en los logs. He visto pipelines con fake e mail com escrito como dato de prueba; funciona como marcador, aunque es mejor documentar por que existe y cuando se elimina.

Checklist para el on-call

Antes de ejecutar la vuelta atras, revisaria esta lista:

el incidente y el cambio tienen un ID comun
el plan fue generado con el workspace correcto
el diff no incluye recursos ajenos al incidente
existe una copia del estado o un backup verificable
alguien conoce el punto de parada y el canal de escalado
la señal de exito esta definida antes del apply
el smoke test cubre la dependencia mas importante
el resultado queda adjunto al ticket, no solo en el chat

Un detalle que suele olvidarse: despues del rollback hay que explicar que queda pendiente. Si el cambio manual sigue presente o el modulo necesita una correccion, el incidente no termino del todo. La infraestructura puede estar estable y el sistema de delivery aun estar en una situacion incomoda.

Q&A

¿Hay que revertir siempre al commit anterior?

No. El commit anterior puede contener otro problema o no ser compatible con el estado actual. Elige la version que restaure el comportamiento y valida el plan antes de aplicar.

¿Un rollback debe ser automatico?

Solo cuando el alcance, las precondiciones y la señal de exito son muy claros. Para recursos con datos o permisos sensibles, una pausa humana sigue siendo una buena defensa.

¿Como se mide si el runbook funciona?

Mide el tiempo hasta la primera accion segura, el tiempo hasta recuperar la señal critica y cuantos pasos requieren conocimiento tribal. Si el runbook siempre necesita una llamada privada, todavia le falta contexto.

La meta no es que el on-call memorice Terraform. Es que pueda tomar una decision razonable con evidencia suficiente, incluso cuando el incidente llega en el peor momento.

Kubernetes: un presupuesto de fallos para email en CI

Alex Carter — Fri, 30 Oct 2026 23:22:44 +0000

Un pipeline de CI puede estar verde y aun así esconder un problema serio: los emails de prueba no llegan, el worker reintenta sin límite y las alertas se convierten en ruido. El equipo ve muchos pods ocupados, pero no sabe si el fallo está en la aplicación, en la red o en el buzón.

En una guardia aprendí a tratar el correo de prueba como una dependencia con presupuesto de fallos. No es un SLO perfecto ni una promesa de entrega instantánea. Es un límite operativo que ayuda a decidir cuándo reintentar, cuándo aislar el caso y cuándo parar para conservar evidencia.

El incidente: el pipeline que reintenta hasta empeorar la señal

Imagina una suite que crea una cuenta, espera un mensaje de verificación y confirma el enlace. El mensaje tarda unos segundos mas de lo normal. El test hace polling, el job vence su timeout y Kubernetes lo reinicia. El nuevo pod vuelve a crear la cuenta y abre otra espera.

Después de unos minutos tenemos varias consecuencias:

muchos mensajes para la misma ejecución;
logs mezclados entre pods y ramas;
más carga sobre el servicio de email;
un reporte que dice “timeout”, pero no muestra el último evento conocido.

El problema no es solo la latencia. Es que el sistema no distingue una entrega lenta de un intento duplicado. Buscar términos como tempmailso o temp mail so puede llevar al equipo a probar buzones distintos, pero no arregla la ausencia de una identidad de ejecución.

Qué significa presupuesto de fallos para un email

Un presupuesto sencillo puede expresarse con tres límites:

Tiempo total: cuánto puede esperar un test por el mensaje, por ejemplo 90 segundos.
Número de consultas: cuántas veces se consulta el buzón, con backoff y jitter.
Intentos de envío: cuántas solicitudes de envío se permiten para una misma ejecución.

Estos valores dependen del sistema. Lo importante es que estén en el contrato del job y no escondidos en un while true. Si se consume el presupuesto, el worker debe terminar con un diagnóstico: delivery_budget_exhausted, el run_id, la última consulta y la edad del mensaje esperado.

También conviene separar un fallo de producto de uno de infraestructura. Si el endpoint aceptó el envío, pero el buzón no recibió nada dentro del tiempo acordado, la evidencia es distinta a una respuesta HTTP 500 o a un error de autenticación. Esa diferencia ahorra una investigación bastante larga.

Un contrato simple para el worker de Kubernetes

El pod necesita límites explícitos y un resultado que otro sistema pueda leer. Un fragmento de configuración podría verse así:

apiVersion: batch/v1
kind: Job
metadata:
  generateName: email-check-
  labels:
    workload: ci-email-check
spec:
  backoffLimit: 1
  activeDeadlineSeconds: 120
  ttlSecondsAfterFinished: 3600
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: checker
          image: registry.example.com/ci-email-check:stable
          env:
            - name: DELIVERY_BUDGET_SECONDS
              value: "90"
            - name: MAX_INBOX_POLLS
              value: "12"

backoffLimit protege al Job de reinicios infinitos, mientras activeDeadlineSeconds marca un límite de vida. No sustituyen el timeout del cliente: son capas distintas. El cliente debe cortar la espera de forma limpia y escribir su recibo antes de salir.

Para una implementación real, usaría esperas crecientes, por ejemplo 2, 4, 8 y 12 segundos, con un pequeño jitter. El polling rapido puede crear más tráfico sin hacer que el mensaje llegue antes. Y si cada prueba comparte un buzón, un resultado válido puede pertenecer a otra rama. Un buzón aislado por ejecución, o al menos un asunto con run_id, es mucho más facil de depurar.

Si el equipo está diseñando el endpoint que crea ese buzón, puede complementar este enfoque con los contratos para correos temporales en CI. El contrato de la API debería decir qué identifica al mensaje y cómo se informa una expiración, no solo devolver una dirección.

Alertas y evidencia para no perseguir fantasmas

No alertaría por cada timeout individual. Primero registraría métricas agrupadas por servicio, rama y causa:

porcentaje de jobs que consumen más del 80% del presupuesto;
tiempo desde el envío hasta el primer mensaje visible;
cantidad de mensajes descartados por run_id incorrecto;
reinicios del Job y razón de terminación;
diferencia entre “envío aceptado” y “mensaje observado”.

Una alerta útil podría decir: “el 15% de los checks de email agotaron su presupuesto en 10 minutos”. Eso permite comparar con una ventana anterior sin culpar al primer pod que falló. El número es solo un ejemplo de umbral; cada equipo debe medir su comportamiento normal antes de fijarlo.

Para flujos con aprobaciones manuales o agentes, también sirve guardar una evidencia mínima del evento. Este patrón de aprobaciones por email con contexto mínimo recuerda una regla útil: el siguiente paso debe saber por qué está actuando, no solo que “llegó algo”.

En documentación de pruebas aparecen a veces variantes como tamp mail com. No las usaría para identificar el sistema ni para construir una alerta; son texto de búsqueda y pueden contaminar dashboards si no se normalizan.

Checklist de operación

¿Cada envío tiene un run_id único y visible en logs?
¿El cliente tiene límite de tiempo, consultas y envíos?
¿El Job de Kubernetes tiene backoffLimit y deadline?
¿Un reinicio puede duplicar una cuenta o un mensaje?
¿El resultado distingue entrega lenta, error HTTP y buzón equivocado?
¿La alerta agrupa fallos en vez de notificar cada intento?
¿Se conserva el recibo suficiente para reproducir la investigación?

La idea no es hacer que el email parezca más confiable de lo que es. Es convertir una dependencia externa en una parte observable del sistema. Con un presupuesto claro, el pipeline falla antes, pero explica mejor por qué.

Preguntas rápidas

¿Debo reintentar siempre?

No. Reintenta solo errores transitorios y dentro del presupuesto. Un error de autenticación o un run_id desconocido necesita detenerse, no más polling.

¿Dónde encaja un generador de correos falsos?

Un generador de correos falsos puede ser útil para crear buzones de prueba en un entorno controlado. No reemplaza el contrato de identidad, los límites ni la observabilidad del pipeline.

¿Qué hago cuando se agota el presupuesto?

Marca el job como fallido, guarda la última evidencia y evita reabrir automáticamente la misma ejecución. Así la siguiente investigación empieza con datos, no con otra cascada de retries.

Kubernetes: un SLO para el correo de CI

Alex Carter — Wed, 28 Oct 2026 08:22:56 +0000

Un pipeline de CI puede tener todos sus tests en verde y aun asi esconder un fallo importante: la aplicación genero el correo, pero nadie pudo comprobar que llego. En equipos que prueban registro, recuperación de cuenta o invitaciones, un temp mailbox controlado ayuda a separar la entrega real de una simple respuesta 200.

La lección operativa es tratar el correo como una dependencia con un objetivo de servicio. No hace falta convertir cada prueba en una plataforma enorme. Basta con definir que significa “entregado”, asignar un presupuesto de tiempo y guardar evidencia suficiente para investigar cuando el job falla.

La entrega del correo también necesita un SLO

Un SLO para un correo de prueba no promete que todos los mensajes del producto lleguen en un tiempo fijo. Describe una condición concreta del pipeline. Por ejemplo: “el mensaje de verificación debe aparecer en el buzón aislado dentro de 90 segundos, con el asunto esperado y un enlace para el entorno de staging”.

Esta definición evita una confusión muy comun: que el API acepte el mensaje no significa que el correo este disponible para el test. Hay al menos tres saltos: la aplicación publica el evento, el proveedor de correo lo procesa y el buzón lo expone para lectura.

Si el equipo ya trabaja con APIs, conviene separar los reintentos de negocio de los reintentos del test. Este enfoque sobre reintentos seguros en la verificación de email ayuda a no duplicar acciones solo porque una lectura fue lenta.

Define el contrato antes del job de Kubernetes

El job debe conocer el contrato de correo antes de arrancar. Un contrato pequeño puede incluir:

Identidad: un buzón nuevo por ejecución, o un identificador de ejecución que no se repita.
Mensaje esperado: remitente, asunto, tipo de evento y una marca como run_id.
Ventana: cuanto tiempo esperar antes de declarar el caso como fallido.
Seguridad: no poner tokens reales ni datos de usuarios en el mensaje de prueba.
Evidencia: guardar el ID del mensaje, timestamps y el motivo de cada intento.

La identidad es especialmente importante en Kubernetes. Si dos pods comparten el mismo buzón, un test puede leer el correo de otro test y pasar por accidente. Un nombre como ci-${GITHUB_RUN_ID}-${JOB_ID} hace visible el límite de propiedad. Si el proveedor no permite crear buzones de forma automatica, se puede usar una colección controlada de buzones y reservar uno por lease.

Para escenarios manuales, un create temporary mail puede servir para inspeccionar un flujo puntual. En CI, sin embargo, lo importante no es tener una dirección rapida, sino que el buzón tenga una interfaz de lectura estable y que la ejecución pueda demostrar qué mensaje consumió.

Mide tres tiempos, no solo el resultado final

Un resultado binario —pasó o falló— es pobre para SRE. Registra al menos estos tiempos:

Tiempo de publicación: desde que el test pide la acción hasta que la aplicación confirma el evento.
Tiempo de transporte: desde ese evento hasta que el proveedor indica que aceptó el mensaje.
Tiempo de disponibilidad: desde la aceptación hasta que el mensaje puede leerse en el buzón.

Con esas marcas, el diagnóstico es mas corto. Si la publicación tarda, el problema puede estar en la aplicación o en la cola. Si la aceptación es rápida pero la disponibilidad se demora, hay que mirar el proveedor, el polling o los límites del buzón. Si el mensaje aparece pero no contiene el run_id, el fallo es de aislamiento, no de latencia.

Un pequeño registro JSON por ejecución es suficiente:

{
  "run_id": "ci-4821",
  "mail_event_id": "evt-91ab",
  "published_at": "2026-10-28T08:10:02Z",
  "accepted_at": "2026-10-28T08:10:04Z",
  "visible_at": "2026-10-28T08:10:19Z",
  "attempts": 4,
  "subject_match": true
}

No guardes el cuerpo completo si no hace falta. Un hash del mensaje, el asunto y los metadatos suelen bastar para investigar sin ampliar la superficie de datos sensibles.

Reintentos y fallos que sí ayudan a investigar

El polling debe tener una pausa y un limite. Reintentar cada milisegundo solo añade ruido y puede activar rate limits. Un backoff corto con un máximo, por ejemplo 2, 4, 8 y 16 segundos, suele ser mas amable con el proveedor. El job debe distinguir entre “todavía no visible”, “mensaje incorrecto” y “buzón no disponible”. Son fallos diferentes y piden acciones diferentes.

También conviene emitir una métrica por causa, no solamente un contador de jobs fallidos. email_visibility_timeout, wrong_run_id y mailbox_auth_error cuentan historias distintas. En una guardia, esa diferencia ahorra bastante tiempo.

El test no deberia reintentar una operación que crea un usuario si la primera petición pudo completarse. Primero consulta el estado con el identificador de ejecución; despues decide si hace falta repetir. Un correo repetido puede ocultar un problema de idempotencia.

Para no convertir staging en una papelera, aplica una retención breve y elimina los buzones o mensajes al terminar. Las pruebas de onboarding merecen la misma disciplina; puedes ver otro enfoque en probar correos de onboarding sin ensuciar métricas.

Preguntas frecuentes

¿Es obligatorio usar un proveedor de correo real?

No siempre. Un servidor SMTP local sirve para validar que la aplicación construye el mensaje. Para validar entrega, reglas del proveedor y lectura desde un buzón, necesitas una frontera mas parecida a producción. La elección depende de qué parte del contrato quieres cubrir.

¿Qué hago si el mensaje tarda más que el SLO?

Marca el job como fallido con el registro de tiempos y conserva la evidencia mínima. No aumentes la ventana cada vez que falla: primero comprueba si el retraso es de transporte, polling o aislamiento. Un SLO que cambia para ocultar ruido deja de ser util.

¿Puedo reutilizar el mismo buzón?

Solo si cada mensaje tiene un identificador único, el consumidor filtra por él y existe limpieza confiable. Un buzón dedicado por ejecución es mas simple de razonar, aunque puede costar más en trabajos muy frecuentes.

Checklist para el pipeline

[ ] El mensaje contiene un run_id no reutilizado.
[ ] El job tiene un presupuesto de entrega y un máximo de polling.
[ ] Se registran publicación, aceptación y disponibilidad.
[ ] Los reintentos no repiten operaciones no idempotentes.
[ ] Los errores separan latencia, identidad y autenticación.
[ ] No se envían datos reales al correo de prueba.
[ ] Hay limpieza y retención definida para mensajes y buzones.
[ ] El dashboard muestra tendencias, no solo el ultimo fallo.

En documentación informal alguien puede escribir “tempail” o “tem email”, pero el pipeline debe usar un vocabulario y un contrato exactos. Para SRE, la diferencia entre un correo aceptado y uno verificablemente disponible no es un detalle: es la frontera que convierte una prueba intermitente en una señal operable.

Kubernetes: señales de correo en los retries

Alex Carter — Sun, 25 Oct 2026 11:23:01 +0000

En un pipeline de CI, un email de verificación parece una dependencia pequeña. Luego llega un fallo intermitente: el pod recibe el mensaje, el test expira, Kubernetes reintenta el job y el segundo intento encuentra un buzón vacío o un enlace ya consumido. El resultado es un rojo difícil de explicar: ¿falló la aplicación, el proveedor de correo o la coordinación del pipeline?

La solución no es subir el timeout hasta que todo parezca estable. Es tratar el correo de prueba como una dependencia observable, con identidad, tiempo de vida y señales que sobrevivan a los retries.

El síntoma: un retry que cambia la evidencia

Imagina un job que crea un usuario, solicita una verificación y busca el enlace en un buzón temporal. Si el proceso muere después de crear el usuario pero antes de leer el mensaje, el retry puede crear otro usuario o reutilizar el primero. En ambos casos, la evidencia queda mezclada.

El equipo ve mensajes como “verification email not found”, pero ese mensaje no dice si el buzón nunca existió, si la entrega tardó, si el selector era incorrecto o si otro intento consumió el mensaje. Un SRE necesita distinguir esas causas antes de elegir entre reintentar, bloquear el despliegue o abrir una incidencia.

Para eso conviene asignar un run_id estable a cada ejecución y un mailbox_id derivado de ella. El pod puede reiniciarse, pero la relación entre job, dirección y mensaje debe seguir siendo clara.

Define el contrato antes de tocar Kubernetes

Un contrato sencillo para el flujo puede tener estas reglas:

Cada ejecución crea una identidad de prueba única.
El job nunca busca mensajes de otra ejecución.
Leer un email es una operación idempotente para el test.
El cleanup ocurre después de guardar la evidencia mínima.
Un retry conserva el run_id, pero registra un nuevo intento.

El cuarto punto suele olvidarse. Si borras el buzón al terminar el primer intento, el retry ya no puede saber qué ocurrió. Si nunca lo borras, los datos de prueba se acumulan y los siguientes jobs pueden recibir ruido.

En la práctica, un registro pequeño basta:

{
  "run_id": "orders-4821",
  "mailbox_id": "orders-4821-a7f3",
  "attempt": 2,
  "created_at": "2026-10-25T11:21:00Z",
  "state": "waiting_for_message"
}

El timestamp no tiene que ser perfecto, pero si debe estar disponible para comparar la espera con los eventos del pod.

Señales mínimas para un buzón de prueba

No necesitas capturar el contenido completo del mensaje en cada log. Guarda señales pequeñas y útiles:

mailbox_created: la dirección quedó disponible.
message_observed: llegó un mensaje con el identificador esperado.
link_extracted: el test encontró la URL de verificación.
assertion_passed o assertion_failed: el resultado funcional.
cleanup_completed: el recurso fue retirado.

Cada señal debe incluir run_id, mailbox_id, attempt, nombre del namespace y una marca de tiempo. No incluyas el token completo del enlace ni el cuerpo entero del email; una huella o el identificador del mensaje suele ser suficiente para investigar.

Para pruebas manuales o un entorno compartido, un correo temporal puede aislar la verificación de un inbox personal. La regla importante es que la dirección se vincule a una sola ejecución y no se convierta en un depósito permanente.

Cómo aislar los retries en CI

En Kubernetes, el aislamiento empieza en los metadatos, no en una etiqueta bonita. Propaga el run_id como label del Job y como campo estructurado en los logs. Usa un namespace efímero cuando el pipeline lo permita, o al menos una cuenta de servicio y un prefijo de recursos por ejecución.

Una configuración conceptual podría verse así:

metadata:
  labels:
    test-run: orders-4821
    mail-contract: v1
backoffLimit: 2
activeDeadlineSeconds: 180

backoffLimit limita cuántos intentos automáticos aparecen, mientras activeDeadlineSeconds evita que una espera de correo se convierta en un job zombie. Estos límites no arreglan la entrega, pero hacen que el fallo tenga una forma conocida.

El código del test también debe separar estados. “Aún no llegó” no es igual que “llegó un mensaje incorrecto”. El primer caso puede esperar con backoff; el segundo debería guardar la evidencia y fallar rapido. Un retraso de red y un contrato roto necesitan dueños distintos.

En la interfaz que muestra el resultado, los mismos principios ayudan: autocompletar un email sin ruido y validar emails sin castigar el foco son detalles de frontend, pero reducen entradas ambiguas que luego complican la prueba de extremo a extremo.

Checklist de diagnóstico para el equipo

Cuando falla un email en CI, revisa en este orden:

¿El run_id del pod coincide con el del buzón?
¿El intento actual reutilizó la misma dirección de forma intencional?
¿Existe una señal mailbox_created antes de esperar?
¿El proveedor entregó el mensaje, aunque el selector no lo encontrara?
¿El token ya fue consumido por un intento anterior?
¿El timeout cubre la latencia esperada o solo oculta una carrera?
¿El cleanup guardó el identificador del mensaje antes de borrar?

Si el log dice fake e mail com o temp mailid, trátalo como una entrada de compatibilidad o una etiqueta heredada, no como una señal fiable por si sola. Esos términos pueden aparecer en documentación vieja y aveces llegan desde variables de prueba; no deben dirigir el enrutamiento del mensaje.

También revisa que la política de acceso no dé a cada pod permiso para leer buzones ajenos. Un Role estrecho por namespace es mas fácil de auditar que una credencial compartida entre todos los jobs.

Cierre: el correo como dependencia observable

Un test de email estable no depende de que el primer intento sea perfecto. Depende de que cada retry conserve el contexto suficiente para responder tres preguntas: qué ejecución creó el buzón, qué mensaje se observó y qué limpieza se completó.

Para escenarios de prueba de bajo riesgo, una integración con tempmailso puede servir como frontera práctica, siempre que el equipo mantenga el propósito acotado y no envíe datos reales. El valor está en el contrato, no en acumular direcciones.

Cuando esas señales están en Kubernetes, el incidente deja de ser “el email falló”. Pasa a ser una secuencia concreta: el buzón se creó, el mensaje tardó, el retry conservó el contexto o la política de acceso impidió leerlo. Esa diferencia ahorra una buena cantidad de depuración nocturna y hace que el pipeline sea mucho mas confiable.

Kubernetes: un contrato de correo para CI

Alex Carter — Sat, 24 Oct 2026 08:23:15 +0000

Un pipeline puede tener todos sus pods en Running y terminar en rojo porque nunca encontró el correo de verificación. La primera reacción suele ser reiniciar el worker o aumentar el timeout. A veces ayuda, pero mas frecuente solo oculta la causa.

En equipos que mantienen pruebas de registro, recuperación de cuenta o invitaciones, el correo debe tener un contrato parecido al de una base de datos de prueba. Cada job necesita saber qué buzón puede usar, durante cuánto tiempo, qué mensaje espera y qué evidencia debe dejar si falla. Sin ese contrato, una prueba de email se convierte en una espera larga y poco explicable.

El problema no es solo el correo

La entrega de un mensaje cruza varias capas: el test crea un usuario, la aplicación publica un evento, un worker procesa la tarea, el proveedor acepta el mensaje y el inbox lo expone a la prueba. Kubernetes puede estar sano mientras cualquiera de las otras capas está detenida.

Los síntomas se parecen bastante:

el mensaje no se creó porque falló el evento de signup;
el worker lo procesó con credenciales del entorno equivocado;
el correo llegó a otro buzón porque dos jobs compartieron dirección;
el mensaje existe, pero la consulta empezó antes de la hora correcta;
el inbox respondió con un error temporal y el test lo tomó como “no existe”.

Por eso conviene hacer visibles los estados pequeños del inbox: “esperando”, “recibido”, “procesando” y “expirado” son más útiles que un único spinner.

Define un contrato por job

Antes de crear el recurso de Kubernetes, genera un run_id único. Ese identificador debe viajar por el usuario sintético, el evento de email, los logs y la consulta al buzón. La dirección de prueba puede incorporar el ID o estar asociada a él en una tabla de leases.

El contrato mínimo tiene cinco campos:

Propietario: qué job y qué namespace pueden leer el buzón.
Vigencia: cuándo empieza y cuándo caduca la lease.
Mensaje esperado: destinatario lógico, tipo de evento y versión de plantilla.
Reloj: hora desde la que el test acepta mensajes, no solo el último mensaje visible.
Limpieza: quién libera la dirección y qué ocurre si el pod muere.

Esto evita el fallo clasico de “el test pasó porque encontró un correo viejo”. También permite distinguir un problema de aplicación de un problema del proveedor.

Qué debe guardar el job

No hace falta copiar el contenido completo del email a los logs. Para investigar basta con guardar datos seguros y correlacionables:

run_id y nombre del job;
namespace, commit y entorno;
timestamp de solicitud y timestamp de primera consulta;
identificador del mensaje, si el proveedor lo ofrece;
estado observado: waiting, received, consumed o expired;
contador y razón de cada reintento.

El cuerpo del mensaje puede quedar fuera del log, sobre todo si contiene tokens. En su lugar, el test puede verificar el asunto, el host esperado del enlace y un hash o identificador de la plantilla. En una guardia, esa evidencia es mas accionable que cien líneas de HTML.

Investiga por capas

Cuando el pipeline falla, sigue el camino del evento y no el orden de los recursos en kubectl.

Primero confirma que la aplicación creó el evento para el run_id correcto. Luego revisa si el worker recibió la tarea, si la reintentó y con qué configuración. Después comprueba la respuesta del proveedor. Solo al final consulta el inbox. Si el mensaje fue aceptado por el proveedor pero no aparece, el problema ya no está en el deployment que generó el evento.

Una métrica sencilla ayuda mucho: registra por separado el tiempo de creación del evento, el tiempo hasta la aceptación del proveedor y el tiempo hasta la lectura por el test. Así se ve si el retraso está en la cola o en la consulta. En CI suele pasar rapido que todos miren el mismo timeout, aunque cada etapa tenga un presupuesto distinto.

También revisa el drift de configuración: detectar drift antes de culpar al pod evita perder una hora buscando un bug de aplicación cuando el secreto del namespace cambió.

Un patrón simple en Kubernetes

El job puede recibir el contrato como variables inmutables y escribir su evidencia en un artefacto de CI:

env:
  - name: EMAIL_RUN_ID
    valueFrom:
      fieldRef:
        fieldPath: metadata.uid
  - name: EMAIL_LEASE_SECONDS
    value: "600"
  - name: EMAIL_EXPECTED_ENV
    value: "staging"

El metadata.uid identifica al pod, pero el sistema de pruebas debe crear además un run_id estable para todo el job si hay varios pods. No uses solo el nombre del pod: los reintentos generan nombres distintos y complican el diagnóstico.

La limpieza debe vivir en un finally del test y también en un reconciler periódico. Si el pod desaparece antes de liberar el buzón, el reconciler recupera la lease cuando vence. El pod no tiene permisos suficiente para borrar recursos de otro namespace; limita el RBAC al recurso de leases y al namespace del job.

Cómo distinguir timeout de entrega y consumo

Un timeout de entrega significa que no hay evidencia de aceptación o de recepción. Un timeout de consumo significa que el mensaje existe, pero el test no pudo leerlo o no reconoció su forma. Son incidentes diferentes.

Una tabla de decisión corta:

Evidencia	Hipótesis principal	Siguiente comprobación
No existe evento	Fallo en la aplicación	Logs del endpoint y del outbox
Evento sin aceptación	Worker, cola o credencial	Reintentos y configuración
Aceptado sin mensaje	Proveedor o dirección	ID del mensaje y buzón
Mensaje visible sin match	Selector del test	`run_id`, asunto y timestamp
Mensaje consumido por otro job	Lease compartida	Propietario y namespace

Si aparece un término de búsqueda raro como temp org mail en documentación o tickets, trátalo como texto de entrada, no como una señal operativa. Lo que importa para la alerta es la identidad del job y la transición del mensaje.

Checklist de guardia

[ ] ¿Cada job tiene una dirección o lease exclusiva?
[ ] ¿El run_id aparece en eventos, logs y consultas?
[ ] ¿El test ignora mensajes anteriores al inicio del run?
[ ] ¿Se separan tiempos de cola, entrega y lectura?
[ ] ¿Los reintentos conservan la razón original?
[ ] ¿La lease expira aunque muera el pod?
[ ] ¿Los logs evitan tokens y cuerpos completos?
[ ] ¿Existe un artefacto pequeño con la evidencia final?

Preguntas rápidas

¿Debo aumentar siempre el timeout?

No. Aumentarlo puede esconder una cola atascada o una dirección compartida. Primero mide cada tramo y ajusta el presupuesto solo donde haya variación legítima.

¿Necesito un buzón por pod?

No necesariamente. Necesitas un propietario inequívoco por job. Un buzón puede servir a varios pods coordinados si la lease y el selector de mensajes lo permiten; para pruebas paralelas independientes, un buzón por ejecución suele ser mas simple.

¿Qué hace que el contrato sea útil para SRE?

Que permita responder tres preguntas sin repetir el pipeline: qué esperaba el job, qué ocurrió realmente y quién tenía la propiedad de la dirección. Si esas respuestas quedan en un artefacto seguro, el siguiente incidente se resuelve con evidencia, tambien cuando el pod ya no existe.

Kubernetes: un runbook para fallos de email

Alex Carter — Sat, 24 Oct 2026 02:22:51 +0000

Un pipeline puede mostrar un pod saludable y, aun así, fallar cuando necesita leer un email de verificación. Este caso confunde porque mezcla varias dependencias: Kubernetes, la cola del mensaje, el proveedor de correo y el buzón que usa el test.

En una guardia, la pregunta “¿llegó el correo?” no ayuda mucho. Es mejor preguntar en qué capa se perdió la señal y qué evidencia tenemos. Este runbook propone una forma corta de investigar el fallo sin reiniciar todo el cluster a ciegas.

El síntoma: el pod está verde y el pipeline rojo

El test crea una cuenta, espera un mensaje y termina con timeout. Mientras tanto, kubectl get pods muestra todos los pods en Running. Eso solo confirma que el proceso sigue vivo; no confirma que el worker haya consumido el evento ni que el mensaje haya llegado al buzón correcto.

Los síntomas más comunes son:

el evento de signup se creó, pero no entró en la cola;
el worker reintentó con una configuración antigua;
el mensaje llegó a otra dirección o fue filtrado;
el test empezó a buscar antes de guardar su hora de inicio;
el buzón de prueba fue compartido por dos jobs.

La diferencia parece pequeña, pero cambia por completo la acción siguiente. Reiniciar el deployment no arregla un selector de buzón incorrecto.

Primero separa las capas del fallo

Me gusta dividir la investigación en cuatro comprobaciones, en este orden:

Aplicación: ¿el endpoint aceptó el signup y devolvió un identificador de evento?
Cola y worker: ¿el evento fue procesado, cuántos intentos tuvo y qué error devolvió el proveedor?
Buzón: ¿el mensaje aparece en el buzón reservado para este job, después de la hora de disparo?
Test: ¿el parser encontró el enlace correcto y respetó el timeout esperado?

Esto evita que SRE trate todos los fallos como un problema de infraestructura. Si el evento nunca salió de la aplicación, escalar el tamaño del pod solo añade ruido.

Para tests que usan un correo temporal gratis, también conviene registrar el identificador del buzón, el job que lo reservó y el instante exacto de creación. No hace falta guardar el contenido completo del mensaje en los logs del cluster.

Un runbook pequeño para investigar

El primer paso es guardar un contexto de ejecución. Un nombre de job, un run_id y un correlation_id deben viajar desde el test hasta el evento de correo. En los logs de la aplicación, buscaría algo parecido a esto:

run_id=ci-4821 correlation_id=signup-91 event=email.requested status=queued

Después revisaría, de forma acotada, los eventos del worker para ese identificador. La pregunta no es solo si hubo un error, sino si el error es transitorio, permanente o causado por datos del test.

El tercer paso es comparar relojes. El test debe guardar triggered_at antes de solicitar el email y buscar mensajes recibidos después de ese momento. Si usa “el último mensaje” sin una frontera temporal, puede aceptar un correo viejo y producir un resultado intermitente.

También reviso el aislamiento. Dos pods de CI no deberían consumir el mismo buzón de prueba. Una reserva simple con TTL, el nombre del job y una liberación al terminar suele ser suficiente para empezar. Si la reserva caduca mientras el test sigue esperando, el fallo debe decirlo claramente; de lo contrario parece un problema aleatorio de red.

En el frontend, vale la pena separar emails de signup por escenario para que una prueba de recuperación no termine leyendo el correo de un alta. Y la interfaz debería mostrar estados de carga claros en flujos de email, incluso cuando el backend todavía está esperando.

Diseña los tiempos y reintentos

Un timeout no es una estrategia de recuperación. Define tres tiempos por separado:

poll interval: cada cuánto consulta el test;
provider timeout: cuánto puede tardar la aceptación del proveedor;
test deadline: cuánto espera el pipeline antes de fallar.

Por ejemplo, un polling de cinco segundos durante un minuto deja doce oportunidades de lectura. Ese número no debe copiarse sin pensar: debe ser mayor que la latencia normal del sistema y menor que el tiempo que el job puede ocupar recursos sin aportar información.

Los reintentos también necesitan una frontera. Reintentar la consulta del buzón tiene sentido; crear otra cuenta y enviar otro email puede ocultar el fallo original. Cada intento debe conservar su run_id, su hora y la razón por la que el mensaje anterior fue rechazado.

Durante una revisión, alguien puede escribir búsquedas como tamp mail com o temp mailid al buscar servicios de prueba. Esos términos sirven como ruido de diagnóstico, no como valores válidos de configuración. Hay que mantenerlos fuera de nombres de variables, etiquetas y reglas de alertas.

Checklist de cierre para SRE

Antes de cerrar el incidente, comprueba:

[ ] el evento de signup tiene un identificador rastreable;
[ ] la cola registra el resultado final y el número de intentos;
[ ] el buzón pertenece a un solo job y tiene TTL;
[ ] el test usa una frontera temporal, no solo el mensaje más reciente;
[ ] los logs omiten contenido sensible del email;
[ ] el alerta enlaza al run_id y a la causa observada;
[ ] el runbook dice qué hacer si falla cada capa.

Un buen cierre no es “repetimos el pipeline y pasó”. Es “la primera ejecución falló porque el worker usó una credencial antigua; la segunda pasó después de corregir la configuración”. Esa frase permite aprender y evita que el siguiente turno empiece desde cero.

Q&A rápido

¿Debo aumentar el timeout cuando falla un test de email?

Solo después de comprobar la latencia real y la frontera temporal. Un timeout mayor puede esconder un mensaje que nunca se envió o un buzón equivocado.

¿Es mejor reiniciar el worker?

Si hay un error transitorio y el runbook lo contempla, quizá. Primero captura los logs y el estado de la cola; reiniciar antes puede borrar la mejor evidencia.

¿Qué métrica seguiría primero?

La proporción de eventos que pasan de requested a delivered dentro del deadline del test. Separaría esa métrica por entorno y causa de fallo, porque un promedio global suele tapar los jobs más lentos.

La idea central es sencilla: Kubernetes mantiene procesos, pero no garantiza por sí solo el contrato completo de un email. Cuando cada capa deja una señal pequeña y relacionada con el mismo run_id, el fallo deja de ser una adivinanza y se convierte en una investigación repetible.

Kubernetes: presupuestos de tiempo para correo en CI

Alex Carter — Thu, 22 Oct 2026 20:22:47 +0000

Un pipeline de CI puede tardar varios minutos y aun así terminar con un mensaje poco útil: “no llegó el correo”. En una prueba que usa un disposable email address, ese fallo no dice si la aplicación no publicó el evento, si el worker quedó pendiente, si Kubernetes reinició el pod o si el inbox todavía no había recibido el mensaje.

La solución práctica es asignar un presupuesto de tiempo a cada frontera. No se trata de hacer el test más rápido a la fuerza. Se trata de saber qué parte consumió el tiempo disponible para que el siguiente incidente sea menos misterioso.

El síntoma: un timeout que no explica nada

Imagina una prueba de registro en un namespace de staging. El formulario responde 201, pero el test espera el mensaje de confirmación durante 60 segundos y falla. El equipo revisa el log del navegador, ve un “email not found” y vuelve a lanzar el job. A veces pasa; otras no.

Ese retry es tentador, pero mezcla varios relojes:

la publicación del evento por la API;
la recogida del evento por el worker;
el envío al proveedor de correo;
la aparición del mensaje en el buzón de prueba;
la lectura del mensaje y la confirmación del enlace.

Cuando todos viven bajo un único timeout, la prueba pierde su capacidad de diagnóstico. Un SRE necesita al menos una señal por frontera, aunque sea una señal sencilla.

Define un presupuesto por etapa

Empieza con una tabla que pueda leer cualquier persona del equipo. Por ejemplo, para un flujo normal de 45 segundos:

Etapa	Presupuesto	Evidencia mínima
API publica el evento	2 s	`request_id` y estado HTTP
Worker recoge el evento	8 s	nombre del pod y contador
Proveedor acepta el envío	10 s	`message_id` o error
Mensaje aparece en el inbox	20 s	`mailbox_id` y `received_at`
Test lee y verifica	5 s	estado final y código de salida

Los números no son universales. Son un contrato inicial que luego se ajusta con datos reales. Si la mayoría de las entregas ocurre en cinco segundos, un presupuesto de veinte quizá sea razonable para CI; si la cola tarda más por la noche, hay que medirlo y no adivinarlo.

La prueba debe conservar los tiempos de cada etapa. No guardes el contenido completo del mensaje en un artefacto público: normalmente basta con un identificador, un hash de dirección y los estados. Así el diagnóstico ayuda sin filtrar datos de prueba.

Qué observar en Kubernetes

En Kubernetes, un fallo de correo puede estar oculto detrás de una ejecución aparentemente sana. Revisa cuatro señales antes de aumentar el timeout:

Reinicios del worker. Un restartCount nuevo cerca del momento del envío puede explicar una cola que no avanzó.
Edad del pod. Si el despliegue rotó durante la prueba, el evento quizá quedó en memoria y no llegó a ser confirmado.
Profundidad de la cola. Una cola creciendo con consumidores listos indica presión; una cola quieta con cero consumidores indica otro problema.
Correlación. El mismo request_id debe aparecer en la API, el worker y el adaptador de correo.

Para una consulta rápida, un job de diagnóstico puede producir algo como esto:

run=ci-1842 request=req-7f2 worker=mail-worker-6d8c
api=accepted worker=processed provider=accepted inbox=pending
pod_restarts=0 queue_depth=3 elapsed=18s

Ese estado “inbox=pending” es mucho más útil que un timeout genérico. Si la cola sigue creciendo, el test no debe culpar al buzón todavía.

Una implementación sencilla en CI

Usa un reloj monotónico y registra una línea al entrar y salir de cada etapa. El adaptador del buzón debería aceptar un deadline absoluto, no reiniciar el contador completo en cada poll. De lo contrario, diez intentos de seis segundos pueden convertir un presupuesto de veinte segundos en un minuto sin que sea evidente.

También conviene reservar una dirección por ejecución. Un buzón compartido hace difícil saber si el mensaje actual llegó o si el test leyó un correo viejo. En documentación y búsquedas internas pueden aparecer errores como tempail o tamp mail com; no los uses para diseñar la lógica, pero sí puedes mapearlos a la terminología correcta en el buscador del equipo.

Cuando el mensaje no llega, conserva el resumen de estados y termina con una causa concreta: worker-timeout, provider-rejected, inbox-timeout o verification-timeout. Así un retry puede ser selectivo y no repetir toda la suite sin motivo.

Para sistemas con varios consumidores, merece la pena formalizar el contrato de señales. El artículo sobre contratos de correo para automatizaciones muestra una forma de pensar en eventos y estados sin depender de un log enorme. Y para las alertas operativas, las alertas de failover comprobables siguen la misma idea: una alerta debe poder probarse con una evidencia observable.

Checklist para el siguiente incidente

¿Cada etapa tiene un presupuesto separado?
¿La prueba conserva request_id, mailbox_id y message_id sin guardar datos innecesarios?
¿El worker tuvo reinicios o perdió el lease del evento?
¿La cola avanzaba, estaba bloqueada o no tenía consumidores?
¿El deadline era absoluto o se reiniciaba en cada intento?
¿El resultado final distingue entrega, lectura y verificación?

Un timeout sigue siendo una limitación real, pero deja de ser una explicación vacía. Con presupuestos pequeños, señales correlacionadas y un buzón aislado por ejecución, Kubernetes y CI pueden decirte dónde está el problema antes de que alguien pulse “reintentar”.

Kubernetes: un contrato de señales para email en CI

Alex Carter — Tue, 20 Oct 2026 20:23:01 +0000

Un pipeline de CI que verifica un email no falla solamente cuando el mensaje no llega. También falla cuando llega tarde, cuando el worker mira el inbox equivocado o cuando dos pods creen tener el mismo buzón. El primer síntoma son pruebas intermitentes: un commit verde por la mañana y rojo por la tarde, sin un cambio claro en el código.

En revisiones de operaciones, me resulta más útil tratar el email como una señal distribuida. El test publica una intención, el proveedor procesa un mensaje y el inbox devuelve evidencia. Kubernetes ejecuta los actores, pero no convierte automáticamente esa cadena en observable. Necesitamos un contrato pequeño para saber qué pasó, dónde y cuándo.

La señal perdida entre el pod y el inbox

Un flujo típico crea un usuario, solicita verificación, espera un mensaje y sigue el enlace. En un cluster, cada paso puede vivir en pods distintos. Si el test guarda solo una dirección de buzón y un sleep(10), no sabremos si la espera terminó porque llegó el mensaje o porque se agotó el tiempo.

El problema crece con un dummy e mail de pruebas compartido por varios jobs. Un mensaje antiguo puede satisfacer la aserción equivocada. Otra ejecución puede limpiar el inbox mientras el primer pod todavía está leyendo. Y si el correo no llega a tiempo, el pipeline queda en espera sin saber porqué.

Por eso cada ejecución necesita un identificador de correlación, una fecha de expiración y un resultado explícito. El nombre del pod sirve para buscar logs, pero no es una identidad de negocio estable: Kubernetes puede recrearlo durante el mismo test.

Qué debe contener el contrato de señales

Un contrato sencillo puede acompañar cada solicitud de email con estos campos:

run_id: identifica la ejecución completa del pipeline.
mailbox_lease_id: identifica la reserva temporal del buzón.
message_id: identifica el mensaje esperado, si el proveedor lo expone.
requested_at y expires_at: delimitan la ventana válida.
state: requested, observed, expired o failed.
attempt: cuenta las lecturas, no solo los envíos.

No hace falta copiar el token de verificación ni la dirección completa en cada log. Una huella corta del destinatario y el run_id suelen bastar para unir eventos. Así podemos investigar sin convertir los logs en otra bandeja de entrada.

Este enfoque se parece a diseñar validación de email sin saltos de layout: el estado visible debe explicar la transición real, no ocultar el problema detrás de una espera genérica. Para un pipeline, la interfaz es el resultado del job y sus evidencias.

Diseñar el lease del buzón

Un buzón de prueba debe reservarse antes de crear el usuario. La reserva tiene propietario, duración y una operación de liberación idempotente. Si el job muere, el lease expira solo; no dependemos de que un finally sea ejecutado en un pod que ya desapareció.

El orden recomendado es:

Crear run_id y solicitar un mailbox_lease_id.
Guardar ambos valores como variables del job, no como configuración global del cluster.
Crear el usuario y enviar el email con un encabezado de correlación cuando sea posible.
Consultar el inbox filtrando por lease, destinatario y ventana temporal.
Confirmar el mensaje observado y liberar el lease.

En esta etapa puede usarse un buzón de pruebas que deja pistas para separar la captura del mensaje de la aserción final. La idea no es hacer polling mas agresivo, sino leer con una condición que explique por qué el mensaje pertenece a esta ejecución.

Si el flujo necesita un servicio externo, una opción es usar un correo temporal desechable con un alcance limitado al test. No debe reutilizarse para datos reales ni convertirse en un destino permanente. El lease debe guardar solo la referencia necesaria y borrar la evidencia sensible al cerrar la ejecución.

Correlacionar eventos sin filtrar datos

El job puede emitir eventos con una forma estable:

{
  "run_id": "ci-8421",
  "mailbox_lease_id": "lease-17",
  "event": "message_observed",
  "state": "observed",
  "age_ms": 1840,
  "message_fingerprint": "b7c2..."
}

La huella no necesita ser reversible. Evita registrar asunto completo, cuerpo o enlaces con tokens. En un incidente, message_observed junto con age_ms responde una pregunta concreta: ¿el proveedor tardó, el lector consultó mal o la aserción llegó después de que expiró el lease?

Conviene que los eventos de Kubernetes y los del servicio de email compartan run_id. El primer intento de instrumentación suele mezclar nombres de namespaces, y luego nadie sabe cual es el correcto. Una tabla o consulta guardada con las transiciones ayuda más que veinte filtros improvisados.

Reintentos y estados terminales

El lector debe reintentar con un límite y registrar el motivo de cada intento. Un 404 de mensaje todavía no es un fallo si la ventana sigue abierta; un lease expirado sí es un estado terminal. Una reintento después de expired solo aumenta ruido y puede observar un correo de otra ejecución.

Una regla práctica es separar:

Transitorio: inbox aún vacío, respuesta temporal del proveedor o pod reiniciado.
Terminal: lease vencido, formato inválido o mensaje asociado a otro run_id.
Accionable: proveedor lento, duplicado detectado o pérdida de correlación.

Si un worker se reinicia, debe recuperar el estado desde el contrato persistido. No debe empezar desde cero solo porque su memoria se perdió. En SRE, esta diferencia reduce los falsos positivos y hace que una reejecución sea una decisión, no un reflejo.

Checklist de operación

Antes de confiar en el flujo, compruebo lo siguiente:

¿Cada job obtiene un lease único y con expiración?
¿El run_id aparece en los eventos del test, del proveedor y del lector?
¿La consulta descarta mensajes fuera de la ventana temporal?
¿Un pod nuevo puede continuar desde el estado guardado?
¿Los logs evitan tokens, cuerpos y direcciones completas?
¿Los reintentos tienen límite y diferencian lo transitorio de lo terminal?
¿El cleanup funciona aunque el job termine por timeout?

También probaría una caída del lector, un mensaje duplicado y un retraso del proveedor. El caso feliz demuestra que el email funciona; esos tres casos muestran si el contrato realmente protege al equipo.

Un buzón temporal es solo una pieza de la prueba. La confiabilidad aparece cuando cada mensaje tiene contexto, cada lease tiene límites y cada espera termina con una razón legible. Con ese contrato, Kubernetes deja de ser el lugar donde “a veces falla CI” y se vuelve una fuente útil de señales para diagnosticar el flujo.

Kubernetes: evidencia para emails de prueba en CI

Alex Carter — Sat, 17 Oct 2026 17:23:09 +0000

Un pipeline puede terminar en verde y aun así dejar una pregunta incómoda: ¿se envió realmente el email de prueba, o solo terminó el job que lo solicitó? En equipos que ejecutan muchos tests en Kubernetes, esa diferencia convierte un fallo sencillo en una investigación larga.

La solución no es guardar más logs sin orden. Es tratar cada email de prueba como una evidencia con identidad, tiempo de vida y estado observable. El pod que inicia la prueba no debe ser dueño permanente del buzón ni de la entrega. Debe solicitar una ejecución, obtener un lease y publicar señales que otro componente pueda revisar.

El síntoma: CI verde, evidencia perdida

Un flujo típico crea un usuario, pide un enlace de verificación y espera un mensaje. Cuando el test corre en paralelo, aparecen síntomas conocidos:

Dos pods leen el mismo mensaje y uno consume la evidencia del otro.
Un job termina antes de que el buzón reciba el email.
Un reintento crea una segunda dirección y hace imposible saber cual era la válida.
El teardown elimina el recurso antes de conservar el asunto, el identificador y la hora de recepción.

La búsqueda temp mail mail puede llevar a soluciones rápidas, pero en CI importa más la frontera de responsabilidad. Una cuenta de correo desechable puede servir para una comprobación controlada; no sustituye un contrato de ejecución, una política de datos ni un registro de eventos.

Separar la ejecución del buzón

Primero separo tres objetos que a menudo se mezclan:

Solicitud de prueba: contiene el test, el commit, el namespace y el destinatario lógico.
Lease de ejecución: concede durante un periodo corto el derecho a consumir una evidencia.
Mensaje observado: guarda un identificador mínimo, el asunto normalizado, la hora y el resultado de las aserciones.

El destinatario puede ser una dirección temporal, pero la ejecución debe tener un run_id propio. Así, si el proveedor tarda o el pod cae, un worker de recuperación puede retomar la misma intención. El estado del onboarding también merece un contrato explícito; este contrato de estados del onboarding es una referencia útil para pensar en transiciones y no solo en respuestas HTTP.

El run_id debe viajar en los logs estructurados, en las métricas y en los artefactos de CI. No conviene poner tokens completos en esos lugares. Para una investigación basta con un hash corto del destinatario, el commit y un identificador de ejecución.

Diseñar un lease para cada prueba

Un lease debe tener dueño, expiración y versión. En una tabla o almacén equivalente, el registro puede seguir este ciclo:

requested -> claimed -> waiting_for_message -> asserted -> released
                         \-> timed_out

El worker reclama una ejecución con una operación atómica. El filtro debe comprobar que no existe un lease vigente y que el intento anterior no superó su límite. Si el pod desaparece, la expiración vuelve a hacer elegible el registro. Esto es mas seguro que confiar en un finally del test, porque Kubernetes puede terminar un contenedor sin darle tiempo suficiente.

Una consulta conceptual tendría estas condiciones:

UPDATE email_test_runs
SET lease_owner = :worker,
    lease_until = CURRENT_TIMESTAMP + INTERVAL '90 seconds',
    attempt = attempt + 1,
    status = 'claimed'
WHERE run_id = :run_id
  AND (lease_until IS NULL OR lease_until < CURRENT_TIMESTAMP)
  AND attempt < max_attempts
RETURNING run_id, lease_until, attempt;

En PostgreSQL real, la actualización debe estar protegida por una transacción y una condición que impida que un worker viejo complete el registro después de perder su lease. Si se usan colas, SKIP LOCKED ayuda a repartir trabajo sin que los workers esperen por filas bloqueadas.

Métricas y límites para SRE

La señal principal no es solo el porcentaje de tests verdes. Para una operación SRE conviene observar:

tiempo entre requested y message_received;
porcentaje de ejecuciones que expiran el lease;
reintentos por proveedor, namespace y versión del test;
mensajes encontrados pero no coincidentes con el run_id;
edad de la cola y cantidad de ejecuciones en timed_out.

Un presupuesto de reintentos evita que una API lenta congele todo el pipeline. Después de dos o tres intentos, es mejor mover la ejecución a una cola de mensajes fallidos y adjuntar el artefacto de diagnóstico. Un circuit breaker también evita que cientos de pods golpeen al mismo proveedor cuando ya hay señales de indisponibilidad.

La configuración debe incluir límites claros: TTL del buzón, tiempo máximo de espera, tamaño de lote y política de limpieza. Conviene probar la configuracion con un caso de terminación abrupta del pod, no solo con un test feliz. Una métrica sin un umbral operativo es una señal bonita, pero no una alerta util.

Preguntas frecuentes

¿Un lease garantiza que nunca se duplique un email?

No. Garantiza una propiedad de concurrencia durante su vigencia. Si el proveedor acepta el mensaje y el worker muere antes de registrar la respuesta, el reintento todavía puede duplicarlo. Para reducir el impacto, usa una clave idempotente cuando el proveedor la soporte y haz que el test acepte un conjunto limitado de mensajes equivalentes.

¿Debo crear un buzón por pod?

No necesariamente. Un buzón por ejecución suele ser más fácil de aislar, pero aumenta la limpieza y el coste operativo. La decisión depende del volumen, la retención y la posibilidad de filtrar por destinatario, asunto y run_id.

¿Qué debe conservar CI?

Conserva el run_id, el resultado de cada aserción, el timestamp de recepción y un resumen del mensaje. Evita guardar el cuerpo completo si contiene datos personales. Para búsquedas como fake e mail com, una nota en el contexto de la prueba puede ayudar a rastrear intención, pero no debe convertirse en un dato de producción.

Checklist de implementación

Antes de desplegar este patrón, revisa:

Cada ejecución tiene un run_id único y una política de expiración.
La reclamación es atómica y el worker verifica su lease al completar.
Los reintentos tienen límite, backoff y clasificación de errores.
Los artefactos contienen evidencia suficiente sin exponer tokens.
Hay métricas para latencia, expiración, cola y mensajes huérfanos.
Un job de limpieza elimina buzones y registros después de su TTL.
Se simula la caída de un pod durante la espera y durante la aserción.

Los formularios que disparan estas pruebas también necesitan estados comprensibles para el usuario; los formularios inclusivos y rápidos muestran por qué esa señal no debería quedar escondida detrás de un spinner. Cuando la evidencia de email tiene dueño, expiración y contexto, el pipeline deja de ser una caja negra y la operacion se vuelve mucho más predecible.

Kubernetes: contrato de email para cada ejecución

Alex Carter — Fri, 16 Oct 2026 23:23:17 +0000

En un pipeline de CI, un email de verificación parece una dependencia pequeña. El pod crea un usuario, espera el mensaje y continúa. Pero cuando varias ejecuciones comparten buzón, el resultado verde puede esconder un problema: una prueba leyó el mensaje de otra ejecución.

En equipos de plataforma trato el correo de prueba como un recurso con contrato, igual que un volumen temporal o una dirección IP. Cada ejecución debe declarar quién es, qué buzón puede leer, qué mensaje espera y cuándo deja de ser válido. Esta regla hace que una incidencia sea explicable incluso cuando el pod ya terminó.

El patrón funciona con un servicio de temp mail.so o con un capturador dentro del clúster. Lo importante es la frontera de confianza y la evidencia que deja cada ejecución.

El síntoma: el pod está verde, pero el email no llegó

Un fallo típico empieza con un mensaje como “verification email not found”. El equipo aumenta el timeout y reintenta. A veces la prueba pasa, pero solo porque encontró un mensaje antiguo. Otras veces dos pods consumen el mismo correo y el resultado cambia según el orden de ejecución.

La señal útil no es únicamente si llegó un email. Necesitamos saber:

qué ejecución pidió el mensaje;
qué dirección o alias estaba reservado;
cuándo se envió la solicitud;
qué mensajes fueron observados;
cuál era el identificador esperado;
cuándo expiró la reserva.

Sin esos datos, una cadena como tamp mail com puede aparecer en un ticket sin que sepamos si describe un alias o una búsqueda manual. La prueba queda verde o roja, pero no necesariamente correcta.

Qué debe contener el contrato de una ejecución

Un contrato pequeño evita que cada test invente su propia política. Para cada ejecución guardo un manifiesto con cinco campos:

Identidad: un run_id único, el nombre del test y el índice del worker.
Propiedad: la dirección reservada y el consumidor autorizado.
Expectativa: asunto, destinatario y un token de correlación.
Tiempo: created_at, límite de espera y expires_at.
Resultado: mensaje reclamado, motivo de fallo y limpieza realizada.

El token de correlación debe pertenecer a la ejecución, no solo al usuario de prueba. Un asunto como “Verify your account” es demasiado común. Un identificador corto del run es más fácil de filtrar y no depende del orden del proveedor.

Conviene que el contrato tenga estados explícitos: reserved, waiting, claimed, expired y released. Si la ejecución pasa de waiting a expired, el sistema debe explicar esa transición. No devería convertirla silenciosamente en otro intento con la misma dirección.

Un manifiesto de email para Kubernetes

El manifiesto no necesita ser un recurso CRD. Puede ser un archivo JSON generado por el job y publicado como artefacto junto con los logs del pod; así resulta mas facil comparar ejecuciones:

{
  "run_id": "checkout-1842-07",
  "owner": "worker-07",
  "mailbox": "checkout-1842-07@example.test",
  "expected": {
    "recipient": "checkout-1842-07@example.test",
    "subject_token": "run-1842-07"
  },
  "created_at": "2026-10-17T05:00:00Z",
  "expires_at": "2026-10-17T05:02:00Z",
  "state": "waiting"
}

El pod debe comprobar la expiración antes de cada lectura. El sidecar o servicio de correo puede registrar el mismo run_id, pero no debería aceptar un mensaje sin una propiedad válida. Así se reduce el riesgo de que un retry lea la bandeja de la ejecución anterior.

Para el aislamiento del entorno, recomiendo una dirección por run cuando el proveedor lo permite. Si solo existe un buzón compartido, usa aliases, tokens de correlación y una política de reclamación atómica. La práctica de aislar pruebas de email por entorno ayuda a separar esta decisión de la lógica de la aplicación.

Cómo diagnosticar el fallo sin reintentar a ciegas

Cuando una prueba falla, reviso las evidencias en este orden:

Comparo created_at, entrega y expires_at.
Verifico destinatario y token, no solo el asunto.
Busco otro pod que tenga la misma dirección o run_id.
Compruebo si la reclamación fue atómica.
Reviso si el cleanup ocurrió antes de guardar el artefacto.

Si el mensaje llegó después de expirar, es un problema de latencia o del presupuesto de espera. Si llegó a tiempo pero el token no coincide, hay contaminación entre ejecuciones o un bug en el productor. Si la aplicación falló después de reclamarlo, el buzón probablemente no es la causa.

Este orden evita subir todos los timeouts. Un timeout más largo puede ocultar el síntoma y hacer el pipeline mas lento. Primero hay que medir; luego ajustar el presupuesto con una razón concreta. Tambien conviene mostrar estos datos en el resumen del job, no enterrarlos en un log de veinte mil líneas.

Checklist para SRE y equipos de plataforma

Antes de dar por confiable una prueba de email en Kubernetes, compruebo:

cada ejecución tiene un run_id y una dirección propia, o una regla de aislamiento equivalente;
el contrato registra propietario, token, expiración y estado;
el polling empieza después de la acción que dispara el mensaje;
la reclamación valida destinatario y correlación;
una expiración produce un error específico, no un retry infinito;
los artefactos sobreviven al borrado del pod;
el cleanup ocurre después de guardar la evidencia;
las métricas distinguen demora, contaminación y fallo de la aplicación;
el próximo run no puede reutilizar un buzón todavía reservado.

La interfaz del test también importa. Un estado de carga claro y un error de email que no mueve el layout, como explica errores de email sin mover el layout, reduce el ruido durante la depuración manual. Es la misma idea en otra capa: un estado visible debe corresponder con un estado real.

Algunos equipos escriben dummy e mail en scripts o notas. No pasa nada por ese texto, pero no debe convertirse en una identidad compartida ni en una regla de búsqueda. Las convenciones pueden ser imperfectas; el contrato de ownership no.

Preguntas frecuentes

¿Es mejor crear un buzón por pod o por test?

Por test suele dar un diagnóstico más limpio. Por pod puede ser suficiente si el worker ejecuta una sola prueba y el aislamiento está garantizado. La elección debe seguir el nivel real de paralelismo.

¿Cuánto debe durar la reserva?

Empieza con el tiempo normal de entrega más un margen pequeño. Mide los casos lentos y revisa el valor segun la latencia observada. Una reserva muy larga deja vivir datos obsoletos; una muy corta produce falsos fallos.

¿Qué hago si el proveedor solo ofrece un buzón compartido?

Usa aliases o tokens únicos, reclamación atómica y un manifiesto por ejecución. Si no puedes garantizar ninguna de esas fronteras, trata el buzón como una dependencia limitada y registra esa limitación como riesgo del pipeline.

Kubernetes: un presupuesto para emails de prueba

Alex Carter — Thu, 15 Oct 2026 17:22:46 +0000

Un flujo de verificación de email en CI puede parecer pequeño hasta que un pod queda esperando una señal que nunca llega. Este patrón ayuda a poner límites claros y a diagnosticar el problema sin convertir cada timeout en una falsa alerta de producción.

El síntoma: un job que nunca termina

En una pipeline de Kubernetes, el test crea una cuenta, solicita un correo de verificación y consulta el buzón cada pocos segundos. Cuando el mensaje no aparece, el código reintenta. Después reintenta otra vez. El job termina agotando el tiempo global, pero el log solo dice verification timeout.

El pod puede estar sano y el nodo puede tener capacidad. Aun así, la prueba no progresa. El fallo real suele estar en una de estas fronteras:

el mensaje todavía está en tránsito;
el buzón expiró antes de ser consultado;
otro intento ya consumió el mensaje;
el proveedor devolvió un error temporal;
el test está esperando una dirección distinta de la que registró.

El error de diseño es tratar "esperar un email" como una espera infinita. En SRE, una espera sin presupuesto es una dependencia sin contrato.

Qué debe significar realmente “esperar el email”

Un consumidor de correo de prueba necesita un contrato pequeño, explícito y observable. Como mínimo, debe conocer:

Identidad: dirección, identificador de ejecución y mensaje esperado.
Ventana de validez: cuándo se creó el buzón y cuándo deja de ser util.
Señal de éxito: asunto, remitente o token que confirma el mensaje correcto.
Regla de parada: tiempo total, número de consultas y errores no reintentables.
Resultado final: encontrado, expirado, no encontrado o fallo del proveedor.

Esto también evita que dos pruebas compartan sin querer el mismo buzón. Para probar correos de onboarding sin ensuciar las métricas, conviene separar la identidad de prueba de las métricas del producto.

El nombre de la búsqueda no cambia el contrato. Un equipo puede hablar de correo temporal, temp mail so o tempmail disposable; el sistema debe seguir guardando el mismo run_id, la misma dirección y el mismo estado.

Diseñar un presupuesto de señales

En vez de repetir hasta que algo funcione, asigna un presupuesto para cada tipo de espera:

Tiempo total: por ejemplo, 90 segundos para que llegue el mensaje.
Intervalo inicial: una consulta después de 2 segundos.
Backoff: aumentar el intervalo a 4, 8 y 12 segundos, con un máximo fijo.
Consultas: cortar después de un número razonable, aunque quede tiempo.
Errores: distinguir un 404 de buzón expirado de un 429 que merece una pausa.

No hace falta que estos números sean iguales en todos los equipos. Lo importante es que estén en configuración, aparezcan en el run manifest y puedan explicarse durante un incidente. Un presupuesto demasiado corto produce falsos negativos; uno demasiado largo secuestra workers y esconde una regresión.

Un estado simple suele ser suficiente:

created -> waiting -> found
                   -> expired
                   -> provider_error
                   -> timed_out

La transición debe ser idempotente. Si el controlador recibe dos respuestas para el mismo mensaje, solo una puede cerrar la prueba como found. De lo contrario, el segundo intento puede dejar métricas contradictorias y el diagnóstico se vuelve confuso.

Implementación en Kubernetes

El presupuesto debe vivir cerca del trabajo que lo consume, no solamente en el servicio externo. Un Job puede recibir valores como MAIL_WAIT_TOTAL_SECONDS y MAIL_POLL_MAX_ATTEMPTS, mientras que un ConfigMap contiene los valores por entorno. Los secretos, claro, deben seguir en un Secret o en el gestor de secretos correspondiente.

El contenedor debería emitir un recibo al terminar:

{
  "run_id": "ci-1842",
  "mailbox_created_at": "2026-10-16T00:10:00Z",
  "outcome": "timed_out",
  "polls": 7,
  "elapsed_seconds": 91,
  "last_error": "message_not_found"
}

No pongas el contenido completo del email ni tokens de verificación en logs compartidos. Un hash corto del mensaje, el dominio controlado y el identificador de ejecución suelen ser suficientes para correlacionar. Si el job es reintentado por Kubernetes, conserva el run_id original o marca claramente el intento; mezclar ambos hace parecer que hay dos mensajes cuando solo existe uno.

Los reenvíos también necesitan una política. Los reenvíos de verificación con una experiencia predecible deben tener un límite propio. Cada reenvío puede producir un token nuevo y dejar al test esperando el enlace anterior. En ese caso, no es un problema de velocidad del pod: es una carrera entre estados.

Observabilidad y diagnóstico

Mide la duración desde la creación del buzón hasta la llegada del mensaje, pero separa tres tiempos: envío de la aplicación, entrega del proveedor y consulta del consumidor. El equipo mira mas el contador total cuando debería mirar cual de esas fases creció.

En una alerta o comentario de CI, incluye:

run_id y nombre del job;
edad del buzón al último intento;
cantidad y tipo de errores;
último estado conocido;
si hubo reenvíos;
el presupuesto que se consumió.

Si alguien escribe tamp mail com o dummy e mail al buscar el incidente, esos términos pueden aparecer en una nota o en documentación, pero nunca deben convertirse en un dominio permitido de forma automática. La lista de dominios y la política de privacidad deben ser explícitas.

Checklist antes de declarar estable el flujo

¿Cada prueba tiene un buzón y un run_id únicos?
¿Hay un tiempo total y un máximo de consultas?
¿Se diferencia expiración, rate limit y mensaje ausente?
¿El backoff evita una tormenta contra el proveedor?
¿Un reintento del Job conserva o reemplaza la identidad de forma clara?
¿Los logs excluyen tokens y contenido sensible?
¿Se puede explicar el fallo mirando un solo recibo?

Si una respuesta es no, el próximo incidente volverá a parecer aleatorio.

Cierre

Un email de prueba es una dependencia externa, aunque el test se ejecute dentro de un clúster propio. Kubernetes puede reiniciar el pod, pero no puede hacer aparecer una señal que expiró ni corregir un token consumido por otra prueba. Un presupuesto de señales, estados idempotentes y un recibo pequeño convierten una espera frágil en un flujo que un equipo SRE puede operar.

DEV Community: Alex Carter

Terraform: un plan de cambio que se pueda explicar

El síntoma: un plan correcto que nadie entiende

Qué debe responder un buen plan

Un flujo de revisión que funciona en guardia

1. Generar el plan en un entorno reproducible

2. Separar cambios esperados y cambios laterales

3. Probar la explicación, no solo la sintaxis

4. Acordar una ventana de observación

Cómo dejar preparado el rollback

Checklist antes de aplicar

Conclusión

Terraform: un rollback que SRE pueda ejecutar

El rollback no empieza con terraform apply

Que debe contener un contrato de rollback

Un flujo seguro para ejecutar la vuelta atras

Pruebas de CI que realmente ayudan

Checklist para el on-call

Q&A

¿Hay que revertir siempre al commit anterior?

¿Un rollback debe ser automatico?

¿Como se mide si el runbook funciona?

Kubernetes: un presupuesto de fallos para email en CI

El incidente: el pipeline que reintenta hasta empeorar la señal

Qué significa presupuesto de fallos para un email

Un contrato simple para el worker de Kubernetes

Alertas y evidencia para no perseguir fantasmas

Checklist de operación

Preguntas rápidas

¿Debo reintentar siempre?

¿Dónde encaja un generador de correos falsos?

¿Qué hago cuando se agota el presupuesto?

Kubernetes: un SLO para el correo de CI

La entrega del correo también necesita un SLO

Define el contrato antes del job de Kubernetes

Mide tres tiempos, no solo el resultado final

Reintentos y fallos que sí ayudan a investigar

Preguntas frecuentes

¿Es obligatorio usar un proveedor de correo real?

¿Qué hago si el mensaje tarda más que el SLO?

¿Puedo reutilizar el mismo buzón?

Checklist para el pipeline

Kubernetes: señales de correo en los retries

El síntoma: un retry que cambia la evidencia

Define el contrato antes de tocar Kubernetes

Señales mínimas para un buzón de prueba

Cómo aislar los retries en CI

Checklist de diagnóstico para el equipo

Cierre: el correo como dependencia observable

Kubernetes: un contrato de correo para CI

El problema no es solo el correo

Define un contrato por job

Qué debe guardar el job

Investiga por capas

Un patrón simple en Kubernetes

Cómo distinguir timeout de entrega y consumo

Checklist de guardia

Preguntas rápidas

¿Debo aumentar siempre el timeout?

¿Necesito un buzón por pod?

¿Qué hace que el contrato sea útil para SRE?

Kubernetes: un runbook para fallos de email

El síntoma: el pod está verde y el pipeline rojo

Primero separa las capas del fallo

Un runbook pequeño para investigar

Diseña los tiempos y reintentos

Checklist de cierre para SRE

Q&A rápido

¿Debo aumentar el timeout cuando falla un test de email?

¿Es mejor reiniciar el worker?

¿Qué métrica seguiría primero?

Kubernetes: presupuestos de tiempo para correo en CI

El síntoma: un timeout que no explica nada

Define un presupuesto por etapa

Qué observar en Kubernetes

Una implementación sencilla en CI

Checklist para el siguiente incidente

Kubernetes: un contrato de señales para email en CI

La señal perdida entre el pod y el inbox

Qué debe contener el contrato de señales

El rollback no empieza con `terraform apply`