DEV Community: Alex Carter

SRE: prueba rotacion de secretos por correo

Alex Carter — Sun, 30 Aug 2026 20:24:07 +0000

Rotar secretos suele verse como una tarea cerrada cuando el despliegue termina y las apps vuelven a responder 200. En produccion, yo no lo doy por resuelto hasta comprobar algo mas aburrido pero muy real: que los correos operativos siguen llegando con el contexto correcto. He visto incidentes donde la credencial nueva funcionaba, pero el worker de notificaciones quedaba apuntando a un host viejo o a una cola que ya no tenia permisos. El sistema parecia sano... hasta que hizo falta una alerta.

Por eso trato la rotacion como un cambio de seguridad y tambien como una prueba de observabilidad. Si el correo de fallo o de aviso no sale bien, el equipo pierde minutos justo cuando deberia ir mas rapido.

Que suele romperse tras rotar secretos

Los fallos comunes no son muy exoticos:

variables actualizadas en la app, pero no en el worker que envia correos
permisos nuevos validos para lectura, pero no para publicar eventos
plantillas que siguen usando enlaces de un entorno anterior
reintentos silenciosos que mandan dos mensajes y confunden al on-call

Lo delicado es que muchos de estos errores no aparecen en el dashboard principal. El deploy queda verde, el readiness probe responde y nadie mira el camino completo del aviso hasta que hay una incidencia de verdad. En ese momento ya vas tarde.

Tambien conviene pensar en como se rastrea la prueba despues. En algunas notas internas la gente busca cosas como fake e mail com porque recuerdan el intento, no la herramienta exacta. Parece menor, pero sirve para documentar mejor y encontrar evidencia mas rapido.

El contrato minimo del correo operativo

Cuando reviso un correo despues de rotar secretos, espero ver cinco cosas:

Que servicio o job genero el evento.
Que entorno, region o namespace estuvo implicado.
Que timestamp corresponde a la corrida.
Cual fue el sintoma inicial, en una frase corta.
Que enlace o siguiente paso debe abrir primero la persona de guardia.

Si ese contrato no esta claro, el correo pasa de ayuda a estorbo. Me gusta mucho la idea de medir eventos de email con menos ruido, porque separa la recepcion del mensaje de la interpretacion humana. Y para equipos que todavia no tienen una rutina estable, revisar correos de activacion con una rutina simple deja una leccion util: una inbox por corrida evita muchas conclusiones equivocadas.

Si necesito una bandeja efimera para validar el flujo end-to-end, a veces uso tempmailso para no mezclar mensajes viejos con la prueba nueva. El valor no esta solo en el servicio, sino en mantener la evidencia aislada por corrida.

Un flujo de prueba que uso antes de cerrar el cambio

No hago una simulacion gigante. Prefiero una prueba corta, repetible y facil de leer:

RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
RECIPIENT="secret-rotate-$RUN_ID@example.test"

emit_security_notice \
  --service "billing-api" \
  --environment "prod-apac-1" \
  --event "secret-rotation" \
  --status "post-check" \
  --recipient "$RECIPIENT"

wait_for_message "$RECIPIENT" 120
assert_message_count "$RECIPIENT" 1
assert_subject_contains "$RECIPIENT" "secret-rotation"
assert_body_contains "$RECIPIENT" "prod-apac-1"
assert_link_host "$RECIPIENT" "runbooks.example.com"

La meta no es demostrar que el mundo es perfecto. La meta es responder rapido a tres preguntas:

llego un solo mensaje o hubo duplicados
el mensaje pertenece a esta corrida y no a una anterior
el enlace principal lleva al lugar correcto

Con eso ya puedes separar varias causas. Si no llega nada, miras permisos, cola o proveedor. Si llega dos veces, revisas reintentos o eventos duplicados. Si el asunto esta bien pero el link apunta a staging, el problema casi seguro vive en plantilla o configuracion. Parece simple, pero ese orden ahorra tiempo y evita la investigacion medio caotica que aparece a las 3 AM.

Tambien me gusta guardar una pequeña evidencia del chequeo: run_id, entorno, destinatario, latencia de entrega y host del enlace principal. No hace falta una novela. Hace falta algo que otra persona pueda leer despues sin adivinar demasiado.

Checklist corta para guardias reales

Antes de cerrar la rotacion, paso por esta lista:

el correo pertenece a la corrida actual
hay exactamente un mensaje por evento esperado
asunto y cuerpo nombran servicio y entorno
el primer sintoma se entiende sin abrir cinco tabs
el enlace principal apunta al runbook o panel correcto
la marca de tiempo coincide con el formato del equipo

No es una checklist glamourosa, pero si evita sustos bastante caros. Muchas veces la mejora mas grande en SRE no viene de una herramienta nueva, sino de dejar una verificacion decente donde antes habia fe.

Preguntas frecuentes

Hace falta correr esto en cada rotacion?

Si la rotacion toca credenciales, colas, webhooks o cualquier pieza del camino de notificaciones, yo diria que si. Cuando solo cambias documentacion o naming interno, puede bastar una prueba programada.

Conviene validar el HTML completo del email?

Normalmente no. Prefiero validar contenido operativo: asunto, contexto, enlace principal y unicidad del mensaje. El resto lo reviso aparte para no volver fragil la prueba.

Cual es la señal mas util?

Para mi, la mejor señal es que una persona medio dormida pueda leer el correo y saber que hacer primero. Si eso falla, el cambio todavia no esta realmente terminado.

Kubernetes: prueba alertas tras cambios de red

Alex Carter — Sun, 30 Aug 2026 17:24:00 +0000

Los cambios de red en Kubernetes suelen romper alertas en silencio. Esta comprobacion corta valida egress, DNS y entrega antes de dar un cambio por cerrado.

He aprendido a desconfiar un poco de los cambios de red "pequenos" en Kubernetes. Una regla de egress, un ajuste en NetworkPolicy o una salida por NAT puede parecer trivial durante la ventana de cambio, pero a veces el problema aparece veinte minutos despues, cuando Alertmanager intenta enviar un correo y nadie lo recibe. En ese punto ya no estas verificando red; estas perdiendo visibilidad operacional.

Por que un cambio de red rompe alertas sin avisar

La mayoria de estos fallos no tumban el servicio principal. La app sigue respondiendo, los probes pasan y el despliegue parece estable. El daño real cae sobre las rutas secundarias: SMTP, webhooks, DNS saliente o resolucion hacia un relay corporativo. Ese patron pasa mucho mas de lo que la gente admite, y por eso una prueba de humo especifica merece su propio paso.

Kubernetes explica que las NetworkPolicy solo afectan al trafico que coincida con los pods seleccionados, lo cual hace facil dejar una dependencia fuera de la cabeza durante un cambio: https://kubernetes.io/docs/concepts/services-networking/network-policies/. El resultado tipico es feo pero silencioso: los paneles siguen verdes y, sin embargo, el canal de alerta queda roto. Es un fallo muy incomodo, porqe la primera señal real puede ser una incidencia ya avanzada.

Mi regla es simple: si el cambio toca salida a internet, DNS interno, firewall de nodo o politicas entre namespaces, cierro el cambio solo despues de probar el camino de las alertas.

La comprobacion corta que hago despues del cambio

No hago una prueba teatral ni larga. Hago una secuencia corta, casi siempre en menos de diez minutos:

Confirmo que el pod de Alertmanager o del servicio emisor sigue resolviendo el host SMTP correcto.
Verifico conectividad al puerto esperado desde el namespace afectado.
Lanzo una alerta controlada o un evento de prueba con un identificador facil de buscar.
Reviso logs del emisor y del relay para asegurar que hubo aceptacion, no solo intento.
Confirmo recepcion en un inbox de prueba aislado.

Ese ultimo punto evita varias discusiones raras en equipos grandes. Si usas un destino compartido, alguien borra el mensaje, otro responde tarde, o una regla de filtrado te confunde. Un inbox de prueba aislado mantiene la validacion limpia. Incluso lo he usado para revisar plantillas de notificacion que terminaban en un email temporal para Facebook durante una integracion heredada medio extraña; no era elegante, pero sirvio para detectar que el asunto habia quedado truncado.

Cuando necesito pensar el flujo como sistema y no solo como "manda correo o no", me ayuda recordar este enfoque de inbox por etapa en flujos con agentes. La idea de validar cada etapa por separado tambien aplica muy bien a operaciones.

Que revisar cuando Alertmanager parece sano pero no entrega

Aqui es donde conviene ser aburridamente metódico.

Primero, DNS. Muchos equipos prueban curl a una API y dan el cambio por bueno, pero el relay SMTP va por otro nombre, otra ruta o incluso otro proxy. Si el pod no resuelve igual que antes, ya tienes media averia armada.

Segundo, tiempos de espera. Segun la documentacion de Prometheus para configuracion de Alertmanager, un error de red o autenticacion en el receptor puede no ser evidente a primera vista si solo miras el estado general del proceso: https://prometheus.io/docs/alerting/latest/configuration/. A veces el servicio esta "up", pero el receptor devuelve errores intermitentes, o reintenta mas de la cuenta y ensucia la lectura del incidente.

Tercero, evidencias. Yo guardo tres cosas en el ticket del cambio:

El comando o alerta de prueba que dispare.
La hora exacta y el identificador de correlacion.
Una captura de los logs donde se vea entrega o rechazo.

Suena basico, pero ahorra bastante tiempo cuando alguien pregunta si el cambio rompio algo horas despues. El mismo principio aparece en este post sobre auditar emails de upgrade: sin una evidencia pequeña y clara, la conversacion deriva rapido en opiniones.

Tambien reviso si algun operador ha metido destinos de prueba improvisados como tamp mail com en scripts viejos o variables de entorno. No deberia pasar, pero pasa. Y cuando aparece, la investigacion se vuelve mas lenta de lo que deveria.

Un ejemplo pequeno para probar el flujo

Este ejemplo no sustituye una prueba real, pero deja listo un chequeo rapido desde el cluster:

kubectl -n monitoring exec deploy/alertmanager -- \
  sh -lc 'getent hosts smtp.internal.example && nc -vz smtp.internal.example 587'

Si eso responde bien, suelo disparar una alerta de prueba o fuerzo un evento controlado desde el sistema que envia la notificacion. Lo importante es que el mensaje lleve un asunto o etiqueta que puedas rastrear sin dudas. En cambios delicados, prefiero anotar el change_id dentro del texto y revisar recepcion completa, no solo handshake de red.

AWS tambien insiste en que la observabilidad y la validacion posterior al cambio forman parte de una operacion sana, no de un lujo opcional, dentro de sus practicas recomendadas para EKS: https://aws.github.io/aws-eks-best-practices/. Estoy bastante de acuerdo. El error no suele estar en no saber Kubernetes; suele estar en asumir que un cambio de red ya quedo validado porque el deployment no se cayo.

He visto equipos cerrar cambios con demasiada prisa porque "el dashboard sigue verde". Luego llega una alerta real y descubren que el canal de correo estaba roto desde hace media hora. Ese tipo de fallo no es dramatico en el momento, pero te roba confianza en el proceso.

Preguntas rapidas antes de cerrar el cambio

¿Basta con probar conectividad al relay?

No. Eso confirma una parte. Todavia falta validar autenticacion, aceptacion del mensaje y recepcion final.

¿Hace falta hacerlo en cada cambio?

Si el cambio puede tocar rutas de salida, DNS, firewall o politicas entre pods, yo diria que si. No siempre tarda mucho, y evita sustos tontos.

¿Debo usar siempre el mismo inbox de prueba?

Solo si esta bien aislado y con contexto claro. Si varios jobs o equipos lo comparten, la señal se degrada bastante rapido.

¿Que quiero ver para cerrar tranquilo?

Resolucion correcta, conexion al destino, evento emitido, logs consistentes y recepcion confirmada. Si falta uno de esos pasos, para mi el cambio aun no esta del todo cerrado.

Las alertas por correo no son la parte mas glamourosa de Kubernetes, pero cuando fallan te dejan operando medio a ciegas. Por eso prefiero tratar esa validacion como parte del cambio y no como un detalle de despues. Es un paso corto, un poco aburrido, y funciona.

SRE: runbooks cortos para incidentes de email

Alex Carter — Sun, 30 Aug 2026 08:23:38 +0000

SRE: runbooks cortos para incidentes de email

Cuando un flujo de email falla en produccion, el problema rara vez es "solo correo". Lo que se rompe de verdad es una cadena: evento, cola, proveedor SMTP, plantilla, tracking y a veces una dependencia externa que nadie miro en el standup. En varios equipos he visto el mismo patron: demasiada informacion suelta y muy poca secuencia operativa. Un runbook corto suele ganar frente a una wiki enorme que nadie abre durante el incidente.

Si trabajas en SRE o Cloud, este tipo de runbook te ahorra minutos que luego parecen horas. Tambien deja evidencia util para la retro. Y si tu producto usa buzones de prueba o un correo desechable en entornos no productivos, conviene separar ese contexto desde el inicio para no mezclar sintomas.

Por que un runbook corto cambia la respuesta

En incidentes de entrega, el primer error comun es empezar por el dashboard favorito del turno. El segundo es saltar a logs sin definir la pregunta. Yo prefiero un runbook de una pagina con checks ordenados por probabilidad y costo de validacion.

No hace falta que sea sofisticado. De hecho, cuanto mas elegante lo haces, menos usable queda a las 3 AM. Un runbook util responde tres cosas:

Que ve el usuario.
Que sistema pudo romperse.
Que prueba reduce incertidumbre mas rapido.

Ese tercer punto es el que suele faltar, y ahi se pierde muchisimo tiempo.

La senal minima que siempre reviso primero

Antes de abrir trazas detalladas, reviso una vista minima con cuatro datos:

tasa de aceptacion del proveedor
tiempo entre evento y enqueue
tiempo entre enqueue y send attempt
porcentaje de rebotes o rechazos por ventana corta

Si no tienes esa vista, construyela. No necesitas una plataforma nueva; con logs estructurados y un panel simple ya puedes detectar si el cuello esta en tu app, en la cola o en el proveedor. Segun Google SRE Workbook, los equipos responden mejor cuando las alertas llevan contexto accionable en vez de solo volumen bruto. No es una idea nueva, pero sigue siendo donde mas se nota la diferencia.

Tambien intento responder una pregunta bien aburrida pero muy potente: "fallan todos los emails o solo un tipo?" Password reset, onboarding y magic links no tienen el mismo impacto ni el mismo camino interno. Suena obvio, pero en incidentes reales eso a veces se descubre tarde.

Un runbook de 15 minutos para fallos de entrega

Este es el esquema que mas me funciona cuando el equipo necesita bajar ruido rapido:

Minuto 0 a 3: confirmar alcance

Busca tres ejemplos concretos con timestamp, tenant o user id y tipo de email. Evita frases vagas como "no sale nada". Si puedes, compara con un envio sano de la misma hora. Parece basico, pero evita una investigacion medio rota desde el arranque.

Minuto 3 a 6: aislar la etapa rota

Comprueba:

el evento de negocio existe
la cola recibio el mensaje
hubo intento de envio
el proveedor devolvio accepted, deferred o rejected

Si el evento no existe, no estas ante un problema de email. Si la cola crece, mira consumidores. Si hay accepted pero no entrega final, entra soporte del proveedor o revisa reputacion/dominio. Es una ruta simple, pero evita discusiones largas y algo inutiles.

Minuto 6 a 10: revisar cambios cercanos

Los cambios que mas rompen estos flujos no siempre son "grandes deploys". Muchas veces son:

rotacion de secretos
cambio de plantilla con variable faltante
regla nueva de rate limit
ajuste DNS o proveedor secundario

Por eso me gusta enlazar en el runbook referencias a trabajos previos como validar correos despues de cambios de infraestructura. No para leer un ensayo completo en plena guardia, sino para recordar patrones de falla que ya vimos.

Minuto 10 a 15: dejar recibos

Si ya sabes el punto roto, deja evidencia antes de correr a arreglarlo:

query usada
ids de ejemplo
metrica que empezo a caer
hipotesis descartadas

Ese recibo vale oro para la retro y para el siguiente turno. Tambien evita el clasico "yo pense que ya estaba claro".

Donde entra el correo desechable sin romper el enfoque

En bastantes equipos, el incidente se mezcla con pruebas internas hechas con inboxes temporales. No es malo usar esos buzones; al contrario, pueden servir para verificar rapidez de entrega y contenido. El error aparece cuando el equipo no distingue pruebas controladas, QA y trafico real.

Mi recomendacion es sencilla:

etiqueta el origen del email de prueba
separa metrica de staging y produccion
guarda run ids para correlacion
no uses un caso de tempail como prueba unica del incidente

Si haces testing de signup o onboarding, una referencia como pruebas reales de signup ayuda a alinear producto y operacion. Los equipos de frontend suelen detectar antes los sintomas de experiencia, mientras SRE mira el pipeline de entrega. Juntarlo temprano va mejor, incluso si al principio paresca que hablan idiomas distintos.

Preguntas frecuentes del equipo

Conviene abrir incidencia con el proveedor de inmediato?

Solo si ya confirmaste que tu evento, tu cola y tu intento de envio estan sanos. Abrir ticket demasiado pronto mete espera sin reducir incertidumbre.

Cuantas metricas debe tener este runbook?

Pocas. Las suficientes para aislar etapa y severidad. Si el panel tiene veinte graficas, en la practica nadie sabe por donde empezar.

Vale la pena probar con muestras manuales?

Si, pero con disciplina. Una muestra manual sirve para confirmar comportamiento, no para reemplazar observabilidad. El runbook debe seguir siendo la fuente principal, aunque el equipo este cansado o con prisas.

Al final, un buen runbook de email no presume complejidad. Hace algo mas valioso: vuelve repetible una investigacion que antes dependia demasiado de quien estaba de guardia ese dia.

Kubernetes: 401 fugaces en CronJobs

Alex Carter — Thu, 27 Aug 2026 23:24:20 +0000

Hay fallos que se ven dramaticos en Slack y luego desaparecen antes de que abras el dashboard. Los 401 intermitentes en un CronJob entran justo en esa categoria. El job corre bien casi toda la semana, pero a las 3:00 o 4:00 AM falla una vez, reintenta, y despues todo queda verde. En guardia esto confunde bastante, porque parece un problema de red cuando muchas veces es autenticacion, reloj o contexto de ejecucion.

Cuando me toca revisar algo asi, intento no empezar por el proveedor externo. Primero reviso el contrato basico del job: identidad, token, tiempo y configuracion efectiva. Ese runbook pequeno evita dar vueltas medio tontas.

Por que un 401 aparece solo de madrugada

El patron mas comun no es "la API amanecio rota". Suelo ver una de estas causas:

El pod toma un token distinto al esperado o uno ya casi vencido.
El job arranca con variables viejas despues de una rotacion de secretos.
Hay skew de reloj entre nodo, workload y servicio remoto.
El endpoint remoto aplica ventanas de validacion mas estrictas en ciertos flujos.

En Kubernetes, varios detalles de CronJob ya invitan a mirar tiempo y scheduling. La documentacion oficial recuerda que el controlador de CronJob revisa el schedule cada 10 segundos, asi que ventanas muy chicas pueden producir comportamientos sorprendentes en la ejecucion programada: CronJob limitations. No explica un 401 por si solo, claro, pero si te obliga a revisar el momento exacto en que el job nacio y con que contexto salio.

El runbook corto que uso primero

Si estoy ayudando a otra persona de guardia, le pido estos cuatro datos antes de discutir teorias:

kubectl describe job <job> y kubectl describe pod <pod>
logs del intento fallido y del siguiente intento exitoso
manifiesto real del CronJob con env, serviceAccountName y volumenes proyectados
hora UTC del 401 y hora UTC del ultimo cambio de secreto o despliegue

Con eso ya puedes armar un diff util. El error no siempre esta en el mensaje HTTP; a veces esta en el contexto que cambió cinco minutos antes y nadie lo relacionó. Tener un par de runbooks pequenos que si escalan ayuda mucho porque fuerza a capturar evidencia y no intuiciones.

Este checklist minimo tambien me gusta:

Confirmar si el 401 ocurre antes o despues del primer retry.
Ver si el pod usa serviceAccountName correcto.
Revisar expiracion de token, no solo presencia de token.
Comparar headers o claims entre intento bueno y malo.
Mirar si el secreto montado cambió pero el cliente conserva cache interna.

Parece obvio, pero en incidentes reales la mitad del tiempo se pierde porque alguien valida solo que "la variable existe". Y existir no alcanza; tiene que ser la credencial correcta, fresca y legible por el proceso. Es una diferencia chica, pero importantisima.

Donde suele estar la causa real

En clusters modernos, yo revisaria muy pronto los tokens proyectados de ServiceAccount. Kubernetes explica que estos tokens tienen expiracion y se rotan automaticamente, lo que mejora seguridad pero tambien deja expuestos a clientes que leen el token una vez y nunca lo refrescan: ServiceAccount token projection. Si tu binario cachea el token al inicio y el job vive mas de lo previsto, ya tienes una pista bastante fuerte.

La segunda causa repetida es una rotacion de secretos mal sincronizada. El secreto nuevo existe, el workload nuevo aun no corre, y el CronJob dispara justo en esa franja rara. El 401 aparece una sola vez, luego el siguiente pod arranca con la version correcta y parece "magia". No lo es, solo fue timing feo.

Tambien miraria endpoints que firman peticiones con timestamp. Cuando el nodo o la imagen base trae hora desalineada, el servicio remoto rechaza la firma aunque la llave sea buena. No es lo mas comun, pero cuando pasa se siente bastante injusto, la verda.

Un detalle mas: si el job toca sistemas de prueba, vas a encontrar rastros raros en payloads y notas operativas, cosas como temp mailid o dummy e mail pegadas en fixtures o variables locales. No son la causa del 401, pero sirven como señal de que el flujo mezcla trafico de QA con operacion real y eso enturbia el analisis.

En esa parte me ayuda pensar en contratos operativos faciles de auditar: que credencial espero, donde se monta, cuanto dura, que claim valida el remoto y que evidencia dejo si falla. Cuando ese contrato no existe, el incidente se alarga por puro desorden.

Que dejar automatizado para la siguiente guardia

Si ya encontraste la causa, no cierres el caso sin dejar una mejora chica. Mis favoritas:

Loggear issuer, audience y expiracion del token sin imprimir secretos.
Emitir una metrica por causa de 401 clasificada en cliente, credencial o remoto.
Guardar hash de version de secreto o config usada por cada job.
Fallar rapido cuando falte serviceAccountName esperado.
Añadir una prueba que levante el job con credenciales rotadas.

No hace falta un sistema enorme. Con dos o tres señales bien elegidas, el siguiente incidente cae mucho mas rapido. Y eso para SRE vale oro, sobre todo en turnos donde el cerebro aun no desperto del todo.

Preguntas frecuentes

Conviene reintentar automaticamente un 401?

Solo si sabes distinguir entre credencial vencida y permiso realmente denegado. Reintentar a ciegas puede esconder el problema y llenar de ruido los logs.

Que comparo entre un intento bueno y uno malo?

Hora de inicio, service account, claims del token, version del secreto y destino exacto. Si comparas solo el body del error, casi nunca alcanza.

Esto pasa solo en jobs largos?

No. Tambien aparece en jobs cortos que arrancan durante una ventana de cambio de secretos, de rollout o de permisos. A veces dura segundos, pero rompe igual.

Si un CronJob tuyo falla con 401 solo de madrugada, yo no empezaria por culpar a la API externa. Empezaria por identidad, tiempo y evidencia del pod. Casi siempre ahi esta el hilo del que tirar, aunque al principio se vea pequeñito.

Kubernetes: depura 401 intermitentes con contexto

Alex Carter — Wed, 26 Aug 2026 05:25:02 +0000

Los 401 intermitentes en Kubernetes son de esas alertas que desgastan mas de lo que parecen. Un pod responde bien durante media hora, luego falla dos minutos, despues vuelve a la vida, y la tentacion es reiniciar primero y pensar despues. El problema es que ese reinicio muchas veces borra la pista util.

En guardias SRE me funciona tratar este fallo como un rompecabezas pequeno: credencial, reloj, cache, permisos y dependencia externa. Casi nunca es una sola cosa, y por eso conviene entrar con un orden simple. Si no, acabas mezclando sintomas de app con sintomas de plataforma y el incidente se vuelve pegajoso.

Por que un 401 intermitente engancha tanto

Lo dificil no es el 401 en si. Lo dificil es que suele aparecer en una ruta concreta, con volumen irregular, y encima convive con metricas que se ven normales. CPU bien. Memoria bien. Latencia promedio aceptable. Pero un flujo de negocio ya esta roto.

He visto tres causas repetirse bastante:

Un secreto se roto bien en Kubernetes, pero la aplicacion relee tarde o nunca.
El token sigue vivo en unos workers y vencio en otros por diferencia de arranque.
La API externa responde 401 por una condicion secundaria, como reloj desfasado o audiencia incorrecta.

En ese punto, reiniciar todo aveces mejora la foto unos minutos, pero no te dice cual causa era la real. Y si el problema vuelve en la siguiente ventana de trafico, el equipo queda igual de ciego.

Que mirar antes de reiniciar

Mi regla es revisar primero cuatro piezas:

Si el secreto o token cambio de verdad y cuando cambio.
Que workloads consumen esa credencial.
Si el fallo ocurre en todos los pods o solo en una parte.
Que dice la dependencia externa sobre rechazos recientes.

Con eso ya puedes evitar media docena de hipotesis flojas. Un chequeo inicial puede ser tan simple como esto:

kubectl get secret api-credential -n billing -o yaml | head -n 20
kubectl get pods -n billing -o wide
kubectl logs deploy/billing-api -n billing --since=15m | rg "401|403|expired|audience|token"
kubectl describe pod -n billing billing-api-7d9f6d7d7b-abcde

Tambien suelo mirar si hubo algun cambio de rollout, porque a veces el problema no es "token malo" sino mezcla de replicas nuevas y viejas. Esa diferencia de estado engancha mucho. En otros equipos lo comparo con validar sin castigar cada tecla: si no separas la senal buena del ruido, terminas reaccionando a cada salto aunque el sistema no te este diciendo la verdad completa.

Un runbook corto para separar causas

Este orden me ha servido bastante bien:

Confirmar si el 401 viene del servicio propio o de una API aguas abajo.
Revisar timestamp de la ultima rotacion y hora de arranque de cada pod afectado.
Comparar un pod sano con uno fallando: env vars, volumenes, service account, reloj y logs.
Probar una llamada controlada con la misma credencial fuera del pod, si el entorno lo permite.
Reiniciar solo una replica o canary cuando ya tengas una hipotesis fuerte.

El punto tres parece aburrido, pero suele ahorrar mucho. Si un pod viejo funciona y uno nuevo no, ya no estas delante de un incidente "global". Estas delante de una diferencia concreta de configuracion, montaje o init flow. Eso cambia la conversacion por completo.

Cuando necesito dejar evidencia clara, anoto algo asi:

pods afectados y pods sanos
hora de arranque de cada uno
version del secreto observada
error exacto devuelto por la API
resultado de una prueba manual corta

No hace falta un documento perfecto. Hace falta una ruta para que el siguiente operador no empiece desde cero, que pasa mas de lo que deberia.

Como valido el fix sin inventarme senales

Una vez rota la credencial o corregido el consumer, intento validar con dos capas. Primero, la llamada principal que antes devolvia 401. Segundo, una senal secundaria que use la misma ruta funcional pero no dependa solo de "parece que ya no falla".

Si tu flujo manda correos, crea jobs o dispara callbacks, una validacion secundaria ayuda. Pero hay que usarla con cuidado. Si la cola o el sistema auxiliar ya iba lento, puedes leer una conclusion falsa. Ese tipo de error se parece bastante a una validacion sin saltos ni foco roto: el objetivo no es producir mas eventos, sino confirmar el estado correcto con el menor ruido posible.

En pruebas internas he visto equipos usar buzones de descarte y nombres de referencia como temp mail so o tempmailso para no mezclar cuentas reales. Esta bien como apoyo. Lo que no conviene es convertir esa prueba en la unica evidencia del fix. Y si aparece en notas viejas algo como tepm mail com o temp mailid, lo trato como pista sucia de QA, no como verdad operativa.

Si quieres una comprobacion algo mas seria, compara:

tasa de 401 antes y despues del cambio
porcentaje de pods sanos por replica set
eventos de rotacion o rollout en la misma ventana
una prueba manual repetible contra el endpoint afectado

Cuando esas cuatro piezas se alinean, ya puedes cerrar la incidencia con bastante mas calma.

Checklist para la proxima guardia

Antes de irme, dejo este checklist pequeno:

cual fue la credencial implicada
si el fallo venia de Kubernetes o de una dependencia externa
cuantos pods estaban realmente afectados
si la app relee secretos en caliente o no
que cambio resolvio el 401
que evidencia confirma que el fix aguanto

Es una lista simple, pero evita que la siguiente guardia repita los mismos dos o tres intentos fallidos. Y honestamente, eso ya vale mucho.

Q&A

Debo reiniciar todo al primer 401?

No. Si reinicias sin separar causas, puede parecer que arreglaste el problema cuando solo moviste el sintoma. Mejor compara pods, secreto y dependencia primero.

Como se si el error es de reloj o de permisos?

Busca el mensaje exacto del proveedor y compara timestamps entre nodos, pods y sistema emisor. Un 401 por reloj desfasado deja pistas distintas a un token vencido o una audiencia incorrecta.

Cuanta evidencia necesito para cerrar?

La suficiente para repetir la conclusion: logs, una prueba manual corta y una caida clara en errores despues del cambio. Si solo tienes intuicion, todavia falta un poco.

Kubernetes: valida alertas tras rotar secretos

Alex Carter — Tue, 25 Aug 2026 17:24:57 +0000

Rotar secretos de SMTP en Kubernetes suele parecer una tarea menor hasta que el primer correo de alerta no sale, sale duplicado o llega con enlaces viejos. El cambio tecnico ya ocurrio, pero la parte operativa sigue abierta. En varios equipos he visto ese hueco: se actualiza el Secret, se reinicia lo justo, se mira que el pod quede sano... y nadie confirma que la alerta mas importante todavia explica bien lo que paso.

Por eso me gusta tratar esta verificacion como un mini cierre de cambio. No hace falta montar una suite enorme. Hace falta una prueba corta, legible y repetible que confirme que el flujo de correo sigue vivo despues de la rotacion. Si usas una direccion de correo desechable para la corrida, mejor todavia, porque aislas evidencia y no llenas una inbox compartida con ruido. En notas internas alguna gente lo llama tem email; no es bonito, pero ya sabes como escribimos cuando vamos con prisa.

Por que rotar el secreto no cierra el trabajo

El riesgo no suele estar en Kubernetes por si solo. El riesgo aparece entre piezas:

el deployment tomo el secreto nuevo pero el worker de alertas no
el certificado o relay externo acepta auth, pero rechaza el remitente
la plantilla del mensaje sigue apuntando a un host viejo
un reintento automatico manda dos avisos y confunde al on-call

Ese ultimo punto pasa mas de lo que parece. Segun el informe 2024 de The State of Production Incidents de PagerDuty, la claridad del contexto inicial sigue siendo uno de los factores que mas reduce escalado innecesario durante incidentes. No hace falta poner un numero en cada runbook para notar lo mismo en guardias reales: si el primer aviso llega raro, todo el mundo pierde minutos valiosos.

Tambien conviene pensar en el cambio como una cadena de estados, no como un unico "correo enviado". Si ya trabajaste patrones para recibir eventos de email sin mezclar estados viejos, esta validacion encaja bien con esa mentalidad. Y si el sistema tiene polling o reintentos, revisar como manejar reintentos de verificacion sin duplicados tambien ayuda bastante.

Que suelo validar justo despues del cambio

Cuando termino la rotacion, reviso solo lo minimo que de verdad evita una guardia tonta:

La alerta sale usando las credenciales nuevas.
El asunto identifica servicio, entorno y accion.
El cuerpo trae un enlace util al sistema correcto.
No aparecen duplicados por restart o por replay del worker.
La marca horaria coincide con el cambio recien hecho.

Si una de esas cinco cosas falla, no doy por cerrado el cambio. Es un criterio simple, pero muy util. Aveses la entrega funciona y aun asi el correo llega con un link a un dashboard viejo o con un nombre de cluster heredado. Eso no rompe el transporte, pero si rompe la operacion.

En entornos con Alertmanager, un relevo SMTP o un worker propio, tambien miro donde se cachean credenciales. Hay procesos que releen secretos al vuelo y otros que necesitan reinicio controlado. Esa diferencia, tan pequena sobre el papel, es la que luego explica porque la prueba manual "parecia bien" y la alerta real de media hora despues no salio.

Un check pequeno que evita guardias confusas

Mi preferencia es usar una sola corrida, una sola inbox aislada y una sola expectativa clara:

RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
RECIPIENT="alert-rotate-$RUN_ID@example.test"

kubectl apply -f smtp-secret.yaml
kubectl rollout restart deploy/alert-dispatcher -n platform
kubectl rollout status deploy/alert-dispatcher -n platform

trigger_test_alert \
  --namespace platform \
  --service checkout-api \
  --severity warning \
  --recipient "$RECIPIENT"

wait_for_message "$RECIPIENT" 120
assert_message_count "$RECIPIENT" 1
assert_subject_contains "$RECIPIENT" "checkout-api"
assert_body_contains "$RECIPIENT" "platform"
assert_link_host "$RECIPIENT" "grafana.example.com"

No intenta probar todo. Solo responde la pregunta correcta: despues de cambiar el secreto, la alerta util sigue llegando y sigue apuntando al sitio correcto? Si la respuesta es no, quiero enterarme en ese momento, no cuando alguien esta medio dormido a las 03:10.

Otra cosa que me sirve mucho es guardar el run_id junto al evento de prueba. Asi puedes separar una entrega tardia de una corrida anterior frente a un fallo real de la actual. Parece obvio, pero en mas de una revision he visto equipos perseguir un flake que era simplemente un mensaje viejo.

Senales que conviene guardar en el runbook

No hace falta llenar el runbook de campos, pero estas senales si las conservo:

run_id
namespace o cluster
nombre del deployment reiniciado
destinatario usado en la prueba
host principal detectado en enlaces
latencia hasta recepcion
resultado final de la verificacion

Con eso ya puedes explicar casi cualquier fallo comun. Si el correo no llega, miras auth y relay. Si llega duplicado, revisas replay o reintentos. Si llega bien pero enlaza mal, la causa suele estar en plantilla o config. Es una tabla de decision bastante humilde, pero funciona.

Preguntas frecuentes

Hay que probar esto en cada rotacion?

Si la rotacion afecta credenciales reales del flujo de alertas, para mi si. No siempre con la misma profundidad, pero al menos con un smoke check corto.

Sirve una inbox compartida?

Puede servir, pero prefiero una aislada por corrida. Una direccion de correo desechable o temporal reduce ruido y hace mas facil saber que mensaje pertenece a este cambio y no a otro.

Debo validar HTML completo?

Normalmente no. Prefiero asunto, destinatario, host de enlaces y una o dos cadenas clave del cuerpo. El objetivo es confianza operativa, no perfeccion visual.

Cual es el error mas comun?

Cerrar el cambio cuando el pod ya levanto y asumir que el correo tambien quedo bien. Esa suposicion es la parte fragil, y suele costar mas de lo que paresce.

Kubernetes: alerta antes de que expire un token

Alex Carter — Tue, 25 Aug 2026 08:24:15 +0000

Los tokens que caducan en Kubernetes rara vez avisan de forma comoda. Lo mas normal es ver primero un sintoma lateral: un job deja de hablar con una API, una integracion externa empieza a devolver 401, o un pod sano en metricas queda medio roto en negocio. En ese punto, el impulso natural es reiniciar algo. A veces ayuda, pero muchas veces solo mueve el problema unos minutos y te quita contexto.

En guardias de SRE me ha servido tratar la expiracion como una senal operativa, no como un detalle de implementacion. Si un token va a vencer pronto, quiero saberlo antes de que caiga el primer flujo importante. Y si ya vencio, quiero ver rapido que workloads quedaron tocados, que margen tengo para rotar, y si el fallo esta en Kubernetes o en el sistema que emite la credencial.

El fallo aparece tarde y por eso engancha

El patron mas pesado es el de degradacion lenta. El token sigue valido en algunos procesos por cache, pero otro componente ya empezo a fallar. Desde fuera se ve raro: latencia estable, CPU normal, y errores de autenticacion subiendo solo en un camino concreto. Ese estado intermedio roba muchisimo tiempo.

Por eso la alerta no deberia decir solo "token expires soon". Me sirve mas cuando trae:

namespace y secreto o service account implicado
workloads que consumen esa credencial
fecha real de expiracion y margen restante
errores recientes de autenticacion asociados
enlace rapido al runbook de rotacion

Es la misma idea de rotar secretos sin reinicios ciegos: una senal con contexto baja el ruido y evita decisiones torpes. Cuando esa pieza falta, el on-call tiene que reconstruir el mapa a mano, y ahi se va media incidencia facil.

Que senales pongo antes de que el token venza

No hace falta montar una plataforma gigante. Un primer paso bastante util es medir tres cosas:

Cuantos dias u horas le quedan a cada token critico.
Que despliegues o CronJobs dependen de el.
Si ya hay errores de autenticacion en logs o eventos.

Cuando el token vive en un secreto sincronizado desde otro sistema, tambien intento guardar la hora de emision original. Sin eso, el operador ve el secreto "nuevo" en Kubernetes y asume que todo esta bien, aunque la credencial copiada ya venia casi vencida. Me ha pasado mas de una vez, y se pierde rato en la direccion equivocada.

Un chequeo sencillo puede verse asi:

kubectl get secret payments-api-token -n payments -o json | jq -r '.metadata.name'
kubectl get deploy -n payments -o json | jq '.items[] | {name: .metadata.name, sa: .spec.template.spec.serviceAccountName}'
kubectl logs deploy/payments-api -n payments --since=20m | rg "401|403|token|expired|credential"
kubectl get events -n payments --sort-by=.lastTimestamp | tail -n 20

No es perfecto, pero ordena la primera media hora. Tambien ayuda a separar un problema de expiracion real de un problema de permisos, reloj desfasado o rollout a medias. Ese matiz parece pequeno, pero cambia mucho la respuesta.

Un runbook pequeno para no reiniciar a ciegas

Cuando veo que una credencial esta cerca del borde, sigo este orden:

Confirmar expiracion real y sistema dueño del token.
Identificar workloads impactados y priorizar los que tocan ingreso o pagos.
Validar si la app relee el token en caliente o solo al arranque.
Rotar en un servicio pequeno o canary antes del resto.
Observar errores de autenticacion, latencia y colas durante 5 a 10 minutos.
Completar rollout solo si la evidencia aguanta.

La parte importante no es que el runbook sea elegante. Lo importante es que reduzca apuestas. Si saltas directo al restart global, aveces recuperas disponibilidad, si, pero tambien escondes cual workload estaba mal cableado y cual seguia usando un token cacheado.

Otra cosa que procuro dejar escrita: quien es el owner del token. Suena obvio, pero en incidentes reales aparece mucho credencial "de plataforma" que en verdad depende de un equipo externo, o de una integracion vieja que nadie quiere tocar. Esa ambiguedad hace el incidente mas largo de lo que deberia ser.

Donde encajan las pruebas de notificacion

Algunas rotaciones activan emails, webhooks o mensajes a otro sistema. Eso no prueba por si solo que el token quedo bien, pero si da una capa extra de evidencia. Para entornos de QA o pruebas internas, a veces uso tempmailso o un servicio de free disposable email para revisar una notificacion sin mezclar buzones reales. Lo importante es tratarlo como validacion secundaria, no como la prueba principal.

Si esa notificacion depende de un worker o de polling, me sirve muchisimo revisar tambien algo como este enfoque de polling de inbox con limites sanos. La razon es simple: si el canal auxiliar ya venia lento, puedes culpar al token y perder tiempo. Un tempail perdido en una cola atrasada no te dice nada bueno sobre la salud del cluster.

En otras palabras, primero estabiliza autenticacion. Luego confirma mensajeria. Hacer ambas hipotesis al mismo tiempo parece eficiente, pero casi nunca sale bien del todo.

Checklist para la siguiente guardia

Antes de cerrar, dejo una nota corta con esto:

que token o secreto estaba por vencer
quien era el owner real de la credencial
que workloads consumian ese valor
si hacia falta reinicio o recarga dinamica
que error desaparecio despues de la rotacion
que prueba secundaria use para validar el flujo
que duda quedo abierta para horario laboral

No tiene que quedar bonito. Tiene que quedar util. Una guardia futura agradece muchisimo esa nota medio fea pero concreta.

Q&A

Conviene alertar por todos los tokens?

No. Empieza por los que sostienen rutas criticas o integraciones externas. Si alertas por todo desde el dia uno, el equipo dejara de mirar la senal bastante rapido.

Reiniciar siempre resuelve?

No necesariamente. Si el token nuevo no llego, o si el sistema emisor entrego una credencial mala, el reinicio solo mueve el error. Primero confirma la causa.

Cuanto margen de expiracion deberia vigilar?

Depende del sistema, pero me funciona separar dos umbrales: uno preventivo para horario laboral y otro mas agresivo para guardia. Ese detalle evita correr por nada, pero tambien evita llegar tarde.

Kubernetes: senales utiles para CronJobs fragiles

Alex Carter — Tue, 25 Aug 2026 02:24:44 +0000

Los CronJobs en Kubernetes suelen parecer simples hasta que fallan de forma intermitente. El contenedor termina, vuelve a correr mas tarde, y el equipo solo ve una alerta floja de "job failed". En guardias SRE eso desgasta bastante porqe cada intento deja pistas distintas: a veces falta CPU, a veces una dependencia externa tarda demasiado, y a veces el problema es un dato raro que solo aparece una vez al dia.

Con el tiempo me sirvio una regla muy concreta: para jobs fragiles no necesitas mas dashboards, necesitas mejores senales iniciales. Si en los primeros cinco minutos puedes responder que cambio hubo, que dependencia se movio y si el fallo fue por saturacion o por datos, ya vas muy por delante. Si no, el triage se vuelve un paseo medio ciego.

Por que los CronJobs fallan sin avisar bien

Un servicio web roto suele dejar errores visibles enseguida. Un job programado no. Puede fallar a las 02:00, reintentarse a las 02:15 y recien notarse cuando una cola amanecio vacia o cuando un reporte no llego. Ese desfase hace que mucha evidencia se pierda o quede desordenada.

Segun el estado de observabilidad 2024 de Splunk, los equipos con mejor contexto operativo reducen el tiempo de investigacion y el trabajo reactivo manual (Splunk Observability Report). No hace falta tomar ese dato como una formula exacta, pero si como recordatorio de algo muy real: una alerta sin contexto obliga al equipo a reconstruir la historia desde cero.

Tambien he visto que el ruido crece cuando el job comparte componentes con flujos asincronos o notificaciones. En esos casos ayuda mucho mantener el contexto cuando un job dispara correos, porque asi no mezclas un timeout del batch con un fallo secundario del canal de salida. Parece obvio, aunqe en una madrugada cansada no siempre lo es.

Las tres senales que reviso primero

Cuando me toca un CronJob inestable, casi siempre empiezo por estas tres preguntas:

El job fallo por recursos, por dependencia o por datos.
Que cambio reciente coincide con la ventana del fallo.
La siguiente corrida hereda el mismo riesgo o no.

Eso traduce el incidente a algo accionable. Si el pod quedo OOMKilled, miro requests, limits y el perfil de memoria. Si termino por timeout, comparo duracion historica y latencia aguas abajo. Si el job salio con error de negocio, intento capturar el input exacto antes de tocar la imagen o el horario.

Un bloque minimo que me gusta tener a mano es este:

kubectl get cronjob reports-sync -n ops -o yaml
kubectl get jobs -n ops --sort-by=.metadata.creationTimestamp | tail -n 5
kubectl describe job reports-sync-28934122 -n ops
kubectl logs job/reports-sync-28934122 -n ops --previous

No resuelve todo, claro, pero te saca del modo "adivinar". Varias veces el problema no estaba en Kubernetes sino en una API lenta o en un secreto rotado de forma incompleta. Si empiezas por señales pequeñas pero firmes, evitas perseguir sintomas demasido vistosos.

Un checklist corto para aislar el problema

Para no abrir veinte pestañas de golpe, suelo seguir este orden:

Confirmar si fallo una sola corrida o varias seguidas.
Mirar lastScheduleTime, concurrencia y politica de reintentos.
Comparar duracion p95 de corridas sanas frente a la corrida rota.
Revisar un cambio cercano: imagen, ConfigMap, secreto o dependencia.
Definir una mitigacion reversible antes de relanzar manualmente.

La parte importante esta en el paso cinco. Hay equipos que rerunean el job demasiado pronto y despues ya no saben si el fix fue real o si solo paso el dato raro. Yo prefiero dejar escrito algo simple: "si la latencia externa sigue alta, no relanzar; si la cola ya dreno y el fix esta aislado, correr una vez". No suena elegante, pero ordena muy bien la conversacion.

En entornos donde el job termina enviando avisos internos o reportes al cliente, tambien me sirve dejar el soporte listo cuando entran avisos de trial. La leccion no es de marketing, es operativa: si la salida del job tiene destinatarios claros, ownership y ventanas de validacion, luego es mucho mas facil detectar si el fallo fue tecnico o solo de distribucion.

Donde entra el correo de usar y tirar en pruebas operativas

No recomiendo meter cuentas temporales en cualquier flujo serio, pero en smoke tests no productivos a veces ayudan. Cuando un CronJob genera resumentes, enlaces de descarga o notificaciones de onboarding interno, un correo de usar y tirar puede servir para comprobar entrega y formato sin mezclar buzones reales del equipo.

La clave es tratarlo como herramienta de prueba, no como parte del diseno principal. Si un test depende de una direccion temporal, debe quedar etiquetado y fuera de cualquier metrica de negocio. Tambien conviene anotar cadenas raras que aparecen en soporte o en seeds de QA, como tempail o fake e mail com, para que nadie las confunda con trafico sano. Este detalle parece pequeño, pero varias veces me ahorro una investigacion boba.

Si ademas dejas el scenario ID, el timestamp y el destino temporal junto al log del job, la siguiente persona entiende la corrida sin pelearse con tres sistemas distintos. Ese tipo de prolijidad paga sola, aunque al principio de un poco de pereza.

Preguntas frecuentes

Conviene alertar por cada fallo de CronJob?

No siempre. Si el job corre cada minuto, alertar por cada error puede tapar lo importante. Me funciona mejor alertar por fallos consecutivos, por duracion anormal o por ausencia de resultado esperado.

Que metrica suele faltar?

La de exito util. Mucha gente mira si el pod termino en Completed, pero no si genero el artefacto correcto, movio los registros esperados o entrego el mensaje correcto. Esa diferencia cambia todo.

Esto es solo para Kubernetes grande?

Para nada. Vale igual en clusters pequenos. De hecho, en equipos chicos se nota mas, porque una señal mala te come media manana sin pedir permiso.

Si tus jobs programados siguen rompiendose de forma borrosa, yo empezaria por mejorar la alerta inicial y el checklist de evidencia. No hace magia, pero baja bastante el tiempo muerto y deja al equipo pensando mejor, no corriendo mas.

Terraform: alertas de drift con contexto

Alex Carter — Fri, 21 Aug 2026 23:24:38 +0000

Las alertas de drift en Terraform suelen fallar de una forma muy discreta. El detector corre, encuentra diferencia entre el estado y la realidad, manda un correo, y en teoria ya esta. En la practica, muchas veces el mensaje llega sin decir que recurso cambio, que workspace esta afectado o si el desvio aparecio tras un deploy legitimo. He visto equipos perder una hora por eso, facil.

Cuando la alerta no trae contexto, la guardia termina abriendo consola, historial de cambios y logs al mismo tiempo. Eso desgasta bastante, y lo peor es que el problema no esta en Terraform sino en como contamos el incidente. Mi regla suele ser simple: si el correo no ayuda a decidir el siguiente paso en menos de un minuto, el alerta esta medio rota aunque haya salido bien.

Por que tantas alertas de drift se vuelven ruido

Lo comun es implementar el check de drift como una tarea programada y dejar la notificacion para el final. Funciona al principio, pero luego aparecen pequeños defectos que se acumulan:

asuntos genericos como "drift detected"
cambios reales sin nombre de workspace o cuenta cloud
enlaces a dashboards que ya no apuntan al entorno correcto
correos duplicados por reintentos mal cerrados
mensajes que dicen que hubo drift pero no separan cambio esperado de cambio peligroso

Ese ultimo punto importa mucho. Un drift despues de una accion manual de emergencia no se interpreta igual que un drift en una politica IAM tocada fuera de pipeline. Si el mensaje no marca esa diferencia, el on-call hace trabajo de detective a las 3 AM, y nadie quiere eso la verdad.

Tambien conviene pensar en la parte humana. En notas internas he visto a gente buscar cosas con palabras raras como temp mailid o tempail porque recuerdan a medias la herramienta o el flujo usado para validar emails. No es elegante, pero asi trabaja la gente cuando va rapido.

El contexto minimo que una alerta debe traer

Para mi, una alerta de drift util deberia responder estas cinco preguntas sin obligarte a abrir otras tres pantallas:

Que workspace, stack o modulo disparo el hallazgo.
Que recurso concreto cambio o al menos que tipo de recurso esta afectado.
En que cuenta, region y entorno aparecio.
Si el drift viene de una lectura periodica, de una aprobacion manual o de una ejecucion fallida reciente.
Cual es el primer enlace util: plan, PR, runbook o dashboard.

Ese formato parece muy basico, pero cambia bastante la calidad operativa. En un articulo anterior sobre rotar secretos sin romper alertas comentaba algo parecido: la alerta debe reducir ambiguedad, no solo demostrar que existe un sistema de avisos.

Si tu equipo ya valida correos en otros flujos, como aprobaciones o upgrades, te puede servir esta guia sobre probar upgrades por email sin ruido. Aunque venga de un contexto SaaS, la idea de aislar una corrida y revisar un mensaje con criterios claros encaja muy bien en DevOps tambien.

Una prueba corta antes de confiar en ella

No hace falta montar una suite enorme para estas alertas. Yo prefiero una prueba corta, repetible y con evidencia minima:

RUN_ID="$(date -u +%Y%m%dT%H%M%SZ)"
WORKSPACE="network-prod"
INBOX="tf-drift-$RUN_ID@example.test"

trigger_drift_check \
  --workspace "$WORKSPACE" \
  --region "ap-southeast-1" \
  --expect-resource "aws_security_group_rule" \
  --recipient "$INBOX"

wait_for_message "$INBOX" 120
assert_message_count "$INBOX" 1
assert_subject_contains "$INBOX" "$WORKSPACE"
assert_body_contains "$INBOX" "aws_security_group_rule"
assert_body_contains "$INBOX" "$RUN_ID"

Lo importante no es el inbox en si, sino que la corrida quede aislada. Si el equipo usa un generador de correo falso o una bandeja descartable, bien. Si usa otra cosa interna, tambien vale. Lo que no conviene es reutilizar la misma bandeja entre corridas y luego discutir si el correo visto era de hoy o del miercoles pasado.

En esta parte suelo guardar un paquete de evidencia pequeño:

run_id
workspace y region
recurso esperado
destinatario usado
host del enlace principal
tiempo hasta recepcion

Eso alcanza para separar problemas bastante distinto entre si. Si el mensaje llega una vez pero sin region, la plantilla esta floja. Si llega dos veces con el mismo run_id, probablemente hay reintentos sin cierre. Si trae recurso y region pero enlaza al plan equivocado, el bug esta en el mapeo entre pipeline y notificacion. Parece obvio escrito asi, pero en incidentes reales ayuda un monton tenerlo ordenado.

La checklist que deja menos dudas

Antes de dejar activa una alerta de drift, reviso esto:

el asunto nombra workspace o stack
el cuerpo menciona recurso, region y entorno
el mensaje distingue drift esperado de drift sospechoso, aunque sea con una nota corta
el enlace principal abre el panel o runbook correcto
no hay duplicados para la misma corrida
el correo incluye una accion siguiente razonable

Si quieres agregar una mejora mas, añade un resumen corto del impacto. Algo como "regla de ingreso abierta a 0.0.0.0/0" orienta mucho mejor que "policy changed". No hace milagros, pero ahorra varias preguntas en Slack y un par de vueltas innecesarias.

Preguntas frecuentes

Conviene correr esta prueba en cada PR?

Solo si el cambio toca plantillas, routing de alertas, politicas IAM relacionadas o la logica que arma el contexto. Para cambios normales de modulos, una corrida programada suele ser suficiente.

Hace falta mostrar el diff completo en el correo?

Normalmente no. Prefiero una version corta con el tipo de recurso, el atributo sensible y un enlace al detalle. Un correo larguisimo se vuelve dificil de leer y casi nadie lo procesa bien bajo presion.

Cual es el error mas comun?

Mandar una alerta correcta pero inutil. Es decir: sale a tiempo, tiene buen asunto, pero no dice que hacer despues. Ese hueco parece menor, pero es donde mas se pierde tiempo cuando hay guardia de verdad.

Kubernetes: rota secretos sin reinicios ciegos

Alex Carter — Thu, 20 Aug 2026 23:24:36 +0000

La rotacion de secretos en Kubernetes casi nunca falla de forma elegante. Lo normal es algo mas incomodo: un token vence, un pod sigue vivo con credenciales viejas, o una app reinicia bien en staging pero raro en prod. Cuando eso pasa, muchos equipos saltan directo a reiniciar todo. Ese reflejo aveces resuelve el sintoma, pero tambien borra pistas y mete ruido justo cuando mas necesitas claridad.

En guardias de SRE me ha servido tratar la rotacion como un cambio operacional con evidencia minima, no como un boton magico. Si un secreto cambia, quiero saber que workloads lo consumen, que parte lee el valor solo al arranque, y que alertas apareceran si hago rollout ahora mismo.

Cuando la rotacion de secretos falla no siempre explota al momento

El patron mas enganoso es este: el secreto ya fue actualizado, pero solo una parte del sistema empezo a usarlo. Algunos pods leen desde variable de entorno, otros desde volumen montado, y otro servicio guarda conexiones abiertas durante varios minutos. Desde fuera parece que todo esta "medio bien". Ese estado medio roto es el que mas tiempo roba.

Por eso prefiero una alerta que diga algo util, no solo "secret changed". Necesito al menos:

nombre del secreto y namespace
despliegues o CronJobs que dependen de el
si el consumo ocurre en arranque, refresh interno o ambos
si hubo errores de autenticacion despues del cambio

Es la misma idea de preparar senales con contexto antes de tocar produccion. Una senal desnuda obliga al on-call a reconstruir la escena entera, y ahi se va un monton de tiempo.

Que revisar antes de reiniciar pods

Antes de tirar un kubectl rollout restart, hago tres preguntas:

El secreto cambio de verdad o solo cambió metadata que no consume la app.
La aplicacion relee credenciales en caliente o necesita proceso nuevo.
El fallo esta en el secreto, o en el sistema que envia la nueva credencial.

Ese tercer punto importa mucho. Varias veces el error no era Kubernetes sino una cola atrasada de notificaciones, un job que escribia tarde, o un proveedor externo que entregaba el valor con demora. Si no ves esa parte, reinicias pods sanos y el incidente se vuelve mas feo.

Un chequeo pequeno que suele bastar:

kubectl get secret api-credentials -n payments -o yaml
kubectl get deploy -n payments -o json | jq '.items[] | {name: .metadata.name, secrets: [.spec.template.spec.containers[].envFrom[]?.secretRef.name]}'
kubectl rollout status deploy/payments-api -n payments
kubectl logs deploy/payments-api -n payments --since=15m | rg "auth|token|secret|credential"

No es un runbook brillante, pero si ordena la primera media hora. Tambien deja visible si el problema es parcial. Y un incidente parcial mal leido, bueno, se convierte facil en incidente total.

Un runbook pequeno para rotar secretos sin panico

Cuando el servicio no soporta recarga dinamica, uso un flujo simple:

Confirmar version nueva del secreto y timestamp real de actualizacion.
Identificar workloads impactados y ordenarlos por criticidad.
Reiniciar primero un replica set pequeno o una canary si existe.
Medir autenticacion, latencia y errores de negocio durante 5 a 10 minutos.
Completar rollout solo si la evidencia sigue limpia.

Si un componente manda emails o links de verificacion al cambiar credenciales, me gusta separar esa prueba de la ruta principal. Para entornos de QA, una direccion desechable puede ayudar a validar la notificacion sin mezclar bandejas reales. Lo importante es que ese paso sea evidencia secundaria, no la prueba central de que el secreto quedo bien propagado.

Tambien conviene hacer visible cualquier backlog de entrega. El articulo sobre hacer visible una cola de notificaciones lentas toca esa idea desde backend, pero en operaciones aplica igual: si la senal externa llega tarde, el operador necesita verlo rapido.

En varios equipos aun aparece un tem email en alguna prueba rapida o un reinicio manual "por si acaso". Yo no diria que sea prohibido, pero si deja deuda. Si la guardia siguiente no entiende por que reiniciaste, el aprendizaje se pierde y el mismo bug vuelve.

Donde ayudan las pruebas de notificaciones

No toda rotacion necesita email, Slack o webhook, pero cuando existen, hay que tratarlos como canales de soporte. Sirven para confirmar que el flujo alrededor del secreto esta sano, aunque no reemplazan logs, metricas ni eventos del cluster.

Algo que si he aprendido a la mala: no mezclar el runbook de credenciales con el runbook de mensajeria. Si cambia una password de base de datos y ademas falla el aviso, primero estabiliza la app. Luego revisas la notificacion. Hacer ambas cosas al mismo tiempo suena eficiente, pero normalmente te deja con dos hipotesis malas en vez de una hipotesis buena.

Checklist para la siguiente guardia

Antes de cerrar el incidente, dejo una nota corta con esto:

que secreto cambio y a que hora
que workloads consumian el valor
si hacia falta reinicio o no
que error exacto desaparecio tras la rotacion
que prueba secundaria se uso para validar el flujo
que duda quedo abierta para horario laboral

No tiene que quedar bonito. Tiene que quedar util. Ese tipo de nota pequeña evita decisiones ciegas despues, y eso ya paga bastante.

Q&A

Debo reiniciar todos los pods apenas rote un secreto?

No siempre. Primero confirma como consume el secreto cada app. Reiniciar sin esa comprobacion es rapido, pero no necesariamente correcto.

Que parte suele faltar en las alertas?

La relacion entre el secreto cambiado y los workloads afectados. Muchas alertas detectan el evento, pero no muestran quien sufrira el impacto real.

Conviene automatizar todo el rollout?

Solo cuando ya entiendes el patron de fallo. Automatizar un proceso confuso hace que el error viaje mas rapido, y eso no ayuda mucho la verdad.

Terraform: drift de IAM con contexto util

Alex Carter — Wed, 19 Aug 2026 08:24:27 +0000

El drift de IAM rara vez empieza como un gran incidente. Normalmente aparece como una duda pequena: un permiso que ya no coincide, un rol que alguien toco desde consola, o una politica que sigue viva aunque el modulo diga otra cosa. Cuando esa diferencia se descubre tarde, el equipo pierde tiempo discutiendo si el cambio fue legitimo, urgente o simplemente un parche que nadie documento.

En equipos de plataforma esto pasa mas de lo que gusta admitir. Terraform dice una cosa, AWS muestra otra, y la alerta llega sin pista de blast radius, sin actor probable y sin una referencia clara al ultimo plan aprobado. Ahi es donde conviene tratar el drift como una senal operativa, no solo como una diferencia tecnica.

Por que el drift de IAM casi siempre llega sin contexto

La mayoria de alertas de drift fallan por el mismo motivo: detectan diferencia, pero no explican impacto.

He visto mensajes que solo dicen "drift detected in prod" y ya. Eso obliga al on-call a reconstruir todo a mano:

que recurso cambio
si el cambio amplio permisos o los recorto
si fue una edicion manual o una automatizacion rara
si el siguiente terraform apply corregira el estado o rompera algo

Esa falta de contexto se parece mucho a otros problemas de observabilidad. En contratos minimos para alertas de produccion, la idea clave era la misma: una alerta util no solo avisa, tambien orienta la primera decision.

Las tres preguntas que una alerta debe responder

Cuando preparo revisiones de drift para IAM, intento que la alerta responda estas tres preguntas en el primer minuto:

Que permiso o relacion de confianza cambio exactamente.
Quien o que sistema hizo el cambio mas probable.
Que riesgo trae esperar hasta la siguiente ventana de apply.

Si no puedes responder esas tres, la alerta todavia esta verde. No importa si el detector sea elegante.

Un ejemplo simple de contexto que si ayuda:

role: payments-api-prod
drift: politica inline agregada fuera de Terraform
scope: acceso adicional a s3:GetObject sobre un bucket sensible
last_apply: hace 2 dias
owner: modulo iam/payments-service
recommended_action: revisar CloudTrail y congelar apply automatico

Con eso, la conversacion cambia bastante. Ya no es "hay drift", sino "hay drift en un rol sensible y si aplicamos ahora vamos a borrar o sobreescribir algo que todavia no entendimos". Parece un matiz chico, pero cambia mucho la calidad de la respuesta.

Un flujo pequeno para revisar drift sin frenar al equipo

Este flujo me ha funcionado bien cuando quiero rapidez sin improvisar demasiado:

terraform plan -refresh-only -out=drift.tfplan
terraform show -json drift.tfplan > drift.json
jq '.resource_changes[] | select(.change.actions == ["update"]) | {address, before: .change.before, after: .change.after}' drift.json
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=payments-api-prod

Lo importante no es correr mas comandos. Lo importante es mirar primero el tipo de diferencia. No todo drift en IAM merece el mismo tono:

cambios en assume_role_policy suelen pedir mas cuidado
permisos ampliados sobre datos o secretos suben prioridad rapido
tags o descripciones raramente justifican una escalada urgente

A veces tambien conviene pausar un pipeline si esta por aplicar automaticamente. He visto equipos corregir demasiado pronto y perder evidencia sobre quien hizo el cambio original. Luego toca adivinar, y adivinar en seguridad cloud sale caro.

Donde entran los correos de aprobacion

Muchos flujos de cambio sensible dependen de un correo de aprobacion o de una notificacion paralela. Esa parte no deberia liderar la investigacion, pero si puede sostenerla. Para probar ese paso sin mezclar bandejas reales, un servicio de correo temporal desechable puede servir en entornos de QA o automatizacion. El truco es no confundir esa prueba con la fuente de verdad del drift.

Tambien ayuda separar bien el ruido de entrega. Si una aprobacion no llega, primero reviso el evento del cambio y luego el canal de correo. Esa disciplina se parece a aislar ruido cuando una senal depende del email: cada capa necesita su propia evidencia, o todo termina mezclado.

En varios equipos aun veo parches con un dummy e mail o un tem email para destrabar pruebas rapidas. Sirve cinco minutos, pero despues nadie sabe si fallo la aprobacion, la regla SMTP o el propio pipeline. Es mejor dejar ese atajo para pruebas bien delimitadas, no para cambios sensibles en prod.

Checklist antes de aplicar o revertir

Antes de decidir apply, revertir o congelar, reviso esta lista:

el recurso afectado esta etiquetado como critico o sensible
el cambio amplia permisos, relaciones de confianza o acceso transversal
existe evidencia de CloudTrail para el actor o proceso que lo hizo
el ultimo plan aprobado sigue siendo valido con el contexto actual
el equipo sabe si el drift fue intencional, temporal o accidental
hay una nota corta para el siguiente turno, aunque sea fea pero clara

Ese ultimo punto parece menor, pero evita muchos errores tontos. En guardias largas, una nota medio imperfecta ayuda mas que una memoria heroica. Si el contexto queda escrito, el siguiente ingeniero entra mejor parado y no repite el mismo analisis de cero.

Q&A

Conviene corregir todo drift de IAM de inmediato?

No siempre. Si el drift toca permisos sensibles, la prioridad puede ser congelar cambios y entender el origen antes de aplicar. Corregir rapido pero a ciegas aveces empeora la situacion.

Que dato falta mas seguido?

El impacto esperado del siguiente terraform apply. Saber que hay drift ayuda, pero saber si el apply borrara, ampliara o restaurara permisos ayuda mucho mas.

Esto reemplaza una revision de seguridad?

No. Esto ordena la primera respuesta. La revision de seguridad sigue siendo necesaria cuando el drift afecta acceso real a datos, secretos o identidades compartidas.

SRE: runbooks utiles para caidas parciales

Alex Carter — Tue, 18 Aug 2026 14:24:25 +0000

Las caidas parciales son de las incidencias que mas tiempo roban en guardia. No tumban todo, asi que nadie entra en modo panico total, pero si rompen suficiente como para llenar Slack, dashboards y tickets a la vez. En equipos SRE esto pasa un monton: una region responde lento, un worker consume mensajes con atraso, o una dependencia externa empieza a fallar solo en ciertos caminos.

Con los años me sirvio una idea simple: el runbook para una degradacion parcial no debe listar veinte comandos. Debe ayudar a decidir rapido si el problema es capacidad, dependencia, despliegue, red o datos. Cuando el documento falla en eso, la guardia se vuelve lenta y cada persona investiga un universo distinto.

Por que una caida parcial confunde mas que una total

Cuando todo cae, el objetivo es obvio. Cuando cae solo una parte, los sintomas se pelean entre si:

El uptime general sigue "verde".
Solo un porcentaje de usuarios ve errores.
Los logs muestran ruido, pero no una firma unica.
La gente empieza a asumir causas demasiado pronto.

Segun el libro Site Reliability Engineering de Google, la claridad operacional y la reduccion del toil son parte central del trabajo SRE, no un lujo documental (Google SRE Book). En incidentes parciales eso se nota enseguida: si tu primer documento no reduce incertidumbre, ya vas tarde.

Tambien he visto que los equipos mezclan evidencia de producto, pruebas y experimentos internos. Ese desorden se parece mucho a evitar mezclar corridas cuando el flujo se complica: si no separas contexto desde el inicio, cada dato parece sospechoso y el triage se pone mas lento.

El runbook que me ha funcionado en guardias reales

Mi version favorita cabe en una pantalla y sigue cinco preguntas:

Que superficie esta degradada exactamente.
Desde cuando ocurre y que cambio coincide.
Si el impacto depende de region, tenant o tipo de trafico.
Que metrica decide si vamos mejorando.
Cual es la accion segura de menor costo.

Ese orden importa. Mucha gente abre primero los logs de aplicacion, pero en varias guardias lo mas util fue empezar por diffs de despliegue, errores por zona y una metrica de saturacion. No suena heroico, pero evita perder media hora persiguiendo sintomas secundarios.

Un runbook base podria verse asi:

# 1. Confirmar alcance
kubectl get pods -n payments -o wide
kubectl top pods -n payments

# 2. Revisar eventos recientes
kubectl get events -n payments --sort-by=.lastTimestamp | tail -n 20

# 3. Comparar despliegue actual vs anterior
kubectl rollout history deploy/payments-api -n payments

# 4. Ver errores por region o tenant en observabilidad
# aqui entra tu consulta en Grafana, Datadog o CloudWatch

No es magico, claro. Lo util es que obliga a mirar estado, cambio y alcance antes de tocar cosas. Esa pausa de dos minutos evita decisiones medio apresuradas.

Que evidencia reunir antes de tocar nada

Si el runbook no define evidencia minima, cada persona captura algo distinto. Yo intento pedir siempre estas piezas:

Una metrica principal de impacto.
El ultimo cambio conocido en la ventana del incidente.
Una lista corta de componentes sanos y degradados.
Un ejemplo concreto de request fallida con timestamp.
Un criterio de rollback o mitigacion.

Parece basico, pero no siempre esta escrito. Y cuando no esta, el canal del incidente se llena de "creo que" o "parece que". Eso desgasta bastante. Tambien ayuda mucho hacer pruebas reales sin perder claridad operativa: si distingues trafico de prueba, seeds raros y notas como temp mailid desde el principio, quitas ruido que luego parece señal util aunque no lo sea.

En AWS, por ejemplo, un cambio de seguridad en una cola o un timeout mas agresivo entre servicios puede dejar solo una franja de requests en mal estado. Ahí conviene mirar dependencia por dependencia y no asumir que "cloud esta fallando". Dicho asi suena obvio, pero en una guardia cansada no siempre lo es.

Como escribir alertas que ayudan de verdad

Una alerta buena no intenta contar toda la historia. Solo debe entregar contexto suficiente para que la primera persona no empiece desde cero.

Yo suelo revisar estas cuatro partes:

Sintoma observable: 5xx en checkout suben al 8%
Alcance: principalmente tenant enterprise en eu-west
Cambio cercano: deploy 2026.08.18-3 hace 11 min
Siguiente paso: comparar latencia de Redis y rollout actual

Eso le gana por mucho a una alerta generica de "high error rate". El informe de PagerDuty sobre incident response ha repetido varios años que la velocidad inicial depende bastante del contexto util, no solo de detectar mas rapido (PagerDuty Incident Response Report). No hace falta memorizar el PDF completo; basta entender que una alerta muda obliga al humano a reconstruir el escenario desde cero.

Tambien me gusta dejar un mini checklist al final del runbook:

Confirmar si el impacto sigue creciendo.
Verificar cambio mas cercano al inicio del fallo.
Aislar componente comun entre requests rotas.
Elegir mitigacion reversible primero.
Registrar que señal confirma mejora.

Es una tonteria pequeña, pero funciona. En guardia nocturna el cerebro agradece esos pasos medio obvios.

Preguntas frecuentes

Un runbook parcial debe ser muy detallado?

No necesariamente. Debe ser especifico en decisiones, no largo por deporte. Si ocupa tres pantallas y aun asi no deja claro que mirar primero, esta flojito.

Conviene ligar el runbook a una sola herramienta?

Mejor no. Puedes poner ejemplos en Grafana o CloudWatch, pero el valor real esta en la secuencia mental: alcance, cambio, evidencia, mitigacion. Esa parte deberia sobrevivir aunque cambie la herramienta.

Esto sirve solo para Kubernetes?

No. Kubernetes aparece mucho en SRE, pero la idea funciona igual para colas, bases de datos, workers o integraciones externas. Lo importante es evitar que cada guardia reescriba el metodo sobre la marcha.

Si hoy tus incidentes parciales duran demasiado, yo empezaria por rehacer dos runbooks clave con esta estructura. No arregla la plataforma por si sola, obvio, pero baja friccion, mejora el diagnostico y le da al equipo una base comun para responder mejor.