Preciso gerenciar integrações entre sistemas
Resposta rápida
Gerenciar integrações entre sistemas é o trabalho silencioso que evita o pior tipo de incidente — a falha que ninguém vê acontecendo. Diferente de sistema que cai (todos percebem), integração quebrada costuma falhar em silêncio: APIs retornando erro que ninguém olha, webhooks que param de chegar, dados que ficam dessincronizados entre sistemas. O ritual mensal cobre quatro frentes: manter inventário vivo das integrações em produção (origem, destino, dado trafegado, frequência, dono técnico, dono de negócio), monitorar saúde com alerta de falha e desvio de volume (caiu de 10 mil por dia para 100 — é sinal), revisar dependências cruzadas (quando A cai, o que mais para?), e atualizar documentação. Integração não monitorada é incidente futuro com hora marcada.
Na empresa pequena, as integrações geralmente são poucas (cinco a quinze) e simples — ERP que envia para sistema fiscal, plataforma de e-commerce que sincroniza com ERP, gateway de pagamento para ERP, CRM para e-mail marketing. Muitas vezes mediadas por automação no-code (Zapier, Make, n8n) ou por integrações nativas dos próprios SaaS. O risco aqui é confiar no painel do SaaS — quando a integração nativa quebra, o painel mostra erro mas ninguém olha. Disciplina mínima: planilha de inventário das integrações com fonte, destino, frequência e dono; verificação mensal de execução nos painéis de cada serviço; alerta por e-mail quando alguma falha. Quando integração crítica falha por dias sem ninguém notar, a conta vem em conciliação financeira ou cliente reclamando.
Na empresa média, o número de integrações cresce para algumas dezenas e a complexidade aumenta — múltiplos sistemas críticos integrados via APIs próprias, webhooks, jobs batch, ETL. iPaaS (Integration Platform as a Service: MuleSoft, Boomi, Tray.io, ou alternativas mais leves) começa a fazer sentido para centralizar. Monitoramento ponta a ponta vira necessidade — não basta saber que a API respondeu, é preciso saber se o dado chegou íntegro no outro lado. O risco característico é "spaghetti integration": cada projeto cria sua integração ponto a ponto, em dois anos ninguém entende o mapa de dependências. Inventário vivo com dono técnico e dono de negócio para cada integração é a base. Documentação leve, mantida junto com o código ou no portal de APIs, evita envelhecer.
Na empresa grande, integrações são centenas a milhares, com iPaaS enterprise (MuleSoft, Workato, IBM App Connect, plataformas próprias), API gateway, ESB legado em alguns casos, event streaming (Kafka, RabbitMQ). Governança formal de APIs com portal, catálogo, versionamento, SLA, política de retirada. Time dedicado de integração com practice própria. O risco aqui é o oposto da pequena: complexidade arquitetural que fica opaca, com múltiplos hops entre sistemas, transformações de dados em diferentes camadas, mensagens que ficam em filas mortas. Observabilidade distribuída (tracing, correlation ID, dashboards de health por integração) deixa de ser luxo. Política de descomissionamento de integrações inativas evita que o catálogo cresça sem limite — APIs zumbis consomem recurso e geram risco.
- Não há lista única e atualizada de integrações em produção
- Integração quebrou e ninguém notou até alguém reclamar dias depois
- Dados ficam dessincronizados entre sistemas sem alguém entender por quê
- Mudança em um sistema quebra integração em outro sem ninguém prever
- Documentação das integrações está desatualizada ou não existe
- Quem fez a integração saiu da empresa e ninguém mais entende
O inventário vivo de integrações
A base de qualquer gestão decente de integração é o inventário. Em empresa pequena pode ser planilha; em grande, catálogo em ferramenta dedicada. Independente da forma, sete informações por integração não podem faltar:
Origem: qual sistema produz o dado.
Destino: qual sistema recebe.
Tipo: API síncrona, webhook, batch, fila, ETL.
Dado trafegado: em alto nível, o que está sendo trocado (pedido, cliente, transação, evento).
Frequência ou trigger: tempo real, a cada X minutos, diário, sob demanda.
Dono técnico: quem mantém o código ou a configuração.
Dono de negócio: quem responde pelo processo que depende da integração.
Inventário sem dono é inventário morto — quando algo dá errado, ninguém é acionado. Dono técnico responde pela saúde da integração; dono de negócio responde pelo impacto quando falha.
Mapa de dependências cruzadas
Além do inventário linear, mapa visual de dependências mostra o que acontece quando algo falha. Quando a integração entre ERP e sistema fiscal cai, o que mais para? Nota não é emitida, faturamento atrasa, conciliação contábil quebra. Esse mapa visualiza o "raio de explosão" de cada falha e prioriza a atenção.
- Atualize o inventário. Novas integrações que entraram, integrações descomissionadas, mudanças em dono ou em frequência.
- Leia os indicadores de saúde. Por integração: taxa de sucesso, volume trafegado vs período anterior, latência média, falhas correlacionadas.
- Investigue desvios. Volume que caiu sem explicação, latência que cresceu, falhas que aumentaram. Pode ser problema em curso ou mudança na origem.
- Verifique mensagens em fila morta. Em integrações assíncronas (filas, webhooks), mensagens que falharam e ficaram presas. Backlog crescente é sinal.
- Revise dependências. Mudanças planejadas em sistemas que afetam integrações conhecidas. Comunicar com antecedência aos donos das integrações afetadas.
- Atualize documentação. Integração nova ganha documentação mínima; integração que mudou tem documentação atualizada. Documentação que envelhece é pior que documentação inexistente.
- Identifique candidatas a descomissionar. Integrações que ninguém mais usa, que apontam para sistema descontinuado, que duplicam outra mais nova.
As falhas que ninguém vê
O incidente mais perigoso em integração é o que não dispara alerta. Categorias clássicas:
Volume caiu drasticamente: integração processava 10 mil eventos por dia, hoje processou 80. Tecnicamente sem erro, mas algo na origem parou. Cliente nada percebe agora; fechamento mensal será catastrófico.
Dados parcialmente corrompidos: integração entrega, mas alguns campos estão errados — vazios, em formato inválido, com codificação errada. Dado entra no destino, mas precisa de retrabalho ou gera erro a jusante.
Atraso crescente: integração estava em tempo real, agora roda com 30 minutos de atraso. Tecnicamente funcional, operacionalmente incompatível com o processo que depende.
Duplicação ou perda: mensagem entregue duas vezes, ou perdida em algum hop. Sem reconciliação periódica, fica invisível até o fechamento.
Cada categoria exige tipo específico de monitoramento — não basta o monitor técnico padrão.
Mudança em APIs e quebra de integração
Fornecedor que muda API sem aviso é fonte clássica de incidente. Webhook que muda formato, endpoint depreciado, autenticação que muda método. Defesa: assinar comunicações de fornecedor (release notes, breaking changes), revisar mensalmente o que está marcado como depreciado, manter ambiente de teste das integrações para validar antes de produção.
Em integrações internas (entre sistemas próprios), governança de API protege: versionamento explícito (v1, v2), política de prazo mínimo de aviso antes de depreciar (90 ou 180 dias), portal com documentação das versões ativas. Sem isso, equipe A muda API e descobre na semana seguinte que três times pararam.
Sem inventário. Quando ninguém sabe quantas integrações existem, gestão é impossível. Inventário vivo é pré-requisito de tudo o resto.
Alerta só em falha técnica. Falha silenciosa (volume caiu, dado corrompido, atraso crescente) é o que mais machuca. Alerta de desvio de volume e reconciliação periódica pegam o que técnico não pega.
Documentação desatualizada. Documentação que mente é pior do que documentação inexistente — induz erro. Atualizar junto com a mudança, mesmo que custe meia hora, paga em meses.
Quem fez saiu sem passar conhecimento. Integração crítica mantida por uma pessoa que saiu é dívida técnica imediata. Documentação mínima (o que faz, como funciona, como recuperar quando falha) é seguro.
- Inventário de integrações está atualizado com novas e descomissionadas
- Cada integração tem dono técnico e dono de negócio definidos
- Indicadores de saúde foram lidos por integração relevante
- Desvios de volume e latência foram investigados
- Mensagens em filas mortas foram tratadas ou aceitas
- Documentação foi atualizada para as integrações que mudaram
- Mudanças planejadas em sistemas foram comunicadas aos donos de integração afetada
- Reconciliação periódica entre sistemas críticos foi executada