Riflessioni su OVH SBG2

Si stanno raffreddando le ceneri del fu datacentre SBG2 di OVH a Strasburgo ed è il momento di fare delle riflessioni.

È già successo che un datacentre di servizi cloud andasse offline, ma è probabilmente la prima volta che in Europa succede qualcosa di così grave, in quanto in questo caso l’offline è drasticamente definitivo.

Una ventina di anni fa durante il boom delle dot-com ho visto molte persone perdere i dati perché credevano che il RAID dei loro server potevano assolvere il ruolo di backup. Erano persone che non avevano esperienza informatica, che consideravano la tecnologia un mero metodo per fare dei soldi facilmente (la storia ha poi dimostrato quanto sbagliassero su tutti i fronti).

Con il cloud si ripete tristemente la storia. Qualche venditore d’assalto sbraita che il cloud e tutto quello che è as a Service permetterebbe a chi vuole avviare un’attività di ignorare gli odiosi dettagli della tecnologia e i fastidiosi termini dell’informatica infrastrutturale.

Vero solamente in parte.

Quando si utilizza una tecnologia, dall’automobile al cellulare al robot da cucina, o anche un semplice strumento, dalla penna stilografica alla chiave a pappagallo al badile, se non si studia un pochino il funzionamento o non si conosce un pochino la tecnologia coinvolta, si finisce per usare lo strumento in modo come minimo inefficiente o alla peggio in modo pericoloso.

“Intuitivo” è una cazzata del marketing.

I sistemi cloud e as a Service sono un gran salto in avanti tecnologico e aprono molte potenzialità di crescita, ma bisogna studiare e conoscere: bisogna capire la tecnologia che si sta utilizzando senza accettare supinamente la propaganda di unicorni e arcobaleni del marketing.

Perché alla fine il marketing ha fatturato, ma le terga ce le mettete voi.

Quando si acquista un servizio informatico bisogna capire innanzi tutto cosa si sta comprando. Non parlo dell’etichetta del prodotto che spesso utilizza parole altisonanti e fuorvianti, parlo della vera tecnologia sottostante che spesso è descritta in piccolo nei termini contrattuali. Qui possono aiutare le famose cinque W del giornalismo.

1. Who? Da chi state comprando il servizio? Che società è, da quanto è presente sul mercato?
2. What? State comprando un server fisico, un server virtuale oppure un servizio applicativo (una mailbox, un database un hosting web)? Cosa state comprando?
3. When? Quanto dura il servizio, come avvengono i rinnovi, quali sono i tempi minimi di contrato? Cosa succede in caso di ritardo dei pagamenti?
4. Where? Dove si trovano i vostri dati? In un punto solo, sono distribuiti, in che territori si trovano, che leggi si applicano?
5. Why? Perché questo servizio? Serve davvero oppure sto seguendo una moda? Ci sono alternative?

Se si acquista un servizio è più facile che il fornitore si incarichi di gestire tutta la tecnologia informatica sottostante e voi dovete solamente utilizzarlo e gestire i dati. Sì sembra strano ma dovreste fare il backup anche se avete la mail su Office 365 o su Google. Sì, anche se avete acquistato un servizio di backup da loro. Perché se vi chiudono il contratto per insolvenza o per presunte violazioni contrattuali voi perdete dati e backup.

I dati sono i vostri e ne siete responsabili.

Se si acquista un host (virtuale o fisico che sia) avete voi l’incarico della manutenzione del host e della sua disponibilità. Se avete preso un host si presume che abbiate un pochino di dimestichezza con queste tecnologia e si presume che abbiate fatto un pochino di disegno strutturale dei servizi che erogate su quelle piattaforme. I vostri host possono essere temporaneamente non disponibili per aggiornamenti del software o per guasti, dovete tenerne conto. Spesso basta far capire a chi li usa che un down di 10 minuti di un sito che vende animali impagliati non è una catastrofe cosmica, fa parte della vita del sito.

Si possono acquistare anche degli spazi nei datacentre per mettere le proprie macchine, ma se appartenete a questo gruppo e non conoscete certe cose peggio per voi.

Dopo aver pagato per l’infrastruttura bisogna pensare all’architettura degli applicativi che ci girano. Se è il backend di una app, dovremo capire se sia il caso di replicare i dati altrove. No, non nel rack a fianco e nemmeno nel datacentre della stessa zona. Altrove! Minimo in una zona diversa dello stesso fornitore, se non si vuole dipendere al 100% da un fornitore meglio un altro fornitore, ma qui potrebbe scattare il lock-in della tecnologia utilizzata (AWS e Azure ci sguazzno in questo).

Cosa vuol dire “zona diversa”? Vari fornitori attribuiscono significati diversi al termine, diciamo che deve essere un punto tale per cui un evento catastrofico che interessa un datacentre non influsica sul funzionamento del datacentre in una “zona diversa”. “Evento catastrofico” include terremoti, inondazioni, tsunami e similari. Il tutto sempre con un occhio al luogo in cui vengono registrati i dati.

Da ultimo bisogna pensare al cosidetto Disaster Recovery (DR), con enfasi sulla parte di recovery perché sul lato disaster siamo tutti dei campioni.

Il DR non è “rispristinare il backup”, ma è un piano di reazione a vari eventi catastrofici. L’utilità del DR è farvi pensare a come possano andar male le cose e come potete reagire. Fate piani concreti e realizzabili, non ipotizzate mai che tutto vada bene, il DR è un piano da attuare quando tutto va male. Ci sono tanti modi in cui le cose possono andar male, attingete dall’esperienza e dalla cronaca, non dite mai “tanto è impossibile che capiti”. Preparatevi all’impossibile e mettete le cose #000000 su #FFFFFF sia perché scrivendo non ci si raccontano storie sia perché se volete ricevere dei finanziamenti una delle prime cose che vi chiedono è “come pensi di far sopravvivere il tuo business?”. Se avete un piano di DR pronto ci fate solo una bella figura.

Veniamo al caso particolare di SBG2.

Un incendio così devastante è un evento catastrofico prima di tutto per l’azienda titolare del datacentre. Ci sta che dei servizi vadano giù per qualche giorno anche se non sono ospitati nella parte interessata dall’incidente. Ci sono priorità e leggi da rispettare: il vostro sito che vende animali impagliati è in fondo alla scala di priorità, prima bisogna stabilire se ci sono vittime, quali siano i danni strutturali, eccetera. In tutto questo immaginate lo shock per le persone che ci lavorano e quanto siano sotto pressione. Portate pazienza.

Non so se questa sia la politica di ogni datacentre di OVH, ma SBG2 era un po’ naïf come struttura: a parte un uso estensivo del legno (cercate bois, che significa legno in francese), il sistema anti incendio era uno sprinkler fatto in casa, non un sistema a nebulizzazione ad alta pressione che è più efficace contro gli incendi di materiale tecnologico. Di certo non il meglio possibile, ma queste informazioni non vengono rivelate tanto facilmente nel nome della sicurezza e della segretezza aziendale, quindi anche chi acquista servizi non può sempre conoscere questi dettagli. Senza contare che mancando questo tipo di trasparenza vi possono raccontare quello che vogliono.

Purtroppo su questo non vedremo soluzioni nel breve tempo, i gestori dei datacentre si trincerano dietro la sicurezza e i segreti aziendali e agli acquirenti non resta che fidarsi. Nei datacentre dove sosno stato (gli ultimi in Georgia, USA) in cui viene noleggiato dello spazio ai clienti c’è molta attenzione alle regole di prevenzione degli incendi, ma non posso dire che sia così dappertutto.

Da ultimo, ma non ultimo, due parole sui colleghi che hanno perso dei dati nel disastro di SBG2, che in questo momento stanno passando brutti momenti. Coraggio, in un modo o nell’altro si sopravvive, anche se adesso sembra che vi sia caduto il mondo addosso. La perdita può essere importante, impattante e molto dolorosa, ma stiamo sempre parlando di bit andati in fumo, non di persone decedute. Si ricostruisce e si ricostruisce meglio. Forza e coraggio.