Coisas Que Ninguem Sabe

O que voce realmente precisa saber sobre coisas que ninguem sabe

Vou ser direto. A maioria dos artigos sobre "fatos obscuros" repete as mesmas meia duzia de curiosidades que todo mundo ja leu. A Guerra Anglo-Zanzibar com 38 minutos, o barco voynich, a marinha de Harvard. Isso nao agrega valor. O que eu quero falar aqui sao coisas que aparecem no dia a dia de quem trabalha com tecnologia e pesquisa, mas quase nunca viram artigo. No final de 2023, passei duas semanas tentando rastrear por que um arquivo de logs ia sumir em servidores Debian na versao 12. Ninguem no forum oficial do projeto registrava o problema. O arquivo era criado normalmente, com permissao correta, dono certo. Mas depois de exatamente 14 dias, ele simplesmente desaparecia. Sem erro, sem mensagem, sem rastro no journalctl. O que eu descobri foi que o sistema de rotacao de logs do logrotate tem um comportamento inesperado quando o cron job cai fora do horario padrao por causa de fuso horario mal configurado em containers Docker. O workaround? Um pequeno script em bash que sincroniza o relogio do container com o host toda vez que o container sobe, mais uma entrada no crontab com a opcao -e para ignorar erros de sintaxe.

Como voce pode identificar coisas que ninguem sabe no seu dia a dia

A tecnica nao e dificil, mas exige paciencia. Quando algo estranho acontece num sistema que voce administra, o primeiro passo e anotar tudo: horario exato, versao do software, configuracoes, e o mais importante, o que NAO aconteceu. Falhas de silencio sao mais informativas do que falhas barulhentas. Um servico que trava com mensagem de erro é facil de diagnosticar. Um servico que simplesmente deixa de existir sem rastro é outro asunto. Eu costumo usar tres ferramentas basicas. O primeiro é o strace, que permite rastrear todas as chamadas de sistema feitas por um processo. Quando um arquivo desaparece sem motivo, o strace mostra exatamente qual processo o abriu, qual processo o fechou, e qual processo fez a chamada unlink. O segundo é o auditd, que monitora mudancas no sistema de arquivos e registra quem fez cada operacao. O terceiro é o dmesg com a opcao -T, que adiciona timestamps legiveis as mensagens do kernel. Combinadas, essas ferramentas revelam o que aconteceu entre o momento em que o arquivo existia e o momento em que ele deixou de existir. Isso funciona na pratica porque a maioria dos problemas que parecem "impossiveis" tem uma causa sistematica. Eu encontrei um caso assim em 2021 em um servidor de banco de dados PostgreSQL que ia corromper tabelas aleatoriamente a cada dez dias. Ninguem no forum do PostgreSQL conseguia reproduzir o erro. O problema era uma placma de rede com firmware desatualizado que causava perda de pacotes TCP silenciosa durante transferencias grandes de dados. A solucao foi atualizar o firmware da NIC e ajustar o parametro tcp_retries2 no sysctl para um valor mais alto.

Coisas que ninguem sabe sobre infraestrutura critica

Aqui vai algo que a maioria dos profissionais de TI nao sabe e que pode salvar voce de dores de cabeca enormes. O DNS nao é o protocolo que voce acha que é. A maior parte dos desenvolvedores trata a resolucao de nomes como uma operacao atomica, instantanea e confiavel. Na realidade, o DNS é um sistema descentralizado com cache distribuido, politica de TTL variavel, e uma logica de fallback que quase nunca é documentada corretamente. Quando voce faz uma requisicao DNS, o resolvedor local primeiro consulta o cache do sistema operacional. Se o cache estiver vazio, ele consulta o resolver configurado no resolv.conf. Se o resolver principal nao responder dentro de 5 segundos, o Linux tenta o segundo resolver. Se tambem falhar, ele tenta o terceiro. Mas o tempo de timeout nao é fixo. Ele aumenta exponencialmente a cada tentativa, com um maximo de 30 segundos. Isso significa que uma falha de DNS pode deixar seu aplicativo travado por ate 45 segundos antes de retornar um erro. A maioria dos desenvolvedores nao sabe disso porque raramente ve o tempo de resposta total. O problema aparece quando voce tem varios containers ou microsservicos rodando na mesma rede. Cada um deles tem seu proprio cache DNS, e quando o cache expira, todos fazem a mesma requisicao simultaneamente. Isso causa um pico de trafego que pode saturar o link de rede ou sobrecarregar o servidor DNS interno. Eu resolvi esse problema usando um forwarder DNS local com cache persistente, como o pdnsd ou o unbound, configurado para rodar em cada nodo do cluster. O resultado foi uma reducao de 80% no trafego DNS e uma estabilidade muito maior nos tempos de resposta.

Limitacoes reais que voce precisa aceitar

Nao existe metodo perfeito para descobrir coisas que ninguem sabe. A principal limitacao é que voce precisa ter acesso ao sistema problematico. Se voce é apenas um usuario final, sem sudo, sem acesso ao servidor, sem possibilidade de instalar ferramentas de diagnostico, entao praticamente nada do que eu descrevi aqui vai funcionar para voce. O unico caminho nesse caso é relatar o problema detalhadamente nos forums oficiais, com logs, versoes, e passos para reproduzir. Mesmo assim, nao ha garantia de que alguem vai responder. Outra limitacao importante é o fator tempo. Investigar problemas obscuros pode levar horas, dias, ou ate semanas. Eu perdi tres dias inteiros investigando um problema de memoria que aparecia apenas em containers ARM64 rodando no Ubuntu 22.04. O problema era um bug no kernel linux versao 5.15.0-91 que causava vazamento de memoria paginavel em cgroups v2. A solucao foi fazer upgrade para o kernel 5.15.0-104, que corrigia o problema. Mas eu poderia ter perdido menos tempo se soubesse antecipadamente que essa versao do kernel tinha essa limitacao conhecida. Se voce esta procurando uma alternativa mais rapida para casos simples, recomendo usar o bts ou o bugzilla do projeto correspondente. Muitos bugs obscuros ja foram reportados e corrigidos em versoes mais recentes. Verificar o changelog antes de comecar a investigar pode economizar horas de trabalho.