A Dutiful Mind

...il blog di Marco Fotino

Come affrontare un disastro informatico (e uscirne anche bene)

Pubblicato il Taggato , , Non ci sono commenti per Come affrontare un disastro informatico (e uscirne anche bene)

Nel tardo pomeriggio dello scorso 31 gennaio, il noto sito GitLab (servizio che ospita progetti software) ha iniziato ad avere dei problemi, tra cui rallentamenti nel servizio e blocchi del sito. Non è una cosa che avviene di rado su Internet, ed è di solito dovuta a qualche tipo di attacco informatico. Quando succede, i gestori del servizio intervengono prontamente per individuare le cause del problema e ripristinare la piena funzionalità del sito web, e ciò è avvenuto anche nel caso di GitLab. La causa era, in questo caso, l’accesso contemporaneo allo stesso progetto da parte di 47mila indirizzi IP (in pratica, qualcuno stava usando GitLab come una specie di CDN, sovraccaricando la banca dati del sito).

In tarda serata, però, la cosa ha preso una piega surreale quando il sito, poco dopo essere tornato online, ha subìto un nuovo blocco, stavolta per “manutenzione d’emergenza del database”.

In gergo tecnico, quello che stava succedendo era un “Disaster Recovery“, ovvero una procedura di recupero di un sistema o dei suoi dati in seguito a un evento imprevisto e distruttivo (nel senso di perdita di dati o funzionalità). Tutti i sistemi informatici oggi prevedono (o dovrebbero farlo…) un insieme di strumenti che permettano di affrontare qualunque imprevisto (dal guasto di un server all’intrusione informatica) e ripristinare il sistema in tempi ragionevoli e con perdite di dati nulle (o almeno minime). Tra questi strumenti ci sono il backup (la produzione periodica di una copia dei dati e delle configurazioni del sistema), la ridondanza (il salvataggio di tutti i dati su diversi database), la replica delle macchine di produzione (una copia dei server conservata su supporti diversi e geograficamente separati). A questo punto in molti sul web aspettavano l’attuazione di queste procedure e il ripristino di GitLab, ma i più curiosi e tecnici, vista la particolare sequenza di eventi (un sovraccarico, il ripristino e, poi, una “manutenzione d’emergenza”) si chiedevano cosa fosse successo. La risposta è arrivata poco più di un’ora dopo, sempre via Twitter:

“Abbiamo cancellato accidentalmente dei dati di produzione e potremmo doverli ripristinare da un backup”.

In queste poche parole è riassunto l’incubo di ogni sistemista informatico: non un disastro naturale, né un guasto, e nemmeno un attacco informatico. La cancellazione dei dati di produzione (quelli importanti) è stata accidentale, probabilmente causata da un errore umano. Il documento linkato spiegava meglio l’accaduto: nel tentativo di correggere i ripetuti errori di replica del database tra i due sistemi di produzione (“db1” e “db2”), il sistemista che ci stava lavorando (chiamato “YP” nel documento e “team-member-1” negli aggiornamenti successivi) ha cancellato i dati anzichè dal db2 (dove la replica non aveva funzionato e che quindi conteneva dati incompleti) dal db1 (cha a questo punto conteneva l’unica copia della banca dati del sistema). YP ci mette un paio di secondi ad accorgersi dell’errore e a interrompere il comando appena impartito, ma ormai la frittata è fatta: dei 310 GB di dati, ne rimangono solo 4,5!!!

A questo punto, di fronte al “disaster”, non resta che attuare le procedure di “recovery”: bisogna recuperare i dati cancellati da qualche parte. Ma qui il problema, anziché avviarsi a soluzione, non fa che peggiorare di minuto in minuto: su 5 modalità di salvataggio dei dati, nessuna sembra aver funzionato a dovere. In particolare:

  1. il salvataggio di una copia dell’intero server avviene ogni 24 ore (solo per un puro caso, YP aveva effettuato un salvataggio manuale 6 ore prima del disastro);
  2. i backup del database avvengono anch’essi ogni 24 ore, ma per un problema di programmazione non funzionavano;
  3. i backup su cloud Microsoft erano stati attivati solo su alcuni server (non su quello che ha subìto la perdita dei dati);
  4.  i backup su cloud Amazon non avevano funzionato (non c’era nessun dato);
  5. le procedure di replica dei dati, scritte a mano, avevano dato degli errori.

In aggiunta, non era stato previsto nessun meccanismo di avviso in caso di fallimento di una procedura di backup, e così nessuno si era potuto preoccupare del problema fino al momento del bisogno. In definitiva, l’unica strada rimasta era il ripristino dei dati vecchi di 6 ore (e la rassegnazione di aver preso tutto ciò che era successo in quelle 6 ore di funzionamento). E’ iniziata quindi una procedura di ripristino che ha portato il sito GitLab a tornare operativo dopo ore (il sito è tornato online nel tardo pomeriggio del giorno dopo).

La perdita per GitLab ammonta quindi a circa sei ore di attività sul sito (circa 5000 progetti, circa 5000 commenti, circa 700 utenti), ma la vicenda ha anche degli aspetti positivi: restano l’esperienza acquisita e tutte le contromisure che sono state prese per evitare che in futuro si verifichi un problema simile. Gran parte della comunità dei sistemisti informatici, inoltre, ha apprezzato la grande trasparenza con cui tutta l’operazione di recupero è stata gestita dai tecnici di GitLab, che hanno tra l’altro:

La comunità ha risposto in maniera solidale ed empatica alla situazione, riconoscendo che si è trattato di un caso emblematico di legge di Murphy (“se qualcosa può andar male, lo farà”). In particolare, alcuni utenti si sono preoccupati per la sorte lavorativa del povero sistemista che aveva causato il guaio (la società ha ripetutamente garantito che non sarà licenziato), altri hanno offerto il proprio aiuto e le proprie competenze per risolvere il problema. In breve, è nato su Twitter l’hashtag #HugOps, che gioca intorno alle parole “hug” (abbraccia) e “Ops” (il sistemista). In breve, quello che era iniziato come il peggiore dei disastri informatici possibili si è risolto con danni limitati per la società e la sua utenza, dimostrando che la trasparenza e la sincerità nell’affrontare i problemi spesso pagano.

Come affrontare un disastro informatico (e uscirne anche bene)

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.

Torna su