Un'Analisi Post Mortem Pubblica di un'Interruzione

Molte cose nella vita hanno un approccio comunemente accettato come “conservativo” e un approccio comunemente accettato come “rischioso” da evitare, almeno secondo il sentire comune. Negli investimenti, ad esempio, vediamo spesso l'acquisto di titoli di Stato o obbligazioni municipali come a basso rischio e l'investimento in azioni (titoli societari) come ad alto rischio, ma i dati statistici ci dicono che è il contrario e che quasi tutti perdono denaro sulle obbligazioni e ne guadagnano sulle azioni. La “saggezza” comune, messa alla prova, si rivela basata puramente sulle emozioni, le quali a loro volta si fondano su idee errate, e la cosa più rischiosa negli investimenti è usare le emozioni per guidare le strategie di investimento.

Analogamente, nelle valutazioni del rischio aziendale, l'approccio comune è quello di provare una risposta emotiva di fronte al pericolo, e questo innesca una reazione di panico e rende le persone fortemente inclini a sovracompensare il rischio percepito. Lo vediamo comunemente con le piccole aziende, la cui infrastruttura IT genera pochissimo fatturato o non è molto cruciale per le operazioni a breve termine, che spendono ingenti somme di denaro per proteggersi da un rischio solo parzialmente percepito e definito in modo molto approssimativo. Questo diventa spesso così drammatico che il processo di mitigazione viene gestito emotivamente anziché intellettualmente, e troviamo regolarmente aziende che implementano progetti di sistema scadenti che in realtà aumentano il rischio anziché ridurlo, spendendo somme di denaro molto ingenti e poi, dato che il rischio era per lo più immaginario, definendo il progetto un successo sulla base di strato dopo strato di idee errate: rischio immaginario, mitigazione del rischio immaginaria e successo immaginario.

Nel recente passato ho avuto modo di essere coinvolto in un disastro totale per una piccola azienda. Il disastro ha colpito quello che era quasi uno “scenario peggiore”. Non del tutto, ma molto vicino. La risposta emotiva al disastro in quel momento fu forte e, una volta che il disastro fu pienamente in atto, era comune che quasi tutti affermassero e ripetessero che la pianificazione del disastro era stata difettosa e che il problema avrebbe dovuto essere evitato. Questo è molto comune in qualsiasi situazione di disastro: gli esseri umani sentono che ci debba essere sempre qualcuno da incolpare e che dovrebbero esistere scenari a rischio zero se facciamo bene il nostro lavoro, ma questo è completamente errato.

Per fortuna abbiamo eseguito un'analisi post mortem completa, come si dovrebbe fare dopo qualsiasi vero disastro, per determinare cosa fosse andato storto, cosa fosse andato bene, come potessimo correggere i processi e le decisioni che avevano fallito e come potessimo mantenere quelli che ci avevano protetto. Tipicamente, quando si verifica un grande evento di sistema, non ho modo di parlarne pubblicamente. Ma ogni tanto posso farlo. È così comune reagire a un disastro, a qualsiasi disastro, e pensare “oh, se solo avessimo….”. Ma bisogna esaminare il disastro. C'è così tanto da imparare sui processi e su noi stessi.

Innanzitutto, un po' di contesto. Un server critico, in esecuzione in un datacenter aziendale, ospita diversi carichi di lavoro chiave che sono molto importanti per diverse aziende. Ha poco più di quattro anni ed è stato in esecuzione in isolamento per molti anni. I server più datati destano sempre una certa preoccupazione man mano che si avvicinano alla fine del loro ciclo di vita. Quattro anni sono ben lungi dal rappresentare la fine del ciclo di vita per un server di classe enterprise, ma di certo non era nemmeno giovane.

Si trattava di un singolo server privo di qualsiasi meccanismo di failover. I backup venivano gestiti esternamente su un'appliance di backup enterprise nello stesso datacenter. Un progetto di sistema molto semplice

Non includerò tutti i dettagli interni, poiché qualsiasi situazione del genere presenta molte complessità nella pianificazione e nell'operatività. Quelle è meglio lasciarle a un processo di analisi post mortem interno.

Quando il server si guastò, si guastò in modo spettacolare. Il guasto fu così totale che non riuscimmo a diagnosticarlo da remoto, nemmeno con l'assistenza dei tecnici in loco presso il datacenter. Persino il fornitore del server non riuscì a diagnosticare il problema. Questo ci lasciò in una posizione difficile: come si affronta un server morto quando l'hardware non può essere riparato in modo affidabile. Potevamo sostituire i dischi, potevamo sostituire gli alimentatori, potevamo sostituire la scheda madre. Chissà quale poteva essere la soluzione.

Alla fine la decisione fu che sia il server sia il sistema di backup dovevano essere ricollocati presso la sede centrale, dove avrebbero potuto essere sottoposti a triage di persona e con il massimo delle risorse. Alla fine il sistema risultò riparabile e non andò perso alcun dato. La decisione di astenersi dal ricorrere al backup fu presa perché il recupero dei dati era più importante della disponibilità del sistema.

A conti fatti, il disastro fu uno dei più completi che si potessero immaginare senza arrivare a una vera e propria perdita di dati. L'interruzione si protrasse per molti giorni e furono impiegati molte apparecchiature di scorta, molte ore di lavoro e numerosi tentativi di riparazione. Il processo fu estenuante, ma una volta completato il sistema fu ripristinato con successo.

La lunga interruzione e il senso di caos mentre si effettuavano le diagnosi e i tentativi di riparazione portarono a una sensazione complessiva di fallimento. Le persone iniziarono a dirlo, e questo porta le persone a crederci. In una condizione di risposta a un'emergenza è molto facile diventare eccessivamente emotivi, soprattutto quando si dorme pochissimo.

Ma quando facemmo un passo indietro e guardammo al risultato finale, ciò che scoprimmo sorprese quasi tutti: l'operazione di triage e la pianificazione iniziale del rischio erano state un successo.

Il caos che si verifica durante un triage fa spesso sembrare le cose molto peggiori di quanto siano in realtà. Ma la nostra gestione del triage era stata eccellente. Il triage non significa magia ed esistono una fase di scoperta e una fase di reazione. Quando analizzammo l'ordine degli eventi e li disponemmo lungo una linea temporale, scoprimmo di aver agito così bene che non c'era quasi nessun punto possibile in cui avremmo potuto ridurre i tempi. Avevamo eseguito buone diagnostiche, coinvolto le parti giuste al momento giusto, messo in moto la logistica per i ricambi il prima possibile, e gran parte di ciò che era sembrato tempo frenetico e sprecato era in realtà “tempo di riempimento” in cui cercavamo di determinare se esistessero ulteriori opzioni o se fossero stati commessi errori mentre attendevamo i ricambi necessari per la riparazione. Questo fece sembrare le cose molto peggiori di quanto fossero in realtà, ma tutto ciò costituiva l'insieme corretto di azioni da intraprendere.

Dal punto di vista del triage e del ripristino, il processo si era svolto in modo impeccabile anche se l'interruzione finì per richiedere molti giorni. Una volta che il disastro era accaduto, ed era accaduto nella misura incredibile in cui accadde, il ripristino procedette in realtà in modo incredibilmente fluido. Nulla è assolutamente perfetto, ma andò estremamente bene. La macchina funzionò come previsto.

La parte di gran lunga più sorprendente fu l'esame dell'impatto del disastro. Ci sono due modi di guardare a questo. Uno è quello più saggio, l'approccio “senza senno di poi”. Qui guardiamo al disastro, al costo dell'impatto del disastro, al costo della mitigazione e applichiamo la probabilità che il disastro si sarebbe verificato per determinare se fosse stata presa la giusta decisione di pianificazione. Questo è difficile da calcolare perché il fattore di rischio è sempre un numero approssimato, ma normalmente si può arrivare a essere abbastanza accurati da sapere quanto fosse buona la propria pianificazione. Il secondo modo è l'approccio del senno di poi perfetto: e se avessimo saputo che questo disastro sarebbe accaduto, cosa avremmo fatto per prevenirlo? È ovviamente del tutto ingiusto rimuovere il fattore di rischio e vedere quanto sia costato il disastro in cifre assolute, perché non possiamo sapere cosa andrà storto e pianificare solo per quell'unica possibilità o spendere denaro illimitato per qualcosa di cui in realtà non sappiamo se accadrà. Le aziende commettono spesso l'errore di utilizzare quest'ultimo calcolo e di incolpare i pianificatori per non aver avuto una previsione perfetta.

In questo caso, eravamo abbastanza fiduciosi di aver fatto la scommessa giusta fin dall'inizio. Il sistema era stato in funzione per quasi un decennio con tempi di inattività pari a zero. Il costo complessivo del sistema era stato basso, il costo del triage era stato moderato e l'evento era stato estremamente improbabile. Il fatto che, considerando il fattore di rischio, avessimo fatto una buona pianificazione non sorprese particolarmente nessuno.

Ciò che sorprese fu che, quando eseguimmo i calcoli senza il fattore di rischio, anche se avessimo saputo che il sistema si sarebbe guastato e che si sarebbe verificata un'interruzione prolungata, avremmo comunque preso la stessa decisione! Questo fu a dir poco sconvolgente. Il costo dell'interruzione prolungata fu in realtà inferiore al costo delle apparecchiature, dell'hosting e del lavoro necessari per costruire un sistema funzionante di mitigazione del rischio, che in questo caso sarebbe consistito nell'avere un server completamente ridondante nel datacenter insieme a quello in produzione. Anzi, il risparmio sui costi derivante dall'accettare questa interruzione prolungata aveva fatto risparmiare quasi diecimila dollari!

Questo si rivelò un caso estremo in cui l'interruzione fu devastante, difficile da prevedere, impossibile da riparare rapidamente e tuttavia si tradusse in enormi risparmi sui costi a lungo termine, ma la lezione è importante. C'è così tanto bagaglio emotivo che accompagna qualsiasi disastro che, se non eseguiamo una corretta analisi post mortem e non ci impegniamo a rimuovere le risposte emotive dal nostro processo decisionale, finiremo spesso per precipitare verso una perdita finanziaria su vasta scala o per attribuire la colpa in modo errato, anche quando le cose sono andate bene. Molte aziende avrebbero guardato a questo disastro e avrebbero reagito spendendo in modo drammaticamente eccessivo per prevenire il ripetersi dello stesso improbabile evento in futuro, anche avendo i conti davanti agli occhi a dimostrare che farlo sarebbe stato uno spreco di denaro persino qualora quell'evento si fosse ripresentato!

Ci furono altre lezioni da trarre da questa interruzione. Imparammo dove le comunicazioni non erano state ideali, dove le persone giuste non erano sempre nella giusta posizione decisionale, dove le comunicazioni con il cliente non erano state quelle che avrebbero dovuto essere, dove il cliente non ci aveva informato correttamente dei cambiamenti e altro ancora. Ma, in linea di massima, le lezioni furono che avevamo pianificato correttamente, che la nostra operazione di triage aveva funzionato correttamente e che avevamo fatto risparmiare al cliente diverse migliaia di dollari rispetto a quello che sarebbe sembrato l'approccio “conservativo” e, grazie a una buona analisi post mortem, eravamo riusciti a evitare che loro, e noi, reagissimo in modo eccessivo trasformando una buona decisione in una cattiva per il futuro. Senza un'analisi post mortem avremmo molto probabilmente cambiato i nostri buoni processi pensando che fossero stati cattivi.

Le lezioni da portare a casa che voglio trasmettervi, lettori, sono che le analisi post mortem sono un passaggio cruciale in qualsiasi disastro, che il tradizionale pensiero conservativo è spesso molto rischioso e che le reazioni emotive al rischio causano spesso disastri finanziari più grandi di quelli tecnici da cui cercano di proteggere.