Che cosa guardare e dove guardare per la manutenzione ordinaria sul server

Manutenzione ordinaria: l’obiettivo non è “guardare tutto”, ma vedere prima i segnali che cambiano

Su un server la manutenzione ordinaria serve a intercettare degrado, saturazione e anomalie prima che diventino incidente. Il punto non è aprire console a caso: bisogna sapere cosa osservare, dove si trova l’evidenza e qual è la soglia che cambia il comportamento. Se fai questo con disciplina, riduci i falsi allarmi e arrivi ai problemi veri con più contesto.

Il criterio pratico è semplice: controlli rapidi e ripetibili, sempre nello stesso ordine, partendo dai livelli che impattano più utenti e più in fretta. In generale: stato host, spazio e I/O, servizi, log, rete, applicazione, backup, aggiornamenti. Se un punto è fuori soglia, non serve proseguire in modo cieco: prima si conferma il segnale, poi si interviene.

Da dove partire: i controlli che hanno più valore in meno tempo

Il primo giro non dovrebbe superare pochi minuti. L’obiettivo è capire se il server è sano, degradato o già in errore. I segnali più utili sono quelli che raccontano saturazione o indisponibilità, non quelli cosmetici.

• Carico CPU e memoria: serve capire se il nodo è sotto pressione o se sta entrando in swap.
• Disco: spazio libero, inode, latenza I/O, filesystem in sola lettura.
• Servizi critici: web server, PHP-FPM, database, mail, DNS, agent di monitoraggio.
• Log recenti: errori ripetuti, restart, timeout, OOM, problemi di certificati, permessi, autenticazione.
• Rete: connettività verso gateway, DNS, backend, storage remoto, repository aggiornamenti.

Se hai un pannello hosting o un sistema di monitoraggio, usa prima quello per vedere trend e allarmi. Se hai solo shell, i comandi base bastano per una fotografia attendibile.

Controlli host: CPU, RAM, load e swap

La CPU alta da sola non è sempre un problema; conta se è persistente e se coincide con latenze o errori. La memoria va letta insieme a swap e cache: un server Linux può usare molta RAM in cache senza essere in crisi, ma se la swap cresce e le prestazioni calano, il rischio è reale.

uptime
free -h
vmstat 1 5
top -b -n 1 | head -n 30

Cosa guardare:

• load average: utile solo se confrontato con il numero di core e con la CPU reale.
• used/swap: se swap cresce e non rientra, spesso c’è pressione memoria o leak.
• si/so in vmstat: attività di swap in/out indica stress.
• wa: attesa I/O alta, tipica di disco lento o storage remoto degradato.

Se trovi un valore anomalo, il passo successivo non è riavviare a caso: verifica quale processo sta consumando risorse e se il consumo è coerente con il carico atteso.

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head
ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%mem | head

Se il problema è OOM o memoria che sale senza motivo, cerca nei log di kernel e systemd.

journalctl -k --since "24 hours ago" | grep -iE "oom|killed process|out of memory"
journalctl --since "24 hours ago" | grep -iE "memory|oom|segfault"

Disco e filesystem: la causa più banale e più sottovalutata

Molti incidenti nascono da spazio disco quasi finito, inode esauriti o filesystem che degrada. Qui la regola è: controllare non solo la percentuale, ma anche la crescita e la directory che esplode.

df -hT
df -ih
lsblk
mount | column -t

Se una partizione è oltre soglia, individua rapidamente le directory più pesanti.

du -xhd1 / | sort -h
find /var/log -type f -printf '%s %p
' | sort -n | tail -n 20

Segnali da non ignorare:

• 100% su / o /var: può fermare log, database, coda mail e aggiornamenti.
• inode esauriti: il disco sembra libero ma non si possono creare file.
• filesystem read-only: spesso c’è stato errore I/O o corruzione.
• log che crescono troppo: rotazione o applicazione in loop di errore.

Se c’è un filesystem in sola lettura o errori I/O nel kernel, non forzare interventi distruttivi senza prima raccogliere evidenza e pianificare un rollback. In quel caso la priorità è preservare i dati e capire se il problema è hardware, storage remoto o filesystem.

Servizi systemd: lo stato non basta, serve capire perché non sta bene

Un servizio può risultare “active” ma essere degradato, restartare in loop o fallire su dipendenze esterne. Per questo la sola riga di stato non basta: va letta insieme a log e restart count.

systemctl --failed
systemctl status nginx php-fpm mariadb --no-pager
systemctl list-units --type=service --state=running

Se un servizio è flapping, guarda gli ultimi eventi.

journalctl -u nginx -n 100 --no-pager
journalctl -u php-fpm -n 100 --no-pager
journalctl -u mariadb -n 100 --no-pager

Le cose da cercare sono ripetizioni, timeout, crash, permessi negati, file mancanti, certificati scaduti, errori di binding sulla porta, dipendenze non disponibili. Se il servizio web risponde ma l’app no, spesso il problema è a monte: PHP-FPM, database, cache, permessi, socket o configurazione virtual host.

Log: il posto giusto per capire se il guasto è nuovo o ricorrente

I log servono a distinguere un’anomalia isolata da una regressione già vista. La manutenzione ordinaria dovrebbe includere almeno una lettura dei log recenti dei componenti critici e dei messaggi del kernel.

Tipicamente controlli:

• web server: errori 502/504, upstream down, timeout, header invalidi.
• PHP-FPM: pool saturati, slowlog, max children, crash.
• database: connessioni negate, deadlock, query lente, recovery.
• mail: code bloccate, rimbalzi, auth fallita, TLS, DNS.
• kernel: OOM, disk error, NIC reset, segfault.

Comandi utili per una lettura veloce:

journalctl -p err..alert --since "24 hours ago"
journalctl --since "24 hours ago" | grep -iE "error|fail|timeout|denied|killed|segfault"

Se usi file log classici, il percorso dipende dallo stack, ma i punti tipici sono /var/log/, i log del vhost, i log del database e i log applicativi. La regola è non fermarsi al primo errore: verifica frequenza, orario, servizio coinvolto e se coincide con deploy, backup o rotazione log.

Rete e reachability: il server è vivo, ma parla con chi deve?

Molti problemi “server giù” sono in realtà problemi di rete, DNS o routing. La manutenzione ordinaria deve includere una verifica di base della connettività verso gateway, resolver DNS, storage remoto e servizi esterni essenziali.

ip a
ip r
ping -c 3 gateway
ping -c 3 1.1.1.1
resolvectl status 2>/dev/null || cat /etc/resolv.conf

Se il server usa servizi esterni o backend interni, verifica anche la reachability verso quei target. Un DNS rotto può sembrare un down applicativo; un backend non raggiungibile può sembrare un problema web; un firewall o una regola WAF può far sparire il servizio solo da certe reti.

Se c’è un bilanciatore o una CDN, controlla anche che l’origin sia healthy e che i certificati siano validi. Un certificato scaduto o una catena errata genera sintomi che a prima vista sembrano un guasto generico del sito.

Applicazione e stack LAMP/LEMP: dove si nascondono i problemi intermittenti

Se il server ospita un sito o un’app, la manutenzione deve guardare anche i componenti dello stack. Qui i problemi più comuni sono saturazione dei worker, query lente, cache non funzionanti, errori di configurazione e dipendenze esterne.

Checklist pratica:

• web server: numero di worker, error log, uptime, reload recenti.
• PHP-FPM: pool saturati, child esauriti, slow requests, opcache.
• database: connessioni, slow query log, spazio dati, replica.
• cache: Redis/Memcached, hit rate, memoria, eviction.
• cron: job bloccati o sovrapposti.

Se l’app è lenta ma il server sembra sano, misura il punto di degrado. Ad esempio TTFB, error rate e p95 latency sono più utili di un “sembra lento”.

curl -o /dev/null -s -w "TTFB:%{time_starttransfer} Total:%{time_total} HTTP:%{http_code}
" https://example.com/

Se la risposta è lenta solo in certe ore, il problema può essere un job schedulato, un backup, un reindex, o un picco di traffico. Se la risposta è lenta sempre, cerca saturazione costante o colli di bottiglia strutturali.

Backup: non basta che esistano, devono essere ripristinabili

La manutenzione ordinaria non si limita a verificare che il job sia partito. Un backup utile è un backup che puoi ripristinare. Il controllo minimo è vedere esito, retention e una prova di restore periodica su ambiente isolato.

Controlli minimi:

• ultimo run: successo o fallimento, durata, dimensione.
• retention: non deve cancellare tutto troppo presto.
• integrità: checksum, archivio leggibile, snapshot consistente.
• restore test: almeno campione di file o database su host separato.

Se usi snapshot di VM o storage, verifica che siano coerenti con il tipo di carico. Un backup “green” ma mai testato è una falsa sicurezza.

Aggiornamenti e sicurezza operativa: ridurre il rischio senza rompere il servizio

Gli aggiornamenti ordinari servono a chiudere vulnerabilità e correggere bug, ma vanno trattati come change. Prima di aggiornare, controlla dipendenze, finestra, rollback e compatibilità del servizio.

Verifiche utili:

• pacchetti in attesa e changelog delle componenti critiche.
• certificati: scadenza, rinnovo automatico, chain corretta.
• permessi e ownership: file di config, chiavi, directory di runtime.
• esposizione servizi: porte aperte solo dove servono.
• secret handling: niente credenziali in chiaro in file o ticket.

Un controllo semplice ma utile è verificare la scadenza dei certificati e la presenza di servizi esposti che non dovrebbero esserlo. Per il resto, meglio un update pianificato che una patch fatta in urgenza senza rollback.

Come distinguere manutenzione normale da pre-incidente

La parte più importante è capire quando un segnale è ancora rumoroso e quando sta diventando incidente. Alcuni pattern ricorrenti meritano attenzione immediata: crescita costante di load, swap che non rientra, disco che scende ogni giorno, log pieni di errori ripetuti, restart automatici, code in aumento, latenza in peggioramento.

Se un valore cambia sempre nella stessa direzione per più controlli consecutivi, non è più rumore: è trend.

Per questo conviene annotare ogni controllo importante con data, valore e azione fatta. Anche una nota breve è sufficiente: “disco /var al 72%, log nginx in crescita, nessun errore kernel, prossimo controllo domani”. Questa disciplina riduce il tempo perso a ricostruire il contesto quando qualcosa va male.

Una routine pratica da usare ogni settimana

Una routine minima e sostenibile vale più di controlli sporadici e lunghi. Per un server singolo o un piccolo parco macchine, una cadenza settimanale può includere:

1. Verifica stato host: CPU, RAM, swap, load.
2. Verifica disco: spazio, inode, errori filesystem.
3. Verifica servizi: systemd, restart, log recenti.
4. Verifica rete: DNS, reachability, certificati.
5. Verifica applicazione: error rate, TTFB, query lente, code.
6. Verifica backup: ultimo run e test di restore a campione.
7. Verifica update: pacchetti, patch di sicurezza, reboot pending.

Se il server è critico, aggiungi trend e alerting: non basta sapere che oggi è verde, devi sapere se sta peggiorando da tre giorni.

Regola finale: ogni controllo deve produrre una decisione

Il valore della manutenzione ordinaria sta nel fatto che ogni controllo porta a una decisione concreta: ok, monitorare; attenzione, programmare intervento; oppure intervenire subito. Se un controllo non cambia mai nulla, probabilmente è troppo generico. Se invece ti aiuta a capire dove agire e in che ordine, allora sta facendo il suo lavoro.

La pratica migliore è mantenere una checklist fissa, adattata al tuo stack, con soglie, percorsi log e comandi già pronti. Così la manutenzione non diventa un rito, ma un processo tecnico ripetibile.

Assunzione: il server è Linux recente con servizi gestiti da systemd e stack web tipico; se usi pannelli o ambienti diversi, mappa gli stessi controlli sui rispettivi log, metriche e schermate di stato.