«Acqua e fuoco i nemici dei sistemi IT»: potrebbe sembrare una
frase a effetto o uno spot pubblicitario. Invece è la
constatazione delle cause dei due più gravi incidenti occorsi a
server farm in Italia negli ultimi anni. L’incendio al server di
Aruba, sprigionatosi nella sala che ospitava i gruppi Ups, ha reso
indisponibili oltre mille siti web e non operative oltre 5 milioni
di caselle e-mail per 12 ore. Un altro incidente, dalle maggiori
conseguenze, si verificò il 2 gennaio 2004 quando, per un guasto
all’impianto di condizionamento, si allagò la sala server della
centrale Telecom di Tor Pagnotta (Roma). Per consentire
l’intervento dei Vigili del fuoco fu necessario spegnere il
sistema di condizionamento: la temperatura nei server crebbe fino a
provocare la fusione dei chip.
L’evento paralizzò le comunicazioni wired e wireless di tutti
gli operatori per sei ore nella zona Sud di Roma, con effetti
riscontrabili anche nei giorni successivi, almeno per quel che
riguardava le comunicazioni verso l’estero. Si riscontrarono
problemi a circa 10mila uffici postali e 1.000 sportelli bancari e
anche all’aeroporto di Fiumicino, dove i desk non Alitalia furono
obbligati ad utilizzare le procedure manuali per il check-in, con
ripercussioni nei voli in mezza Europa. Si rischiò un black-out
elettrico: la sala operativa di Acea perse il controllo di metà
delle sottostazioni elettriche che servono a gestire la rete a
Roma. Questi episodi risaltano quali esempi da manuale per quel che
riguarda gli aspetti di risk analysis per come, in entrambi casi,
l’evento, non solo si è prodotto, ma ha anche evidenziato che i
piani di Business Continuity non hanno operato al meglio. Eppure
siamo certi che entrambe le strutture avessero effettuato
correttamente le procedure previste ed effettuato i controlli
prescritti. E allora, perché?
Come sempre, “The devil is in the details”! Quanto più una
struttura è complessa, articolata e sofisticata, tanto più vale
la teoria di Charles Perrow dei “Normal Accidents”. Lo studioso
americano teorizzava, già a metà degli anni ’80, che in
presenza di strutture in cui possono verificarsi nel tempo in modo
arbitrario due o più eventi avversi, esisterà sempre una
concatenazione tale da rendere inefficienti i sistemi di ridondanza
presenti (si veda il black-out del 2003 negli Usa); quindi la
domanda da porsi non è se un evento disastroso accadrà, ma solo
quando questo succederà.
Cerchiamo di vedere, però, il bicchiere mezzo pieno. Questi
episodi devono farci riflettere su come dovrebbe intendersi la
Business Continuity. Da più parti sta emergendo la necessità di
una sua diversa impostazione, che trova appropriata declinazione in
due leggere e complementari varianti di tale espressione, ovvero
“Business Resilience” e “Service Continuity”. Con la
locuzione “Business Resilience” si mette in evidenza che
l’obiettivo è disegnare sistemi e processi robusti, in grado
cioè di operare, eventualmente in modalità degradata, anche in
assenza di alcuni o molti dei suoi elementi strategici. Nella
letteratura inglese si è introdotto il termine di plasticity per
indicare, appunto, la capacità del sistema di adattarsi alle
risorse disponibili e, quindi, di mantenere la sua capacità di
erogare in ogni caso un sotto-insieme di servizi.
L’altro termine, “Service Continuity”, appare ancora più
rivoluzionario. L’elemento principale delle politiche di gestione
degli eventi anomali non è più la perseveranza del business
quanto porre al centro dell’attenzione l’utente finale.
Apparente paradosso considerando il fine ultimo delle aziende: fare
business. Ma è sempre più chiaro che l’obiettivo si centra solo
coinvolgendo l’utente nel processo di gestione dell’evento
avverso. Un aspetto che ha molto infastidito gli utenti è stata la
quasi totale assenza di informazioni che le società hanno fornito
all’utenza. Sia Telecom Italia che Aruba, nella fase incipiente
della crisi, non hanno ritenuto di dover allertare i propri clienti
, né fornito indicazioni sull’evoluzione della crisi e sulle
previsioni relative alla soluzione.
Rendendo impossibile la messa in esercizio delle strategie di
contenimento del danno da parte degli utenti. Con una comunicazione
immediata Acea avrebbe potuto dislocare squadre di intervento sul
territorio per operazioni di manovre manuali. Allertando
tempestivamente gli utenti Aruba avrebbe consentito loro di mettere
in atto varie tipologie di azione, come, per fare un solo esempio,
il reindirizzamento. La “security by obscurity” non è
certamente la strada migliore per approcciare queste
problematiche.
* Direttore Master in Homeland Security dell’Università Campus
Biomedico
e Segretario dell’Associazione Italiana Esperti Infrastrutture
Critiche-Aiic
