Imagina la escena: es Black Friday. Tienes el café en una mano, el ratón en la otra y tu chat de Slack echando humo. Comienza una de las campañas más importantes, hablamos del 30 % de la facturación anual de tu empresa en tan solo un día.
Pero, para entender el drama que está a punto de desatarse, primero os presento a los actores de nuestra arquitectura (basada en hechos reales, cualquier parecido con tu empresa es pura coincidencia… o no):
- Cart Service (El Cajero): El encargado de procesar los artículos y sumar la «pasta». Si este falla, no cobramos. Es el VIP de hoy.
- Config Service (El Cerebro): Un servicio central que reparte configuraciones, feature flags y, lo más importante hoy: las reglas de las promociones. Nuestro cerebro. Imagínate fallar y aplicar descuentos por encima de lo calculado.
- La base de datos: La Memoria del Cerebro.Por supuesto, nuestra memoria también se comparte con otros servicios.
- Otros servicios: No solo el Cart Service necesita configuraciones, otros servicios también. Es el mundo real de una arquitectura distribuida, verdad?
Veamos la arquitectura de forma simplificada:
El Incidente
Son las 11:00 AM. Hora crítica cualquier día en nuestra plataforma de ecommerce. Nuestros clientes suelen comprar por las mañanas entre las 10:00 y 14:00. Imagínate en un día de black friday.
De repente, se acabó la paz. Las alarmas comienzan a saltar. Uno de los SLOs más importantes, que es el volumen de ventas, está cayendo.
Viendo nuestras gráficas parece que nuestros clientes en cambio sí que están accediendo a la web e intentando realizar compras, pero algo está pasando que les impide acabar el proceso.
El equipo de operaciones observa que la latencia se dispara en el servicio de Cart Service: las órdenes procesadas están tardando >10 segundos en lugar de los habituales 800ms. Esto está provocando una situación crítica en nuestros sistemas.
- El cliente refresca la web e intenta volver a realizar la compra.
- Al no completarse el cliente desiste de realizar la compra.
- Esto provoca un efecto cascada en otros sistemas, debido al aumento de intentos por parte de los clientes el resto de sistemas se están viendo afectados también.
Se escala la incidencia al equipo de Cart Service, sudando la gota gorda, mira sus trazas y señala con el dedo: «¡Es culpa del Config Service! ¡Nos estáis frenando!».
Se añade a la incidencia al equipo de Config Service.. Y aquí ocurre el clásico de los sistemas distribuidos, esa frase que debería estar prohibida por la Convención de Ginebra:
«Imposible. Nuestro dashboard está todo en verde. Nuestro P95 (percentil 95) está perfecto. El problema sois vosotros.»
Se inicia la guerra. ¿Quién miente? Spoiler: Nadie miente, pero a las métricas le faltan CONTEXTO.
La verdad, muy a menudo, tiene varias realidades. Todo depende del punto de vista..
¿Cómo puede ser que el equipo de “Cart Service” vea el edificio arder y el equipo de Config Service esté totalmente tranquilo?
Aquí viene la lección de negocio y técnica: La dilución del error.
- El Config Service es muy popular. Atiende a todos: al catálogo, al login, a la home, al buscador… recibe millones de peticiones por minuto.
- El Cart Service, aunque tiene un rol fundamental, representa una fracción muy pequeña del tráfico total del Config Service (ojalá toda la gente que entrara en nuestra web comprara, ¿eh?).
- El Problema: Aunque el 100% de las peticiones de Cart Service sean lentísimas, estas son solo una gota en el océano de peticiones rápidas del resto de servicios.
Al mirar el Promedio o el P95 global, esas pocas peticiones lentas quedan ocultas por la inmensa mayoría de peticiones rápidas. El dashboard verde es matemáticamente correcto, pero funcionalmente digamos …que le falta contexto.
La Solución: Contexto y Correlación al Rescate
Sin observabilidad real, estaríamos perdidos en una reunión de tres horas culpando a la red o al DNS. Pero, por suerte, tenemos nuestro ecommerce bien observado. Y no solo tenemos métricas, también tenemos trazas y logs.
Pensad en métricas, logs y trazas como lentes que nos permiten aumentar la perspectiva desde la que estamos viendo el sistema.
Para resolver esto, no necesitamos intuición ni zascandilear por dashboards interminables, necesitamos Contexto:
- La Lupa (Traza): Gracias a que propagamos un Trace ID a través de los servicios, podemos ignorar el ruido y aislar una de esas transacciones lentas de Cart Service.
- El Hilo: Seguimos la traza: Cart Service -> Config Service -> Database. Observamos el end to end de la petición de Service Cart y claramente vemos que el 98% del tiempo de la petición se lo está llevando una consulta a la BD. Get ads from database.
- El Hallazgo: Ya hemos localizado al culpable, pero .. ¿qué query a base de datos estamos haciendo? Pongamos la lupa en la traza.
Umm .. ese WHERE body LIKE ‘%telescope%’ no tiene buena pinta.
- La solución: Parece que nuestra última actualización en la feature recomendaciones tenía una query que, digamos de otro modo, está “poco optimizada”. Hacemos rollback y volvemos a observar nuestro sistema.
Respiramos aliviados.. parece que todo vuelve a la normalidad.
