He creado el Sentinel (y estoy muy orgulloso)

Y mientras tanto, algo se rompió.

La instancia de nuestra base de datos de Staging estaba caída.

¿Cómo lo supe? Porque alguien me avisó.

Bueno, alguien no, sino algo.

Un sistema de alarmas que me había montado yo. Y que, mientras yo estaba reunido, hacía su parte y me avisaba de que algo no iba bien.

Así que en cuanto empezó el problema yo ya lo sabía, y tenía una pull request esperándome con una posible solución.

(de hecho lo sabía desde antes, porque ya me avisó de que algo iba a pasar, pero yo lo vi cuando ya había sucedido)

Y eso es solo una alarma.

Ahora multiplícalo por todo lo que tengas montado: cada servicio de tu plataforma avisando de forma independiente cuando algo va mal.

Esto encaja justo con los flujos autónomos que te conté hace unas semanas, ya que con ellos puedo pasar horas sin tocar el ordenador y a la vuelta tengo features nuevas listas para probar.

Pero eso genera un problema.

¿Se te ocurre cuál es?

Que llega un momento en el que produces tanto que mirarlo todo es imposible.

Dependes de que los usuarios encuentren los bugs. Algo que ha pasado siempre, pero ahora sacas muchas más features y cada vez con menos revisión humana antes de salir.

Ya te he ido contando en los vídeos que la revisión de código vamos a quitarla. Repasar las PRs en GitHub está dejando de tener sentido: la pieza más lenta del sistema somos nosotros.

Así que necesitamos otra forma de saber si lo que desplegamos va bien o mal. Y esa es la observabilidad.

Si has hecho formación técnica seguramente la recuerdes como una palabra aburrida de alguna asignatura. En la práctica es más divertida: saber qué pasa dentro del sistema sin meterte a tocar nada.

El DORA de 2025, el gran estudio sobre cómo entregamos software, dice que adoptar IA va de la mano de entregar más rápido. Algo que… cógelo con pinzas, porque lo publica Google y Google vende IA. Peeeeero, en mi experiencia es cierto.

Y esto tiene dos caras: entregamos más rápido y rompemos más. En esa misma encuesta, casi 1 de cada 3 dice que se fía poco o nada del código que le genera la IA.

Yo esto lo he solventado de dos maneras.

(y las dos son mecanismos de observabilidad ;)

La primera ya la has visto. Las clásicas alarmas de AWS para nuestros microservicios, que avisan por un canal de Slack. Y encima un flujo que vigila ese canal e investiga cada vez que salta una.

A veces solo informa y a veces lo arregla él. Si hace falta una acción humana (como recargar un proveedor), abre un ticket.

Además de eso, he montado el Sentinel. Probablemente sea de lo que más orgulloso estoy en toda mi carrera.

¿Qué hace?

Revisa el estado de la plataforma (el back desde AWS, el front desde Sentry) y lo cruza con los últimos despliegues. Si algo empezó a fallar justo después de un deploy, ya sabe por dónde mirar. Lo que encuentra lo corrige y abre los tickets.

Todo lo hace por comparación: lo de hoy contra lo de ayer.

Además, revisa si hay algo que se ha callado.

Mide el tráfico que entra a cada servicio, y si algo que siempre habla deja de hablar salta igual que si estuviera petando.

Así que no solo me avisa de si hay algo mal, sino de si algo ha dejado de ir bien.

El silencio sale de las métricas (CloudWatch, vamos), y la ejecución diaria cuesta cuatro céntimos.

Esto vive en mi ordenador, con Claude en modo headless y unos cronjobs.

Todo funciona sin que yo tenga que accionar nada. Y… es la hostia la verdad.

El mejor ejemplo lo ves si te cuento lo que pasó el 26 de agosto. A las seis de la tarde, 253 errores 502 en cuatro segundos. La primera lectura, la del propio Sentinel, fue la fácil: se ha caído un momento el servicio de al lado.

Pero no. El flujo del Sentinel continuó y en la etapa siguiente se fue a las métricas y descubrió lo contrario: ese servicio estaba entero, cero errores y sus dos máquinas sanas. Los 502 los devolvía el balanceador de carga.

Resultó que el problema era nuestro.

Un proceso leía todas las conexiones del día sin paginar y las lanzaba a la vez, un Promise.all dentro de otro Promise.all. 2.389 peticiones de golpe, repartidas en 2.119 conexiones simultáneas, contra un servicio que vive con diez peticiones por minuto.

Dos días antes ese mismo servicio se había tragado 20.241 peticiones en un minuto. Ocho veces y media más que las nuestras, y sin problema ninguno. La diferencia es que las nuestras llegaron todas a la vez: el tiempo de respuesta se fue de 5 milisegundos a casi 3 segundos.

El arreglo que le dimos fue sencillo. Ponerle un tope y batchear de 50 en 50. Con una PR automática que el flujo abrió por sí mismo.

«Pero Jesús, ¿no falla el sistema?»

Sí, claro que sí.

Y es que un sistema que corrige solo también se equivoca solo, así que he ideado algo para que los fallos duelan lo menos posible.

De nuevo, con la filosofía que ya te conté por aquí: «un error se arregla una sola vez».

Cada flujo que termina produce un informe con lo que ha hecho y las decisiones que ha tomado por sí mismo. Si alguna no me gusta, itero el flujo y ya no vuelve a pasar.

Las primeras semanas había cambios casi a diario. Ahora llevo varios días sin corregirle ni una.

Durante este tiempo el Sentinel ha soltado tickets sin parar: casos de uso que petaban por un side-effect mal manejado, y algún bug de nuestros despliegues que cacé antes de que lo viera ningún usuario. Pero ya lleva dos ejecuciones sin nada nuevo en el informe. Cada vez más cerca de una plataforma zero-errors.

Y a mí no me ha quitado horas, porque mientras él resuelve tickets, yo saco mis features o me voy a mis reuniones. Ha sido como tener a otra persona en el equipo dedicada solo a mantener la plataforma limpia y segura.

Al mismo precio además, porque sale de la suscripción de 200 € que ya pagaba. Los primeros días me comía los límites, pero se pasó en cuanto afiné los sistemas.

Ahora empiezo el día leyendo un informe de cosas que ya han pasado sin mí.

Está guay enterarse de todo y decidir con información, más que con intuición.

A lo tonto estoy disfrutando mucho de iterar todo esto.

E incluso puedo decir que ya me gusta la palabra:

Observabilidad

P.D. A un compañero le picó el gusanillo con todo esto y se ha montado nuestra página de status, como la de Claude pero con nuestros microservicios. Está guapísima.