Uma semana antes do pico da temporada do ano passado, eu caminhava por um 3PL em Rialto quando seu diretor de TI me mostrou com orgulho a nova API de etiquetas da transportadora que haviam acabado de integrar. «Processa 2.000 solicitações por segundo», disse ele. Fiz uma única pergunta, e ele congelou: «Se essa API cair às 2h da manhã, quem é a primeira pessoa a saber?»
Ele pensou por um longo momento. «Provavelmente... o operador da impressora de etiquetas às 6h?»
Isso diz tudo. O quanto uma integração é robusta — isso é uma questão técnica. Quem fica sabendo primeiro quando ela quebra — isso é uma questão de gestão. A maioria dos armazéns, na prática, não tem monitoramento de integrações. Não porque nunca tenham configurado, mas porque o que configuraram é quase como se não existisse: limites absurdos, alertas roteados para uma caixa de entrada que ninguém lê, ou mensagens de texto às 3h da manhã que acordam a equipe inteira até todo mundo silenciar o canal.
Em vinte anos, já vi integrações morrerem de pelo menos vinte formas diferentes. Aqui está meu checklist de monitoramento e alertas, explicado em linguagem clara. Siga-o, e a primeira pessoa a saber de uma queda será alguém da sua equipe — não o seu cliente.
Os cinco sinais. Todo o resto é bônus.
Não comece com um dashboard de observabilidade elegante. Num armazém, cinco sinais cobrem tudo. Perca um, e a alta temporada ainda pode morder você.
Primeiro, o heartbeat. O endpoint está vivo? O mais simples e o mais negligenciado: faça ping no endpoint de health-check a cada cinco minutos, ou envie uma mensagem de teste. APIs de etiquetas de transportadora, validação de endereços, calculadoras de impostos de importação — tudo de terceiros precisa do seu próprio heartbeat. Em 2023, um 3PL em Ontario perdeu quatro horas de impressão de etiquetas porque o certificado TLS de uma transportadora expirou. Sem sonda de heartbeat, sem aviso. Nove mil pedidos se acumularam antes que alguém percebesse. Testes de heartbeat custam praticamente nada. Ignorá-los é pura preguiça.
Segundo, a taxa de erros. Solicitações falhadas como proporção do total numa janela de cinco minutos. Proporção, não contagem absoluta — no pico, o volume multiplica por dez, então as falhas absolutas vão subir normalmente. Uma proporção crescente é o que significa problema de verdade.
Terceiro, a latência. Latência P99, não a média. Uma média de 200ms soa linda até o P99 chegar a oito segundos — o que significa que um por cento das solicitações empacam, geralmente concentradas nos minutos mais movimentados, e é exatamente isso que trava a linha de embalagem.
Quarto, a profundidade do backlog. Comprimento da fila, contagem de arquivos não processados, profundidade do pool de tentativas. «Lento mas não morto» é o modo de falha mais cruel: tudo parece bem na superfície enquanto a fila cresce cada vez mais fundo, e quando você percebe, 30.000 mensagens estão enterradas e não dá mais para cavar.
Quinto, lacunas de conciliação. Conciliação programada: pedidos que enviamos versus pedidos que eles receberam. Etiquetas de transportadora, documentos EDI 850/856, sincronizações de estoque — concilie pelo menos diariamente. A conciliação é a última linha de defesa. Quando os quatro primeiros sinais falham, este detecta.
Como definir limites: três níveis, sem tamanho único
O erro clássico é um limite para tudo: ou o menino que gritava lobo todo dia, ou uma queda real que ninguém nota. Eu classifico por impacto no negócio:
P1 — ligação telefônica, responder em cinco minutos. Gatilhos: heartbeat falha duas vezes seguidas numa interface crítica (impressão de etiquetas, confirmação de envio, sincronização de estoque); taxa de erros acima de 5% numa janela de cinco minutos; latência P99 acima de dez segundos por dez minutos seguidos. P1 significa uma ligação telefônica de verdade para o engenheiro de plantão. Não uma mensagem de texto, não um e-mail. Sem resposta em cinco minutos, escala automaticamente para o segundo contato.
P2 — texto mais mensagem de grupo, responder em trinta minutos. Gatilhos: interface não crítica (validação de endereços, callbacks de rastreamento) com taxa de erros acima de 3%; backlog de fila acima de 5.000 mensagens e ainda crescendo depois de quinze minutos; mais de cinquenta tentativas falhadas no mesmo lote. P2 vai para o canal de plantão, e um «recebido» conta como reconhecimento.
P3 — e-mail mais resumo diário, tratar no horário comercial. Gatilhos: lacuna de conciliação abaixo de 0,5%; uma lenta subida do P99 que ainda não cruzou a linha; um certificado expirando em trinta dias. Estes vão no relatório da manhã para o standup de TI.
Um detalhe crítico: ajuste os limites por interface, e congele mudanças de limites duas semanas antes do pico. A pior configuração que já vi tinha todas as interfaces compartilhando um limite de 1% de taxa de erros. No pico, a API de validação de endereços ficava em 2–3% de erros o dia todo porque os compradores digitam endereços lixo — os alertas disparavam o tempo todo, todo mundo ignorava, e naquela noite uma queda genuína P1 foi ignorada como só mais um falso alarme. Calibre cada limite contra o P95 histórico daquela interface antes do pico. Leva uma tarde. Ignorar isso custa o único alerta que importa.
Quem recebe o alerta: a escala de plantão importa mais que a tecnologia
A tecnologia pode ser perfeita e ainda assim inútil se os alertas chegam a pessoas que silenciaram tudo. Três regras que exijo:
Uma, tem que haver uma escala de plantão — uma pessoa nomeada, não «a equipe». Um alerta num chat de grupo significa que todo mundo assume que outra pessoa vai tratar. Alertas P1 vão ponto a ponto: primeiro o engenheiro de plantão, sem resposta em cinco minutos escala automaticamente para o gerente de TI, depois para o diretor de operações, que tem autoridade para tomar decisões de negócio como trocar para uma transportadora de backup. A escala roda semanalmente, publicada com uma semana de antecedência, e plantões de feriado ganham banco de horas. Uma escala sem banco de horas não sobrevive um mês.
Dois, separe os canais por severidade. P1 por telefone, P2 por texto e chat de grupo, P3 por e-mail. Nunca jogue o resumo P3 no mesmo canal que P1 — uma vez que o ruído é suficiente, as pessoas aprendem a ignorar tudo. Já vi um canal de 200 pessoas disparando 300 alertas por dia. Um P1 enterrado ali tinha zero chance.
Três, revise os falsos alarmes mensalmente. Puxe os alertas do mês passado: quais foram incidentes reais, quais foram falsos positivos, quais dispararam e foram ignorados. Qualquer limite com taxa de falsos positivos acima de 30% é reajustado. Alertas ignorados são investigados. Um sistema de alertas, como uma pessoa, apodrece sem revisão.
E uma lição paga com sangue: faça um simulado de «cortar a rede» antes do pico. Numa manhã tranquila de fim de semana, corte a API da transportadora em staging e cronometre tudo — quão rápido o alerta dispara, quão rápido o plantonista responde, quão rápido o plano de contingência entra. Um plano que só foi discutido no papel vai falhar no primeiro teste de verdade, garantido. Os armazéns com que trabalhei que fazem o simulado versus os que não fazem se comportam como duas espécies diferentes na noite do pico.
Quanto custa isso? Vamos fazer as contas.
Configurar isso não é caro. Sondas de heartbeat e rastreamento de taxa de erros com um APM pronto (Datadog, New Relic, ou Prometheus open-source mais Alertmanager) levam cerca de uma semana para subir. O custo real é o adicional de plantão: por aqui, um turno de noite em dia de semana custa $50–80, nos fins de semana $100–150. Na escala, isso dá alguns milhares de dólares por mês.
Agora o custo de não fazer. O cenário mais comum: a API de etiquetas morre de noite, ninguém sabe até às 6h, 8.000 pedidos atrasados. Cada pedido atrasado um dia — cutoffs da transportadora perdidos, tickets de suporte, penalidades dos marketplaces (o OTDR da Amazon cai meio ponto e seu peso na Buy Box leva o golpe), mais hora extra para recuperar. Um incidente assim custa $20.000–50.000, sendo conservador. Um único incidente num ano paga o monitoramento dez vezes.
Então meu veredito é direto: monitoramento de integrações não é disciplina eletiva de TI. É disciplina obrigatória da operação do armazém. Você pode pular os dashboards elegantes e as palavras da moda de observabilidade, mas cinco sinais, três níveis de limites e uma escala de plantão — esses três deveriam existir até hoje à noite.
A primeira coisa amanhã de manhã: pergunte ao seu líder de TI quem fica sabendo primeiro quando uma interface morre às 2h da manhã. Se ele não souber responder, você já sabe o que fazer.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
