Limpar este servidor

Um servidor que fica meses rodando acumula bagunça: downloads de pacotes de que ele não precisa mais, imagens antigas de kernel em /boot, containers Docker parados, caches de build, arquivos de log rotacionados, atualizações de segurança esperando para serem aplicadas e serviços que, aos poucos, foram vazando memória. Nada disso é necessariamente um problema isolado, mas tudo vai se acumulando até o disco encher, uma atualização falhar ou um site ficar mais lento do que deveria.

Limpar este servidor é um botão que faz uma varredura em tudo isso de uma só vez — e uma conversa no chat que confirma qualquer coisa arriscada antes de executar.

O que ele realmente faz

Três categorias, cada uma podendo ser executada separadamente — marque o que quiser e deixe o resto de fora:

• Liberar espaço em disco — limpa o cache de download de pacotes, remove dependências de pacotes removidos, limpa containers Docker parados + imagens pendentes, corta o cache de build do Docker com mais de uma semana, reduz os logs do systemd para os últimos 30 dias, apaga arquivos de log rotacionados (.gz / .1 / .old) com mais de 30 dias e, opcionalmente, remove imagens antigas do kernel / revisões desativadas do snap.
• Instalar atualizações de segurança — atualiza a lista de pacotes e instala a versão mais nova de todos os pacotes instalados (apt update + apt upgrade). Se a atualização incluir um novo kernel, isso vira uma etapa seguinte de "reiniciar quando for conveniente", em vez de algo que simplesmente acontece sem você pedir.
• Reiniciar serviços com vazamento — opcional. Reinicia seus sites + bancos de dados + workers um por um (~10–30s de indisponibilidade cada) para liberar a memória que eles foram acumulando lentamente ao longo das semanas. Medimos o tempo de resposta antes e depois e só dizemos que ficou "mais rápido" se houver evidência real.

Além disso, algumas verificações somente leitura sempre rodam: relatório de pontos de uso intenso do disco (quais diretórios estão consumindo espaço), serviços com falha (qualquer coisa sinalizada pelo systemd), logins SSH recentes (para você identificar acessos desconhecidos), status do Fail2ban e uma verificação de /var/run/reboot-required (o arquivo que uma atualização do kernel cria para sinalizar "você precisa reiniciar").

Como começar

Quatro pontos de entrada, o mesmo modal:

O CTA de Armazenamento é o caminho mais comum — você percebeu que o disco estava enchendo, foi olhar o armazenamento e o botão de limpeza está bem ali.

O modal antes de começar

Clicar em qualquer ponto de entrada abre a mesma lista de verificação. O modal faz duas coisas ao mesmo tempo: mostra exatamente o que está prestes a acontecer e autoriza as etapas seguras para que o chat não perca seu tempo perguntando de novo sobre coisas que você já marcou.

Observe os pontos — eles mostram o que esperar:

• Verde-sálvia (seguro) — roda imediatamente. Sem pergunta no chat, sem confirmação, apenas uma linha de status dizendo que foi feito.
• Pêssego (confirmar no chat) — pausa para um sim/não na conversa antes de executar. Usado para coisas como instalar atualizações que podem reiniciar serviços.
• Rosa (confirmar por item) — lista cada candidato (por exemplo, cada volume Docker órfão) e pergunta um por um. É o nível do "você tem certeza sobre este item específico?".

Cada linha também tem uma expansão "O que isso faz?" com o comando shell exato que vamos executar, para usuários técnicos verificarem que não há surpresa. Usuários não técnicos podem ignorar.

A opção Reiniciar seus workloads após a limpeza na parte inferior do modal é uma decisão separada. Ela reinicia cada site / banco de dados / worker em execução, um de cada vez, com ~10–30 segundos de indisponibilidade cada, mede o tempo de resposta antes e depois e informa a diferença. Deixe desligado se a indisponibilidade agora for pior do que uma memória com leve vazamento; ligue se você já estiver fazendo manutenção.

Suas marcações são lembradas por servidor — na próxima vez que você abrir o modal no mesmo servidor, as mesmas caixas já estarão marcadas. Novas ações adicionadas por atualizações futuras aparecem automaticamente marcadas por padrão quando forem seguras (e desmarcadas nos demais casos).

O que acontece durante a execução

Clique em Iniciar limpeza e o modal fecha. A partir daí, a conversa conduz o processo:

1. Snapshot — um lote rápido de comandos somente leitura captura a imagem do "antes" (disco livre, RAM, tamanho dos logs, atualizações pendentes, serviços com falha, maiores diretórios, logins recentes, Fail2ban). O chat apenas diz "Snapshot concluído, X GB livres, N atualizações pendentes. Iniciando limpeza…" — você não vê uma parede de saída bruta.
2. Etapas seguras rodam automaticamente. apt update, apt clean, journalctl --vacuum, docker system prune, a exclusão de logs rotacionados — tudo isso roda em silêncio, e cada etapa emite uma linha de status. Sem pedidos de aprovação (o modal já autorizou).
3. Etapas de atenção perguntam. Qualquer item com ponto pêssego (apt upgrade, docker system prune -a, remoção de kernel, revisões do snap) faz uma pergunta de uma linha no chat antes de executar. Você diz sim, a ação roda; você diz não, ela é ignorada e a próxima ação segue em frente — a receita não para por causa de uma única recusa.

4. Etapas por item perguntam uma vez por candidato. Se você marcou a remoção de volumes órfãos, Faro lista cada volume pendente e pergunta um por vez, incluindo uma dica de qual imagem costumava montá-lo. "Não para todos" / "parar" / "pular o resto" interrompe os itens restantes.

5. Reinícios opcionais de workloads. Se você ativou a opção, cada site/banco de dados em execução é reiniciado com amostras de tempo de resposta antes e depois.

Se, em algum momento, o kernel for atualizado e uma reinicialização for necessária para realmente usar o novo kernel, a receita não reinicia automaticamente. Ela exibe um card de ação para você resolver depois.

Quando uma reinicialização acontece

Qualquer coisa que derrube a conexão SSH — systemctl reboot, reinício do sshd / dbus / networking — aciona um banner âmbar fixo no topo do chat. O chat pausa sozinho com uma mensagem sintética "Reinicialização solicitada. O chat ficará em silêncio por ~30–60s…"; o envio de mensagens fica desativado enquanto o banner estiver visível.

Nos bastidores, uma sondagem tenta reconectar via SSH a cada poucos segundos usando as credenciais que o Server Manager armazenou quando você se conectou. Quando o servidor responde, o banner fica verde ("Servidor voltou · uptime 8s · retomando monitoramento"), desaparece automaticamente após 5 segundos e o campo de mensagem é reativado. Não é preciso atualizar o navegador.

O resumo e "O que você precisa fazer"

Quando a execução termina, Faro publica uma mensagem final com os ganhos quantificados logo no início e uma tabela de métricas alteradas.

A tabela só inclui linhas em que a ação correspondente realmente rodou E a mudança é diferente de zero — então, se você pulou Docker, não aparece uma linha de Docker. A coluna "Por que isso importa" usa linguagem clara ("Espaço para bancos de dados e uploads", "Vulnerabilidades corrigidas", "Menos disputa por CPU"), não jargão.

Se a reinicialização de um workload gerou uma melhoria mensurável, você também verá uma tabela Tempo de resposta do workload por workload — e só nesse caso. A receita não vai afirmar que "seu site ficou mais rápido" com base em ruído.

Cards de ações seguintes

Qualquer coisa que a limpeza não conseguiu concluir sozinha — uma reinicialização pendente, serviços rodando código de bibliotecas desatualizadas, workloads que você recusou reiniciar, volumes órfãos aos quais você disse não — aparece como uma seção O que você precisa fazer com cards numerados. Cada card oferece duas formas de resolver:

• Opção A — peça para mim aqui — um caminho de chat com um clique. O texto de resposta do callout aparece como um chip clicável acima do campo de mensagem, para você não precisar rolar a tela de volta.
• Opção B — pelo console do seu provedor — instruções específicas do provedor, clique por clique, para fazer a mesma coisa (por exemplo, "DigitalOcean → Droplet → Power → Reboot"). Útil se você preferir fazer de propósito por conta própria.
• Trade-off — uma frase por card explicando quando cada caminho faz mais sentido.

A faixa de chips fixada acima do campo de mensagem espelha esses cards como ações pendentes ☐. Clique em um chip → o texto de resposta dele preenche o campo de mensagem → pressione Enviar. Enquanto Faro trabalha nisso, o chip muda para ⏳ em andamento; quando termina, fica ✓ riscado e some automaticamente após 5 segundos. Cada chip também tem um pequeno botão × para dispensar caso você tenha decidido ignorar aquela ação — essa ocultação persiste pelo restante da sessão do navegador.

Casos comuns de borda

"Nenhum volume órfão encontrado" — a ação por item apenas informa isso e pula. Não é erro; a lista estava vazia.

Reboot-required já estava definido antes da limpeza — comum quando outra pessoa (ou uma execução anterior) instalou atualizações sem reiniciar ainda. A receita verifica /var/run/reboot-required tanto no momento do snapshot quanto depois do apt upgrade. Se o arquivo já existia, o card de ação seguinte "Reiniciar o servidor" aparece mesmo quando esta limpeza não instalou nada novo — ainda assim é a ação correta.

Meus sites ficam atrás de Traefik / nginx / Apache — a receita não mexe na configuração do seu servidor web. Ela reinicia os containers subjacentes (ou unidades systemd) dos sites que consegue identificar no inventário; o proxy continua rodando normalmente. Se o proxy reverso de um workload estiver na frente de containers que o Server Manager não conhece (uma configuração personalizada não gerenciada), ele é ignorado em silêncio — sem URL de sondagem, não há reinício mensurável.

Snap não está instalado neste servidor — a etapa "Remover revisões desativadas do snap" apenas diz "Snap não está instalado — pulando." e continua. Marcá-la em um servidor sem snap não causa problema.

**apt autoremove removeria algo que eu quero manter** — toda etapa de autoremove é precedida por uma simulação que imprime "Would remove: pkg-a, pkg-b, …". Se a lista parecer errada, diga não — a execução real só acontece depois que você confirma.

Eu disse sim a uma etapa e quero voltar atrás no meio do processo — pressionar Esc interrompe o agente. Comandos que já estão rodando não são interrompidos (eles terminam), mas o loop é encerrado. Você pode pedir para Faro revisar depois qualquer coisa que tenha sido pulada.

O chat parece travado durante o reinício de um serviço — qualquer coisa que reinicie sshd, dbus ou a pilha de rede aciona o mesmo banner da reinicialização do servidor (variante de curta duração). Se o banner aparece, o chat está pausado de propósito; se ele não aparece e o chat realmente parece congelado, veja Recuperar quando o SSH para de funcionar.

O relatório final — no que prestar atenção

A mensagem de resumo tem uma estrutura propositalmente consistente para você bater o olho rápido:

1. Título — uma linha em negrito: "🧹 Recuperamos 6,2 GB e aplicamos 14 atualizações de segurança." Esse é o ganho. O número que não mudou não é mencionado.
2. Explicação em uma linha — a maior melhoria específica em linguagem clara (mais disco liberado, segurança corrigida, menos serviços com falha — o que tiver sido mais relevante).
3. Tabela "O que mudou" — Antes / Depois / Mudança / Por que isso importa, uma linha por métrica que realmente mudou. Linhas possíveis: espaço livre em disco (GB e %), inodes livres (%), uso de disco do Docker, tamanho dos logs do sistema, atualizações de segurança pendentes, serviços com falha, memória disponível, carga em segundo plano.
4. Tabela "Tempo de resposta do workload" (somente se você optou pelos reinícios E houve um ganho mensurável) — antes / depois / mudança por workload.
5. Seção "O que você precisa fazer" (somente se houver ações seguintes) — os cards numerados descritos acima.
6. Rodapé "Puladas: …" (somente se você recusou etapas) — a lista de rótulos das ações para você poder executar de novo depois e revisitar.

Se o servidor já estava organizado e não havia nada a fazer, Faro encerra com "Seu servidor já está organizado. Nada a fazer." — sem tabela de resumo inventada, sem relatório enchendo linguiça.

Referência

O que é pré-autorizado e o que ainda pergunta

Armazenamento das suas marcações — sua seleção (e a opção de reiniciar workloads) é salva no localStorage do navegador, associada ao hostname do servidor. Limpar os dados do navegador redefine as marcações para a seleção padrão.

Como funcionam as ações seguintes + o desvio da confirmação de reinicialização — quando a receita de limpeza está ativa, os scripts de snapshot somente leitura da receita e qualquer comando do nível seguro que você marcou no modal desviam do classificador de comandos destrutivos — é isso que evita os prompts duplicados de "Aprovar este comando?". Os níveis de atenção + por item sempre perguntam de novo. O desvio leva o conteúdo em conta (cada segmento de comando é validado contra uma lista de permissões somente leitura), e padrões proibidos como rm -rf / sempre são bloqueados.