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
