El objetivo es saber que tu sistema no está saludable antes de que tus usuarios te lo digan. Una buena observabilidad te permite responder preguntas que no anticipaste, no solo verificar un conjunto fijo de dashboards. Como tech lead, configuras esto antes del incidente, no durante.
Page sobre lo que el usuario siente, no sobre jitter interno. Ancla las alertas a SLOs: error rate, latencia (p95/p99) y disponibilidad. Un pico en CPU no es un incidente; checkout fallando para el 2% de los usuarios sí lo es.
| Alertar sobre | No paginar sobre |
|---|---|
| Error rate violando SLO | Pico de CPU único |
| Latencia p99 sobre presupuesto | Una request lenta |
| Health checks fallidos | Disco al 60% |
Cada alerta debe ser urgente, real y accionable — nombra qué está mal y señala el próximo paso. Las alertas que disparan constantemente entrenan al equipo a ignorarlas; alert fatigue es cómo se pasan por alto los incidentes reales. Añade health checks y dashboards que muestren las señales doradas de un vistazo.
Los equipos que observan solo después de un incidente vuelan a ciegas: se enteran de interrupciones por clientes enojados y debugean con adivinanzas. Invertir en observabilidad desde el inicio convierte misterios de las 3 a.m. en diagnósticos de 5 minutos, reduce el downtime y libera al equipo para que envíe código en lugar de apagar fuegos.