Por qué tu servidor está en marcha pero el producto no

La mayoría de los equipos no monitorean aquello que realmente falla.

En lo que respecta al monitoreo, las comprobaciones habituales abarcan:

• CPU

• Memoria

• Disco

• Base de datos

• Disponibilidad de la aplicación

Si un servidor se cae, todo el mundo se entera rápidamente.

Se disparan las alertas. Los paneles de control se ponen en rojo. Comienza la investigación.

Sin embargo, en los últimos años en Olisen Studio hemos observado un patrón interesante: los incidentes más problemáticos rara vez implican caídas del servidor.

Por lo general, lo que falla es otra cosa. Y estos son precisamente los tipos de problemas que a menudo pasan desapercibidos durante más tiempo.

Cuando la aplicación funciona, pero los usuarios ya enfrentan problemas

Un producto SaaS moderno rara vez existe de forma aislada.

Incluso una aplicación relativamente sencilla puede depender de docenas de servicios externos:

• Stripe

• OpenAI

• Telegram

• GitHub

• Notion

• Slack

• APIs internas

Un fallo en cualquiera de estas dependencias puede afectar a una función crítica del producto.

Por ejemplo:

• una clave de API de OpenAI caduca;

• un webhook de Stripe deja de enviar eventos;

• un token OAuth pierde los permisos necesarios;

• la API de GitHub empieza a devolver errores;

• una tarea en segundo plano no se ejecuta;

• una integración deja de recibir eventos.

Sin embargo, desde la perspectiva de la infraestructura, todo parece estar bien.

El sitio carga. La base de datos está en marcha. El servidor responde. El monitoreo muestra un estado verde.

Pero alguna funcionalidad ya no está disponible.

Por qué estos problemas se detectan demasiado tarde

El monitoreo tradicional responde a la pregunta:

¿Está funcionando el sistema?

Pero para el usuario, importa más otra pregunta:

¿Funciona realmente la característica que vino a utilizar?

Imagina un servicio que publica contenido automáticamente a través de una API de terceros.

Si esa API deja de aceptar solicitudes:

• la aplicación sigue funcionando;

• los usuarios pueden iniciar sesión;

• el servidor no muestra errores críticos.

Sin embargo, el valor fundamental del producto desaparece. A veces, estos fallos se detectan tras unas horas. Otras veces, tras unos días. Y, en ocasiones, solo cuando un cliente contacta con el soporte técnico.

Es precisamente esta brecha entre la aparición del problema y su detección la que a menudo resulta ser la parte más costosa del incidente. ## Las dependencias se han convertido en un nuevo punto de fallo

Hace apenas unos años, la mayoría de los fallos ocurrían dentro de la propia infraestructura de la empresa.

Hoy en día, la situación ha cambiado.

Incluso un producto SaaS pequeño puede depender de docenas de componentes externos; cada uno de ellos se convierte en un posible punto de fallo.

Además, muchos de estos servicios escapan al control del equipo de desarrollo.

No puedes corregir un error en OpenAI. No puedes influir en la infraestructura de Stripe. No puedes obligar a la API de GitHub a funcionar más rápido.

Pero sí puedes detectar el problema mucho antes.

Y la velocidad de detección repercute directamente en la magnitud de las consecuencias.

Qué merece realmente la pena monitorizar

En la práctica, tiene sentido monitorizar no solo la infraestructura, sino también los procesos empresariales críticos.

APIs externas

Es importante monitorizar no solo la disponibilidad del servicio, sino también la corrección de su funcionamiento.

Una API puede devolver un código de estado HTTP 200 y, aun así, proporcionar datos erróneos o resultados incompletos.

Integraciones mediante webhooks

Muchos procesos dependen de la recepción de eventos.

Si los eventos dejan de llegar, el producto puede parecer totalmente funcional durante mucho tiempo.

Autorización y acceso

Los tokens caducados, los permisos perdidos y las credenciales incorrectas siguen siendo algunas de las causas más comunes de fallos silenciosos.

Tareas en segundo plano

Las colas, los planificadores de tareas y los trabajos cron a menudo fallan sin activar alertas de monitorización de infraestructura.

Funciones de negocio

Resulta útil verificar los escenarios reales de uso:

• ¿se procesan los pagos?

• ¿se crea contenido?

• ¿se entregan las notificaciones?

• ¿se sincronizan los datos?

• ¿funcionan las integraciones clave?

Una nueva perspectiva sobre la monitorización

La monitorización de la infraestructura sigue siendo esencial. Pero hoy en día, eso ya no basta.

Los productos modernos dependen cada vez más de servicios externos, APIs e integraciones. En consecuencia, la pregunta:

«¿Está funcionando el servidor?»

está dando paso gradualmente a otra:

«¿Funciona el producto en su conjunto?»

Hoy en día, un número significativo de incidentes surge precisamente a nivel de dependencias, integraciones y flujos de trabajo de los usuarios.

Y ahí es exactamente donde muchos equipos carecen de visibilidad.

En Olisen Studio, nos encontramos con este problema al trabajar en proyectos SaaS y herramientas internas. Por eso, actualmente estamos explorando enfoques para monitorear dependencias externas, API, integraciones de webhooks y procesos en segundo plano.

Si este tema te resulta interesante, o si has lidiado con incidentes similares, nos encantaría conocer tu experiencia.

Checklane: https://checklane.olisen.studio/