Sì, Inps avrebbe potuto evitare, tecnicamente, il disastro epocale del sito, sovraccaricato di richieste per il bonus 600 euro e per ore reso inaccessibile. Su Internet, un picco improvviso di richieste non è certo un evento straordinario; e se, come in questo caso, il picco è previsto, non è così difficile farvi fronte. L’esempio classico è quello del Black Friday, che mette a dura prova tutti i siti di e-commerce, e a cascata tutti i servizi che essi utilizzano, dalla mail allo storage; il traffico può essere anche il triplo di quello di un giorno normale. Anche se alcuni siti hanno comunque problemi, nella maggior parte dei casi la piattaforma di e-commerce funziona bene, senza alcun rallentamento. Ma come è possibile?
Come fanno Amazon & C a evitare il collasso dei siti
La risposta è semplice: da diversi anni ormai, proprio per gestire i picchi di richieste (beninteso anche quelli causati da attacchi Ddos, lamentati da Inps), si è sviluppato il modello delle risorse in cloud, che tra i vari vantaggi ha quello di poter distribuire con grande facilità siti e servizi in diverse collocazioni geografiche e su un grande numero di server, numero che può essere facilmente e tempestivamente aumentato o ridotto secondo le necessità. In passato, non si poteva gestire efficientemente il triplo del traffico perché sarebbe stato necessario comprare e pagare per tutto l’anno il triplo dei server per poi usarli un giorno solo; ma con le cosiddette infrastrutture “as a service” è possibile aggiungere capacità anche per un brevissimo periodo e pagare solo quella.
Al giorno d’oggi, praticamente qualunque sito di qualche importanza è gestito in cloud. Tuttavia, per poterlo fare è necessario concepirlo secondo questo modello sin dal principio, e realizzarlo di conseguenza. Il sito va progettato in modo da poter “scalare orizzontalmente”, ossia da poter distribuire gli accessi su un numero qualsiasi di server. Il principio è quello delle casse del supermercato, in cui i clienti in attesa di pagare possono mettersi in coda a una cassa qualsiasi, cercando di equilibrare la lunghezza delle code tra le varie casse, e nei momenti di grande afflusso si aprono ulteriori casse che vengono poi chiuse quando il numero dei clienti scende.
I problemi da affrontare…e le soluzioni
Ci sono indubbiamente problemi da affrontare; il primo è che se le richieste al sito vengono dirette su un server a caso, tutti i server devono disporre esattamente della stessa copia dei dati. Questo è relativamente facile per i dati da leggere, che basta replicare in tempo più o meno reale tra i vari server; è meno facile quando bisogna scrivere nel database, perché per mantenere la coerenza dei dati è necessario che le scritture vengano coordinate in un’unica copia “master”. Ma anche qui, le soluzioni esistono; in molti siti, le scritture sono molto poche rispetto alle letture e si possono mantenere su un singolo sistema dedicato, replicando invece sui vari server copie della base dati in sola lettura; oppure, si possono suddividere sin dal principio le utenze tra i server, come se ci fosse un supermercato dedicato a tutti quelli col cognome che inizia per A, uno per quelli con la B e così via, consentendo in questo modo che ogni supermercato sia piccolo e possa avere una cassa sola.
Insomma, il problema che ha dovuto affrontare l’INPS è tutt’altro che sconosciuto, ed è anzi alla base della moderna progettazione di servizi online. E qui, sinceramente, casca l’asino: evidentemente, chi ha realizzato il sito dell’INPS non è proprio al passo con la tecnologia; oppure, ha posto talmente tanti vincoli di sicurezza e controllo da non sapere come gestirli nel cloud; oppure, il sito dell’INPS è vecchio di parecchi anni e nessuno si è mai posto il problema di aggiornarne la parte infrastrutturale, quella che non si vede.
Quest’ultimo è un comportamento tipico delle aziende in cui la competenza tecnica passa in secondo piano, e in cui quindi gli investimenti vengono concentrati su ciò che il management vede – ad esempio il rifacimento della grafica della home page, o una imperdibile sezione di video-interviste all’amministratore delegato – invece che su ciò che non si vede ma è ben più importante per la funzionalità del servizio offerto ai propri clienti.
Senz’altro un problema che l’INPS non ha invece avuto è quello della scarsità di investimenti; infatti, lo stesso sito ci dice che negli ultimi quindici anni l’ente ha investito in commesse per i sistemi informatici qualcosa come 776 milioni di euro, anche se Inps si è lamentata oggi sul Corriere del taglio recente di 250 milioni di euro.
Non saranno andati tutti nel sito, ma sono comunque una gran bella somma.
E’ dunque evidente che, nonostante la grande spesa, il sito non era stato progettato per poter aumentare rapidamente ed efficientemente le risorse in caso di necessità. Questo ha causato poi, a cascata, i problemi; si sono osservati infatti, nel corso della notte e della mattinata, tentativi di redirigere il traffico verso le piattaforme cloud di alcuni dei grandi fornitori, ma questo non può essere fatto bene se viene fatto così, all’ultimo momento e in emergenza.
Questi tentativi disperati hanno creato più problemi di quanti ne abbiano risolti; anche la clamorosa violazione della privacy riscontrata da moltissimi utenti, che dopo essere in qualche modo riusciti a effettuare il login si sono trovati davanti a dati personali estremamente sensibili di altre persone sconosciute, è probabilmente una conseguenza di qualche meccanismo di cache inserito al volo e malfunzionante.
L’uso di Cdn
Infatti, una tecnica per alleviare il carico di un sito sotto stress, specialmente un sito realizzato “dinamicamente” – ricalcolando ogni volta il contenuto di ogni pagina – in modo non efficiente e anche quando il contenuto stesso è sempre lo stesso, è quella di pre-generare le pagine una volta sola in una cache, in modo da non doverle ricalcolare a ogni accesso. Esistono, e sono comunissimi, servizi di “content delivery network” che permettono di distribuire i contenuti del sito in giro per la rete, inviandoli all’utente da server collocati molto vicino al punto della rete in cui si trova, e scaricando dal relativo carico il sito vero e proprio. Ovviamente però questo può essere fatto in maniera semplice solo per i contenuti e per le pagine uguali per tutti gli utenti; in caso di pagine personalizzate, a meno di accorgimenti appropriati, la cache verrebbe riempita con la pagina di uno specifico utente che poi sarebbe inviata anche a tutti gli altri, creando appunto il problema di cui sopra.
Qui però emergono elementi di ulteriore incompetenza. Infatti, è successo a ogni webmaster di trovarsi in emergenza per un aumento di carico non prevedibile, per un attacco informatico (in realtà non così frequente, ma è sempre una buona scusa da tirar fuori col management per scaricare le responsabilità) o per improvvisa popolarità dei contenuti. Si chiama “effetto Slashdot”, sin da quando, vent’anni fa, la pubblicazione di un link a un sitarello semisconosciuto sul popolarissimo sito Slashdot creava una tale ondata di traffico da renderlo completamente irraggiungibile.
Che cosa avrebbe potuto fare Inps per evitare il collasso
Questo non è il caso dell’INPS, dato che la scadenza del primo aprile era nota sin dal 16 marzo, e c’era comunque il tempo per prepararsi. Possiamo però concedere che, avendo fatto l’errore di non progettare il sito in modo scalabile sin dal principio, due settimane sono troppo poche per rifarlo in tale direzione.
- Esistono però delle alternative; per esempio, si poteva preparare rapidamente un sito separato solo per la presentazione di questa domanda, ottimizzato meglio di quello principale, salvando almeno il resto del sito dal tracollo.
- Oppure, come hanno velocemente fatto in queste settimane tutti i siti della grande distribuzione presi d’assalto per la spesa online, si può inserire davanti al sito un meccanismo di coda ordinata, che tenga gli utenti in attesa scaglionando gli accessi al sito vero e proprio. Queste soluzioni avrebbero tranquillamente potuto essere realizzate in due settimane, senza dover modificare in alcun modo il sito principale.
- Ma c’è ancora un altro approccio che risolve questo genere di problemi in maniera estremamente efficiente, spesso a costo zero: quello organizzativo. Il picco di carico da affrontare è dovuto semplicemente al fatto di avere richiesto la presentazione di una domanda tramite il sito in un momento preciso, a tutti contemporaneamente, perdipiù in esecuzione di una legge che stabilisce che i fondi sono limitati e che quando essi saranno esauriti l’INPS deve smettere di concederli anche a chi ne avrebbe diritto, assumendo implicitamente l’ordine di presentazione della domanda come criterio di priorità.
Sapete come è stata gestita la stessa domanda proprio in questi giorni in Svizzera? Semplice: la si è fatta presentare via email. Nemmeno via PEC, che è una invenzione tutta italiana per soddisfare la nostra attitudine a cavillare e a contestare, se ci fa comodo, anche l’evidenza. Bastava inviare una email e la pratica veniva tranquillamente acquisita, smistata a uno dei dipendenti dell’ente, ed esaudita nel minor tempo possibile, inviando anche la risposta tramite email.
La posta elettronica è infatti un sistema di comunicazione estremamente stabile ed efficiente, capace di gestire senza grossi problemi gli aumenti di carico tramite meccanismi di accodamento previsti nel sistema sin dal principio. Non sarà “cool” come l’ultima app da cellulare… ma funziona molto meglio.
Si potevano immaginare molti altri meccanismi organizzativi che avrebbero evitato l’assalto al sito. Era sufficiente, per esempio, stabilire nella legge un criterio di priorità per le domande diverso dall’ordine di presentazione; anche solo un pubblico sorteggio. Era possibile prevedere che il bonus fosse, almeno per chi aveva delle tasse arretrate da pagare, una compensazione fiscale automatica. Era possibile, come hanno fatto negli Stati Uniti, inviare ai beneficiari una carta di pagamento con l’importo precaricato sopra.
In cocnlusione
Si potevano inventare mille modi più efficienti di gestire la situazione, eliminando il problema alla radice; ma per qualche motivo quando si parla di burocrazia e di procedure pubbliche l’Italia, uno dei paesi più creativi e fantasiosi del mondo, non riesce a produrre altro che una zoppicante trasposizione elettronica delle domande in carta bollata che ci assillano sin dall’Ottocento.
Se qualcosa va imparato da questa vicenda, è proprio questo: che per offrire online servizi pubblici efficienti è necessario prima di tutto cambiare il modo di pensare, e magari affidarsi alla competenza dei nativi digitali; perché anche enormi investimenti sono inutili se sono affidati alle persone sbagliate.
