En este cliente, mi trabajo tenía dos frentes. Uno era un proyecto con principio, medio y fin: apagar una línea de producto financiero entera. El otro era el día a día, asegurando que los equipos de producto no se quedaran parados esperando a la plataforma.
Apagar sin romper
La empresa decidió discontinuar una línea de producto. Quedaron atrás más de una docena de microservicios, cada uno con base de datos, secretos, pipelines e infraestructura en sandbox y producción, además de decenas de repositorios. Parte ya estaba archivada, pero nadie estaba seguro de qué seguía corriendo.
Apagar un sistema financiero es delicado. Borrar algo que todavía está en uso tira producción, y borrar sin backup puede significar perder datos que hay que guardar. Por eso, antes de borrar nada, escribí una guía de apagado y la apliqué servicio por servicio, siempre en el mismo orden: quitar el exporter de métricas, quitar la infraestructura de Terraform y los releases de Helm, ubicar la base del servicio a través de Vault, borrar los secretos y las referencias en Vault y Jenkins, eliminar las bases de sandbox y de producción y, por último, archivar los repositorios.
Antes de quitar cada servicio o VM, había backup y snapshot. Cada etapa quedó registrada con evidencia en la tarjeta del servicio, en sandbox y en producción. Y documenté cómo descubrir qué base usaba cada servicio a partir de sus secretos en Vault, un conocimiento que no estaba escrito en ningún lado.
Al final, todos los servicios se apagaron con trazabilidad: para cada uno se puede probar qué se quitó, cuándo y con qué backup. La empresa pasó a mantener y pagar menos infraestructura, con menos secretos expuestos, y la guía quedó lista para los próximos apagados.
Destrabar a quien entrega
En el día a día, los equipos de producto dependían de la plataforma para casi todo lo que no era código. Atendí decenas de pedidos de equipos distintos. En secretos, eran credenciales de integraciones en Vault, credenciales dinámicas de base de datos y claves cifradas con KMS. En CI/CD, fallas de build y deploy en Jenkins, Helm y SonarQube, incluido un bloqueo de quality gate en plena semana de entregas. En accesos y red, SSO, VPN, DNS interno, security groups, rutas de API gateway y permisos en S3 y EKS.
Para que los pedidos repetidos dejaran de depender de mí, escribí una guía de solución para los tipos más comunes y registré una deuda técnica: configuraciones de API gateway hechas a mano en homologación, que tenían que pasar a infraestructura como código.
"El partner está lento"
Las llamadas a un partner externo a veces pasaban de tres segundos, y el partner garantizaba que siempre respondía en menos de 500 ms. En lugar de discutir quién tenía razón, medí. Escribí un script que, desde dentro del clúster, repetía la llamada y separaba el tiempo de DNS, conexión TCP, handshake TLS y respuesta.
DNS y TCP eran siempre rápidos. En 4 de cada 10 llamadas, el retraso de unos tres segundos ocurría exactamente en el handshake TLS. La conversación salió del "es la red" y del "es el partner" y pasó a tener un lugar específico para investigar.
Por qué los desarrolladores no veían sus pods
Los ingenieros no podían ver el consumo de CPU y memoria de los pods en ningún entorno. Fui capa por capa. El mapeo de usuarios en el clúster estaba bien. El rol de lectura de Kubernetes ya incluía las métricas. El login por SSO asumía el rol correcto en AWS. Lo que faltaba era el rol del SSO registrado en los accesos del clúster EKS. Agregué la entrada, y los ingenieros pasaron a ver el consumo sin pedírselo a la plataforma.
Lo que me llevo
En sistemas heredados, el peligro no está en lo que sabes que existe, sino en lo que nadie recuerda que sigue corriendo. Una guía con evidencias convierte una tarea riesgosa en un proceso auditable. Y cuando dos partes no se ponen de acuerdo, sea sobre latencia o sobre permisos, dividir el problema en etapas suele terminar la discusión y mostrar dónde buscar.