Lunedì, ore 8:40. L’applicativo dei servizi demografici non risponde. Allo sportello ci sono già tre persone in fila: una deve ritirare un certificato, una ha appuntamento per la carta d’identità, una è lì per un cambio di residenza. Il responsabile dell’ufficio prende il telefono e chiama l’informatico: “Quando torna su?”.
È una domanda legittima. Ma è la domanda sbagliata, fatta nel momento sbagliato. Quella giusta era un’altra, e andava fatta sei mesi prima: “Quanto tempo possiamo restare fermi? E cosa facciamo nel frattempo?”.
Lavorando con decine di comuni, ho visto questa scena ripetersi con piccole varianti: cambia l’ufficio, cambia l’applicativo, non cambia la convinzione di fondo. La continuità del servizio è un problema dell’ICT. Proviamo a smontarla.
Indice degli argomenti
Perché la continuità operativa nei comuni non è solo ICT
Per chi lavora in un ufficio, il servizio digitale funziona come una lampadina: premi l’interruttore e si accende. Nessuno si chiede da quale centrale arrivi la corrente, finché non salta.
Dietro la “lampadina” di un servizio comunale, però, c’è una catena lunga: il PC dell’operatore, la rete, il server o il data center del fornitore, l’applicativo, il database, le integrazioni con piattaforme nazionali come ANPR, pagoPA e App IO, la connettività, l’alimentazione elettrica. Ogni anello può rompersi. E quando si rompe, il servizio si ferma, a prescindere da chi abbia la colpa.
Delegare tutto all’ICT sembra prudenza: “non è il mio mestiere, se ne occupano i tecnici”. In realtà è una forma di evitamento. L’ICT sa come ripristinare un server, ma non sa quanto costa all’ente un giorno di anagrafe ferma, quali scadenze di legge scattano se il protocollo non registra, quali pratiche non possono aspettare. Queste informazioni le ha solo chi il servizio lo eroga.
Responsabilità della continuità operativa negli enti locali
Diciamolo chiaramente: la continuità operativa non è “compito dell’ICT”. Ma non è nemmeno solo compito del responsabile del servizio. È una responsabilità su tre livelli, e il guaio nasce quando uno dei tre fa finta che non lo riguardi.
Il responsabile del servizio fissa i requisiti
Chi gestisce tributi, anagrafe, protocollo, SUAP o servizi sociali deve saper dire quanto il servizio può restare fermo, quanti dati può permettersi di perdere, quali attività sono critiche e quali possono attendere, come si lavora se il sistema non c’è. Senza queste risposte l’ICT tira a indovinare. E di solito indovina male: o sovradimensiona, spendendo troppo, o sottodimensiona, e lo scopre al primo guasto.
ICT e fornitori trasformano i requisiti in soluzioni
Il compito dell’ICT, interno o esterno, è tradurre quei requisiti in soluzioni: backup, replica, ridondanza, contratti con livelli di servizio adeguati, test periodici di ripristino. E dire con chiarezza quando un requisito costa più di quanto l’ente può spendere.
Il vertice decide rischio e risorse
Sindaco, giunta, segretario, dirigenti: tocca a loro decidere quanto rischio accettare e quante risorse investire. Non è un dettaglio tecnico, è una scelta di governo.
Non è solo buon senso organizzativo. Il D.Lgs. 138/2024, che recepisce la direttiva NIS2, all’articolo 23 chiama in causa direttamente gli organi di amministrazione e direttivi: sono loro ad approvare le misure di gestione del rischio e a risponderne. Va detto con precisione: tra gli enti locali la norma riguarda città metropolitane, comuni sopra i 100.000 abitanti e capoluoghi di regione.
Per la gran parte dei comuni italiani non è un obbligo diretto. Ma è il modello verso cui si muove tutto il sistema, e la logica vale per chiunque: la responsabilità sta in alto e sta nel servizio, non nella sala server.
C’è poi il GDPR, che vale per tutti: l’articolo 32 chiede al titolare del trattamento di garantire la capacità di ripristinare tempestivamente disponibilità e accesso ai dati personali in caso di incidente. Il titolare è l’ente, non il tecnico.
Continuità operativa dei servizi: backup, RTO e RPO
Nessuno chiede al responsabile dei tributi di configurare un sistema di replica. Gli si chiede di capire cinque concetti, quanto basta per fare le domande giuste.
Backup. È una copia dei dati conservata separatamente dall’originale. Detta così sembra banale. La domanda vera è: dove sta la copia, e qualcuno ha mai provato a ripristinarla? Un backup mai testato è una speranza, non una garanzia. E un backup sullo stesso server, o raggiungibile dalla stessa rete, rischia di essere cifrato dal ransomware insieme a tutto il resto.
Retention. È il tempo per cui si conservano le copie. Se un errore o una manomissione vengono scoperti dopo tre settimane e i backup coprono solo gli ultimi sette giorni, si sono conservate solo copie del dato già sbagliato. Qui il responsabile del servizio ha un ruolo preciso, perché conosce i tempi del procedimento e gli obblighi di conservazione.
Disaster recovery. È il piano per riattivare i sistemi dopo un evento grave: incendio, allagamento, attacco informatico, guasto del data center. Non è il backup, è ciò che serve per tornare operativi usando il backup: infrastruttura alternativa, procedure, persone che sanno cosa fare.
RTO, Recovery Time Objective. È il tempo massimo entro cui il servizio deve tornare disponibile. Quattro ore? Due giorni? Una settimana? Dipende dal servizio, ed è il responsabile che deve dirlo.
RPO, Recovery Point Objective. È la quantità massima di dati che si può perdere, misurata in tempo. Un RPO di 24 ore significa accettare di rifare il lavoro di un giorno intero. Per la biblioteca forse va bene. Per il protocollo, che registra atti con valore giuridico, probabilmente no.
Il punto è che RTO e RPO non sono parametri tecnici. Sono decisioni di servizio con un prezzo: più si abbassano, più costa la soluzione. È esattamente il tipo di trade-off che non si può delegare a chi il servizio non lo conosce.
Servizi cloud e continuità operativa nei comuni
C’è una convinzione diffusa: “ora siamo in cloud, quindi il problema è del fornitore”. È vero solo in parte. Il cloud sposta la responsabilità tecnica dell’infrastruttura, non quella del servizio.
Quando un comune usa un applicativo in modalità SaaS, il fornitore garantisce che il sistema giri. Ma cosa garantisce sui dati? Il backup è incluso nel contratto o è un servizio a parte? Con quale retention? I dati sono replicati in un’altra sede? Se il fornitore ha un incidente, entro quanto torna operativo, ed è scritto da qualche parte?
E poi la domanda che pochi fanno: se il contratto finisce, se il fornitore cambia condizioni o viene acquisito, come riprendo i miei dati, in che formato, in quanto tempo? La qualificazione dei servizi cloud da parte dell’Agenzia per la Cybersicurezza Nazionale assicura requisiti minimi di sicurezza e affidabilità, ma non decide al posto dell’ente quali livelli di servizio gli servono. Quello resta un compito di chi compra.
Modalità degradata per la continuità dei servizi comunali
C’è una parte della continuità operativa su cui l’ICT dell’ente non ha alcun potere. Se ANPR, pagoPA o un’altra piattaforma nazionale non rispondono, il Comune non può fare nulla per accelerare il ripristino.
Può però decidere come lavorare nel frattempo. Ed è qui che la tesi di questo articolo diventa più evidente: la modalità degradata è competenza del servizio. Come si registra una richiesta se il sistema non c’è? Quali pratiche si possono raccogliere su carta e caricare dopo? Cosa si dice al cittadino allo sportello e cosa si pubblica sul sito? Chi decide di rimandare gli appuntamenti?
Nessun informatico può scrivere queste procedure al posto dell’ufficio. Può solo aiutare a progettarle. E se a volte Google o Microsoft non vanno, potrebbe essere che qualche disservizio capiti anche a CIE o pagoPA?
Continuità operativa nel procurement ICT
Il momento in cui la continuità operativa si decide davvero non è il giorno del guasto. È il giorno in cui si scrive il capitolato o si rinnova il contratto. Se una garanzia non è scritta, dopo non la si ottiene, oppure la si paga a prezzo di emergenza.
Ecco le domande minime da porre a ogni fornitore di applicativi e servizi, in locale o in cloud:
- Quali RTO e RPO garantite, e sono scritti nel contratto con le relative penali?
- Dove sono conservati i backup, con quale frequenza, per quanto tempo, e sono separati dall’ambiente di produzione?
- Quando avete fatto l’ultimo test di ripristino, e potete documentarlo?
- Esiste un piano di disaster recovery su un sito diverso, e cosa copre?
- In caso di incidente, chi ci avvisa, entro quanto tempo e con quali informazioni?
- A fine contratto, come restituite i dati, in che formato e in quali tempi?
Non serve essere tecnici per fare queste domande. Serve sapere che vanno fatte. E serve che il responsabile del servizio partecipi alla definizione dei requisiti, invece di firmare un capitolato scritto solo dall’ufficio informatico o, peggio, copiato dall’offerta del fornitore.
AI e continuità operativa degli uffici comunali
L’intelligenza artificiale rende questo discorso più urgente, non meno. Ogni volta che un servizio inizia a dipendere da un assistente, da un chatbot, da un sistema di classificazione delle pratiche, si aggiunge un anello alla catena. Spesso un anello esterno, gestito da un fornitore che a sua volta dipende dal modello di un terzo soggetto.
Chi introduce l’AI in un ufficio dovrebbe chiedersi subito: se domani questo strumento non risponde, l’ufficio sa ancora lavorare? Le competenze per fare a mano ciò che oggi fa la macchina sono ancora in casa? È la versione aggiornata della modalità degradata, con un rischio nuovo: non solo il sistema che si ferma, ma le persone che hanno disimparato a farne a meno.
Allo stesso tempo l’AI può essere un alleato: aiutare a mappare processi e dipendenze, leggere i contratti dei fornitori cercando cosa manca, scrivere una prima bozza delle procedure di emergenza. Purché poi qualcuno che conosce il servizio le validi.
Dalla delega ICT alla continuità dei servizi
Finché la continuità operativa sarà raccontata come “roba da informatici”, resterà un costo da tagliare e una delega da scaricare. Va ribaltata la prospettiva: non è l’ICT che garantisce il servizio, è il servizio che sa cosa gli serve, e l’ICT che lo rende possibile.
Ecco un esercizio concreto, da fare in ogni ufficio entro fine anno. Prendete i tre applicativi da cui il vostro lavoro dipende di più. Per ciascuno rispondete a tre domande: quanto tempo possiamo stare fermi, quanti dati possiamo permetterci di perdere, cosa facciamo se domani mattina non funziona. Poi portate le risposte all’ufficio informatico e al fornitore, e confrontatele con quello che c’è scritto nel contratto.
Molti scopriranno che la distanza tra ciò che serve e ciò che è garantito è ampia. È una scoperta che è molto meglio fare oggi, a tavolino, che un lunedì mattina alle 8:40 con tre o trenta o trecento persone in fila allo sportello.
Partecipa alla community