Hay averías que se anuncian solas. Un disco que se llena, un servicio que no arranca, un certificado que vence. Y hay otras que se esconden: el sistema no reporta nada raro, los monitoreos están en verde, y sin embargo cada pocos días algo se cae.
Este es el segundo caso. Lo interesante no es cómo se arregló, sino por qué nadie lo había encontrado en semanas — y qué hizo falta para verlo.
El escenario
Una plataforma concentra toda la operación diaria de una organización: su correo corporativo, su sistema de gestión empresarial, su mensajería interna y las herramientas de trabajo de su equipo.
Lo que a simple vista son cinco servidores es, por dentro, casi cuarenta aplicaciones funcionando de forma coordinada:
- Plataforma de correo — 12 aplicaciones
- Gestión empresarial — 5 aplicaciones
- Mensajería corporativa — 3 aplicaciones
- Datos e inteligencia artificial — 2 aplicaciones
- Plataforma y operación — 17 aplicaciones
En números: 34 espacios de trabajo aislados, 60 contenedores, 40 servicios internos y 11 publicaciones web. Y en la parte de correo: 101 buzones en 5 dominios, con 105.000 mensajes y 58 GB de histórico.
Y algo que no vive en los servidores
Fuera del clúster hay además una tubería de datos sin servidores: siete procesos que se ejecutan solos, cuatro de ellos en horarios programados cada día. Recorren fuentes externas, que a su vez son procesadas con inteligencia artificial e integradas en las aplicaciones de gestión empresarial — sin que nadie copie y pegue nada.
Aquí está el detalle que hace interesante este caso: parte de esa tubería notifica sus resultados por correo, y ese correo es el mismo de la plataforma. Cuando el correo se caía, la automatización seguía ejecutándose pero sus avisos no llegaban a nadie. El fallo no se quedaba en los cinco servidores: alcanzaba a procesos que ni siquiera corrían ahí.
Es exactamente el tipo de acoplamiento que un mapa de arquitectura revela y que un diagrama de servidores no muestra. Ya está en agenda desacoplarlo, sustituyendo la notificación por correo por un canal independiente del servicio de correo.
Por qué una plataforma propia y no una suite SaaS
Es la pregunta que cabe hacerse: si existen servicios en la nube que resuelven cada una de estas piezas por separado, ¿para qué operar una plataforma propia?
La respuesta es la ingeniería de datos.
Una suite SaaS resuelve el correo, otra el ERP, otra la mensajería. Cada una guarda sus datos en su propio silo y los deja ver únicamente a través de lo que su fabricante decidió exponer: una interfaz limitada, con cuotas de consulta y sin acceso al dato en bruto. Funciona perfectamente — hasta el día en que se quiere cruzar información entre ellas, alimentar un modelo o construir un agente que necesite ver el conjunto.
Y ese día llega. La inteligencia artificial, el aprendizaje automático y los agentes exigen exactamente lo que el modelo SaaS no da: acceso directo al dato, en volumen, sin intermediarios, sin límites de consulta y con la libertad de moverlo donde haga falta procesarlo. Sin esa base, cualquier iniciativa de IA se queda en una demostración bonita que no se puede llevar a producción.
Una plataforma propia cuesta más operar. A cambio, deja los datos donde sí se pueden usar — y esa diferencia es la que separa a las organizaciones que hablan de IA de las que efectivamente la tienen funcionando.
Cuando esa plataforma se detiene, la organización se detiene. No hay plan B.
Este punto —por qué la inteligencia artificial exige una arquitectura de datos propia— lo desarrollamos a fondo en Por qué tu iniciativa de inteligencia artificial no va a funcionar sobre SaaS.
Qué estaba pasando
Tres síntomas que parecían no tener nada que ver entre sí:
El correo se caía. Los usuarios dejaban de poder entrar a sus buzones. Al rato volvía solo. Ocurrió dos veces en un mismo día.
El panel de administración devolvía errores. Cada tantos días, la consola desde la que se gestiona toda la plataforma dejaba de responder. El procedimiento conocido era entrar al servidor y reiniciar servicios a mano.
La búsqueda del correo no funcionaba. Buscar un mensaje devolvía un error de tiempo agotado. Llevaba así desde siempre.
Cada síntoma se trataba por separado. Y había una nota en la documentación interna que descartaba explícitamente una de las causas posibles. Esa nota resultó ser el error de diagnóstico más caro.
El hallazgo
La causa raíz no apareció en los registros del sistema. Apareció en la factura de la nube.
El servidor que coordina toda la plataforma corría sobre un tipo de instancia "ampliable": una máquina económica que acumula capacidad de cómputo mientras está ociosa y la gasta cuando trabaja. Es una opción excelente para cargas irregulares. Es una opción pésima para un servidor que trabaja de forma sostenida.
Las métricas mostraron que llevaba unas dos semanas con el saldo agotado y la deuda en su tope máximo. Traducido: el cerebro de toda la plataforma estaba funcionando con menos de medio núcleo de procesador. Y encima, el proveedor facturaba el excedente.
Tres características hacen que este fallo sea casi imposible de detectar:
- Es invisible desde dentro del servidor. Las herramientas de monitoreo muestran carga baja, porque el procesador sencillamente no se entrega. El sistema no trabaja mucho: espera.
- La configuración parecía protegerlo. La máquina estaba en un modo que permite pedir capacidad prestada. Lo que no dice la documentación con suficiente énfasis es que ese préstamo tiene un límite, y alcanzado ese límite la restricción se aplica igual.
- Se manifiesta como fallos de otros componentes. Base de datos, resolución de nombres, panel de administración, correo. Ninguno reporta "falta de procesador".
Con esa pieza en su lugar, los tres síntomas dejaron de ser tres problemas y pasaron a ser uno solo.
Las herramientas que hicieron posible el diagnóstico
Este caso se resolvió combinando varias tecnologías que implementamos y damos soporte. Vale la pena explicar qué hace cada una, porque el valor no está en ninguna por separado sino en cómo encajan.
AWS — la infraestructura
Amazon Web Services es la plataforma de servicios en la nube más extendida del mundo. En lugar de comprar servidores físicos, instalarlos y mantenerlos, se contratan por demanda: se encienden en minutos, se pagan por hora y se apagan cuando no hacen falta.
Lo que la mayoría no aprovecha es su capa de observabilidad. La causa raíz de este caso salió de las métricas de facturación de AWS, no de los registros del sistema. Saber que esos datos existen, y saber leerlos, es la diferencia entre semanas de parches y una tarde de diagnóstico.
Kubernetes y RKE2 — la orquestación
Kubernetes es el estándar de la industria para ejecutar aplicaciones en contenedores. Un contenedor empaqueta una aplicación con todo lo que necesita para funcionar; Kubernetes decide en qué servidor corre cada uno, lo reinicia si falla y lo mueve si su máquina se cae. Es lo que permite que una plataforma siga en pie aunque un servidor muera.
RKE2 es una distribución de Kubernetes desarrollada por SUSE, diseñada con foco en seguridad y certificada para entornos regulados. Es la base sobre la que corre todo en este caso.
SUSE Linux y Rancher — la plataforma empresarial
SUSE Linux Enterprise Server es una de las distribuciones de Linux para empresas más sólidas del mercado: soporte de largo plazo, actualizaciones sin reiniciar y las certificaciones que exigen los sectores más regulados. Es la base sobre la que operó esta plataforma durante su fase inicial, y una de las opciones que implementamos según lo que cada entorno necesite.
Rancher, también de SUSE, es la consola que convierte a Kubernetes en algo manejable. Kubernetes por sí solo se opera con comandos y archivos de configuración; Rancher da una interfaz visual para ver el estado de los servidores, desplegar aplicaciones, gestionar permisos y administrar varios clústeres desde un solo lugar. Para un equipo que no quiere —ni debe— vivir en la línea de comandos, es la diferencia entre poder operar la plataforma y depender de un especialista para cada cambio.
AWS Lambda y Amazon Bedrock — automatización sin servidores
AWS Lambda permite ejecutar código sin administrar ningún servidor. Se define qué hacer y cuándo; la nube se encarga del resto y solo se paga por los milisegundos de ejecución real. Si un proceso corre cinco minutos al día, se paga por esos cinco minutos. No hay una máquina encendida las veinticuatro horas esperando.
Amazon Bedrock es el servicio de AWS para usar modelos de inteligencia artificial de distintos proveedores —incluido Claude— desde la propia infraestructura, sin exponer datos fuera de la cuenta y sin operar servidores de IA.
Combinados, permiten lo que en esta plataforma funciona todos los días: procesos programados que recorren fuentes externas, un modelo de IA que clasifica e interpreta la información, y una carga automática al sistema de gestión. Trabajo que antes era manual y repetitivo, hoy ocurre solo — y cuesta centavos al día.
Claude — el copiloto de ingeniería
Claude es un asistente de inteligencia artificial desarrollado por Anthropic. En su versión para ingeniería, Claude Code, no se limita a responder preguntas: se conecta a la infraestructura real, ejecuta diagnósticos, correlaciona información de fuentes distintas y redacta la documentación del trabajo.
En este caso concreto hizo algo que un humano difícilmente sostiene en una sola jornada: cruzar registros de aplicación, arquitectura de contenedores y métricas de facturación — tres mundos que normalmente nadie mira juntos— hasta que apareció la única explicación que encajaba con todos los síntomas a la vez.
Lo que no hizo fue trabajar solo. Las decisiones de arquitectura, el criterio sobre qué riesgo asumir y el conocimiento del negocio los puso nuestro equipo. Hubo un momento en que la investigación se estaba dispersando persiguiendo síntomas sueltos, y fue una instrucción del ingeniero responsable —"levantá primero el mapa completo del sistema"— la que reorientó todo el trabajo. La causa raíz apareció después de ese cambio de método, no antes.
Esa es la forma correcta de usar esta tecnología: amplifica a un experto, no lo sustituye.
Los resultados
| Antes | Después | |
| Carga del servidor coordinador | saturado | normalizada |
| Memoria disponible | 126 MB | 4,2 GB |
| Componentes reiniciándose solos | 6 | 0 |
| Acceso al correo | caído | 5 dominios operativos |
| Búsqueda en el correo | error de tiempo agotado | funcional en segundos |
| Punto único de fallo en el acceso | sí | eliminado y probado |
Además, en la misma jornada:
- Se migró la plataforma completa a servidores con capacidad de cómputo dedicada, eliminando de raíz el problema. La migración se hizo **servidor por servidor, sin detener el servicio**: primero se agrega capacidad, se verifica, y solo entonces se retira la antigua.
- Se eliminó un punto único de fallo en el sistema de autenticación del correo —el que había provocado las dos caídas— y se **comprobó destruyendo deliberadamente uno de los componentes** para confirmar que el servicio seguía en pie.
- Se reconstruyó el índice de búsqueda de los 101 buzones en menos de 12 minutos, con cero errores. Descubrimos en el proceso que el índice estaba configurado para procesar texto en inglés sobre un correo escrito en español: buscar "facturas" no encontraba "factura". Corregido, la búsqueda no solo funciona, sino que **encuentra lo que antes no encontraba**.
- Se entregó el mapa arquitectónico completo de la plataforma, que no existía, y un manual de operación con procedimientos de verificación y reversión.
Lo que nos llevamos de este caso
Una conclusión documentada es más peligrosa que una duda abierta. La nota interna que descartaba la limitación de procesador llevaba semanas impidiendo mirar en la dirección correcta. Las conclusiones también caducan, y conviene revisarlas cuando los síntomas insisten.
Lo barato puede salir caro de forma invisible. Las instancias económicas son excelentes para cargas irregulares y una mala idea para un servidor que trabaja de forma sostenida. La diferencia de costo entre lo que había y lo correcto era de unas decenas de dólares al mes; el costo de las caídas era muy superior.
Medir antes de dimensionar. Al revisar el consumo real encontramos entornos de prueba que reservaban capacidad de producción y usaban el 0,2% de ella. Ese tipo de hallazgo solo aparece midiendo, nunca estimando.
Probar el arreglo, no solo aplicarlo. Un punto único de fallo no está resuelto hasta que se reproduce a propósito el escenario que causaba la caída y el servicio aguanta.
¿Tu plataforma tiene un fallo invisible?
Si tu operación depende de una infraestructura en la nube y convivís con caídas que "se arreglan solas", con procedimientos manuales que alguien repite cada semana, o con la sensación de que hay algo de fondo que nadie ha encontrado — probablemente lo haya.
Trabajamos con AWS, SUSE Linux, Rancher, Kubernetes, AWS Lambda, Amazon Bedrock y Claude para diagnosticar, estabilizar y operar infraestructura crítica. Somos partner de estas tecnologías y las usamos todos los días en producción, no solo en presentaciones.
Escribinos y conversemos sobre tu caso.