I servizi IT sono fallibili, proprio per la natura stessa degli elementi infrastrutturali sottesi all'erogazione del più semplice e banale servizio ICT.
Il 29 aprile è una data che gli addetti ai lavori e, soprattutto, gli utenti Aruba non dimenticheranno facilmente visto che un "principio d'incendio" in un loro datacenter ha causato un downtime totale dei servizi di svariate ore.
Ricordando l'incipit e tenendolo bene a mente per tutta la durata della lettura di questo appunto vado a puntualizzare alcuni aspetti.
Punto primo
C'è chi grida allo scandalo perché disservizi di ore sono ingiustificabili, perché esistono soluzioni di Business Continuity tali da evitare downtime di diverse ore (anche più di 8);
Verissimo, esistono eccome. Tra le varie soluzioni di BC rientra anche la realizzazione o la fruizione di un sito di Disaster Recovery *MA* non si può pretendere certo di fruire di un sito DR se paghi un host condiviso a qualche decina di euro al mese o addirittura all'anno.
Punto secondo
Associazione consumatori richiedono la class action contro il fornitore per i danni derivanti dal disservizio.
In linea di massima mi sembra una posizione corretta ma esistono i contratti e anche gli SLA, gli accordi sui livelli di servizio.
E poi c'è Aruba che nel punto 14) e 14.x) del documento Condizioni Generali di Contratto Webfarm Services specifica chiaramente che lo SLA offerto prevede una disponibilità *best effort* e non garantisce *niente*.
A titolo esemplificativo e non esaustivo incollo il punto 14.4:
14.4: In tutti i casi sopra elencati, e in ogni caso in cui si manifesti una sospensione e/o interruzione del Servizio, a qualsiasi causa dovuta, ad eccezione dei casi in cui tali situazioni siano dovute a dolo o colpa grave di Aruba, quest’ultima non sarà in alcun modo responsabile nei confronti del Cliente o di Terzi per la mancata disponibilità del Servizio, impegnandosi ad assicurare la migliore funzionalità del sistema ma non garantendo comunque la continuità del servizio, l'integrità dei dati memorizzati o inviati attraverso il sistema di Aruba e/o attraverso internet. Il Cliente, pertanto, prende atto ed accetta che non potrà avanzare alcuna richiesta di risarcimento danni, siano essi diretti o indiretti, prevedibili o imprevedibili, di rimborso o di indennizzo (a titolo esemplificativo e non esaustivo, per perdite economiche/finanziarie, di affari, di ricavi e di utili e/o di avviamento commerciale) nei confronti di Aruba per il verificarsi di ritardo, cattivo funzionamento, sospensione o interruzione del Servizio e la solleva, ora per allora, da qualsiasi responsabilità in proposito.
In ogni caso, piaccia o no, tenere a mente il punto uno.
(Mi viene da pensare all'integrità dei dati non garantita: vedi servizio PEC)
Punto terzo
Nella sezione modulistica e contratti non mi sembra venga fatta distinzione da soluzioni in hosting condiviso da 10 euro all'anno o server dedicati da 300 euro al mese.
Se ho ben inteso (e spero di ricevere tante smentite in proposito) cambia la connettività, la soluzione tecnologica, i servizi erogati e le loro prestazioni ma non la disponibilità degli stessi (vedi punto 2 e punto 1).
Molto mi verrebbe da dire in relazione al servizio PEC ed ai danni derivanti dalla mancata erogazione (l'integrità dei dati di un servizio PEC deve rispettare una normativa specifica e rigorosa).
Punto quarto
Ore 11:25 (stralcio):
Si è verificato un principio di incendio nel Powered center della server farm principale che ha coinvolto le batterie degli UPS senza intaccare le sale dati.
Il sistema antincendio si è attivato facendo scattare l' energy power off togliendo per sicurezza energia all'intera struttura come da procedura.
Stralcio del comunicato stampa:
Inoltre, nonostante sia consuetudine installare le batterie all’interno del data center, per evitare il ripetersi di quanto accaduto, da oggi le batterie del data center di Arezzo e di tutti gli altri data center del Gruppo Aruba saranno installate in appositi locali, esterni e separati dalla struttura principale.
Ora, in primo luogo non è affatto una consuetudine tenere gli ups nei data center. Almeno non mi risulta lo sia per fornitori diversi da Aruba.
Inoltre, cosa ancora più importante del "mal comune mezzo gaudio", il comunicato stampa che, a mio avviso, smentisce de facto quanto affermato nel primo comunicato.
Dal comunicato stampa si capisce chiaramente che c'è una consuetudine (palesemente falso, ndr) di alloggiare le batterie UPS all'interno dei data center ma che, "per evitare il ripetersi di quanto accaduto", da *oggi* *saranno* delocalizzate in appositi locali esterni e separati dalla "struttura principale" ossia elaboratori, dispositivi di routing, dati, etc.
Questo significa che, fino a *ieri*, erano localizzate insieme a detti ambienti. Questo cozza completamente con quanto affermato nel primo comunicato dove si specificava che il principio d'incendio non ha interessato le sale dati.
Un po' di confusione, forse, può starci in momenti di emergenza come quello vissuto dallo staff di Aruba.
Certo è che il lettore resta perplesso, l'utente si perplime decisamente di più.
Ho riassunto anche le mie personali conclusioni: le trovate sul taccuino.
_________
Taccuino
@Mauro una piccola rassegnazione è comprensibile e condivisa. Credo che la tua esperienza sottolinei la scarsa consapevolezza di cosa sia un servizio, cosa siano gli accordi di servizio e cosa sia un accordo su questi ultimi, sia da parte di chi li offre che da chi li acquista.
Ancora awareness con un cappello più alto ed organizzativo ma sempre scarsa consapevolezza da ambo le parti. Sbaglio?
Scritto da: Armando Leotta | 09/05/2011 a 16:17
Mi permetto di aggiungere un'esperienza recente: un'azienda cliente ci ha richiesto, in un grosso progetto di logistica, uno SLA sui tempi di risoluzione guasti. Il sistema, in circa sei mesi di funzionamento a regime, ha subito un paio di guasti hardware ed alcuni malfunzionamenti software indotti da una condizione limite, che era stata sottovalutata, in caso di guasti della WAN.
Ciascun guasto è stato affrontato e risolto ampiamente nei tempi dello SLA anche se, soprattutto in un caso, ci sono stati degli impatti non nulli sull'operatività. Il cliente si è naturalmente lamentato di questi impatti.
Noi non abbiamo potuto che richiamarlo al fatto che da nessuna parte era richiesta una totale resilienza, e che lo SLA si limitava a dare dei tempi di apertura ticket e risoluzione dei malfunzionamenti. La nostra buona volontà ha fatto sì che in ciascun caso i disservizi siano stati nulli o molto limitati, ma questo non era richiesto dal contratto. E quindi nulla era dovuto a titolo di penale o qualsivoglia altra rivalsa su di noi.
La considerazione che mi viene è che non è nemmeno sufficiente ricordarsi di inserire un "livello di servizio": bisogna anche sapere qual è l'indicatore vero di soddisfazione sul servizio, e non limitarsi ad applicare i criteri della scorsa fornitura (per la quale magari andavano bene).
In sintesi, comprare servizi non è facile, e venderli tanto meno. Ma purtroppo a volte mi sembra che l'animale-uomo impari davvero soltanto quando si è fatto male. Devo rassegnarmi?
Scritto da: Mauro Cicognini | 09/05/2011 a 16:00
Concordo con te.
Il caso specifico non mi appassiona. Come si suol dire, la frittata è fatta...
Al contrario, questo è emblematico di come non si riesca a fare marketing su e con la sicurezza, e di come invece dovrebbe essere possibile farlo.
Ovviamente, per poter fare marketing di un tipo di offerta di servizi che godono di un certo supporto di sicurezza, dovrebbero altresì esistere utenti attenti a questo tipo di garanzie, ma se questa cultura la costruiamo a forza di incidenti, e non "governando" un processo culturale, si va poco avanti.
La mia impressione è che l'utente tipico, di fronte a questi casi, "impari" a subire l'evento imprevedibile, piuttosto che pretendere che un certo margine di rischio sia gestito dal proprio fornitore. E questo, purtroppo, accade quasi esclusivamente nell'IT, come se i computer fossero ancora scatolette magiche oscure e misteriose.
Non solo i fornitori, ma anche le associazioni di consumatori, di categoria, noi del CLUSIT, la P.A. (lo abbiamo detto tante volte) dovrebbero prendere possesso di questo processo culturale, facendo capire (non tanto alla grande azienda) che sebbene determinati eventi siano poco prevedibili, è comunque possibile pretendere, ed avere, determinate garanzie.
Dopodichè, la questione dei servizi a basso o alto costo esisterà sempre, ma a me piacerebbe che fosse, anche per il cliente finale, un "rischio calcolato"..
Mi rendo conto che alcune considerazioni paiono un tantino utopiche, ma credo che in buona parte l'essenza del problema stia proprio in queste considerazioni.
Scritto da: Luca Bechelli | 04/05/2011 a 11:28
Concordo con te.
Il caso specifico non mi appassiona. Come si suol dire, la frittata è fatta...
Al contrario, questo è emblematico di come non si riesca a fare marketing su e con la sicurezza, e di come invece dovrebbe essere possibile farlo.
Ovviamente, per poter fare marketing di un tipo di offerta di servizi che godono di un certo supporto di sicurezza, dovrebbero altresì esistere utenti attenti a questo tipo di garanzie, ma se questa cultura la costruiamo a forza di incidenti, e non "governando" un processo culturale, si va poco avanti.
La mia impressione è che l'utente tipico, di fronte a questi casi, "impari" a subire l'evento imprevedibile, piuttosto che pretendere che un certo margine di rischio sia gestito dal proprio fornitore. E questo, purtroppo, accade quasi esclusivamente nell'IT, come se i computer fossero ancora scatolette magiche oscure e misteriose.
Non solo i fornitori, ma anche le associazioni di consumatori, di categoria, noi del CLUSIT, la P.A. (lo abbiamo detto tante volte) dovrebbero prendere possesso di questo processo culturale, facendo capire (non tanto alla grande azienda) che sebbene determinati eventi siano poco prevedibili, è comunque possibile pretendere, ed avere, determinate garanzie.
Dopodichè, la questione dei servizi a basso o alto costo esisterà sempre, ma a me piacerebbe che fosse, anche per il cliente finale, un "rischio calcolato"..
Mi rendo conto che alcune considerazioni paiono un tantino utopiche, ma credo che in buona parte l'essenza del problema stia proprio in queste considerazioni.
Scritto da: Luca Bechelli | 04/05/2011 a 11:27
Ciao Luca, gli aspetti sono vari.
Da una parte l'utente ha firmato un contratto dove, se leggo correttamente, non viene garantita alcuna continuità ma, udite udite, nemmeno l'integrità dei dati.
E' scritto sul contratto quindi da questo punto di vista sono stati corretti e trasparenti. L'utente, consapevolmente o magari un po' ingenuamente, ha sottoscritto un contratto "economico" e non può certo pretendere un BC con DR e copia sincrona, per capirci.
L'unica osservazione che potrebbe lasciare spazio ad una verifica approfondita potrebbe essere il passaggio in cui viene specificata la contrapposizione causa di forza maggiore vs adozione di tutte le misure possibili (sempre nel contratto).
Discorso diverso ancora per la PEC: dai una lettura alla Circolare 24 novembre 2005, n. CNIPA/CR/49 e vedrai requisiti puntuali per essere accreditato dal CNIPA (leggi assicurazione per eventuali danni, piano della sicurezza, analisi dei rischi, iso 9001 etc etc): direi che ci sono spazi per approfondire.
In ogni caso, lo sottolineo nuovamente, l'utente non può stupirsi se non legge i contratti E paga poco.
Scritto da: Armando Leotta | 03/05/2011 a 21:44
Trovo molto interessanti i primi due punti, e ti ringrazio per averli evidenziati. Non sta a me ovviamente valutare se il costo del servizio è congruo anche in relazione al livello di servizio (non) garantito, ma va da se che è un fatto culturale che gli utenti stessi (a quanto pare, dalle lamentele) hanno palesemente ignorato di prendere in considerazione i livelli di servizio offerti dall'azienda quando hanno acquistato il servizio.
Al cliente stesso bisogna ricordare che è stato il primo a non occuparsi della propria Business Continuity, e se ha sottoscritto un contratto con un provider esterno per "spostare" il rischio fuori dalla propria azienda, lo ha fatto decisamente male, ignorando di prendere in considerazione clausole chiare e ben leggibili.
Con questo non voglio difendere Aruba, ma un fornitore di servizi ha il diritto di assumersi il rischio di esporsi al pubblico lubridio, mentre non è detto che i suoi clienti possano permettersi il lusso di scaricare su Aruba la colpa di un disservizio dei quali non possono non ritenersi in parte "corresponsabili" (non del problema materiale, ma di non aver in alcun modo valutato la conseguenza della scelta del fornitore).
Scritto da: Luca Bechelli | 03/05/2011 a 11:52