Em condições normais, monitoramento de e-commerce é retrospectivo: olha-se o que aconteceu, identifica-se anomalias, e toma-se ação. A janela de análise é horas ou dias.
Na Black Friday, o monitoramento precisa ser prospectivo e em tempo real. A janela entre detectar um problema e ter impacto mensurável em vendas é de minutos não horas.
Um checkout que começa a degradar às 10h17 e só é percebido às 11h30 perdeu 73 minutos de volume de pico.
Com o tráfego típico de Black Friday, esse intervalo pode representar centenas de pedidos que não foram finalizados.
A diferença entre monitoramento eficiente e ineficiente durante o evento não está na quantidade de métricas acompanhadas.
Está em três coisas: métricas certas, alertas calibrados para o volume do evento, e protocolo claro de resposta.
As métricas que importam e as que parecem importar mas não importam
O que acompanhar
- Latência do checkout por percentil (p95 e p99): Latência média é enganosa. Se 95% dos checkouts respondem em 1 segundo e 5% demoram 15 segundos, a média pode ser de 1,7 segundo número aceitável. Mas 5% dos usuários estão tendo uma experiência péssima. p95 diz: 95% dos checkouts respondem em até X segundos. p99 diz o mesmo para 99% dos usuários. Esses percentis revelam o comportamento de cauda onde os problemas de degradação aparecem primeiro. Threshold de alerta: p95 acima de 3 segundos, investigar. p95 acima de 5 segundos, escalar imediatamente.
- Taxa de erro por endpoint: Não a taxa de erro global do sistema a taxa de erro por endpoint específico. Erro no endpoint de submissão de pedido é crítico. Erro no endpoint de busca de produto é importante mas não bloqueia conversão. Ter a taxa de erro granularizada por endpoint permite priorizar a resposta corretamente: problema no checkout tem prioridade máxima; problema no sistema de recomendação, pode aguardar investigação. Threshold de alerta: qualquer endpoint de checkout com taxa de erro acima de 0,5%.
- Hit rate do cache: Porcentagem de requisições respondidas pelo cache versus processadas pelo servidor. Deve estar alto acima de 80% para páginas de produto e categoria em pico de tráfego. Hit rate caindo indica que o cache está sendo invalidado com frequência excessiva, que o TTL está muito curto para o nível de tráfego, ou que houve mudança no catálogo que invalidou grandes porções do cache. Cada um desses cenários tem implicação diferente para a ação. Threshold de alerta: hit rate abaixo de 70% em páginas de produto durante pico.
- Utilização de conexões do banco de dados: Porcentagem do pool de conexões disponíveis que está em uso. Quando esse número se aproxima de 100%, novas requisições começam a esperar conexão disponível o que se manifesta como lentidão no site sem causa aparente na camada de aplicação. Threshold de alerta: utilização acima de 75% do pool, investigar. Acima de 90%, escalar.
- Tempo de resposta das integrações externas (por serviço): Gateway de pagamento, antifraude, cotação de frete, consulta de CEP cada um precisa ter seu tempo de resposta monitorado separadamente. Uma integração externa ficando lenta é o tipo de problema que o monitoramento geral não captura, mas que afeta diretamente o fluxo de compra. Threshold de alerta: qualquer integração no caminho crítico do checkout com tempo de resposta acima de 2 segundos no p95.
- Volume de pedidos por hora (comparado com a projeção): Não como métrica de sucesso em tempo real como sinal de saúde do sistema. Se a projeção de pico é 800 pedidos por hora e o sistema está processando 200, ou o tráfego está abaixo do esperado, ou algum gargalo está impedindo que pedidos sejam finalizados. Volume de pedidos muito abaixo da projeção em horário de pico, sem queda equivalente de tráfego no site, é sinal forte de problema no fluxo de checkout.
- Fila de processamento de pedidos: Tamanho da fila de pedidos aguardando processamento pelo ERP ou pelo sistema de fulfillment. Fila crescendo desproporcionalmente ao volume de pedidos indica gargalo na integração entre plataforma e ERP que se manifesta como atraso de emissão de nota, atraso de separação, e eventual problema de entrega.
O que parece importar mas é ruído durante o evento
- Comparação de conversão com o ano anterior em tempo real. Não tem valor durante o evento os contextos são diferentes demais para a comparação informar ação imediata.
- Volume de tráfego como métrica de saúde. Tráfego alto não significa que tudo está bem. Checkout degradado pode manter tráfego alto enquanto a conversão despenca.
- Receita acumulada como métrica de performance de sistema. Receita crescendo não significa que o sistema está saudável pode significar que os pedidos que passaram estão passando, e os que estão travados não aparecem na receita.
Como configurar os alertas antes do evento
Alerta calibrado para o volume de Black Friday é diferente de alerta calibrado para o volume normal.
Um alerta que dispara quando a latência do checkout passa de 800ms faz sentido no dia normal.
Na Black Friday, com volume 5x a 10x maior, alguma degradação de latência é esperada o threshold de alerta precisa ser ajustado para refletir o que é normal no volume do evento versus o que é problema.
- Calibração por percentil de volume. Os thresholds de alerta devem ser ajustados com base na projeção de tráfego do evento. Se o sistema normalmente opera com 50 conexões de banco ativas e 200 no pico projetado, o alerta de banco não deve ser em 50 deve ser em 160 (80% do pico projetado).
- Alertas por janela de tempo. Spike de erro de 30 segundos em checkout pode ser anomalia transitória. Erro acima do threshold por 3 minutos consecutivos é problema real. Os alertas devem ter janela de tempo configurada para reduzir falsos positivos de alerta porque alerta que dispara com frequência alta perde a atenção do time técnico.
- Separação por criticidade. Três níveis: atenção (investigar quando possível), alerta (investigar imediatamente), crítico (ação imediata com escalação). Cada métrica precisa ter seu threshold para cada nível.
- Canal de alerta por criticidade. Alertas de atenção vão para o dashboard. Alertas reais vão para o canal de comunicação do time técnico. Alertas críticos disparam notificação para o responsável de plantão mesmo que seja 3h da madrugada.
O que fazer e o que não fazer quando o alerta dispara
O que fazer
- Diagnóstico antes de ação. Quando uma métrica sai do threshold, o primeiro passo é identificar a causa não executar uma correção. A causa de latência alta pode ser banco de dados, pode ser integração externa, pode ser cache invalidado. A correção é diferente em cada caso. Ação sem diagnóstico pode piorar o problema.
- Verificar métricas correlacionadas. Latência alta do checkout pode ser causada por banco de dados sobrecarregado (verificar utilização do pool), integração externa lenta (verificar tempo de resposta por serviço), ou cache com hit rate baixo (verificar hit rate). Olhar as métricas correlacionadas ao mesmo tempo que a métrica de alerta reduz o tempo de diagnóstico.
- Seguir o protocolo definido antes do evento. O protocolo de resposta a incidente quem aciona, por qual canal, qual é o tempo máximo de diagnóstico antes de escalar deve ter sido definido antes do evento. Durante o evento sob pressão, improvisar protocolo é mais lento e mais sujeito a erro do que seguir o que foi planejado.
- Documentar em tempo real. Todo alerta, diagnóstico e ação deve ser registrado durante o evento. Essa documentação alimenta o post-mortem técnico dos dias seguintes e é o que permite melhorar o processo para o próximo ano.
O que não fazer
- Fazer mudança de configuração não planejada em produção. A tentação quando uma métrica está ruim é ajustar alguma configuração para melhorá-la. O risco é alto: mudança não planejada em produção durante pico de tráfego pode ter efeito colateral inesperado que piora a situação. A regra geral é: só execute mudanças que foram planejadas, testadas em homologação e incluídas no protocolo de resposta. A exceção: rollback de uma mudança recente que está claramente causando o problema. Rollback para estado anterior conhecido é uma ação segura.
- Reagir a spike transitório sem confirmação de tendência. Um checkout que ficou lento por 45 segundos e voltou ao normal não exige ação — pode ser ruído ou spike transitório. Ação sem confirmação de tendência pode interromper processos que estavam funcionando corretamente. Aguarde a confirmação pela janela de tempo configurada no alerta antes de agir.
- Tomar decisão de rollback sem aprovação. Rollback de funcionalidade em produção durante o evento tem impacto imediato em vendas. É uma decisão que precisa de aprovação explícita do responsável técnico — não de ação unilateral de quem está monitorando.
O dashboard que o time precisa enxergar
Durante o evento, um dashboard único com as métricas críticas visível para todo o time técnico de plantão.
Não 7 ferramentas abertas em paralelo um dashboard consolidado.
O que precisa estar visível:
- Latência do checkout (p95, p99) com gráfico de linha em tempo real
- Taxa de erro por endpoint crítico com número e tendência
- Hit rate do cache com percentual e gráfico
- Utilização do pool de banco de dados com percentual e threshold marcado
- Tempo de resposta por integração externa gateway, antifraude, frete
- Volume de pedidos por hora com comparação com projeção
- Fila de processamento de pedidos
Cada métrica com cor de status: verde (dentro do esperado), amarelo (atenção), vermelho (alerta ou crítico).
O time precisa saber o estado geral da operação de um olhar — não precisar ler cada número individualmente.
Uma nota sobre agentes de IA no monitoramento
Monitoramento que depende de humano lendo dashboard tem um limite de velocidade de resposta.
Mesmo com dashboard bem configurado, o intervalo entre anomalia aparecer e humano tomar ação raramente é menor que 3 a 5 minutos.
Agentes de IA aplicados a monitoramento têm latência de resposta de segundos.
Detectam padrão de degradação antes que o threshold de alerta seja atingido porque são capazes de identificar tendência, não só nível absoluto e podem executar ações de resposta configuradas automaticamente: aumentar TTL do cache, acionar circuit breaker de integração lenta, escalar para fila de análise manual os pedidos que chegaram durante a degradação.
Não é ficção científica é o modelo de operação que grandes plataformas de e-commerce já usam em produção.
Para o e-commerce de médio porte, a aplicação prática começa com automação das respostas mais simples (acionar fallback de integração, ajustar pool de conexões dentro de parâmetros pré-definidos) e cresce conforme a maturidade da operação.
A Black Friday bem preparada ainda pode dar errado se o monitoramento não estiver configurado para detectar o problema antes que ele cresça.
E a Black Friday com monitoramento eficiente permite que problemas que seriam desastres se tornem incidentes menores resolvidos em minutos, não em horas.
Preparação e monitoramento não são etapas separadas.
São duas faces do mesmo investimento em operação resiliente.
A Dupla acompanha implementações de observabilidade e monitoramento para e-commerces, incluindo configuração de dashboards, definição de thresholds e protocolos de resposta a incidente.
Se quiser entender como estruturar o monitoramento do seu evento, fale com a gente.
