O telefonema chegou numa quinta-feira. As notas fiscais não estavam saindo.

Não é um problema técnico qualquer — nota que não imprime é mercadoria que não sai. O caminhão fica no pátio, o pedido não fatura, e a cada hora o problema custa mais. É o tipo de chamado que entra na frente de todo o resto.

O que ninguém imaginava é que levaria onze dias para achar a causa. E que ela estaria a três telas de distância de tudo o que foi investigado.

Dia 1: o problema não se comporta como problema

A primeira coisa que se faz é reproduzir. Clica no botão de imprimir, e aí vem o detalhe que mudaria toda a investigação: nada acontece. Nenhuma mensagem de erro. Nenhum aviso. A tela não reclama de nada.

Havia um segundo sistema — o de homologação — rodando a mesma versão, o mesmo código, a mesma configuração. Lá a nota imprimia todo dia, sem falhar. Dois ambientes gêmeos, um funcionando e outro não.

Isso é, ao mesmo tempo, a melhor e a pior notícia possível. A melhor porque dá um ponto de comparação. A pior porque significa que a diferença está escondida em algum lugar que ninguém pensou em olhar.

A semana das hipóteses razoáveis

Começou-se pelo óbvio, como sempre se começa.

A impressora. Havia mesmo uma diferença de configuração entre os dois ambientes. Foi corrigida com alguma esperança. Não resolveu.

O sistema de impressão. Talvez estivesse travado? Não: mais de dezessete mil documentos tinham sido impressos naquela semana, no mesmo sistema. Saudável.

O formulário e o gerador de PDF. Testados nos dois ambientes, resposta idêntica.

A versão do software. Componente por componente, mesma atualização nos dois.

A autorização do usuário. Autorizado nos dois.

Uma semana depois, a lista de coisas descartadas era longa e a lista de suspeitos estava vazia. E cada verificação que dava “igual nos dois” tornava o problema mais estranho, não menos.

O silêncio que ninguém tinha estranhado

A virada de perspectiva veio de uma contagem simples. Cada documento a ser impresso vira um registro com um estado: em preparação, liberado, em processamento, concluído, ou erro.

No ambiente com problema:

• 250 documentos parados em “em preparação”
• 7 em “liberado”
• zero concluídos
• zero em erro

Aquele último número é o achado. Nada tinha falhado. Nada tinha nem tentado.

É por isso que nenhum monitor apitou, nenhum log registrou nada, nenhum alerta disparou. Ferramenta de monitoração encontra falha. Ali não havia falha — havia ausência. E ausência não aciona alarme nenhum.

A descoberta que atrasou tudo

No oitavo dia veio o que parecia ser a resposta. Pulando o caminho normal e mandando o sistema emitir a nota diretamente, ela imprimiu. Quatro segundos, documento na fila, concluído.

A leitura foi imediata e natural: se funciona quando eu chamo direto, o problema está em quem chama. A investigação virou para o programa que dispara a impressão, e chegou a isolar a linha exata onde ele parecia falhar. Tudo batia.

E estava errado.

A chamada direta funcionava justamente porque pulava a peça quebrada, em vez de atravessá-la. O teste que parecia confirmar a hipótese era, na verdade, a prova de que a hipótese olhava para o lugar errado — só que lido ao contrário.

Foram mais dois dias nessa direção. É assim que investigação longa custa caro: não no erro grosseiro, mas na teoria coerente que explica tudo o que você vê — e nada do que você não viu.

A pergunta que faltava

No décimo primeiro dia, alguém fez uma pergunta que não era sobre impressão: quantos trabalhos estão na fila esperando para serem executados?

No ambiente de homologação, onde tudo funcionava: zero. Executava na hora.

No ambiente com problema: 109.678.

Cento e nove mil unidades de trabalho paradas, esperando. Cinquenta e seis delas eram as notas fiscais. As outras cento e nove mil e seiscentas eram tudo o mais que aquele sistema deveria estar processando em segundo plano — inclusive uma fila que estava travada havia mais de um mês, sem que ninguém tivesse notado.

Um endereço que não existia

O componente que distribui esses trabalhos precisa de um supervisor para funcionar. Esse supervisor tem um endereço de conexão configurado — e naquele sistema o endereço apontava para um ambiente que não existia ali.

Era um número de mandante válido em outro sistema da paisagem, provavelmente copiado numa configuração antiga. No ambiente de homologação aquele mandante existe de verdade — e é exatamente por isso que lá tudo sempre funcionou.

Sem supervisor válido, o distribuidor de trabalho não distribui nada. Os documentos eram preparados, liberados, e ficavam esperando alguém que nunca viria. Sem erro, porque não houve falha.

Onze dias de investigação para um campo com o número errado.

O que este caso ensina

Sistema “no ar” não é sistema trabalhando. Aquele ambiente passava em qualquer verificação de disponibilidade. Estava ligado, respondia, tinha usuários conectados. E havia semanas que não executava uma parte do trabalho.

Zero erros não é boa notícia — é uma pergunta. Quando um processo deveria produzir resultado e não produz nem sucesso nem falha, o defeito raramente está no processo. Está em quem deveria pegá-lo e não pegou.

“Funciona quando faço manualmente” é pista de que o problema está na automação, não na tarefa. Neste caso foi lido ao contrário, e custou dias.

Comparar dois ambientes é a ferramenta mais forte que existe — desde que se compare a coisa certa. Comparar configuração funcionou. Comparar tamanho de programa não, porque o número que parece ser o tamanho do código é, na verdade, o tamanho dele comprimido.

O limite honesto

Onze dias é muito, e a maior parte foi gasta em hipóteses razoáveis e erradas. Não dá para prometer que a próxima investigação será curta — sintoma silencioso é caro por natureza, porque não deixa rastro.

O que dá para mudar é a ordem das perguntas. Antes de investigar o processo, confirme que a infraestrutura que o executa está viva — a fila, quem a distribui, para onde ela aponta. São quatro verificações de dez minutos que, aqui, teriam economizado dez dias.

Por que este é um caso de diagnóstico, e não de suporte

Repare no que estava acontecendo ao lado do problema que abriu o chamado. A nota fiscal era 56 de 109.678 unidades paradas — menos de 0,1%. Todo o resto também não estava sendo processado, e ninguém tinha aberto chamado sobre nada disso.

Essa é a diferença entre suporte e diagnóstico. Suporte responde ao que dói. Diagnóstico olha o ambiente inteiro e encontra o que está quebrado antes de doer — a fila que acumula, o processo que não roda, a configuração que aponta para lugar nenhum. Nada disso gera alarme, porque nada disso é um erro.

O sintoma que gerou o telefonema foi o único que alguém percebeu. Não foi o único que existia.

Se você suspeita que há coisas paradas no seu ambiente que ninguém notou, é exatamente isso que o diagnóstico de TI procura. E se o padrão de “cada dia falha de um jeito novo” soa familiar, o caminho é a investigação dirigida, não o chute.