Kubernetes: un runbook para fallos de email

Un fallo en el envío de correos electrónicos a través de Kubernetes puede confundirse por una aplicación saludable, ya que involucra varias dependencias, como el correo electrónico, la cola de mensajes y el buzón. En lugar de preguntar si el correo llegó, es mejor investigar dónde se perdió la señal y qué evidencia hay. Este runbook ofrece una forma rápida para investigar los fallos sin tener que reiniciar todo el clúster. El síntoma es que el pod está verde, pero el pipeline está rojo.

Los tests suelen crear una cuenta, esperar un mensaje y terminar con un tiempo de espera. Si el pod está en Running pero no se recibe el correo, se deben investigar varios síntomas. Por ejemplo, el evento de registro se puede crear sin entrar en la cola, el worker puede reintentar con una configuración antigua, o el mensaje puede llegar a otra dirección o ser filtrado. También es posible que el test comience antes de guardar la hora de inicio, o que el buzón de prueba sea compartido por dos trabajos.

Para investigar, se deben seguir cuatro comprobaciones en este orden: la aplicación, la cola y el worker, el buzón y el test. Si el evento nunca sale de la aplicación, aumentar el tamaño del pod no ayuda. También es útil registrar el identificador del buzón, el job que lo reservó y el tiempo de creación. No es necesario guardar todo el contenido del mensaje en los logs del clúster.

El runbook sugiere mantener un contexto de ejecución, con un nombre de job, un run_id y un correlation_id, para rastrear el problema desde el test hasta el correo electrónico.

Para cada paso, se debe comprobar si hubo un error y si es transitorio, permanente o causado por datos del test. También es importante comparar los relojes para asegurarse de que el test se inició antes de la hora de inicio y que se haya recibido el correo después de ese momento. Los pods de CI no deben consumir el mismo buzón de prueba, por lo que se debe establecer una reserva con TTL y nombre del job para evitar problemas de prueba.

En la implementación, se debe separar los emails de registro por escenario para que una prueba de recuperación no lea el correo de un alta. La interfaz también debe mostrar estados claros en flujos de correo electrónico, incluso cuando el backend todavía está esperando. Los tiempos y reintentos deben definirse para cada capa, como el intervalo de consulta, el tiempo de espera del proveedor y el tiempo de ejecución del test. También es importante mantener los términos de búsqueda fuera de variables y reglas de alerta.

Antes de cerrar el incidente, se deben verificar varios aspectos, como que el evento de registro tenga un identificador rastreable, que la cola registre el resultado final y el número de intentos, que el buzón pertenezca a un solo job y tenga un TTL, que el test use una frontera temporal, que se eliminen los datos sensibles de los logs y que el alerta enlace al run_id y a la causa observada. También es útil documentar qué hacer si cada capa falla.