O objetivo é saber que seu sistema está unhealthy antes de seus usuários te avisarem. Uma boa observabilidade permite que você responda perguntas que não antecipou, não apenas verificar um conjunto fixo de dashboards. Como tech lead, você configura isso antes do incidente, não durante.
Page sobre o que o usuário sente, não sobre jitter interno. Ancore alertas em SLOs: taxa de erro, latência (p95/p99) e disponibilidade. Um pico de CPU não é um incidente; checkout falhando para 2% dos usuários é.
| Alerte sobre | Não page sobre |
|---|---|
| Taxa de erro ultrapassando SLO | Pico único de CPU |
| Latência p99 acima do orçamento | Uma requisição lenta |
| Health checks falhando | Disco em 60% |
Cada alerta deve ser urgente, real e acionável — deve nomear o que está errado e apontar um próximo passo. Alertas que disparam constantemente treinam o time a ignorá-los; alert fatigue é como incidentes reais passam despercebidos. Adicione health checks e dashboards que mostrem os sinais ouro de um relance.
Times que observam apenas após um incidente estão voando às cegas: aprendem sobre outages de clientes furiosos e debugam com adivinhação. Investir em observabilidade desde o início transforma mistérios às 3 da manhã em diagnósticos de 5 minutos, reduz downtime e libera o time para fazer ship em vez de apagar fogo.