Browsed by
Tag: downtime

Eventi straordinari e siti istituzionali: un rapporto (ancora) tormentato.

Eventi straordinari e siti istituzionali: un rapporto (ancora) tormentato.

Anni fa ho scritto questo articolo (in un momento di frustrazione causata dalla puntuale indisponibilità dei siti istituzionali nei momenti di loro maggiore utilità), nella speranza quantomeno di aprire una linea di dialogo. Ero stato fortunato e questa si era aperta, ma il tutto era stato impacchettato e rispedito al mittente senza troppi complimenti.

Il problema in breve: sono molti i siti informativi, soprattutto in ambito Pubblica Amministrazione, “inutili” e poco visitati per il 99.9% del tempo, che però diventano critici in momenti di particolare interesse. Immaginate ad esempio il censimento della popolazione: ha cadenza decennale e dura due mesi. Durante questa finestra di tempo ogni cittadino userà l’apposito servizio online, ovviamente aspettandosi che tutto funzioni a dovere.

Altro esempio è il portale del Ministero dell’Istruzione: basso carico per gran parte dell’anno, ma quando vengono annunciate le commissioni di maturità, deve essere funzionante, pronto e scattante. Pensate poi al sito dove vengono pubblicati i risultati delle elezioni: utilizzato ogni quattro o cinque anni, diventa il più visitato d’Italia durante le poche ore di scrutinio.

Internet oggi è la fonte primaria di informazione per molte persone: è un dato di fatto che non si può ignorare, ed è necessario dare adeguata importanza alle piattaforme che contribuiscono a questa informazione.

Ne parlavo nel 2011, perchè è stato l’anno in cui i tre servizi sopracitati hanno mancato il loro obiettivo primario: quando servivano, non funzionavano. Se ne era parlato, soprattutto tra gli addetti ai lavori: ci eravamo arrabbiati, ma qualcuno aveva commentato che le soluzioni al problema (che spaziano da questioni molto tecniche come lo sharding dei database e l’elasticità delle infrastrutture a questioni più di buon senso, come una corretta previsione dei carichi) erano molto distanti dal mondo dei “comuni mortali”, e ancor di più dal settore pubblico.

Un punto di vista secondo me contestabile, ma quasi sicuramente con un fondo di verità: al tempo il concetto di “cloud” esisteva da pochi anni, e alcuni vendor dubitavano ancora delle sue potenzialità.

Sembra di parlare della preistoria.

(per non dimenticare: il load balancing manuale delle Elezioni 2011)

Adesso siamo nel 2017: sono passati sei anni dal mio articolo e come alcuni continuano a ripetere, “cloud is the new normal”. Il cloud è la nuova normalità, tutti lo usano, lo scetticismo, se mai c’è stato, è sparito: il tempo ha ormai provato che è una nuova e rivoluzionaria tecnologia e non solo un trend temporaneo o una pazzia di un singolo vendor.

In questi anni, nella nostra PA, sarà cambiato qualcosa?

Alcuni segnali fanno ben sperare: Eligendo ad esempio, il portale delle Elezioni, è esposto tramite una CDN (ma non supporta HTTPS). Altri fanno invece perdere la speranza appena guadagnata: questo mese si è tenuto il Referendum per l’Autonomia della Lombardia – serve che vi dica in che stato era il sito ufficiale durante gli scrutini? Timeout.

Le soluzioni a questo tipo di problemi sono ormai ben conosciute e consolidate: caching estremo, utilizzo di CDN, sfruttamento di infrastrutture scalabili, etc. I costi sono molto bassi e granulari: con una architettura ben studiata, si possono servire tutte le richieste senza sprecare un euro. Fa in un certo senso pensare il fatto che in certi ambienti siano ancora presenti e gravi problemi che l’industria ha risolto già da tempo, come quello dei picchi di carico.

Quali sono quindi i fattori limitanti, quindi?

Non stento a credere ci sia una scarsa comprensione del tema e della sua importanza ai “piani alti” di ogni ente: solo di recente siamo riusciti a mettere insieme una community di sviluppatori e un “team digitale” (composto da professionisti di veramente alto rango) volto a svecchiare il “sistema Italia”.

L’iniziativa sta già portando i suoi primi frutti, ma si tratta di un team per ora piccolo molto focalizzato sullo sviluppo e non sulle operations/mantenimento: il passo per il cambiamento della mentalità generale è ancora lungo. Non è difficile immaginare come una scarsa comprensione del tema porti molto velocemente alla mancanza di interesse e di risorse dedicate – con conseguente frustrazione di quelli che sono i “piani inferiori”.

Un secondo fattore spesso portato (o meglio, trascinato) in gioco è la scarsità di infrastrutture: se questo poteva essere vero una volta, oggi, con l’affermazione delle tecnologie cloud e del concetto di “on demand”, questo smette di essere un punto bloccante. Le infrastrutture ci sono, basta sfruttarle.

Ultimo, ma non per importanza, il discorso “competenze”: non stento a credere come molti fanno notare che sia difficile reclutare personale adatto e che chi si occupa oggi di sistemi nella PA abbia ben altre responsabilità e quindi ben altre basi. Ritengo però non si possa ignorare il fatto che al giorno d’oggi il concetto di “as a service” (servizi managed se volete chiamarli con un nome forse più familiare) rimuova buona parte di questo problema, e che l’immensa offerta di training e relativa facilità di sperimentazione renda estremamente facile la coltivazione delle skills mancanti.

Può servire tempo, ma da qualche parte bisognerà pur partire. Molti IT manager e sistemisti sono lì fuori pronti, a fare il passo: hanno solo bisogno di essere ispirati.

Ispiriamoli, no?

Design for failure

Design for failure

“Scusa ma non siamo capaci di offrirti la stabilità di cui hai bisogno, potresti pensarci tu?”

(Anonimo Cloud-Eretico sul Design for Failure)

C’erano una volta… gli sviluppatori, e le applicazioni. Gli sviluppatori si concentravano sul codice, dando per scontata la stabilità e la scalabilità dell’infrastruttura sottostante: usavano query SQL indescrivibili, ed era compito del sistemista farle girare velocemente, scrivevano codice senza gestione delle eccezioni perchè era compito del sistemista far si che quel determinato database server fosse sempre disponibile e non restituisse mai errori. Scrivevano software impossibile da distribuire su più macchine perchè tanto il sysadmin, in qualche modo, avrebbe fatto.

La colpa di ogni rallentamento o malfunzionamento di chi era? Del sistemista. Questo ha portato chi si occupa di infrastrutture a progettare soluzioni sempre più avanzate per far sopravvivere l’applicativo alle più inimmaginabili catastrofi, senza che questo subisse mai malfunzionamenti. Qualunque disgrazia fosse accaduta alle macchine che la servivano, l’applicazione sarebbe dovuta rimanere in piedi e funzionante.

Va detto che ci siamo (quasi) riusciti. Grazie alla virtualizzazione siamo arrivati a creare quello che è a tutti gli effetti hardware indistruttubile: la macchina fisica è diventata virtuale e quella virtuale sappiamo muoverla tra diversi nodi senza spegnerla, al solo costo di qualche millisecondo di freeze.

Abbiamo così creato piattaforme che astraevano quasi completamente la complessità sottostante, usando processori virtuali che restavano disponibili anche se quelli fisici prendevano fuoco e dischi virtuali che continuavano a servire dati anche se l’intero rack di storage veniva rubato dagli alieni.

Questa soluzione non era però ottimale: la replica sincrona, per esempio, era possibile solo in ristretti contesti geografici. Il costo di queste soluzioni era spesso proibitivo, e la loro complessità alta e non necessaria. Queste strutture, per quanto immortali potessero essere, erano sempre sotto la stessa autorità amministrativa. Tutto per non dare agli sviluppatori un compito in più: gestire la disponibilità dell’applicazione.

Screen Shot 2014-01-28 at 20.58.15

(Anonimo Cloud-Eretico che non ha compreso il ‘Design for Failure’)

Poi è arrivata una nuova generazione di developers: sviluppatori che volevano più controllo, volevano poter decidere come l’applicazione avrebbe reagito a malfunzionamenti dell’infrastruttura, e soprattutto si rifiutavano di pagare al fornitore complessi meccanismi di failover perchè… non ne avevano bisogno. Sapevano fare di meglio e sapevano farlo in modo più economico ma soprattutto più effettivo, più semplice.

Questi sviluppatori non chiedevano più a chi vendeva infrastrutture hardware immortale, chiedevano semplicemente del ferro: di qualunque tipo, prestazioni, forma, colore e dimensione, ed in ogni luogo. Si sarebbero occupati loro di inoltrare meno richieste ai processori meno potenti, di tenere in RAM i dati se i dischi della macchina erano troppo lenti. Si sarebbero curati loro di evitare di interrogare un database server che non rispondeva più ai comandi.

Volevano occuparsi, soprattutto, delle azioni di disaster recovery nel caso in cui un intero datacenter fosse andato a fuoco. Perchè nessuno meglio dello sviluppatore può sapere come deve reagire una applicazione a determinati eventi e di cosa questa ha bisogno.

Hanno poi iniziato a chiamarlo ‘Design for Failure’. La disponibilità non è più compito di chi gestisce l’infrastruttura: è l’applicazione ad esser progettata per far fronte a ogni evento o disgrazia, e la struttura sottostante fa solo il sollevamento pesi.

Nel modello ‘Design for Failure’ ognuno fa il suo lavoro: lo sviluppatore conosce l’applicazione e si occupa di farla funzionare, il gestore dell’infrastruttura si occupa delle prestazioni ma non si infila più in infiniti tunnel senza uscita per garantirne la disponibilità. Tutti risparmiano, perchè è tutto più semplice, con meno sovrapposizioni. Tutti vincono: perde solo chi non ha voglia di innovare.

Ecco perchè questo modello non è un fallimento, come tanti lo descrivono: è il futuro.

Censimento OnLine: una odissea.

Censimento OnLine: una odissea.

Avendo un pò di tempo a disposizione (cosa già di per sè incredibile), mi sono messo a compilare il Questionario OnLine del Censimento 2011. Si, quello cartaceo l’ho ricevuto, ma a causa di un madornale errore di compilazione avrei dovuto chiederne una nuova copia e ho deciso, per semplicità, di compilarlo online.

Provo ad accedere al sito, inserisco codice fiscale e password e premo il tasto per iniziare la compilazione, ma dopo 60 secondi di caricamento… Un bell’HTTP 503.

A dire il vero, ero già pronto ad una situazione simile. Ieri ho aperto il sito, ho letto due cose e poi ho fatto un controllo veloce (inclinazione professionale): nessuna traccia di load balancer o di sistemi di caching. Era prevedibile quindi che tutto sarebbe stato inutilizzabile durante il picco di richieste, che sarebbe avvenuto, sempre ad occhio, per oggi, giorno del lancio ufficiale.

Insomma, sito lentissimo o down: impossibile compilare il questionario, per ora. Ok, mi rassegno, smetto di riprovare, ci penserò nei prossimi giorni. Ma non è la prima volta che succede una cosa simile (anzi, potrei dire che è successa ogni volta in cui ho avuto bisogno di usare un sito legato alla Pubblica Amministrazione), e sinceramente sono abbastanza stanco di questo.

A memoria:

  • Elezioni 2011: inizia lo scrutinio e il sito su cui vengono pubblicati i risultati inizia a caricare in modo lentissimo, e a tratti cade. Tutto questo aggiunto al ridicolo sistema di “load balancing manuale” studiato per l’occasione (probabilmente per supplire al ridicolo down delle Elezioni 2008).
  • Pubblicazione Commissioni Maturità 2011: sito web inutilizzabile per 24 ore, con continui errori e timeout.

Per dirla in altre parole, siti che, quando servono, sono inutilizzabili. Completamente, inutilizzabili. Con una aggravante: tutti, a maggior ragione chi se ne occupa, sapevano benissimo quando sarebbero serviti.

Noi che lavoriamo in questo settore sappiamo che  una adeguata, perfetta previsione del carico di lavoro è la base per la messa online di una struttura simile.

Noi che lavoriamo in questo settore, sappiamo che le soluzioni per reggere il forte carico di un sistema che probabilmente non necessita neanche di un DB centralizzato, se non per qualche elemento*, non sono poi così complesse.

Noi che lavoriamo in questo settore sappiamo che c’è la possibilità di avere n-mila server e di pagarli solo per il tempo in cui li si è usati. Sappiamo anche che questo ABBATTE i costi, e apre la strada a soluzioni prima impensabili.

Soprattutto, noi che lavoriamo in questo settore sappiamo che un errore in uno qualunque di questi punti vuol dire una sola cosa: contratto stracciato da parte del cliente, eventuali penali da pagare e reputazione praticamente rovinata (ci si vende per “persona che ti da una piattaforma stabile per il tuo grosso sito” e poi cade tutto?).

Alla luce di ciò mi chiedo: non è ora di far saltare qualche appalto per la gestione di strutture informatiche, visto che ci sono in giro sistemisti che non ne sbagliano una da anni e ogni volta ci mettono faccia e reputazione?

* Ovviamente, non so come siano stati studiati i database. Ma, con davanti agli occhi i fogli del questionario, posso dire che non c’è alcuna necessità di salvarli in tempo reale tutti nello stesso database, tutti i server devono poter accedere solo ad una tabella che impedisca la doppia compilazione del questionario. Il resto, può essere separato e riunito solo su necessità.

Class-action contro Aruba: la pazzia continua.

Class-action contro Aruba: la pazzia continua.

Solo un veloce aggiornamento sulla vicenda (di cui ho parlato dettagliatamente qui). L’idea di Class-Action contro Aruba da parte del Codacons ha riscosso molto meno successo di quanto pensassi. Immaginavo centinaia di commenti in pochi giorni sul blog dell’Avv. Rienzi (sul quale è stato formalmente richiesto dal Codacons di rilasciare una pre-adesione), invece dopo 5 giorni questi sono appena una sessantina, di cui almeno la metà sono contro l’azione di gruppo nei confronti del colosso dell’hosting o di persone che come me tentano di spiegare, a tempo perso, la situazione.

Così tanto FLOP che da ieri ho iniziato a taggare i miei tweet riguardo la vicenda con il tag #FLOP oltre che #Aruba e #Codacons.

Segnalo l’articolo di Antonio Angelino, che riprende in parte i miei punti del precedente post ed estende il discorso. Per chi fosse interessato ad approfondire un minimo il discorso tecnico o a leggere pareri di professionisti come me, segnalo questo thread su HostingTalk.it.

Sto anche continuando a leggere (e a rispondere) divertito ai commenti dei vari utenti che si lamentano delle perdite milionarie subite a causa del down di 12 ore si un hosting lowcost da 30 € annuali che non offre garanzie da contratto. Inutile commentarli o rispondere a uno a uno, ma nell’insieme emergono alcuni punti interessanti. Non intendo trattarli nel dettaglio (anche perchè un professionista del settore o presunto tale -questo dovrebbe essere il mio target, considerato che non so scrivere in modo umano- dovrebbe capire senza troppe spiegazioni), ma solo elencarli:

  • Nessuno dei clienti che intendono proseguire nell’azione contro Aruba ha letto il contratto prima di sottoscriverlo. Appare ovvio, perchè al suo interno è esplicitamente contemplata la possibilità di danni per incendio e l’impossibilità di offrire rimborsi ai clienti. Più in generale non ci si rende conto che al momento della firma di un contratto per un servizio lowcost, la sostanza dell’accordo tra Provider e Cliente è “Ok Cliente, io ti do un servizio che costa la metà, ma sappi che per abbassare il prezzo devo togliere garanzie, va bene?”.
  • C’è una scarsissima conoscenza del mercato. Anche una nocciolina (fatta eccezione per qualche mia amica l’arachide è la cosa più stupida che conosca), vedendo che esistono pacchetti di hosting da 10 €, da 40 €, da 250 € e da 1500, tenterebbe di informarsi e di capirne le differenze, arrivando così in ben poco tempo a parlare di uptime, garanzie, penali etc.
  • C’è anche una conoscenza tecnica pari a zero. E’ comprensibile ovviamente, ma quello che non è comprensibile è la pari presunzione di esprimere pareri a riguardo. Ci sono persone che parlano di “server di emergenza” senza sapere minimamente cosa significhino la parola failover o la parola sincronizzazione, altri che parlando di “misure di emergenza” che Aruba AVREBBE DOVUTO mettere in atto senza riuscire minimamente a spiegare di cosa si stia parlando.
  • Si nota anche un certo livello di illogicità: c’è chi fatica a capire che anche se ha acquistato 20 pacchetti da 40 €, questi rimangono 20 pacchetti lowcost, o chi tira fuori la solita storia del mancato pagamento del rinnovo causa imprevisto dell’ultimo momento (si, esatto, quello li, quello che ti impedisce di pagare al sessantesimo giorno il dominio, senza che si capisca bene cosa hai fatto per i 59 giorni precedenti).
  • AGGIUNTA: Me l’ero dimenticata ma è di importanza fondamentale. Certi utenti hanno un’idea di “pagamento rateale” abbastanza alterata. Il ragionamento, in sostanza è: “sono dieci anni che pago 30 euro, quindi dovrebbero aggiungere ridondanza”. Bene, svelerò un segreto: no, non funziona così. Pagare 30 euro annuali per 10 anni non obbliga l’azienda ad offrire un servizio da 300 euro annuali.

E molto, molto altro. #FLOP

Giorgio

PS: Non so quale sia la fonte dell’immagine di Aruba in fiamme. Io l’ho presa QUI.

Class-Action contro Aruba: un delirio?

Class-Action contro Aruba: un delirio?

Ieri, Venerdì 29 Aprile 2011, alle 4 di mattina un corto circuito nella sala batterie del sistema UPS della WebFarm di Arezzo del gruppo Aruba ha causato uno spegnimento di tutta la struttura, portando offline i milioni di siti ospitati, caselle email, server dedicati etc. Ne hanno parlato testate autorevoli, come il TGCOM, il Quotidiano Nazionale o il Giornale.

Alle 10.30 è iniziata la rimessa in tensione delle sale. In qualche ora tutti i server erano nuovamente alimentati e i servizi iniziavano a tornare online (discorso diverso chiaramente per le macchine con filesystem corrotti a causa dello spegnimento improvviso). In serata, poi, è arrivato il Comunicato Stampa.

Il Comunicato spiega che si è attivato normalmente il sistema antincendio della sala UPS, ma che poi il fumo, diffuso in tutta la struttura, ha fatto scattare anche quello delle sale dati che ha causato l’interruzione di corrente. Sembra quindi che dopo il corto circuito relativo agli UPS sia entrato in funzione senza problemi il sistema di bypass di questi ultimi e le sale dati siano rimaste alimentate, salvo poi essere “spente” per un “errore” del sistema antincendio. Ma la questione è di poca importanza, perchè comunque i Vigili del Fuoco avrebbero chiesto di staccare l’interruttore generale prima di intervenire.

La cosa veramente interessante (cioè, ridicola) in tutta la vicenda è la Class-Action (cos’è?) che il Codacons ha promesso nei confronti di Aruba, per i disagi causati ai clienti durante il downtime. Da leggere assolutamente i commenti sul blog dell’Avv. Rienzi di chi non si rende conto che nessuno ha in mano coltelli, ma c’è un contratto, firmato, di chi ha una mail fondamentale per il suo lavoro ma la mette su un lowcost, di chi ha un sito fondamentale tramite il quale fa un immenso fatturato ma decide di ospitarlo su un pacchetto lowcost senza garanzie etc etc.

Mi fanno piacere i commenti di chi ha si scelto di ospitare un E-Commerce (anzi, 30) su sistema lowcost, ma sapeva a cosa andava incontro, sapeva cosa stava comprando e ha agito di conseguenza. Sono molti anche quelli che insultano il Codacons contro la class-action, da notare chi assume un atteggiamento “pan per focaccia” nei confronti dell’avvocato e del suo blog. C’è poi chi come al solito incolpa l’Italia, e confonde il bollino dorato “Uptime Garantito” con una garanzia da contratto e non si rende conto che per quel prezzo è semplicemente IMPOSSIBILE offrire garanzie. Ovviamente ci sono anche il MIO commento e quello dello (stimato) ex-collega Domenico De Monte.

Il punto focale è che il contratto firmato dai clienti spiega chiaramente che non sono fornite garanzie in termini di uptime, e che il prodotto offerto è soggetto a questo tipo di problemi. Il pacchetto di hosting è quindi qualcosa di “best effort”, ovvero “il meglio possibile”, in parole povere Aruba promette di offrire al cliente un buon servizio (ovviamente non può essere down 24ore al giorno), ma senza offrire garanzie in caso di problemi. Il cliente deve quindi saper valutare, decidere se il rischio di downtime per lui è accettabile.

Se lo ritiene accettabile, utilizza un servizio risparmiando non pochi euro (per soluzioni con delle garanze di uptime si parlerebbe di prezzi intorno alle migliaia di euro annuali), ma accetta di non richiedere risarcimenti in caso di downtime. Se non lo ritiene accettabile, ovvero crede che il rischio sia troppo alto e che l’eventuale perdita sarebbe troppo grossa, deve guardare da altre parti e tirare fuori il libretto degli assegni.

Una class-action che costringa il provider a risarcire i clienti quando da contratto negava questa possibilità, nata da clienti insoddisfatti di un servizio che hanno semplicemente sbagliato a comprare, sarebbe distruttiva per il settore: si costringerebbero le aziende ad offrire risarcimenti in situazioni economicamente impossibili. Il che può portare ad una sola cosa: la fine del lowcost. Essendo costretti a fornire risarcimenti in caso di problemi, i provider deciderebbero di offrire solo servizi all’altezza di una simile prospettiva, al fine di evitare inutili perdite.

Insomma, se volete sottoscrivere questa class-action, fatelo ma ricordate:

  1. Chi ha subito danni li ha subiti in quanto non ha letto il contratto e ha acquistato un servizio inadatto alle sue esigenze
  2. No, non avete perso email. Il protocollo SMTP è studiato per far fronte a queste situazioni
  3. Una azione simile, se vinta dai consumatori, creerebbe conseguenze catastrofiche sul mercato
  4. Eventi simili sono rarissimi, si fa prima a cancellare e ripartire

Vi terrò aggiornati.

Giorgio

%d bloggers like this: