La observabilidad es uno de esos temas donde la conversación de la industria está totalmente desfasada de lo que la mayoría de los equipos realmente necesita. Los proveedores enterprise venden plataformas pensadas para flotas de servicios y plantillas para operarlas. Los equipos pequeños, razonablemente desconfiados ante la factura, terminan lanzando con console.log y rezando para que nada se rompa un domingo. Ambos extremos se equivocan en la misma dirección.
La lectura honesta es esta: hay un bloque de dos semanas de trabajo de observabilidad que se amortiza durante toda la vida del sistema, y un montón mucho mayor de trabajo más allá de ese punto que solo vale la pena cuando ya tienes la escala para aprovecharlo. Los equipos que aciertan son los que terminan el primer bloque antes de necesitarlo y resisten la tentación del segundo hasta que de verdad lo necesitan.
Así se ve el primer bloque, en el orden en que lo construimos.
Logs estructurados con un request ID
Es el cambio de mayor apalancamiento que un sistema pequeño puede hacer, y la mayoría de los equipos lo saltan porque el prototipo ya "tiene logging". No lo tiene, no en el sentido que importa.
Lo que quieres es salida JSON, un evento por línea, con un conjunto estable de claves: timestamp, level, service, request_id, user_id cuando aplique, y el mensaje. Cada salto interno — llamada HTTP entre servicios, job en segundo plano lanzado desde una petición, query de base de datos que valga la pena trazar — lleva el mismo request_id hacia adelante. El middleware que lo genera es un solo archivo. La disciplina de propagarlo es el trabajo real.
En el momento en que esto está en su sitio, la experiencia de debuggear cambia de carácter. Un usuario reporta que un checkout falló a las 14:32. Haces grep de request_id=... en todos los flujos de logs y obtienes la historia completa en orden: la petición entró, llegó a la API, llamó al worker de pagos, el worker hizo timeout esperando un servicio externo, la API devolvió 502, el frontend mostró el toast de error equivocado. Esa historia antes te llevaba una hora correlacionando timestamps en tres terminales. Ahora son tres segundos. Multiplica eso por cada incidente que el sistema vivirá, y el caso a favor de los logs estructurados se escribe solo.
Los logs no estructurados, en cambio, se degradan. Lucen bien el día uno y se vuelven inutilizables en el momento en que tienes más de un servicio o más de un ingeniero.
Un dashboard
No veinte. Uno.
El error que comete cada equipo después de descubrir una herramienta de métricas es construir un dashboard por servicio, por equipo, por preocupación, y luego construir un dashboard "principal" que enlaza a todos. Nadie lee ninguno. El dashboard que vale la pena es el que un ingeniero cansado puede abrir en el móvil a las 11pm y leer en tres segundos.
Lo que va en él: latencia p95 y p99 por endpoint público, tasa de error por endpoint, profundidad de cola para cualquier worker asíncrono, conteo de queries lentas en los últimos cinco minutos. Quizá una métrica de negocio si hay un solo número que significa "el producto está funcionando" — checkouts por minuto, signups por hora, lo que sea el equivalente. Eso es todo.
La disciplina no está en construir el dashboard. Está en no añadir los otros dieciocho paneles que alguien sugirió en una reunión. Cada panel que añades reduce a la mitad la probabilidad de que alguien lea el dashboard. El equipo que no puede leerlo en tres segundos es el equipo que no lo va a leer.
Alertas conectadas a un canal que un humano lea
Las carpetas de correo no cuentan. Las carpetas de correo son donde las alertas van a morir. El canal tiene que ser uno que un humano concreto revise dentro del plazo en que la alerta es realmente útil — Slack, Discord, PagerDuty si tienes guardias, incluso SMS para los casos duros.
La disciplina más difícil, por un orden de magnitud, es podar. La primera semana después de conectar las alertas, te van a inundar. La tentación siempre es añadir más alertas porque cada una parece estar capturando algo real. El trabajo real es borrar las que disparan sin una acción asociada — las que todos aprenden a deslizar para ignorar. Una alerta que ha sido ignorada tres veces seguidas ya no es una alerta. Es ruido que va a esconder la real cuando llegue.
El listón que mantenemos es: cada alerta corresponde a un paso de runbook o a "despertar a un humano". Si no aplica ninguno, no es una alerta; es un panel de dashboard.
Dos runbooks con nombre
Escribe dos runbooks antes del primer incidente. "La base de datos está caída" y "los deploys están rotos". Una página cada uno. Prosa llana, los pasos que darías, los comandos que ejecutarías, las personas a las que llamarías.
La razón de que sean dos y no diez es que los dos primeros cubren la mayoría de los incidentes tempranos que realmente vas a ver, y un runbook escrito antes de un incidente es útil mientras que uno escrito durante un incidente es ficción. El punto de escribirlos pronto no es ser exhaustivo. Es forzar al equipo a confrontar los supuestos cocinados dentro del sistema mientras todos están lo bastante tranquilos como para pensar.
El beneficio de segundo orden es que un ingeniero nuevo puede leer ambas páginas el día uno y entender más sobre cómo el sistema realmente falla de lo que tres semanas de reuniones de arquitectura le enseñarían.
Lo que no nos molestamos en hacer
Eso es el mínimo. Más allá, hay una larga lista de cosas que genuinamente se amortizan a escala y genuinamente no a escala pequeña.
Los traces distribuidos son el ejemplo canónico. OpenTelemetry es tecnología excelente. Para un sistema con dos servicios y un worker, es overhead que te compra muy poco que los logs estructurados con un request ID compartido no te den ya. El día que tengas ocho servicios y la historia del request ID deje de caber en una pantalla, los traces se vuelven esenciales. Hasta entonces, son un impuesto.
Las métricas personalizadas para cada operación son similares. El instinto de instrumentar todo parece rigor y es mayormente desorden. Las métricas valen la pena cuando tienes suficiente tráfico para que los números sean estadísticamente significativos y suficientes ingenieros para que alguien realmente las mire.
Los SLOs formales con error budgets son una herramienta para organizaciones lo bastante grandes como para que la conversación "¿shippeamos la feature o pagamos deuda de fiabilidad?" necesite un número que la ancle. Para un equipo de cinco personas, esa conversación es una conversación. Añadirle maquinaria de SLO no mejora la respuesta; solo añade ceremonia.
Nada de esto es un argumento contra ninguna de estas herramientas. Es un argumento a favor de la secuencia. Se amortizan después, y "después" importa porque el coste de adoptarlas demasiado pronto es el coste de no terminar las cuatro cosas de arriba.
Por qué los equipos lo saltan
La razón por la que los equipos saltan el mínimo no es que no entiendan su valor. Es que nada se rompe de forma visible el día después del lanzamiento. Un sistema sin logs estructurados, sin dashboard, sin alertas y sin runbooks luce idéntico a uno que tiene los cuatro — hasta el primer incidente real.
La razón por la que se arrepienten es que el día que sí se rompe es el día en que podría haberse resuelto en tres clics y en cambio toma seis horas de trabajo detectivesco, un email de disculpa a los clientes y una conversación de lunes por la mañana sobre por qué nadie lo vio venir.
Dos semanas de trabajo enfocado, devueltas a lo largo de toda la vida del sistema. Lo construimos por defecto al inicio de cada engagement que tomamos. Nadie lo vende. Todos lo necesitan.