“Il sito è lentissimo da stamattina.” Così inizia un ticket tipico. Il primo sguardo va al web server, al processo PHP, alla cache. Ma la causa vera spesso sta tutt'altrove – per esempio su un altro server che il cliente non vede mai.
Sintomo e causa sono due posti diversi
Il sintomo è il punto in cui una persona si accorge di un problema. La causa è il punto in cui il problema nasce. In mezzo ci sono spesso più sistemi. Tre schemi tipici dal lavoro quotidiano:
- Il sito è lento – causa: un disco pieno sul server del database. Il database non riesce più a scrivere correttamente, le query si bloccano e il web server aspetta.
- Le mail non arrivano – causa: un certificato scaduto sul relay. Il mail server del mittente funziona; fallisce solo la connessione TLS verso il passaggio successivo.
- Il login fallisce – causa: un orologio indietro di tre minuti. Le procedure basate sul tempo, come i codici TOTP o le asserzioni SAML con finestra di validità, tollerano solo piccole differenze.
In tutti e tre i casi riavviare il servizio interessato sarebbe inutile o aiuterebbe solo per poco. Il ticket forse sarebbe chiuso, il problema no.
Workaround o causa?
I workaround non sono un male. Se un cliente non può lavorare, ripristinare il servizio ha la precedenza. Un riavvio, una cartella svuotata a mano, un'impostazione cambiata temporaneamente – tutto legittimo.
L'importante è chiamarlo con il suo nome: “Questo è un workaround.” Poi arriva la seconda domanda: perché è successo e cosa impedisce che succeda di nuovo? Un workaround chiude il ticket. Solo l'analisi della causa evita il prossimo.
Un metodo semplice
Per cercare la causa non serve un framework complicato. Questi passaggi funzionano bene:
- Delimitare il momento. Da quando esattamente? Un orario trasforma una descrizione vaga in una traccia nei log.
- Chiedere cosa è cambiato. Aggiornamenti, deployment, nuovi record DNS, certificati scaduti, manutenzioni del provider. I sistemi raramente si rompono senza motivo.
- Seguire la catena. Dall'utente attraverso DNS, rete, web server, applicazione e database fino allo storage. A ogni anello verificare: funziona da solo?
- Chiedere più volte “perché?”. Il sito è lento – perché? Il database non risponde – perché? Il disco è pieno – perché? Un log non viene ruotato. È lì che si interviene in modo duraturo.
- Confermare la causa. Un'ipotesi diventa la causa solo quando la correzione elimina davvero il sintomo.
I primi minuti su un server Linux
Molte cause si trovano con pochi comandi standard, prima di andare in profondità:
df -h # spazio su disco
df -i # inode
timedatectl # ora e sincronizzazione NTP
systemctl --failed # servizi falliti
journalctl -p err --since "1 hour ago"
uptime # carico e uptime
Per i certificati di un servizio remoto basta controllare la data di scadenza:
openssl s_client -connect mail.esempio.it:465 -servername mail.esempio.it </dev/null 2>/dev/null \
| openssl x509 -noout -enddate
Non sostituisce un'analisi, ma in due minuti esclude i candidati più frequenti: dischi pieni, ora sbagliata, servizi fermi, certificati scaduti.
Documentare perché non si ripeta
Una buona analisi della causa si chiude con poche frasi chiare: qual era il sintomo, qual era la causa, cosa si è fatto nell'immediato e cosa cambia in modo permanente? Per esempio un monitoraggio del disco, un promemoria prima della scadenza del certificato, una sincronizzazione dell'ora che funziona davvero.
Questa nota aiuta il collega che vedrà lo stesso caso fra tre mesi – e spesso anche noi stessi.
Checklist
- Annotato il momento esatto della prima comparsa?
- Controllate le modifiche nel periodo precedente?
- Verificata tutta la catena, non solo il punto del sintomo?
- Esclusi spazio su disco, ora, servizi e certificati?
- Workaround chiamato come tale?
- Causa confermata dalla correzione?
- Misura permanente e breve documentazione messe per iscritto?
La mezz'ora in più dedicata alla causa sembra un lusso sul momento. Calcolata sulle settimane, è il tempo più conveniente che si possa investire nel supporto.