Come affrontare un disastro informatico (e uscirne anche bene)

HugOps

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.

Tecnologia che aiuta a rimettersi in forma

mibandUn’altra estate si avvicina, e porta con sé l’ormai consueto terrore per la “prova costume”: i vestiti sempre più leggeri non ci aiuteranno più a coprire quei chiletti di troppo che abbiamo accumulato negli ultimi mesi… Non si tratta ovviamente solo di un problema estetico: chi come me ha superato i “trenta” sa benissimo che il benessere che solo pochi anni fa davamo per scontato (in termini di fiato, agilità, resistenza) diventa col tempo una conquista difficile da raggiungere e ancor più ardua da mantenere. Da questo punto di vista, ho osservato come le persone si dividano in due gruppi molto differenti: da una parte ci sono quelli che fanno del fitness una religione, frequentando palestre con assiduità, iniziando attività semi-professionistiche di cross-fit, body-building, running e così via, dall’altra parte invece si trovano quelli che fanno una fatica immane ad abbozzare qualsivoglia attività fisica, incollati alla scrivania o al sedile dell’automobile dai propri impegni di lavoro e non. Pur provando enorme invidia per gli appartenenti al primo gruppo, io (così come molti miei coetanei) appartengo sicuramente al secondo. Certo, non a quella parte che ha già gettato la spugna, ma resta il fatto che per me iniziare (e soprattutto mantenere nel tempo) un’attività fisica resta una sfida non da poco. Per aiutarmi a vincerla, quindi, meglio ricorrere a tutti i mezzi (leciti!) a disposizione, come l’incoraggiamento da parte di amici più disciplinati di me (ai quali mi aggrego per fare un po’ di sport in compagnia) e, perchè no, sfruttando tutti i mezzi che la moderna tecnologia mette a disposizione per agevolare il compito (dopo tutto, sono sempre un nerd!). In questo post, in particolare, voglio parlarvi di due espedienti che possono aiutare quelli come me a condurre una vita un po’ più sana e regolare e a fare un po’ di attività fisica in più: una funzionalità di Google Calendar recentemente introdotta e un “activity tracker” molto economico. Continua a leggere

Punto Zero

website_2_0Per anni abbiamo sentito parlare del “Web 2.0”, di “Tecnologie 2.0” e simili, senza sapere mai davvero di cosa si stesse parlando. Non ci hanno nemmeno dato il tempo di comprendere bene cosa fosse “Duepuntozero” e cosa no, ed ecco che i media cominciano a utilizzare l’espressione “Web 3.0”. Ci siamo persi un passaggio? Siamo destinati a rimanere dei trogloditi informatici mentre un’orda di nativi digitali prende il possesso della nostra società? O siamo vittima di una (l’ennesima) supercazzola degli addetti al marketing? Per capirlo, proviamo innanzitutto a ricostruire l’origine e il significato dell’espressione “2.0”. Continua a leggere

Google Inbox: organizzare la propria vita tramite le email

Logo Google InboxIl tempo è denaro, si sa… e se c’è una cosa che il denaro non può comprare, è proprio il tempo: ai ricchi così come ai poveri, ogni giorno vengono donate esattamente 24 ore. Se consideriamo, poi, che un terzo di questo tempo lo passiamo a dormire, si capisce subito come sia facile trovarsi spesso a corto di tempo per fare tutto ciò che vorremmo (o dovremmo), e facciamo spesso la fine del famoso Bianconiglio di Alice nel paese delle meraviglie, correndo disperati al grido di “E’ tardi! E’ tardi!”. C’è una soluzione? Escludendo ipotesi fantascientifiche (viaggi nel tempo) e una revisione al ribasso dei propri desideri (secondo la teoria della decrescita serena), una sola: l’organizzazione del proprio tempo. Continua a leggere

M.C. Escher, l’inventore del selfie

Hand-with-Reflecting-Sphere-1935Guardate l’immagine qui accanto, e ditemi se la prima parola che vi viene in mente non è “selfie”. La differenza con quelli che fate quotidianamente con i vostri smartphone è che questa è stata realizzata a mano, utilizzando una sfera riflettente, nel 1935. L’autore, Maurits Cornelis Escher (si pronuncia “èscer”, so che ve lo stavate chiedendo), ha utilizzato questo espediente per ritrarre su una superficie a due dimensioni uno spazio tridimensionale: ma non gli bastava, come succedeva dall’invenzione della prospettiva in poi, rappresentare la profondità su un piano, lui voleva andare oltre e mostrare, oltre a quello che aveva davanti agli occhi, anche ciò che si trovava dietro di sè (compreso se stesso). La riflessione deformante della sfera diventa quindi un espediente per includere nel soggetto dell’opera tutto l’ambiente circostante: le quattro pareti, il soffito, il pavimento e tutto ciò che si trova nella stanza. Un po’ come si fa nella realtà virtuale (quella di Google Street View o delle foto a 360°, o Photosphere), ma senza l’aiuto della tecnologia.
Continua a leggere