Il mese scorso, il fornitore di strumenti software Atlassian ha subito un grave blackout di rete durato due settimane che ha colpito più di 400 degli oltre 200.000 clienti dell’azienda australiana. L’interruzione ha coinvolto molti dei prodotti Atlassian tra cui Jira, Confluence, Atlassian Access, Opsgenie e Statuspage ed è stata il risultato di una serie di sfortunati errori interni da parte dello stesso personale di Atlassian e non il risultato di un attacco informatico o di un malware. Alla fine, nessun cliente ha perso più di pochi minuti di transazioni di dati e la stragrande maggioranza di essi non ha riscontrato alcun tempo di inattività.

La cosa interessante dell’intera situazione è quanto male Atlassian abbia gestito la comunicazione iniziale dell’incidente ai propri clienti, per poi (alla fine di tutto) pubblicare un lungo post ricco di dettagli sulle cause che hanno portato a questa lunga interruzione. È raro che un fornitore colpito da un blackout di rete così massiccio si impegni a ricostruire attentamente cosa sia successo (e perché) e a fornire una serie di consigli da cui anche altri possano imparare.

Nel post, Atlassian descrive in dettaglio la sua infrastruttura IT esistente, sottolinea le carenze nel suo programma di ripristino di emergenza (e come risolverne le carenze per prevenire interruzioni future) e descrive tempistiche, flussi di lavoro e modi in cui intende migliorare i suoi processi.

Il documento è sincero, fattuale e pieno di importanti rivelazioni e dovrebbe essere letto da qualsiasi ingegnere e manager di rete. Dovrebbe anche essere utilizzato come modello per qualsiasi azienda che dipenda dal software per individuare e correggere errori simili e funge da struttura di discussione per valutare onestamente i manuali di ripristino di emergenza di qualsiasi azienda.

Lezioni apprese dall’incidente

I problemi sono iniziati quando l’azienda ha deciso di eliminare un’app legacy diventata superflua dopo l’acquisto di un nuovo software dalle funzioni simili. Tuttavia, Atlassian ha commesso l’errore di ricorrere a due team diversi con responsabilità separate ma correlate. Un team ha richiesto l’eliminazione dell’app superflua, mentre l’altro team è stato incaricato di capire come eseguire effettivamente questo passaggio. Ciò avrebbe dovuto sollevare immediatamente qualche segnale d’allarme.

I due team non utilizzavano lo stesso linguaggio e gli stessi parametri e di conseguenza hanno avuto problemi di comunicazione immediati. Ad esempio, un team ha utilizzato l’ID app per identificare il software da eliminare, ma l’altro team pensava che i colleghi si riferissero all’ID dell’intera istanza cloud in cui si trovavano le app.

Lezione 1: Migliorare la comunicazione interna ed esterna

Il team che richiede modifiche alla rete e il team che le implementa effettivamente dovrebbero essere la stessa cosa. In caso contrario, è necessario mettere in atto solidi strumenti di comunicazione per garantire che i team siano sincronizzati, utilizzino la stessa lingua e abbiano la stessa precisione sulle procedure. A causa dell’errore di comunicazione, gli ingegneri Atlassian non si sono resi conto dell’entità del loro errore per diversi giorni.

Ma la comunicazione tra team era solo una parte del problema. Quando Atlassian ha analizzato le comunicazioni tra i vari manager e i suoi clienti, ha scoperto di aver pubblicato i dettagli sull’interruzione entro un giorno sui propri sistemi di monitoraggio, ma non è stata in grado di raggiungere direttamente alcuni dei loro clienti perché le informazioni di contatto erano andate perse quando i siti legacy erano stati eliminati e altre informazioni erano obsolete.

minacce

Inoltre, i dati eliminati contenevano le informazioni necessarie ai clienti per compilare un ticket di richiesta di supporto valido. Per aggirare questo problema, è stato necessario l’intervento di un team di sviluppatori per creare e distribuire un nuovo processo di ticket di supporto. La società ammette inoltre che avrebbe dovuto avvisare prima nella sequenza temporale dell’interruzione e non dopo aver aspettato di avere un quadro completo dell’ambito dei processi di ripristino.

Ciò avrebbe consentito ai clienti di pianificare meglio le contromisure da adottare dopo l’incidente, anche senza intervalli di tempo specifici. “Avremmo dovuto riconoscere la nostra incertezza nel fornire prima una data di ripristino del sito e renderci disponibili prima in modo che i nostri clienti potessero pianificare di conseguenza. Avremmo dovuto essere trasparenti su ciò che sapevamo sull’interruzione e su ciò che non sapevamo”, si legge nel documento dell’azienda.

Lezione 2: proteggere i dati dei clienti

Trattate i dati dei vostri clienti con cura, assicuratevi che siano aggiornati e accurati e che ne venga eseguito il backup in più posizioni separate. Assicuratevi anche che i dati dei vostri clienti possano sopravvivere a un disastro e includete controlli specifici in qualsiasi programma di disaster recovery.

Ciò solleva un altro punto importante per quanto riguarda il ripristino di emergenza. Durante il blackout di aprile, Atlassian ha mancato i suoi obiettivi di tempo di ripristino (recovery time), ma ha raggiunto gli obiettivi di punto di ripristino (recovery point), visto che è stata in grado di ripristinare i dati solo pochi minuti prima dell’interruzione effettiva. Inoltre, non aveva modo di selezionare un insieme di siti dei clienti e ripristinare tutti i loro prodotti interconnessi dai backup a un momento precedente in modo automatizzato.

“Le nostre eliminazioni a livello di sito avvenute ad aprile non avevano operazioni e procedure di routine che potessero essere rapidamente automatizzate per la portata di questo evento. Avevamo la possibilità di ripristinare un singolo sito, ma non avevamo creato funzionalità e processi per il ripristino di un grande lotto di siti”.

Lezione 3: Testare scenari complessi di ripristino di emergenza

Controllate e ricontrollate i vostri programmi e le vostre procedure di ripristino di emergenza per assicurarvi che soddisfino i vari obiettivi. Assicuratevi inoltre di testare quanti più scenari possibili. Ciò significa affrontare in modo specifico e anticipare la risposta agli incidenti su larga scala e comprendere le varie complesse relazioni dei clienti che utilizzano più prodotti o dipendono da una serie di vostre applicazioni.

Se state utilizzando l’automazione, assicuratevi che le vostre API funzionino correttamente e inviino segnali di avviso appropriati quando non funzionano. Questo è stato uno dei problemi di cui Atlassian ha dovuto eseguire il debug al volo mentre l’interruzione si trascinava per giorni.

Lezione 4: proteggere i dati di configurazione

Infine, c’è il problema su come sono stati eliminati i dati, cosa che ha dato l’avvio all’intera interruzione. L’eliminazione dei dati, in particolare di un intero sito, non dovrebbe essere consentita. Non a caso Atlassian sta passando alla cosiddetta “cancellazione graduale” (soft delete), che non elimina immediatamente i dati finché questi non sono stati controllati con rollback del sistema definiti e non hanno superato una serie di salvaguardie.

Atlassian sta anche stabilendo una politica di “eliminazione temporanea universale” su tutti i suoi sistemi e creando una serie di standard e revisioni interne. L’opzione di cancellazione graduale è più di una semplice opzione. Non eliminare i dati di configurazione prima di averli testati nell’intera infrastruttura è infatti qualcosa di assolutamente essenziale e obbligatorio.