1 Não validar antes de mexer em disco, partições e permissões

Um dos jeitos mais rápidos de quebrar um sistema é assumir que “funciona assim” e sair alterando
partições, montagens e permissões sem checar o estado atual. Em Linux, o impacto pode ser imediato.

• Editar fstab sem entender UUIDs e opções de montagem. Um erro vira boot em loop ou filesystem inconsistente.
• Rodar comandos destrutivos sem checar o alvo. Ex.: confundir /dev/sdX, usar o comando certo no dispositivo errado.
• Permissões no “chute”. Você até consegue “resolver”, mas abre caminho para acessos indevidos e efeitos colaterais.

2 Ignorar logs e assumir que “deu certo”

Logs são sua linha de defesa. O que parece “ok” no terminal pode estar falhando silenciosamente em
serviços (systemd), rede, autenticação ou permissões.

• Não checar o status do serviço. Se um daemon falha na inicialização, você precisa do motivo exato.
• Não olhar mensagens do kernel. Problemas de hardware, I/O, drivers e filesystem aparecem em dmesg e journalctl.
• Ignorar rotação e retenção. Quando logs enchem a partição, você perde justamente o que precisa.

# Status do serviço e últimas falhas
sudo systemctl status NOME_DO_SERVICO --no-pager
sudo journalctl -u NOME_DO_SERVICO -n 200 --no-pager

# Erros recentes do kernel
sudo journalctl -k -b -p err --no-pager
dmesg -T | tail -n 80

Sempre que algo “deu errado mas não ficou claro”, a resposta geralmente está nos logs — e você economiza horas usando o comando certo na hora certa.

3 Subir serviços como root e “deixar pra depois”

Rodar tudo como root é um convite a incidente. Mesmo quando “parece funcionar”, você aumenta a superfície
de ataque e dificulta auditoria e governança.

• Aplicações rodando como root sem necessidade. Isso amplia o impacto de vulnerabilidades.
• Sem separar usuário/grupo. Melhor prática: o serviço roda com um usuário dedicado.
• Permissões amplas em diretórios de config e dados. Evite 777, privilégios excessivos e ownership incorreto.

4 Desconsiderar rede, DNS e autenticação (e perder tempo depurando no escuro)

Problemas de rede e autenticação costumam ser interpretados como “bug do serviço”, quando na verdade
é DNS, rota, firewall ou configuração de PAM/SSH.

• Assumir que DNS está certo. O serviço resolve errado e você só descobre tarde.
• Ignorar portas e conectividade. Se a porta não está aberta (ou o firewall bloqueia), não adianta insistir em logs do app.
• Configurar SSH sem conferir impacto. Trocar autenticação ou chaves sem fallback pode te bloquear fora do servidor.

# Verificar resolução DNS (substitua o domínio)
dig +short SEU_DOMINIO

# Testar conectividade TCP para uma porta específica
# (substitua IP/hostname e PORTA)
nc -vz SEU_HOST  PORTA

# Ver portas ouvindo no servidor
sudo ss -lntp

Quando a conectividade falha, o caminho correto é: DNS → rota/ARP → firewall → porta → aplicação. Ignorar essa ordem vira frustração.