Quem descobriu a queda primeiro, você ou o seu cliente?

O painel do fornecedor estava verde enquanto o checkout ficava fora. O problema não é o sistema cair, é a ordem em que as pessoas ficam sabendo: o cliente antes do fornecedor que você paga para vigiar. Sobre por que o monitoramento certo mede sintoma, não CPU.

Sábado de manhã, faltando pouco para as dez, um founder que eu ainda não conhecia me chamou no WhatsApp, indicado por um cliente nosso, atrás de uma segunda opinião. Mandou um print. Não era dele: era de um cliente dele, num grupo de compradores, com a foto da tela de erro do checkout e a legenda "de novo isso?". Ele tinha perguntado ao fornecedor que cuida do sistema há quanto tempo o pagamento estava fora. Ninguém soube responder. O painel de monitoramento do fornecedor estava verde.

A parte que me incomoda nessa história não é o sistema ter caído. Sistema cai, é da natureza da coisa. O que me incomoda é a ordem em que as pessoas ficaram sabendo: o comprador antes do founder, o founder antes do fornecedor que ele paga justamente para vigiar aquilo.

Se você contrata engenharia de fora e vem descobrindo as quedas de produção pela reclamação de quem usa o seu produto, este texto é sobre a pergunta que quase ninguém faz antes de assinar: quando quebrar, e vai quebrar, quem descobre primeiro?

O painel estava verde. O sistema não.

O painel do fornecedor mostrava tudo no lugar porque estava medindo a coisa errada. CPU em 30%, memória tranquila, o servidor respondendo ao health check a cada trinta segundos. Nada disso é mentira. Só que nenhuma dessas métricas sabe se um cliente consegue finalizar uma compra.

O health check clássico bate numa rota tipo /health e recebe um "ok". Essa rota costuma responder "ok" mesmo com o serviço de pagamento fora, porque ela nem toca no serviço de pagamento. O servidor está de pé, atendendo a um teste escrito justamente para passar.

Verde, ali, significa só que o processo não morreu. É o teto mais baixo de saúde que existe, e ainda assim é o que boa parte dos contratos trata como suficiente. Quando a gente assume um produto no Diagnostic Sprint, uma das primeiras coisas que eu abro é a lista de alertas configurados. Já vi produto rodando por dois anos com exatamente um alerta ligado: "servidor não responde". Nenhum sobre erro, latência ou fila travada.

Um painel cheio de gráficos coloridos pode estar todo verde e ainda assim não dizer se um cliente conseguiu terminar a compra.

O que o cliente sente não cabe num gráfico de CPU

A virada é simples de dizer e trabalhosa de fazer: medir sintoma, e não recurso. O usuário não sente o seu uso de CPU. Ele sente que o botão girou por oito segundos e voltou um erro. Monitoramento que presta observa a experiência de quem está do outro lado da tela, e traduz isso em sinais que acordam alguém.

Na prática vira um punhado de alertas que qualquer time consegue configurar numa tarde:

• Taxa de erro: percentual de respostas 5xx acima de um limite (digamos, 2% numa janela de cinco minutos) dispara aviso, não espera o cliente abrir chamado.
• Latência que importa: não a média, que esconde tudo, mas o p95. Se o percentil 95 do checkout passa de um segundo, alguém precisa saber antes que vire abandono de carrinho.
• Teste sintético: um robô que a cada minuto refaz o caminho real do cliente (login, adicionar ao carrinho, pagar em ambiente de teste) e grita quando algum passo trava.
• Fila e job: se o processamento de pedidos para de andar, o servidor segue verde, o cliente espera uma confirmação que não chega, e nenhum health check percebe.

Nenhum desses alertas é caro ou exótico. Datadog, Grafana, ou até um cron com curl e um webhook no Slack já cobrem o básico. Quando falta, quase nunca é questão de orçamento. É que ninguém parou para pensar no cliente antes de o incidente acontecer.

A gente monta essa malha de sinais nas primeiras semanas de qualquer projeto; se você quer descobrir o que o seu monitoramento de hoje simplesmente ignora, dá para mapear isso num diagnóstico antes que o próximo sábado faça o serviço por você.

O servidor de pé, respondendo ao health check a cada trinta segundos, não sabe se a fila de pedidos parou de andar lá dentro.

Nem todo sistema precisa de plantão às três da manhã

Preciso ser justa aqui, senão o texto vira alarmismo. Nem todo software merece plantão o dia inteiro. Se o seu produto é uma landing page, um site institucional de cinco páginas ou uma ferramenta interna que quatro pessoas usam em horário comercial, montar rodízio de plantão com PagerDuty é gastar bala em passarinho. Um alerta simples no e-mail resolve, e você segue a vida.

A pergunta que separa os dois casos é direta: se isso ficar fora por uma hora num domingo, alguém perde dinheiro, confiança ou dado? Quando a resposta é não, relaxa mesmo. Quando é sim, e para quase todo produto que gera receita ela é sim, descobrir a queda pela boca do cliente não é um detalhe operacional. É risco de negócio que ninguém precificou.

Quem fica liga o alarme que o barato nunca ligou

Aqui está a diferença que não aparece na proposta. O fornecedor barato entrega a funcionalidade pedida e some. Instrumentar alerta não é uma tela que o cliente desenhou no escopo, então não cabe no orçamento apertado que ganhou a concorrência. O incidente, quando chega, já é problema seu.

Num cliente de logística que a gente pegou no ano passado — time enxuto, seis pessoas — a primeira semana não teve linha de código nova. Foi instrumentação: alerta de erro por rota, p95 na tela de agendamento de entrega, um teste sintético refazendo o fluxo de rastreamento a cada minuto. Na terça seguinte o sintético apitou às 6h47; um deploy da madrugada tinha quebrado a rota de rastreio. O time corrigiu antes de o primeiro cliente abrir o app.

Antes disso, a média deles para perceber uma queda girava em torno de duas horas, sempre pela reclamação. Esse número veio do relato deles, não de um dashboard, então trato com desconfiança: pode estar inflado pela memória de quem passou raiva. Mesmo cortando pela metade, uma hora com a tela de agendamento fora num pico de fim de tarde já sai caro.

É isso que um squad que fica faz por hábito: entrega a funcionalidade já com os olhos que vão vigiar ela depois. O monitoramento entra no mesmo pacote da feature, e faz parte de considerar a entrega pronta.

Alguns desses casos, com nome de produto no ar e não print de tela, estão em revin.com.br/pt/cases.

A conta do silêncio

O founder do print de sábado ainda está reconstruindo a confiança com aquele grupo de compradores. O prejuízo maior não foi a hora de checkout fora. Foi o cliente perceber que ninguém do lado de dentro estava olhando. Isso não aparece em gráfico nenhum, e é o mais lento de recuperar.

Todo mundo pergunta ao fornecedor se ele entrega rápido. Quase ninguém pergunta como ele vai saber que quebrou. E é essa segunda resposta que decide se, no próximo sábado de manhã, quem te avisa é o seu monitoramento ou o seu cliente.

Se você já viveu um sábado desses e não quer o próximo, marca uma conversa com a gente: a gente olha junto o que o seu sistema hoje não está te contando.