Leggo qui di una serie di disservizi che ha colpito alcuni servizi di Google. Il motivo per cui l’articolo ha attirato la mia attenzione è l’accenno al livello di servizio dichiarato da Google per “Apps for business” (99.9% di uptime) in rapporto ai guasti di questa settimana. Quello dell’uptime dichiarato è un tema che serve da tempo immemore per mostrare come i livelli di servizio siano una questione tutt’altro che banale. il 99.9% vuole dire che è tollerato un giorno su mille di disservizio, ma naturalmente c’è differenza ad esempio, per chi ci deve lavorare, se si tratta di disservizi della durata di un minuto, o se il disservizio è di una giornata consecutiva. Il computo di Google è fatto mensilmente, secondo la tabella, quindi per ogni mese sono tollerati circa tre quarti d’ora di disservizio… come giustamente segnala l’articolo, in questa settimana diversi utenti si sono già trovati oltre questo limite. A parte la possibilità per loro di dimostrare che il disservizio c’è stato, che affidabilità ha un fornitore che è già noto che non rispetta i propri SLA, per una percentuale imprecisata di utenti? Certo, per molti dei suoi utenti il problema non si è manifestato (o non se ne sono accorti), ma il punto non è quello e non è neanche Google in sé: il punto è che la sua infrastruttura non sembra garantire che lo SLA sia rispettato, anzi sembrerebbe il contrario, anche se poi sui grandi numeri finora gli è andata bene. Il problema degli SLA è che… finché non c’è il guasto, il sistema funziona 😉
Ma il vero punto dei livelli di servizio sono le penali, ovvero: cosa succede se invece il servizio rimane fermo per più di un giorno ogni tre anni, in violazione di quanto promesso? Così mi sono andato a cercare gli SLA del servizio, e ci ho trovato esattamente quello che mi aspettavo (alla data di oggi).
Cominciamo quindi con una serie di definizioni, la più interessante delle quali mi sembra questa:
“Downtime” means, for a domain, if there is more than a five percent user error rate. Downtime is measured based on server side error rate
Astraiamoci da Google e pensiamo a generici servizi in cloud.
Immaginiamo quindi che il servizio sia utilizzato da un’azienda per gestire la propria contabilità. Se c’è un tasso di errori di meno del cinque per cento, non è nemmeno downtime. Sarebbe interessante sapere cosa intendono per errori, ma potenzialmente la nostra azienda si potrebbe trovare con almeno una fattura su 25 registrata in modo errato (o magari persa?) senza che sia neppure downtime. Questo ci porta ad una considerazione importante: quando si parla di cloud si pensa sempre alla disponibilità, ma con la complessità di certe architetture anche l’errore e la perdita di dati sono problemi tutt’altro che trascurabili.
Ma la vera essenza dello SLA è quella riportata nel primo paragrafo e nella tabella, che è la classica clausola “per il consumatore” che si trova anche in molti contratti di connettività:
If Google does not meet the Google Apps SLA, and if Customer meets its obligations under this Google Apps SLA, Customer will be eligible to receive the Service Credits described below. This Google Apps SLA states Customer’s sole and exclusive remedy for any failure by Google to meet the Google Apps SLA.
Bene, quindi se la mia azienda resta con l’amministrazione ferma per 10 giorni… quello che ottiene sono altri quindici giorni di servizio a fine contratto. Fantastico.
Ora mi permetto una piccola analogia: immaginiamoci che un fornitore di materiale da costruzione vi venda delle travi d’acciaio che sono garantite per una certa tensione di rottura, e che vi dica che… se per caso le travi non sopportano effettivamente quella tensione, ve ne danno un’altra gratis. Le usereste per fare un ponte? No, ma non si porrebbe neanche il problema: la trave deve reggere, non importa se la trave in sé costa poco, e per garantire che regga ci si prendono una serie di margini di sicurezza notevoli. Allora, se il cloud deve servire per delle infrastrutture importanti e non solo per giocare, bisogna cominciare a ragionare negli stessi termini, compresi i margini di sicurezza dimostrabili.
Naturalmente si può dire che le infrastrutture IT sono molto più complesse di qualsiasi altra, e in parte è certamente vero, ma è anche vero che nell’IT la robustezza è un costo che si può trascurare con molta più facilità, mentre invece, proprio per la maggiore complessità dei sistemi, non dovrebbe essere così.
Giusto per fare un esempio, prima di parlare di banda larga a piacere, bisognerebbe parlare di banda garantita: se la rete sarà lo strumento con cui aziende e cittadini interagiranno fra loro e con la PA, allora non dovrebbe essere possibile un’offerta in cui la connettività va giù ad ogni temporale e viene ripristinata “nelle 48 ore lavorative” quando va bene…
