Um cliente operava um sistema desenvolvido por nós, hospedado em um data center, para rotinas essenciais como baixa de estoque. Em determinados dias da semana, sempre por volta das oito horas da noite, o acesso ficava instável. O usuário iniciava uma operação, a conexão falhava e ele precisava refazer o trabalho.

Do nosso lado, o primeiro movimento foi proteger o trabalho das pessoas. Implementamos salvamento automático para que nenhuma informação preenchida se perdesse. Mas uma dúvida continuou em aberto: a origem da intermitência estava no sistema ou em algum lugar fora dele?

1. Proteger o usuário enquanto se investiga a causa

O autosalvamento resolveu o sintoma imediato: ninguém mais perdia uma operação quase concluída. Era uma melhoria legítima e necessária. Porém, tratar o sintoma não respondia à pergunta principal, e conviver com uma intermitência recorrente não era aceitável para uma operação que dependia do sistema todos os dias.

A decisão foi investigar a fundo, em um pente fino, sem presumir culpado. Essa postura importa: quando cada fornecedor assume que o problema é do outro, o cliente fica sozinho no meio. Preferimos o caminho oposto, sentar à mesa com os outros parceiros do cliente e procurar a causa juntos.

2. O problema tinha hora marcada

Entramos em contato com a operadora de internet do cliente, que na época fornecia o link por rádio, e não por cabo. Em uma investigação conjunta, confirmamos o padrão: a partir das oito da noite, em determinados dias, havia de fato uma intermitência na conexão.

Havia um detalhe revelador. O cliente conseguia acessar sites de notícia sem grandes dificuldades, mas o nosso sistema sofria muito mais. A explicação estava na sensibilidade de cada aplicação: páginas com buffer toleram pequenas quedas sem que ninguém perceba, enquanto um sistema transacional sente cada interrupção. E o próprio autosalvamento, ao tentar gravar os dados durante os momentos de instabilidade, acabava ampliando a percepção do problema.

Restava a pergunta central: por que o dia inteiro funcionava e, a partir das oito da noite, não?

Um problema com hora marcada quase sempre tem uma causa com hora marcada. A investigação precisa seguir o relógio, não apenas o código.

3. A resposta estava no caminho do sinal

Trabalhando junto com o fornecedor de internet, mapeamos o trajeto do sinal entre o ponto onde o cliente estava e a próxima antena. No meio desse caminho havia um parque de diversões. A partir das oito da noite, um dos brinquedos entrava em funcionamento e cruzava exatamente a linha entre as duas antenas, interrompendo o enlace de rádio.

Era uma causa que nenhum teste de software encontraria. Nenhum log de aplicação, nenhuma análise de código e nenhuma auditoria de infraestrutura revelariam um brinquedo de parque de diversões atravessando um feixe de rádio. Só a parceria entre quem desenvolvia o sistema e quem operava a rede permitiu enxergar o cenário completo.

O que a parceria revelou

A intermitência não era do sistema nem exatamente da operadora. Era física: um obstáculo móvel bloqueava o sinal de rádio em horários previsíveis.

4. Duas soluções, em duas frentes

Com a causa identificada, atuamos em paralelo. No sistema, desenvolvemos um cache local: as informações passaram a ser gravadas automaticamente no próprio equipamento e enviadas de uma vez quando o sinal estava estável. A intermitência deixou de interromper o trabalho, mesmo quando acontecia.

Na infraestrutura, junto com a operadora de internet, as antenas foram reposicionadas para sair do circuito obstruído pelo parque. A causa física do problema deixou de existir no trajeto do cliente.

Cada frente protegia a outra. O cache local tornava a operação resiliente a qualquer instabilidade futura, e o reposicionamento das antenas removia a instabilidade que motivou a mudança. Nenhuma das duas empresas teria chegado a essa solução completa sozinha.

5. O resultado de ninguém ter empurrado o problema

O desfecho foi o melhor possível: o cliente não cancelou o sistema, não cancelou a operadora e voltou a operar sem interrupções. Três partes continuaram trabalhando juntas, com mais confiança do que antes do problema.

Esse caso resume um princípio que orienta nosso trabalho: parceria não é apenas com o cliente, mas com o ecossistema de fornecedores que sustenta a operação dele. Quando todos investigam juntos em vez de se proteger, o problema vira um caso de sucesso.

Parceria é uma prática de engenharia

Teríamos razões para encerrar o assunto no autosalvamento: o sistema estava protegido e a causa não era nossa. Mas software não existe isolado do mundo. Ele depende de redes, antenas, fornecedores e até de um parque de diversões que ninguém imaginava relevante.

O sucesso do cliente é o nosso sucesso não como frase de efeito, mas como método de trabalho. Significa assumir o problema até o fim, convocar os parceiros certos e entregar uma solução que resiste à realidade, não apenas aos testes.