Urgência · Integração
A integração caiu e a operação parou de falar com o sistema
Integração não é projeto com fim: é serviço com disponibilidade. Quando ninguém monitora, a queda é descoberta pelo cliente — não pelo time.
Resposta direta
Integração que cai e para a operação revela falta de observabilidade, não falta de tecnologia. A causa operacional mais comum é não existir alerta de falha nem de ausência: quando o processo executa zero registros, ninguém é avisado e a queda é descoberta pelo cliente.
Em resumo
- Alerta de ausência é mais importante que alerta de erro: processo que não rodou não gera erro.
- Reprocessamento idempotente é o que permite religar sem duplicar.
- Integração sem dono nominal é a que fica caída mais tempo.
01
Contenção antes de conserto
Com a integração parada, a operação improvisa. O improviso é o que cria o segundo problema: pedido digitado duas vezes, estoque baixado em dobro, nota emitida sem lastro.
- Defina um único ponto de entrada manual e comunique a todos.
- Congele o reprocessamento até saber o que já foi gravado.
- Registre o que foi feito manualmente, com horário e responsável.
- Avise quem depende do dado antes de religar.
02
Por que a queda foi descoberta tarde
A causa operacional quase nunca é técnica — é de observabilidade.
- Não existe alerta de falha, apenas log.
- O alerta existe e chega em um e-mail que ninguém lê.
- A integração não tem horário de execução conhecido, então ninguém nota ausência.
- Não há indicador de volume: se processou zero, deveria acender.
03
O que verificar antes de religar
Quatro checagens que evitam duplicidade.
- Conte os registros processados com sucesso até o momento da queda.
- Verifique se houve gravação parcial no destino.
- Identifique a fila pendente e ordene por data de origem.
- Teste o reprocessamento com um único registro antes de liberar o lote.
04
O que fazer depois
O que transforma um incidente em melhoria.
- Alerta de ausência de execução, não só de erro.
- Indicador de volume processado por hora.
- Reprocessamento idempotente, que não duplica se rodar duas vezes.
- Registro de incidente com causa e correção, para não repetir.
05
O limite honesto
Integração com sistema de terceiro sempre terá indisponibilidade. O objetivo não é zero queda — é detectar em minutos, conter sem duplicar e reprocessar com segurança.
Perguntas frequentes
Antes de decidir
Comparando contagem de origem e destino por janela de tempo e conferindo o identificador único. Sem identificador único, a duplicidade não é detectável — e esse é o defeito de origem.
Só se o reprocessamento for idempotente. Sem isso, rodar de novo duplica o que já tinha passado.
Precisa ser nominal. Integração sem dono é a que cai e ninguém percebe — a responsabilidade difusa é a causa mais comum de queda longa.
Só depois de saber se a causa foi ferramenta, credencial, mudança de API do terceiro ou volume. Trocar sem diagnóstico repete o problema com outro fornecedor.
Se este é o seu caso, o próximo passo é entender o contexto
Continuar