Certificati INPS Telematici

queue

“Certificati on line, sistema subito in tilt – Il ministero: “Un guasto, niente sanzioni”

Lunghe e inutili attese al call center, la linea che cade, il tempo perso a tentare di collegarsi e pazienti che pretendono l’invio: medici in rivolta a poche ore dalla partenza del sistema che obbliga alla trasmissione telematica dei “referti”, pena anche il rischio di licenziamento”

Da “Certificati on line, sistema subito in tilt” apparso su Repubblica oggi.

Insomma, dopo mesi di timori, ora il flop del sistema per i certificati digitali dell’INPS è ufficiale e viene ammesso persino dallo stesso Ministero.

Ma com’è possibile che il Governo Italiano, attraverso la sua Pubblica Amministrazione, risulti essere sistematicamente incapace di mettere in piedi un servizio pubblico online di questo genere che funzioni al primo colpo (o persino dopo mesi di sperimentazione, com’è il caso dell’INPS)? Cosa c’è di tanto complicato? Cosa si può imparare da questi errori?

Il precedente del SUI

Come ricorderete, questo dei certificati INPS non è il primo caso di “suicidio” telematico della nostra Pubblica Amministrazione. In precedenza c’era già stato l’irraggiungibile degli irraggiungibili: il famigerato SUI (Software Unico per l’Immigrazione), cioè il sistema che i datori di lavoro (figuriamoci!) avrebbero dovuto usare per chiedere la regolarizzazione dei loro dipendenti extracomunitari.

Il SUI è per sua stessa definizione irraggiungibile ed inutilizzabile: il suo scopo consiste nell’impedire alla quasi totalità degli extracomunitari di presentare una regolare domanda di regolarizzazione, in modo da rendere compatibile la loro marea montante con il patetico flusso di immigrazioni previsto dalla legge (Bossi/Fini… basta il nome…).

Cinicamente, è persino comprensibile che sia così.

Ma che senso ha sabotare i cittadini italiani ed i medici di famiglia attraverso questa storia dei certificati INPS telematici?

L’esempio di Amazon.com

Di siti web costretti a macinare centinaia di milioni di richieste al mese e ad ospitare decine di milioni di utenti al mese ce ne sono ormai parecchi su Internet. Uno dei casi più famosi è www.amazon.com . Se date un’occhiata alle statistiche che lo riguardano, ad esempio su Compete, potrete vedere con i vostri occhi qual’è il livello di traffico prodotto da questo mega-store:

http://siteanalytics.compete.com/amazon.com/

Nei momenti di magra, a Febbraio, quando in giro per il negozio ci sono solo le vecchiette con il cagnetto incappottato, si parla di circa 60.000.000 (sessanta milioni) di visitatori al mese e circa 200.000.000 di pagine visualizzate. In altri termini, quando è un deserto, Amazon accoglie circa 23 persone diverse al secondo e macina qualcosa come 80 pagine al secondo. Questo quando è un deserto. Sotto Natale si parla di oltre 90.000.000 di utenti singoli al mese e quasi 400.000.000 di pagine visitate al mese.

Vi ricordo che in Italia abitano “solo” 60.000.000 di persone, solo 20 delle quali dispongono di una qualche forma di connessione ad Internet (e solo 10 la utilizzano).

Per reggere questo livello di traffico, Amazon usa un’architettura hardware e software degna di una potenza nucleare. Si parla di centinaia di server sparsi in decine di paesi.

Ecco, da sistemi come Amazon.com probabilmente si può imparare qualcosa. Vediamo cosa.

Chi decide cosa

La prima regola d’oro per far funzionare un grosso sistema hardware/software è che a prendere le decisioni critiche sul suo funzionamento deve essere la stessa gente che poi lo dovrà implementare e mantenere.

Con il termine “decisioni critiche” mi riferisco a cose come:

  • Che hardware e che software usare
  • Dove piazzare i server
  • Come collegarli ad Internet
  • Quanta gente dedicare al progetto

Ma anche e soprattutto come gli utenti finali debbano interagire con il sistema.

Se è un “amministrativo” o, peggio del peggio, un Ministro a mettere mano a queste decisioni, il fallimento è praticamente garantito ancora prima di partire.

DDoS auto-inflitto

Sia il SUI che il sistema dell’INPS soffrono dello stesso problema: a causa del modo in cui (per legge) gli utenti devono interagire con questi sistemi, si viene a creare un drammatico DDoS (Distributed Denial of Service) auto-indotto. Vedi:

http://it.wikipedia.org/wiki/DDOS

In buona sostanza: si obbligano gli utenti ad assalire il sistema tutti nello stesso momento, provocandone il collasso.

Questo è quello che succede quando a decidere come gli utenti debbano interagire con un sistema informatico è un Parlamento, un Ministro o comunque un giurista, e non un tecnico.

La corsa dei ratti

Evidentemente, i nostri Ministri ed i loro sottoposti provengono da una tradizione di rapporto con il pubblico che è basata sulla “corsa dei ratti”: si piazza un pezzetto di formaggio all’estremità della pista (di solito un certo ammontare di posti di lavoro disponibili nella Pubblica Amministrazione), poi si aprono le gabbie con i ratti affamati (cioè voi ed io) e ci si gode lo spettacolo di queste povere bestie che corrono all’impazzata per raggiungere per primi l’agognata meta (senza peraltro risparmiarsi ogni sorta di sabotaggio l’uno contro l’altro lungo il percorso).

Probabilmente sotto il dominio austro-ungarico questa soluzione aveva persino un senso. Dopotutto ai tempi di Francesco Giuseppe c’erano i dirigibili ed i treni a vapore.

Oggi, vent’anni dopo la diffusione di massa di Internet, è soltanto un puro e semplice atto di sadismo nei confronti degli utenti e di autolesionismo informatico da parte della PA.

I sistemi commerciali che devono davvero servire i loro utenti, come Amazon, non vengono certo progettati in questo modo.

Se non ci si libera da questa “sindrome dell’allevatore di ratti da corsa”, non si potrà mai superare questo tipo di problemi.

Non è tutto sbagliato

Ad onor del vero, va detto che non tutte le scelte effettuate dalla PA per la gestione di questi sistemi sono sbagliate. Ad esempio, deve essere reso un pubblico riconoscimento alla PA per aver tentato di sgravare i propri server il più possibile di quel carico di lavoro che può essere delegato ai computer degli utenti.

Sia il SUI che altri sistemi della PA sono concepiti in modo tale che l’utente possa compilare i propri moduli sul proprio PC di casa e che sia costretto a parlare con il server solo quando questo è effettivamente necessario, cioè quando deve inviare la domanda.

Si tratta di “cosa buona e giusta, nostro dovere e fonte di salvezza”.

Diluizione nel tempo

In ogni caso, la prima regola che deve rispettare un sistema ad alto traffico è che ciò che può essere diluito nel tempo deve essere diluito nel tempo. Se non c’è una vera ragione tecnica per far succedere due cose nello stesso momento, allora queste due cose devono avvenire in momenti diversi.

Nei sistemi ad alto traffico è normale che ogni singola operazione avvenga separatamente dalle altre. Si può “mettere la roba nel carrello” senza impegnare la cassa ed il sistema che accetta i pagamenti. Si può scrivere un testo senza tenere impegnato il sistema che poi lo dovrà pubblicare. Ogni cosa a suo tempo.

Soprattutto, se non c’è una vera ragione per chiedere agli utenti di partecipare tutti insieme ad un evento, allora ci si limita a prendere atto delle azioni degli utenti quando questi utenti decidono di partecipare, un po’ alla volta. Anzi: si cerca di convincerli a partecipare all’iniziativa a piccoli gruppi, diluiti nel tempo.

Se occorre selezionare n utenti tra un numero molto più grande m, allora si effettua un sorteggio. Assolutamente NON ci si basa mai sul principio “chi primo arriva meglio alloggia” perché questo principio crea immediatamente le condizioni per un massiccio DDoS auto-inflitto.

Diluizione nello spazio

La seconda regola è altrettanto semplice: se è possibile far svolgere due operazioni diverse a due sistemi diversi, magari dislocati in luoghi diversi, è meglio farlo. Più il sistema è decentrato e diversificato, più è resistente e più è disponibile a soddisfare le richieste degli utenti.

Amazon, Google, Facebook ed ogni altro grosso operatore del web hanno server diversi per scopi funzionali diversi e persino server diversi per servire bacini d’utenza geograficamente diversi.

Per esempio, quasi sempre il sistema che permette di navigare all’interno del catalogo dei prodotti è separato da quello che accetta gli ordini e spesso risiede su un server diverso.

In modo simile, il server che serve gli utenti italiani è dislocato in Italia ed è diverso da quello che serve gli utenti tedeschi, dislocato in Germania.

Amazon, per esempio, gestisce almeno una dozzina di gruppi di server (“cluster”), uno per ogni area geografica che viene servita. All’interno di ogni cluster ci sono almeno una mezza dozzina di computer (“server”), ognuno dei quali svolge una funzione diversa.

Visti i risultati di questi giorni, forse è meglio creare una rete di server INPS federati tra loro, uno per ogni regione, provincia o comune, e chiedere agli utenti di usare quello di loro competenza.

Comunicazione asincrona

Infine, se non c’è una vera ragione per fare una telefonata (comunicazione sincrona) allora è meglio spedire un SMS (comunicazione asincrona).

In una comunicazione sincrona, le due parti che comunicano devono essere collegate alla stessa linea nello stesso momento, per cui si vìola il primo principio, quello che impone di non fare due cose nello stesso momento se le si può fare in momenti diversi.

Una comunicazione sincrona, come una telefonata, mantiene impegnata una linea per ogni coppia di utenti. Quando le coppie di utenti sono milioni, questo diventa un problema.

In una comunicazione asincrona, come una lettera, un messaggio e-mail od un SMS, il mittente spedisce il messaggio e poi se ne frega (“fire&forget”). Il destinatario lo leggerà quando avrà tempo e, se del caso, risponderà.

In una comunicazione asincrona non c’è bisogno di mantenere impegnata una risorsa (la linea) per tutto il tempo della comunicazione. Quando le coppie che comunicano sono molte, questo è un grosso vantaggio.

Come ho già detto, va reso pubblico riconoscimento alla PA di aver adottato questa soluzione per alcuni dei suoi servizi, anche se questa soluzione, da sola, non può risolvere tutti i problemi.

Solo Windows?!!!

Molti sistemi della PA italiana impongono ancora ai loro utenti di usare degli specifici programmi, di solito questi:

  1. Microsoft Windows, magari in una specifica versione.
  2. Microsoft Office
  3. Microsoft Internet Explorer

Non ci vuole una laurea per capire che questo obbligo produce inevitabilmente una lunga serie di problemi a molti utenti (“Non ho la versione giusta di Widows”, “Non mi funziona Explorer”, “Non riesco a leggere il documento”, etc.).

Esistono da circa vent’anni diverse tecnologie per permettono di far girare lo stesso programma su quasi qualunque tipo di computer:

  1. Java
  2. Nokia Qt
  3. wxWidgets
  4. GTK++
  5. e molte altre…

Nello stesso modo, esistono formati di file standardizzati (de jure e de facto), che possono (anzi: DEVONO, per legge) essere fruibili da tutti, come ODF:

http://it.wikipedia.org/wiki/OpenDocument

Infine, non esiste NESSUNA ragione al mondo per rendere un sito web PUBBLICO accessibile solo con un browser web proprietario come MS Internet Explorer.

Nessun sito commerciale, come Amazon, impone ai suoi utenti di usare questo o quel browser.

Una maggiore attenzione a questo aspetto sarebbe segno di civiltà, di indipendenza dai fornitori (Microsoft) e di trasparenza e renderebbe molte cose molto più semplici a molte persone.

Qualche piccolo consiglio

A questo punto, possiamo elencare qualche piccolo consiglio che può tornare utile a tutti coloro che si trovano a gestire sistemi informatici soggetti a livelli di traffico molto elevati.

  1. Inchiavardare le porte della “stanza dei bottoni” e tenere fuori gli amministrativi. Le decisioni tecniche devono essere prese dai tecnici, senza interferenze esterne.
  2. Eliminare le deadline. Se gli utenti possono presentare le domande nell’arco di un anno, usare tutto l’anno per accettarle, non solo il primo giorno. Per evitare la calca, basta effettuare un sorteggio.
  3. Decentralizzare il sistema, ad esempio creando dei centri di raccolta dati regionali o comunali.
  4. Rendere asincrona la comunicazione. Permettere agli utenti di compilare la loro documentazione sul loro computer (client) e di inoltrarla al server solo quando è conclusa, con una sola operazione.
  5. Non obbligare gli utenti ad usare questo o quel sistema, o questo o quel programma. Rispettare le esigenze di tutti.

Conclusioni

Speriamo che questa situazione di stallo sia passeggera e che la PA riesca davvero a sfruttare le potenzialità offerte dall’informatica. Siamo già indietro di dieci anni rispetto a molti altri paesi e non è proprio il caso di rallentare ancora.

Alessandro Bottoni

 

L’immagine di copertina proviene da qui ed è sotto licenza Creative Commons:

geograph.org.uk/photo/1429992

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: