Storie dalla Sala Macchine


Home Page | Commenti | Articoli | Faq | Documenti | Ricerca | Archivio | Storie dalla Sala Macchine | Contribuire | Login/Register

Test Finto, Disastro Vero

Ah, i computers ed i sistemi computerizzati. Tutto si appoggia sui computer oggi. Fateci caso. Andate al lavoro in auto? Il semaforo che vi sta facendo perdere un quarto d'ora e' controllato da un computer che probabilmente scambia informazioni con altri computer lungo la strada e tutti quanti sono in combutta contro di voi. Prendete il tram? Gli scambi ed i semafori sono anche loro oramai computerizzati e pure loro fanno parte della cospirazione.

Taxi? Una parola: "Uber".

Quando finalmente arrivate in ufficio ed andate alla macchina del caffe' per una meritata tazza, anche quella funziona perche' c'e' un computer dentro.

E non contenti di tutta questa fuffa informativa, vogliamo ancora piu' computer attaccati a... praticamente tutto. Dal campanello d'ingresso al frigorifero passando per il tostapane e l'orologio a cucu'.

E che succede quando non funzionano? Il chaos. Ovviamente.

Perche' i computers, che ci piaccia o no, sono congegni che si possono rompere. E quando non e' l'hardware a rompersi e' il software che si introia piu' si che no. Perche' tutto e' fatto da esseri umani che commettono errori, spesso e volentieri, e non sempre hanno il tempo, la voglia o la possibilita' di correggerli.

Tuttavia, per qualche strano motivo, tutti quelli che utilizzano sistemi computerizzati non pensano mai alla possibilita' che qualche cosa non funzioni nel loro bellissimo sistema. Si fanno piani, proiezioni e progetti assumendo che tutto funzionera' nella maniera migliore, tutto sara' completato secondo i tempi stabiliti. Non ci saranno ne' incidenti ne' imprevisti. E sappiamo tutti come vanno a finire le cose.

Quindi e' sempre una sorpresa quando qualcuno si mette a parlare di "Disaster Recovery" prima che il "disaster" faccia capolino.

Il "disaster" recovery e', in soldoni, il pensare a che cosa potrebbe andare male (ok, peggio di come va normalmente) e come risolvere e rimettere in piedi il tutto nel piu' breve tempo e con il minimo danno. Che e' un'idea fantastica se non fosse che nella maggioranza dei casi, tutti i "modi" a cui si puo' pensare richiedono soldi e tempo. Cioe' le due cose che il manglement non vuole nemmeno sentire nominare.

Sembra che dal 2000 in avanti, cioe' da quando l'IT e' diventata una cosa "importante", un sacco di gente si sia convinta che i computer possano fare tutto in un tempo virtualmente nullo e senza mai dover pagare per niente.

Io incolpo quella chiavica di Star Trek per questo. Che ancora non ho capito perche' dopo il 1980 continuano a farne e c'e' gente che continua a guardare quella cagata.... oh, aspetta...

Si'... ecco, quello...

Comunque sia, entra in scena $noipensiamoatutto. Societa' di Marketing (o similare) che, probabilmente durante un dopo-meeting con troppo alchol, decide che sarebbe meglio fare un bel "disaster recovery test".

Ora, questi signori avevano, non so bene come, deciso di avere un sistema "a prova di bomba", con tutto doppio. Tutto meno, ovviamente, il database che era usato da tutti i loro sistemi. Ed il server di "gestione" che faceva da "centrale" a tutto. Ed il load balancer. E... insomma, mettila come la vuoi, ma in generale ti ritrovi sempre con uno o piu' "single point of failure".

Quando questi informarono che volevano fare un 'test' di Disaster Recovery, noi facemmo presente che prima di fare un 'test' dovresti avere un Piano di disaster recovery, cioe' cosa fare ed in che ordine. Quelli rimasero per un po' stupefatti che NOI non si avesse tale piano. Facemmo rispettosamente notare che noi facevamo l'hosting del sistema, ma i dettagli li avevano solo loro.

Dopo una serie di meeting risulto' chiaro che i problemi erano: 1. il database e 2. il server di "gestione".

Per quanto riguarda il database, dato che si appoggiavano a SQL Server, le uniche cose che si poteva fare era avere un "cluster", e quindi una seconda macchina con le stesse caratteristiche della prima, o avere dei backup relativamente frequenti ed essere pronti a fare un restore se si rendeva necessario. Che significa pero' perdere dei dati.

Il server di "gestione" era una faccenda molto piu' complessa... Per qualche strano motivo questa gente usava un server Linux per fare la "gestione" dei vari server di produzione che erano Windows... No, non lo so perche'. In ogni caso, l'intero arnese era basato su Jenkins, ed era usato per effettuare "rilasci" del codice facendo un bel download del codice via Git e poi un bel upload dello stesso sui vari server di produzione usando un mix di SSH e PowerShell scripting.

Il ragionamento che fu utilizzato fu che "stiamo pensando ad un DISASTRO, che non dovrebbe essere una cosa normale, ed il sistema e' tutto basato su macchine virtuali, percui per il database possiamo fare un restore su una nuova macchina virtuale, fatta con un clone della macchine precedente. E per il sistema di gestione, tutta la roba e' su Git, quindi non dovrebbe essere un grosso problema ricostruirlo da zero anche se viene spianato".

Tutti pompati dopo il ciclo di "brainstorming", $noipensiamo presentarono il "piano" che comprendeva una montagna di operazioni interdipendenti e da effettuare in concerto tra noi e loro. A questo punto io feci notare un piccolo difetto nell'intera cosa: loro non avevano un sistema di test. Quindi se volevamo fare un "test", dovevamo farlo sul sistema di produzione. E questo significava, sostanzialmente, mettere tutto in downtime per l'intera durata dell'operazione. Durata che era calcolata in circa 5 ore.

Dopo aver boccheggiato come pesci fuor d'acqua per un po', $noipensiamo (che a questo punto dovrebbe cambiare nome ma vabbe'), decisero che la cosa doveva essere fatta comunque e, per "minimizzare i disturbi ai di loro clienti", l'intera faccenda avrebbe dovuto essere svolta nottetempo... ovviamente, perche' di disturbare i sysadmin non gliene frega un cazzo a nessuno.

E cosi' venne il grande giorno... o meglio la grande notte. Ed in effetti, a me non sarebbe dovuto fregarmene assolutamente niente, se non fosse che venni svegliato alle 5 del mattino (svegliato per modo di dire dato che ero gia' stato svegliato dai gatti alle 4) da uno dei miei colleghi (CL) in preda al panico perche' in tutto il pensamento, nessuno aveva pensato che noi non avevamo mai provato un restore del database, e adesso si scopriva che il restore non funzionava tanto bene... Ovviamente nessuno, nel panico del "disaster", tutti avevano anche evitato di pensare che... Non c'era nessun "disaster" in effetti perche' era un TEST. Il database non era morto, era solo stato spento. E bastava riaccenderlo per farlo rifunzionare.

Una volta fatto notare quell'insignificante particolare, tutti quanti si presero un paio di minuti per pensare "perche' non ci abbiamo pensato noi?" e poi cominciarono tutti quanti a strillare contemporaneamente.

UL1 - Quindi basta riaccenderlo?
IO  - Bhe, sarebbe meglio prima spegnere quello "nuovo", se sono sullo stesso IP non credo sia una bella cosa metterli in funzione insieme.
UL2 - E che facciamo con i server?
IO  - Non lo so, che cosa volete fare con i server?
UL2 - Secondo il nostro piano dovrebbero fare "fall-back" sui server nell'altro datacenter.
IO  - E lo hanno fatto?
UL2 - Non lo so... come facciamo a saperlo?
IO  - ...chi e' che lo ha pensato questo piano?
UL1 - Noi ma...
CL  - Allora posso riaccendere il database e lasciare perdere questo restore? Che sta girando gia' da 3 ore...
IO  - Se avete pensato al piano dovreste anche aver pensato a come verificarlo. E come verificare ogni passo intermedio per assicurarsi che funzioni. O no?
UL1 - Si ma...
IO  - Quindi dovreste sapere come controllare se quei server hanno fatto "fallback" o no.
CL  - Hemmm... posso dire una cosa?
UL2 - Il fallback dovrebbe essere controllato dal server di gestione, ma in questo scenario il server di gestione e' inagibile finche' non viene ricostruito.
IO  - Quindi quello dovrebbe essere il primo passo nell'intero processo... o no?
UL1 - Veramente no, prima dovrebbe essere riattivato il database.
IO  - Il database e' usato dal server di gestione in qualunque forma?
CL  - ...non e' che vorrei dire cose strane ma...
UL2 - No, il server di gestione non lo usa, non direttamente, ma deve eseguire certe query durante le fasi di rilascio.
IO  - Quindi il server di gestione prima ed il database dopo.
UL1 - Ma secondo il nostro piano il server di gestione e' l'ultima parte.
IO  - Gente, questo piano lo avete pensato e discusso voi, non io. Se non avete considerato la priorita' di come fare e verificare le cose suggerirei di abortire l'intero test e ripensarci un attimo. Prima che vi ritroviate con un vero disastro e senza piano.
CL  - Ecco appunto, quello che volevo dire...
IO  - ...cosa?
CL  - Che mi sa che c'e' qualche cosa che non va perche' non riesco piu' ad accedere al sistema...
IO  - ...quello che dovrebbe essere spento o quello che dovrebbe essere acceso?
CL  - Nessuno dei due...

Ed e' a questo punto che ci siamo accorti che nella foga del "test" nessuno si era accorto che ad uno dei "cloni" dei server da ricostruire era stato assegnato lo stesso ip del gateway del datacenter. Che non e' una bella cosa da fare.

Davide
23/07/2018 14:05

Precedente Successivo

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

4 messaggi posta messaggio
Messer Franz Di Messer Franz - postato il 13/08/2018 09:07 - rispondi

Quando si crea un sistema informatico, sia esso web o locale, si devono sempre seguire 4 regole:

1)provvedere a misure che garantiscano continuità alla corrente e protezione in caso di sovraalimentazione, per esempio con un adeguato sistema di UPS

2)ridondanza, perchè tutto può rompersi o smettere di funzionare, dalla connettività a semplicemente un cavo in cui uno inciampa e non si accorge che lo ha staccato

3)software adeguato, che valuti la possibilità di malfunzionamenti, hdd pieni, RAM piena, connettività intermittente o assente ecc

ma il più importante è il punto 4:

NON FAR MAI FARE LA COSA A DEI MANAGER, A GENTE CHE USA C# ANCHE PER SAPERE SE C'E' LA CARTA IGIENICA NEL BAGNO E A CHI L'HARDWARE TE LO VENDEREBBE , nel qual caso aspettati di avere un 486 difettoso venduto come un server della NASA e al prezzo corrispondente.

 

Se i manager li chiudi in bagno con la macchinetta del caffè durante la riunione ( o tutti i giorni dell'anno, al massimo li facciamo uscire a capodanno sperando si prendano un razzo in faccia ) il sistema , è scientificamente provato , acquista già di per sè una maggiore stabilità, minor costo ed una efficienza esponenzialmente maggiore...

--
Messer Franz


Davide Busato Di Davide Busato - postato il 14/08/2018 10:09 - rispondi

Jeri Ryan, 7 di 9 per gli amici, per la serie la patonza fa sempre audience :P

--
Davide Busato


Anonymous coward Di Anonymous coward - postato il 14/08/2018 10:53 - rispondi

Hai presente i "jump scare", quando nei film horror arriva il mostro all'improvviso e tutti urlano? Ecco, nemmeno con Sadako ho urlato così tanto come quando ho letto la frase "...era stato assegnato lo stesso ip del gateway del datacenter..."!!!

Questa diventa la mia storia preferita da raccontare intorno al fuoco, con la torcia puntata sotto al mento. Altro che "who was phone?"

Il gateway. Sto ancora tremando.

 

--
Anonymous coward


Coso de Cosis Di Coso de Cosis - postato il 16/08/2018 15:02 - rispondi

Procedura per pianificare un "disaster recovery":

1) Schiaffare di fronte a tutti i mannagger a cui piacciono le donne un'immagine di Jeri Ryan (o altra gnocca megagalattica del genere) possibilmente nuda - e di pari passo schiaffare di fronte a tutti i mannagger a cui piacciono gli uomini un'immagine di qualche bel fusto - al fine di distrarli e impedire loro di pianificare a membro di canis domesticus.

2) Mandare tutti i CL a prendersi un caffè al bar a 10 km di distanza dicendo loro che glielo offre la casa.

3) Procedere alla pianificazione vera.

--
Coso de Cosis


Precedente Successivo


Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.


Questo sito era composto con VIM, ora e' composto con VIM ed il famosissimo CMS FdT.

Questo sito non e' ottimizzato per la visione con nessun browser particolare, ne' richiede l'uso di font particolari o risoluzioni speciali. Siete liberi di vederlo come vi pare e piace, o come disse qualcuno: "Finalmente uno dei POCHI siti che ancora funzionano con IE5 dentro Windows 3.1".

Web Interoperability Pleadge Support This Project
Powered By Gojira