Como recuperamos automações críticas em produção em 72 horas

Recuperar automações críticas em produção não significa simplesmente reiniciar um servidor ou executar novamente um fluxo. O objetivo é restaurar o serviço, preservar dados, impedir duplicidades e produzir evidências suficientes para entender o que aconteceu. Em três incidentes acompanhados pela Trait, o trabalho foi organizado em janelas de 72 horas, com decisões explícitas de contenção, rollback, correção e validação.

Os casos envolveram um e-commerce, uma fintech e uma empresa SaaS. As tecnologias e os nomes foram anonimizados, mas as sequências operacionais refletem registros de incidentes, cartões de coordenação e evidências técnicas usados durante atendimentos reais.

A primeira hora foi dedicada a limitar o impacto, e não a procurar o culpado. A equipe identificou o fluxo afetado, pausou novas execuções quando necessário, isolou credenciais em risco e definiu uma pessoa responsável pela comunicação. Essa disciplina evita que várias mudanças simultâneas destruam a evidência do incidente.

O runbook de escalonamento e comunicação para automações críticas ajuda a transformar essa coordenação em um procedimento repetível. Ele deve ser adaptado ao seu ambiente, às responsabilidades internas e aos acordos de atendimento.

A abordagem também segue práticas de resposta a incidentes, como preparação, detecção, contenção, erradicação, recuperação e lições aprendidas. O guia de resposta a incidentes do NIST apresenta esse ciclo como referência para estruturar decisões sem confundir restauração imediata com investigação completa.

Os três casos abaixo mostram decisões diferentes. Em nenhum deles a resposta foi repetir todas as mensagens sem controle. A equipe primeiro calculou o risco de reprocessamento e separou eventos confirmados, pendentes e desconhecidos.

Caso 1: e-commerce, fila de pedidos parada após mudança na API

Às 08h10, o painel indicou que os pedidos pagos não estavam chegando ao sistema de separação. Às 08h18, a Trait confirmou que o fluxo no n8n recebia respostas 401 de uma API alterada, enquanto pedidos antigos permaneciam na fila.

Às 08h27, o gatilho foi pausado e o endpoint foi testado com uma credencial de serviço isolada. Às 08h42, a equipe encontrou um escopo removido durante a rotação de credenciais. Às 09h05, o fornecedor do e-commerce confirmou a mudança e enviou o escopo correto.

Às 09h20, a decisão foi fazer hotfix, não rollback. A versão anterior também usava a mesma credencial e poderia falhar novamente. O fluxo recebeu uma validação explícita de resposta, registro do identificador do pedido e encaminhamento de falhas para uma fila de reprocessamento.

Às 10h15, cinco pedidos de teste foram processados com sucesso. Às 11h00, um lote de 50 pedidos foi liberado. Após quatro horas sem duplicidades e com conciliação entre pagamentos e expedição, o restante da fila foi processado em lotes menores.

Em 27 horas, o fluxo estava normalizado e 100% dos pedidos pendentes haviam sido conciliados. A principal correção permanente foi separar credenciais por finalidade, monitorar respostas 401 e 403 e testar alterações de contrato antes da liberação, prática detalhada no checklist para testar mudanças de API em produção.

Caso 2: fintech, duplicidade potencial em notificações de pagamento

Às 14h03, o time financeiro informou que alguns clientes haviam recebido duas notificações de confirmação. Às 14h12, a análise mostrou que um nó de integração atingia o tempo limite depois de enviar a requisição, fazendo o fluxo tentar novamente sem saber se o primeiro envio havia sido concluído.

Às 14h25, novas notificações foram bloqueadas, mas a captura de pagamentos permaneceu ativa. Às 14h40, a equipe cruzou identificadores de transação no sistema financeiro e no provedor de mensagens. Havia 184 eventos em estado ambíguo, isto é, enviados ao destino, mas sem confirmação registrada no n8n.

Às 15h10, o rollback foi descartado porque a versão anterior não tinha controle de idempotência. O hotfix adicionou uma consulta pelo identificador único antes do envio e salvou o resultado em uma tabela de controle. Eventos já confirmados foram marcados como concluídos, sem novo disparo.

Às 18h30, a amostra de validação apresentou zero duplicidades. Durante as 24 horas seguintes, os eventos foram liberados gradualmente, com limite de lote e conferência automática. Em 46 horas, o fluxo estava recuperado, e a fila de exceções caiu de 184 para 3 registros que exigiam análise humana.

A recuperação evitou uma interrupção percebida pelos clientes porque o processamento financeiro principal continuou separado das notificações. A lição foi arquitetural: uma automação crítica precisa distinguir falha de transporte, falha de negócio e estado desconhecido. O guia de validação de dados em integrações oferece verificações úteis para esse tipo de controle.

Caso 3: SaaS, servidor sem espaço e execuções interrompidas

Às 06h50, alertas apontaram aumento de falhas em um fluxo de provisionamento de contas. Às 07h02, o acesso SSH confirmou que o volume de dados estava com 98% de ocupação. Logs antigos e arquivos temporários haviam crescido após uma alteração no nível de registro.

Às 07h15, as execuções foram pausadas para evitar gravações incompletas. Às 07h32, a equipe coletou espaço disponível, processos ativos, tamanho dos logs e últimas execuções. Às 07h50, foi criado um snapshot conforme a política de recuperação do ambiente.

Às 08h10, arquivos temporários elegíveis foram removidos após validação, sem apagar registros de auditoria. Às 08h40, o serviço foi reiniciado de forma controlada. Às 09h15, três contas de teste foram provisionadas e verificadas no banco, no sistema de cobrança e no painel do cliente.

O fluxo voltou a operar em 13 horas, mas o incidente só foi encerrado após 72 horas de observação. A correção definitiva incluiu retenção de logs, alerta de capacidade em 70%, limpeza automatizada com exclusões protegidas e revisão do dimensionamento. O guia de monitoramento de infraestrutura para PMEs ajuda a estruturar esses indicadores antes que a falta de capacidade interrompa uma operação.

A métrica mais conhecida é o MTTR, ou tempo médio para recuperação. Meça o intervalo entre a detecção e a restauração do serviço, mas também registre o tempo até a contenção e o tempo até a conciliação completa dos dados. Um fluxo pode voltar a executar em duas horas e ainda exigir mais um dia de conferência.

Nos três casos, usamos pelo menos cinco indicadores: MTTR, tempo de contenção, porcentagem de eventos processados sem intervenção, quantidade de duplicidades e volume de exceções após a recuperação. Também acompanhamos a taxa de erro por dependência, pois um aumento de falhas em uma única API costuma exigir ação diferente de uma falha no servidor.

Outra medida prática é o número de intervenções manuais evitadas. No caso da fintech, a consulta por identificador impediu o reenvio de 181 eventos que poderiam ter exigido conferência individual. No e-commerce, a fila controlada preservou os pedidos sem obrigar a equipe a relançar cada transação manualmente.

Compare indicadores antes e depois do incidente. Se o MTTR caiu de 18 para 6 horas, mas os incidentes recorrentes aumentaram, a recuperação foi rápida e a prevenção foi insuficiente. O resultado adequado combina restauração, redução de risco e menor dependência de pessoas específicas.

Um painel simples pode exibir disponibilidade do fluxo, idade da fila, taxa de falha, tempo desde a última execução bem-sucedida, eventos em estado desconhecido e intervenções humanas. O artigo sobre indicadores e painéis para observabilidade em automações detalha como levar essas métricas para uma conversa orientada ao negócio.

A Trait costuma transformar o pós-mortem em backlog priorizado, com dono, prazo, impacto esperado e critério de aceite. Assim, o incidente não termina em uma reunião, mas em mudanças verificáveis no fluxo, na infraestrutura, no monitoramento ou no processo de suporte.