Manutenzione preventiva delle applicazioni PHP: la checklist mensile per una PMI
Le applicazioni in produzione hanno una caratteristica insidiosa: si degradano in silenzio. Non c'è un allarme che suona quando una dipendenza accumula una vulnerabilità nota, quando un certificato si avvicina alla scadenza, quando un disco si riempie lentamente o quando un backup ha smesso di funzionare settimane fa senza che nessuno se ne accorgesse. Tutto sembra a posto, finché un giorno non lo è più, e di solito quel giorno arriva nel momento peggiore. La filosofia del "se funziona non si tocca", che molte PMI applicano per risparmiare, è in realtà la strategia più costosa che esista, perché trasforma una serie di piccoli interventi pianificabili in un unico grande incidente non pianificato. La manutenzione preventiva è il lavoro poco visibile che evita quell'incidente, e la sua forza sta nell'essere una routine ripetibile invece che una reazione all'emergenza. Ecco la checklist mensile che applico alle applicazioni PHP che gestisco, organizzata per aree, con il senso di ciascun controllo e non solo il controllo.
Perché "se funziona non si tocca" è la strategia più cara
Vale la pena capire il meccanismo, perché è controintuitivo. Un'applicazione che non viene toccata non resta ferma: il mondo intorno a lei si muove. Le sue dipendenze accumulano vulnerabilità man mano che ne vengono scoperte; la versione di PHP su cui gira si avvicina alla fine del supporto di sicurezza; i dati crescono e le query rallentano; i log si gonfiano e mangiano il disco. È entropia: il sistema tende al disordine se nessuno spende energia per mantenerlo in ordine. Non toccare nulla non congela lo stato, lo lascia degradare.
Il calcolo economico è impietoso. La manutenzione preventiva costa qualche ora al mese, pianificata, a freddo, senza pressione. L'incidente costa molto di più, e non solo in ore: costa il downtime mentre l'azienda è ferma, costa il recupero d'emergenza fatto di corsa e quindi peggio, costa la perdita di fiducia dei clienti, e nel caso di un data breach costa anche la notifica alle autorità e le possibili sanzioni. Pagare poco e regolarmente è quasi sempre più economico che pagare tanto e all'improvviso, ed è esattamente questo il valore che un'azienda compra con la manutenzione preventiva.
La manutenzione preventiva è come la revisione dell'auto: nessuno la fa perché è divertente, la si fa perché restare a piedi in autostrada costa molto di più. La differenza è che un'applicazione non ti avvisa con una spia accesa, si limita a rompersi.
1. Audit delle dipendenze e dei CVE
Il primo controllo riguarda le dipendenze, perché sono la superficie d'attacco che cresce da sola. Ogni mese verifico se i pacchetti in composer.json hanno vulnerabilità note, con composer audit, che confronta le versioni installate contro il database degli advisory di sicurezza. Una vulnerabilità in una libreria che usi è una porta aperta nel tuo codice anche se il tuo codice è perfetto, e queste vulnerabilità emergono di continuo, quindi un audit fatto sei mesi fa non dice nulla su oggi. Insieme controllo i pacchetti abbandonati, quelli che non riceveranno mai più una patch, perché sono debito di sicurezza latente, e i pacchetti molto indietro rispetto alle versioni correnti, che prima o poi andranno aggiornati.
Questo controllo l'ho reso così frequente che ho costruito uno strumento per farlo a colpo d'occhio: nel mio sito metto a disposizione un audit di sicurezza per Composer che analizza un file di dipendenze e segnala i problemi noti. L'audit delle dipendenze non è un lavoro una tantum, è un controllo periodico, perché il rischio non sta fermo.
Se gestisci applicazioni PHP in produzione e vuoi impostare una manutenzione preventiva seria invece di rincorrere le emergenze, nel mio profilo professionale trovi l'esperienza concreta sulla gestione e l'hardening di applicazioni e infrastrutture per le PMI.
2. Patch di sicurezza del runtime e del sistema operativo
Il secondo controllo è sul runtime. Una versione di PHP arriva a fine supporto a una data precisa, e da quel momento non riceve più patch di sicurezza: continuare a girarci sopra è correre con vulnerabilità del linguaggio non più corrette. Il calendario va tenuto d'occhio sulle versioni supportate ufficiali di PHP, perché le date si avvicinano in fretta: PHP 8.2, per esempio, chiude il supporto di sicurezza alla fine del 2026, e una PMI che ci gira sopra dovrebbe già avere in calendario la migrazione. Lo stesso vale per il framework (le major di Laravel e Symfony hanno le loro finestre di supporto) e per il sistema operativo, dove le patch di sicurezza vanno applicate man mano che escono, non accumulate. La manutenzione qui non significa aggiornare sempre all'ultima versione il giorno dell'uscita, significa non restare su versioni fuori supporto, che è una cosa diversa e non negoziabile.
3. Verifica dei backup, e soprattutto del ripristino
Questo è il controllo che salva la vita, ed è quello che vedo trascurato più spesso. Avere un backup non serve a niente se non sai che funziona, e l'unico modo per saperlo è provare a ripristinarlo. Un backup che gira ogni notte ma che non è mai stato testato è una scommessa, e troppe aziende scoprono che il backup era corrotto, incompleto o non ripristinabile proprio nel momento in cui ne avevano disperatamente bisogno. Ogni mese verifico non solo che il backup sia stato eseguito, ma che un ripristino di prova vada a buon fine, e che i tempi di ripristino siano compatibili con quanto l'azienda può permettersi di stare ferma.
Questo lega la manutenzione a due numeri che ogni PMI dovrebbe conoscere: quanto può perdere di dati (l'intervallo tra due backup) e quanto può stare ferma (il tempo di ripristino). Se non li hai mai definiti, è il momento di farlo, ed è parte del ragionamento più ampio sul perché un piano di disaster recovery è strategico per un'azienda. Un backup non verificato non è una rete di sicurezza, è l'illusione di averne una.
4. Rotazione e revisione dei log
I log sono utili e pericolosi insieme. Utili perché sono la prima fonte per capire cosa sta succedendo a un'applicazione; pericolosi perché, se non ruotati, crescono fino a riempire il disco e mandare giù tutto. Il controllo mensile ha due facce. La prima è operativa: verificare che la rotazione dei log funzioni, che i file vecchi vengano compressi e archiviati e che non ci sia un log dimenticato che cresce senza limiti. La seconda è di sicurezza: dare una lettura ai log per intercettare i segnali deboli, errori ricorrenti che indicano un problema latente, tentativi di accesso anomali, picchi di richieste sospette. Molti incidenti di sicurezza lasciano tracce nei log molto prima di diventare visibili altrove, e una revisione periodica è il modo per coglierli quando costa poco rispondere.
5. Performance e baseline: cogliere il degrado prima che diventi disservizio
Le prestazioni di un'applicazione raramente crollano di colpo: di solito peggiorano lentamente, man mano che i dati crescono e che piccole inefficienze si accumulano. Il problema è che, senza un riferimento, questo degrado è invisibile, perché ci si abitua a tempi di risposta sempre un po' peggiori. La manutenzione qui consiste nel tenere una baseline: i tempi di risposta tipici, le query più lente, il tasso di errore in condizioni normali. Confrontare i valori del mese con quelli del mese precedente fa emergere il degrado mentre è ancora gestibile, prima che diventi un disservizio percepito dai clienti. È il genere di sorveglianza per cui esistono strumenti di monitoraggio, e che ho descritto parlando di monitoraggio del VPS orientato alla prevenzione del downtime: vedere il problema arrivare è metà del lavoro di evitarlo.
6. Spazio disco, certificati e processi di base
L'ultima area raccoglie i controlli infrastrutturali che, banali come sembrano, causano una quota enorme dei disservizi reali. Lo spazio disco va guardato in tendenza, non solo in valore assoluto: un disco al 60% che cresce di un punto a settimana è un problema con una data di scadenza calcolabile, ed è meglio affrontarlo a freddo. I certificati TLS hanno una scadenza, e un certificato scaduto rende un sito inaccessibile o pieno di avvisi di sicurezza: è uno dei disservizi più comuni e più stupidi, perché del tutto prevedibile. Verifico anche che i processi di base siano vivi e funzionanti: i cron schedulati girano ancora? i worker delle code sono attivi o si sono fermati in silenzio dopo un riavvio? Un worker fermo non lancia errori, semplicemente non lavora, e te ne accorgi quando il lavoro accumulato diventa un problema. Sono controlli da pochi minuti che evitano i disservizi più frustranti, quelli che con cinque minuti di attenzione non sarebbero mai successi.
Automatizzare ciò che si può, presidiare a mano il resto
Una manutenzione preventiva matura non è tutta manuale, e nemmeno tutta automatica: è la combinazione giusta delle due. Alcuni controlli vanno automatizzati perché sono ripetitivi e binari, e affidarli alla memoria umana è garantire che prima o poi salteranno: l'allarme sullo spazio disco oltre una soglia, la notifica della scadenza di un certificato con settimane di anticipo, il controllo che i worker delle code siano vivi, l'esecuzione e la verifica automatica dei backup. Questi sono compiti per la macchina, e una macchina che vigila ventiquattro ore su ventiquattro batte qualunque controllo mensile fatto a mano.
Altri controlli, invece, richiedono giudizio e vanno presidiati da una persona: la lettura dei log per cogliere i segnali deboli, la decisione su quando e come aggiornare una dipendenza che ha una vulnerabilità ma anche un breaking change, la valutazione se un degrado di performance giustifica un intervento ora o può aspettare. La regola che applico è automatizzare tutto ciò che è meccanico e oggettivo, e riservare il tempo umano a ciò che richiede esperienza e contesto. Così la checklist mensile non diventa una lista infinita di verifiche noiose, ma un appuntamento in cui una persona guarda le cose che contano davvero, mentre la macchina ha già filtrato e segnalato il resto. Documentare questa divisione, in un semplice runbook scritto, è ciò che rende la manutenzione delegabile e ripetibile invece che dipendente da una singola persona che "sa come funziona".
Ogni quanto va fatta la manutenzione preventiva?
La cadenza giusta per la maggior parte di questi controlli è mensile, con due eccezioni che richiedono più reattività: le patch di sicurezza critiche, che si applicano appena escono, e il monitoraggio continuo di spazio disco, certificati e processi, che dovrebbe essere automatizzato con allarmi invece che affidato a un controllo manuale. Il principio chiave è trasformare la manutenzione da reazione a routine pianificata: un appuntamento fisso in calendario, con una checklist scritta, eseguito sempre e non solo quando "c'è tempo". È proprio quando c'è tempo che non lo si fa, e quel rinvio è esattamente ciò che fa accumulare i problemi fino all'incidente. Una checklist ripetibile rende il lavoro indipendente dalla memoria e dalla buona volontà, e lo rende delegabile e verificabile.
La differenza tra un fornitore reattivo e uno proattivo
C'è un motivo per cui insisto su questo tema, ed è una questione di posizionamento oltre che di tecnica. Il fornitore IT reattivo, il "cugino che sa di computer", interviene quando qualcosa si rompe: è economico finché non succede nulla, e diventa carissimo nel momento dell'emergenza, perché lavora sotto pressione, di corsa, su un problema già esploso. Il professionista proattivo lavora perché l'emergenza non accada, e il suo valore è precisamente nelle cose che non succedono: il sito che non va giù, i dati che non si perdono, la vulnerabilità chiusa prima di essere sfruttata. È un valore meno visibile, perché un incidente evitato non fa notizia, ma è quello che separa un'infrastruttura che si può dimenticare da una che tiene sveglie le persone.
Tirando le somme, la manutenzione preventiva di un'applicazione PHP non è un costo, è un'assicurazione che si paga in piccole rate invece che in un unico premio catastrofico. La routine mensile (audit delle dipendenze, patch del runtime e dell'OS, verifica dei backup e del ripristino, rotazione e lettura dei log, controllo delle performance contro una baseline, e i controlli infrastrutturali di disco, certificati e processi) è il lavoro poco visibile che tiene un sistema in salute mentre intorno tutto cambia. Nessuno di questi controlli è difficile preso da solo; la difficoltà sta nel farli con costanza, ed è per questo che la forma giusta è una checklist ripetibile in calendario, non la buona intenzione di "controllare ogni tanto". Se gestisci applicazioni PHP in produzione e ti accorgi di intervenire solo quando qualcosa si rompe, contattami per una consulenza diretta: nella mia esperienza, impostare una manutenzione preventiva seria è uno degli investimenti con il ritorno più alto e meno appariscente che una PMI possa fare sulla propria infrastruttura.