Saber antes que o cliente ligue

Sexta-feira, 16h40. Um cliente escreve dizendo que sua aplicação está "lenta desde esta manhã". Você abre o painel: tudo verde. O processador está estacionado em 30 %, a memória está estável, a sonda de disponibilidade responde 200 há três semanas sem interrupção. Você não viu nada, e mesmo assim o cliente tem razão. Uma hora depois, você descobre que 4 % das requisições levam mais de dez segundos, todas no mesmo ponto de entrada, todas para os clientes cuja conta tem mais de dez mil linhas. Nenhuma das suas sondas poderia ter visto isso: elas verificavam se o serviço respondia, não se respondia corretamente para todo mundo.

Essa defasagem não é uma falha de ferramenta, é uma falha de método. Uma sonda verifica uma hipótese que você formulou de antemão: "o processo está vivo?", "o disco está cheio?". Ela é excelente para as falhas que você já encontrou e cega para todas as outras. Ora, em produção, os incidentes que custam caro são quase sempre aqueles que ninguém havia antecipado: uma dependência que fica lenta sem cair, um cache que se esvazia, uma consulta SQL cujo plano de execução muda depois de uma atualização de versão. A pergunta útil, portanto, não é "tenho sondas suficientes?", mas "quando um incidente inédito acontece, meus dados me permitem entender sem implantar código?". É exatamente isso que a palavra observabilidade designa, e é um critério mensurável, não um slogan de fornecedor.