Server down: cosa fare nei primi 60 minuti per limitare i danni

Sono le 9:15 di lunedì mattina. Un cliente ti scrive: "il sito non si apre". Apri il browser, confermi. Il server non risponde. Hai 60 minuti per trasformare il panico in una risoluzione ordinata.

Questa guida è il playbook che usiamo noi stessi quando riceviamo un alert di downtime. Non è teoria: è la sequenza esatta che seguiamo su centinaia di sistemi in produzione.

Se sospetti una compromissione o attività malevola, questa guida non basta: passa subito a Incident response: cosa fare nella prima ora di un server compromesso. Se invece vuoi supporto operativo immediato, c'è la pagina SOS.

Minuto 0-5: Conferma e triage

Prima di tutto: conferma che il problema esiste davvero e circoscrivilo.

• Ping il server: ping -c 5 IP_SERVER - se risponde, il server è acceso ma il servizio web è giù. Se non risponde, il problema è più grave (rete, hardware, o crash del kernel).
• Prova la console: accedi via SSH. Se SSH risponde, hai un punto d'ingresso. Se non risponde, prova la console KVM/IPMI del provider.
• Controlla da un altro punto: usa un servizio come check-host.net o ping.pe per escludere problemi della tua rete locale.

Minuto 5-15: Diagnosi rapida

Se hai accesso SSH, questi comandi ti danno il quadro in 2 minuti:

# Carico e uptime
uptime

# Disco pieno? (causa #1 di crash silenziosi)
df -h

# RAM e swap
free -h

# Processi che consumano più CPU/RAM
ps aux --sort=-%cpu | head -10

# Il web server è in esecuzione?
systemctl status nginx    # o apache2, httpd, lsws
systemctl status mysql    # o mariadb, postgresql

# Ultimi errori nei log
journalctl -u nginx --since "1 hour ago" --no-pager | tail -30
tail -50 /var/log/syslog

Le 5 cause più comuni

1. Disco pieno al 100% - MySQL non parte, i log non scrivono, tutto si blocca. Soluzione: libera spazio nei log (journalctl --vacuum-size=100M) o in /tmp.
2. OOM Killer ha ucciso MySQL/Apache - Cerca in dmesg | grep -i "killed process". Il kernel ha terminato il processo per mancanza di RAM.
3. Web server crashato - systemctl start nginx e guarda se riparte. Se no, controlla i log: spesso è un errore di configurazione.
4. Certificato SSL scaduto - Il sito "non si apre" perché il browser blocca la connessione. echo | openssl s_client -connect dominio:443 2>/dev/null | openssl x509 -noout -dates.
5. Aggiornamento automatico andato male - Un apt upgrade notturno ha rotto una dipendenza. Controlla /var/log/apt/history.log.

Se il downtime si ripete con pattern uguali, il problema non è più "server down" ma mancanza di monitoraggio, capacity planning o hardening. In quel caso hanno più senso le pagine Monitoring e Server Management.

Minuto 15-30: Azione

A questo punto sai qual è il problema. Agisci in base alla causa:

Disco pieno

# Trova i file più grandi
du -sh /var/log/* | sort -rh | head -10

# Ruota i log
logrotate -f /etc/logrotate.conf

# Svuota log vecchi di mail/access
truncate -s 0 /var/log/mail.log

Servizio crashato

# Riavvia il servizio
systemctl start nginx
systemctl start mysql

# Verifica che sia effettivamente attivo
systemctl is-active nginx mysql

OOM (memoria esaurita)

# Chi sta usando tutta la RAM?
ps aux --sort=-%mem | head -10

# Riavvia il servizio critico
systemctl restart mysql
systemctl restart php8.2-fpm  # o la versione PHP in uso

Minuto 30-45: Verifica e stabilizzazione

Il servizio è ripartito. Ora verifica:

• Il sito risponde? curl -sI https://dominio.com | head -5 - devi vedere HTTP/2 200
• Il database è integro? mysqlcheck --all-databases per un check rapido
• I cron funzionano? Verifica che WordPress cron e backup notturni non si siano fermati
• Monitoring attivo? Se hai Uptime Kuma, Hetrixtools, o simili, verifica che il check sia tornato verde

Minuto 45-60: Comunicazione e prevenzione

Comunica al cliente

Scrivi un messaggio sintetico:

"Il sito è tornato online alle [ora]. La causa era [X]. Abbiamo risolto con [Y]. Stiamo monitorando per assicurarci che non si ripresenti."

Non nascondere il problema. I clienti preferiscono trasparenza a scuse vaghe.

Previeni la prossima volta

• Monitoring: se non hai monitoring, è il momento di metterlo. Un check HTTP ogni 60 secondi avvisa prima del cliente.
• Alert disco: configura un alert quando il disco supera l'80%
• Log rotation: assicurati che logrotate funzioni davvero (logrotate -d /etc/logrotate.conf per debug)
• Backup testato: se hai dovuto ripristinare, il backup era funzionante? Se no, questo è il momento di sistemarlo

Quando chiamare rinforzi

Se dopo 30 minuti di diagnosi:

• Non riesci ad accedere al server in nessun modo
• Il problema si ripresenta entro minuti dal fix
• Sospetti una compromissione (processi sconosciuti, file modificati)
• Il server gestisce dati sensibili e hai bisogno di certezze

Allora serve un sistemista con esperienza specifica. Non è una sconfitta: è gestione del rischio.

Checklist riassuntiva

• [ ] Conferma il downtime da più punti
• [ ] Accedi via SSH (o console KVM se SSH non risponde)
• [ ] Controlla disco, RAM, processi, log
• [ ] Identifica la causa root
• [ ] Risolvi con il fix meno invasivo possibile
• [ ] Verifica che il servizio sia stabile
• [ ] Comunica al cliente con trasparenza
• [ ] Implementa monitoring e alert per il futuro

La differenza tra chi gestisce un downtime bene e chi lo gestisce male non è la competenza tecnica. È avere un playbook pronto prima che il problema arrivi.