Servidor caiu? Checklist de 10 passos para diagnosticar antes de entrar em pânico
O servidor parou e a empresa parou junto. Antes de reiniciar tudo no susto, siga este checklist de diagnóstico em ordem e descubra a causa raiz.
Quando um servidor cai, o relógio começa a correr e a pressão sobe. A tentação é reiniciar tudo no susto — mas isso muitas vezes apaga a evidência do que causou o problema e você fica refém de uma falha que vai voltar. O caminho profissional é diagnosticar em ordem. Siga este checklist.
1. Confirme o escopo: o que exatamente caiu?
Antes de mexer em qualquer coisa, responda: caiu o servidor inteiro, um serviço específico (banco, web, e-mail) ou só o acesso a ele? Um site fora do ar pode ser DNS, e não o servidor. Delimitar o problema economiza horas.
2. Você consegue pingar o servidor?
ping 192.168.1.10- Responde: o servidor está ligado e na rede — o problema é em um serviço ou aplicação.
- Não responde: pode ser rede, energia ou o servidor travado/desligado. Vá para o passo 3.
3. É energia ou hardware?
Verifique fisicamente (ou via iDRAC/iLO/IPMI, se houver): o servidor está ligado? LEDs de erro acesos? Fontes redundantes funcionando? Um nobreak que falhou silenciosamente é uma causa clássica e subestimada.
4. É rede?
Se outros dispositivos no mesmo switch também caíram, o problema é de rede, não do servidor. Cheque o switch, o cabo e a porta. Um loop de rede ou um switch superaquecido derruba tudo o que está nele.
5. Acesse o console (não só o SSH/RDP)
Se o SSH ou o RDP não responde, use o console fora-de-banda (iLO/iDRAC/IPMI ou o console do hypervisor). Ele te mostra a tela real da máquina — inclusive uma tela de erro de boot ou um sistema de arquivos em modo somente leitura que o acesso remoto jamais revelaria.
6. Disco cheio: o assassino silencioso
Em servidores Linux, disco 100% cheio derruba serviços de forma misteriosa.
df -hOlhe especialmente /, /var (logs!) e a partição do banco de dados. Logs descontrolados são a causa nº 1 de “disco cheio”.
7. Memória e CPU
free -h
topUm processo consumindo 100% de CPU ou a memória esgotada (com o OOM killer matando serviços) explica muita “queda” que não é queda — é exaustão de recurso.
8. Leia os logs ANTES de reiniciar
Esta é a etapa que separa o reparo do “puxão de tomada”. No Linux:
journalctl -xe --since "30 min ago"
tail -n 100 /var/log/syslogNo Windows, abra o Visualizador de Eventos (Sistema e Aplicativos). Os minutos que antecedem a queda quase sempre contêm a resposta.
9. O serviço específico está rodando?
systemctl status nginx
systemctl status mysqlSe o servidor está de pé mas o serviço caiu, reiniciar só o serviço (e ler por que ele caiu) é melhor do que reiniciar a máquina toda.
10. Só então, reinicie — com um plano
Se nada acima resolveu e o reboot é inevitável, faça-o sabendo o que vai verificar quando a máquina voltar. E documente: o que aconteceu, o que você viu nos logs e o que fez. Isso transforma um incidente em conhecimento.
A diferença entre uma equipe amadora e uma profissional não é a velocidade do reboot — é a capacidade de dizer por que o servidor caiu e garantir que não cairá de novo pelo mesmo motivo.
Prevenção vale mais que diagnóstico
A maioria das quedas dá sinais antes: disco enchendo, memória subindo, temperatura aumentando. Monitoramento proativo (com alertas) transforma uma queda das 3h da manhã em um aviso tranquilo às 15h da tarde anterior.