Sua automação parou. Quando você vai descobrir?
Quem descobre que a automação parou costuma ser o cliente que ligou cobrando. A rotina não avisa quando falha, ela apenas deixa de rodar, e o silêncio se parece com funcionamento normal. Fazer a operação avisar é decisão de arquitetura, não escolha de ferramenta de monitoramento.
Por que a falha silenciosa é o estado normal de uma automação?
Porque o erro que aparece na tela tem uma pessoa olhando para ele, e o erro que acontece às três da manhã não tem. A diferença é essa.
Quando um usuário clica e a tela trava, existe alguém incomodado e um chamado aberto em minutos. Quando a rotina noturna que empurra pedidos do portal para o ERP falha, não existe pessoa nenhuma na cena. O sintoma é um número um pouco menor no dia seguinte, e um número menor sempre encontra uma explicação plausível.
O problema é mais antigo e mais estrutural que a sua operação. Yuan e colegas estudaram 198 falhas reais reportadas por usuários em cinco sistemas de dados de uso amplo, entre eles Cassandra, HDFS e Redis, e publicaram o resultado na OSDI de 2014. Em 92% das falhas catastróficas, a causa foi o tratamento incorreto de um erro não fatal que o próprio software já havia detectado e sinalizado.
Releia a frase, porque ela desmonta a intuição comum. O erro foi visto. Ele só não foi levado a ninguém.
O detalhe seguinte é pior. Em 35% das falhas catastróficas, o trecho de código que deveria tratar o erro caía em três padrões triviais, entre eles estar vazio ou conter apenas uma linha de log. Log que ninguém lê é silêncio com carimbo de data. Os autores calculam ainda que um teste simples do próprio tratamento de erro teria apanhado 58% dessas falhas catastróficas.
O estudo é de 2014 e trata de software de infraestrutura, não da sua integração de pedidos. A lógica é a mesma sempre que alguém precisa decidir o que o programa faz quando o outro lado não responde, e esse alguém não é quem vai sentir a consequência.
O que na sua operação tem data de validade?
Mais coisas do que estão anotadas em algum lugar com dono. Certificado digital, chave de API, token de acesso, senha de serviço, contrato de fornecedor e o cartão que paga a assinatura da ferramenta.
No Brasil, o certificado ICP-Brasil do tipo A1 vale um ano e o A3 vai de um a cinco, segundo o ITI. Uma data por ano, em uma única linha do inventário.
O certificado que sustenta a ligação técnica entre dois sistemas encolheu mais rápido. O CA/Browser Forum, onde emissores de certificado e fabricantes de navegador definem essas regras, aprovou em 11 de abril de 2025 a redução progressiva do prazo, com 25 votos a favor, nenhum contra e 5 abstenções entre os emissores, e 4 a zero entre os navegadores. Pela tabela de datas do documento normativo, o máximo caiu de 398 para 200 dias em 15 de março de 2026, vai para 100 dias em 15 de março de 2027 e para 47 dias em 15 de março de 2029.
Uma tarefa por ano virou duas, depois quase quatro, e em 2029 serão perto de oito. No mesmo período o lembrete foi desligado. A Let's Encrypt encerrou o serviço de aviso de vencimento por e-mail em 4 de junho de 2025, citando, entre outros motivos, que muitos assinantes já automatizaram a renovação.
O argumento está certo para quem automatizou. Para quem dependia daquele e-mail, o alarme saiu do ar nove meses antes de a frequência da tarefa dobrar.
Quanto tempo o relatório continua contando um ganho que já parou?
Até alguém conferir a execução, e essa conferência não está no calendário de ninguém. O caso de negócio da automação foi aprovado com uma conta de horas por execução vezes execuções por mês, e essa conta continua rodando na planilha depois que a rotina morreu.
A distorção é dupla. O ganho segue reportado no número cheio e o retrabalho manual que voltou aparece diluído na folha, sem nome próprio. Isso é raciocínio sobre a mecânica do indicador, não medição de campo, e é uma das razões pelas quais o retorno de uma automação precisa ser medido no fluxo, não na estimativa de aprovação.
Vale um exemplo, e ele é uma hipótese: os números abaixo são ilustrativos e não descrevem nenhum cliente. Uma distribuidora com faturamento acima de R$ 200 mil por mês liga o portal de pedidos ao ERP: o pedido entra no portal e uma rotina cria o pedido correspondente no ERP a cada quinze minutos. O fornecedor do portal muda o formato de um campo de data. A rotina passa a falhar apenas nos pedidos com entrega agendada e continua funcionando em todo o resto.
Ninguém percebe. A queda de volume cabe dentro da variação normal do mês, e a equipe resolve o problema no nível dela: volta a digitar aqueles pedidos à mão, porque é mais rápido que abrir chamado. A automação está morta em uma fatia do fluxo, o relatório mostra o ganho inteiro e o time absorveu a diferença sem contar a ninguém.
Repare no formato dessa falha. A parada total vira reclamação em horas. A falha parcial cabe dentro da variação normal e sobrevive meses.
O que faz a operação avisar quando algo para?
Quatro decisões, todas anteriores à escolha de qualquer ferramenta.
A primeira é o sinal de vida. A rotina precisa registrar que rodou, e não apenas gritar quando falha, porque a rotina que morreu não grita. Se o registro de execução não chega dentro da janela esperada, isso é o alarme. Ausência de notícia vira notícia.
A segunda é a conferência das duas pontas. Quantos pedidos saíram do portal e quantos entraram no ERP no mesmo período. Essa comparação não depende de o erro ter sido tratado corretamente lá dentro, e é ela que pega a falha parcial do exemplo acima.
A terceira é o inventário de vencimentos com dono. Uma lista de cada ligação, com o que vence, quando vence e quem responde por ela. Enquanto a data morar na caixa de e-mail de quem configurou a integração, ela sai da empresa junto com a pessoa. É o mesmo hábito que sustenta documentar e versionar automações, aplicado ao prazo de validade.
A quarta é o destino do erro. Todo erro precisa de um endereço humano e de uma ação esperada, senão ele volta a ser uma linha de log. Definir isso é decidir quem é chamado, em quanto tempo e o que essa pessoa tem alçada para fazer, e a falta dessa definição é uma das falhas que mais comprometem integrações de sistemas internos.
Nenhuma das quatro é compra de software de monitoramento. Monitorar servidor responde se a máquina está de pé. A pergunta do negócio é outra: o pedido chegou do outro lado. Nenhuma ferramenta responde isso sem que alguém tenha definido antes o que deveria ter chegado. A UniTrust, IMO de seguros dos EUA, gerencia apólices, agentes e comissões desde 2022 e a Reatop registra resíduos hospitalares em campo, com uso offline e sincronização posterior. Em operações assim, o desenho começa pela mesma pergunta: como o sistema prova que o registro chegou.
Perguntas frequentes
A implementação disso não vai consumir tempo demais do meu time?
Três das quatro decisões são desenho, não construção. Definir quem recebe o erro, o que precisa bater entre as duas pontas e quem responde por cada vencimento é trabalho de reunião. A parte que vira código são dois itens, o registro de execução e a contagem comparada, e nenhum dos dois exige mexer na lógica da integração que já está de pé.
Como eu meço o resultado de um alarme, se ele só serve para avisar que algo parou?
Com dois números que a sua operação já consegue contar. O tempo entre a parada e a descoberta, e quantas ocorrências foram descobertas pelo sistema em vez de pelo cliente. Se o segundo número não melhora depois da mudança, o desenho está errado, e essa também é uma resposta útil.
Isso não é só mais um painel que ninguém vai olhar?
Seria, se a saída fosse um painel. Painel depende de alguém lembrar de abrir, e a falha silenciosa acontece justamente quando ninguém lembrou. O que muda a operação é o caminho inverso: a divergência procura uma pessoa nomeada, com prazo e alçada para agir.
O próximo passo
Se você não sabe dizer hoje quantas ligações a sua operação tem e qual delas avisa quando para, o Diagnóstico de Arquitetura Operacional é uma conversa de 30 minutos para mapear isso. Fale com um arquiteto.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico