SLA e Downtime: calcolare i costi dell’inattività IT

Le organizzazioni, quando un sistema smette di funzionare, pensano subito a come rispristinarlo. Solo dopo ci si chiede quanto sia costato il downtime e, spesso, non c’è una risposta, perché il downtime viene trattato come un evento tecnico e non come una voce di rischio finanziario.

Tuttavia, un’ora di inattività dell’e-commerce, del gestionale o della processo produttivo incide su ricavi, produttività, reputazione e rapporti con i clienti.

Gli SLA (Service Level Agreement) sono lo strumento con cui l’organizzazione trasforma la disponibilità dei servizi in un impegno misurabile. Ma affinché i servizi funzionino, serve un passaggio preliminare: sapere quanto costa davvero il downtime.

Come calcolare l’impatto economico del downtime sui servizi aziendali

È importante evidenziare che il costo del downtime non coincide con il fatturato perso durante il blocco: una stima affidabile parte dalla distinzione tra processi critici e processi tollerabili e dal peso che ciascuno ha sul funzionamento dell’organizzazione.

Inoltre, la stima delle perdite finanziarie derivanti dall’inoperatività dei sistemi deve integrare la mappatura dei rischi ibridi, definendo la tolleranza massima al disservizio per ciascun processo core.

È proprio su questa base che si può costruire il calcolo dell’impatto economico del downtime, considerando la seguente semplice formula che, ovviamente, ciascuna organizzazione deve adattare al proprio contesto:

Quali sono i costi diretti e indiretti generati dall’inoperatività dei sistemi IT

È importante evidenziare che, per applicare correttamente la formula, bisogna sapere quali voci includere, distinguendo tra ciò che risulta subito evidente e ciò che emerge nel tempo.

I costi diretti sono i più semplici da rilevare:

• mancate vendite e ordini non evasi durante il fermo;
• stipendi pagati a personale che non può lavorare;
• interventi tecnici straordinari e consulenze di emergenza;
• penali contrattuali verso clienti e partner;
• rimborsi o crediti di servizio riconosciuti agli utenti.

I costi indiretti, invece, sono meno visibili, ma spesso più gravosi:

• danno reputazionale e perdita di fiducia dei clienti;
• abbandono verso la concorrenza;
• ritardi a catena su produzione, logistica e fatturazione;
• calo di morale e produttività interna;
• possibili sanzioni per violazioni normative, ad esempio se l’indisponibilità riguarda dati soggetti a obblighi di legge.

Si consiglia di assegnare a ogni processo un costo orario di fermo, tenendo conto di fasce lavorative e periodi di picco, considerando che lo stesso guasto costa molto di più durante una campagna promozionale che di notte.

Come definire le metriche RTO e RPO all’interno dei contratti di servizio (SLA)

Dopo aver determinato il costo del fermo, il passo successivo è tradurre la tolleranza al disservizio in requisiti tecnici misurabili.

Lo standard ISO 22301, riferimento internazionale per i sistemi di gestione della continuità operativa (BCMS, Business Continuity Management System), affronta il tema attraverso gli obiettivi di ripristino, che nella pratica si esprimono con due parametri:

• RTO (Recovery Time Objective), i.e. il tempo massimo entro cui un servizio deve tornare operativo dopo un’interruzione.
• RPO (Recovery Point Objective, i.e. la quantità massima di dati che l’azienda accetta di perdere, misurata come distanza temporale dall’ultimo salvataggio utile.

È i importante evidenziare che tali valori non si scelgono in modo arbitrario e scaturiscono dalla Business Impact Analysis (BIA), ovvero, l’analisi che stima come l’interruzione di ciascuna attività produca danni crescenti nel tempo e che individua il periodo massimo tollerabile di interruzione (MTPD, Maximum Tolerable Period of Disruption), oltre il quale le conseguenze diventano inaccettabili.

È importante ricordare che l’RTO deve sempre restare entro questo limite: la convenienza economica guida la scelta, ma non può superare la soglia di tollerabilità.

Pertanto, per definire RTO e RPO da inserire nei SLA, in modo corretto e coerente con lo standard, si può procedere come segue:

1. partire dal costo orario di fermo di ciascun processo, valorizzato attraverso la BIA;
2. classificare i sistemi per criticità (per esempio critico, importante, non essenziale) e individuare l’MTPD di ciascun processo;
3. confrontare le soluzioni di ripristino possibili e scegliere quella che minimizza il costo totale, dato dalla somma tra costo di protezione (investimenti e canoni) e perdita attesa residua (costo orario di fermo × durata dell’interruzione × frequenza stimata degli eventi), verificando che l’RTO risultante resti entro l’MTPD;
4. inserire i valori nel contratto SLA in forma esplicita, con modalità di misurazione e verifica, assicurandosi che i fornitori si impegnino su obiettivi allineati a quelli del proprio piano di continuità.

È importante evidenziare che valori troppo ambiziosi, in termini di RTO e RPO, comportano investimenti sproporzionati, mentre valori troppo laschi lasciano l’azienda esposta a perdite evitabili. Il punto di equilibrio non è quello in cui i due costi si uguagliano, ma quello in cui il loro totale è più basso, sempre nel rispetto dei limiti di tollerabilità emersi dalla BIA.

Pertanto, RTO e RPO vanno riesaminati con regolarità e messi alla prova con test di ripristino, considerando che occorre dimostrare che gli obiettivi dichiarati siano realmente raggiungibili e non solo scritti nel contratto.

ESEMPIO – A titolo puramente illustrativo, ipotizziamo i seguente caso per comprendere meglio il tutto.

Si ipotizzano questi dati di partenza:

• costo di fermo del processo: 10.000 € all’ora;
• frequenza stimata degli eventi gravi: 3 interruzioni l’anno;
• costo di ricostruzione dei dati persi: 500 € per ogni ora di dati non recuperati, per evento;
• MTPD emerso dalla BIA: 4 ore.

Fase 1: quantificare le ore di fermo – Ogni soluzione ha un RTO diverso, quindi produce un fermo complessivo diverso. Moltiplicando l’RTO per il numero di eventi si ottengono le ore di inattività annue, che si possono poi ricondurre a una media giornaliera e a una percentuale di disponibilità.

La media giornaliera è calcolata su 365 giorni. Per un processo attivo solo nei giorni lavorativi, il valore va rapportato ai giorni effettivi di operatività.

Fase 2: tradurre le ore in euro e sommare i costi – Le ore di fermo si moltiplicano per il costo orario. A questo si aggiunge la perdita dovuta ai dati non recuperati, determinata dall’RPO, e il costo annuo della soluzione.

Fase 3: giustificare la scelta. La soluzione B è la più conveniente in quanto:

1. Rispetta il vincolo di tollerabilità. Il suo RTO di 2 ore rientra nell’MTPD di 4 ore. La soluzione A, con RTO di 8 ore, lo supera ed è esclusa a prescindere dal costo, anche se è la più economica da mettere in opera.
2. Minimizza il costo totale. Rispetto ad A, l’investimento aggiuntivo di 30.000 € l’anno elimina 18 ore di fermo e circa 184.500 € di perdite. Rispetto a C, risparmia 21.000 € l’anno: passare al failover automatico farebbe recuperare solo 5,25 ore di fermo (circa 52.500 € di perdita da fermo) e 1.500 € di perdita da dati, a fronte di 75.000 € di costo di protezione in più.

L’RTO di 2 ore e l’RPO di 1 ora sono quindi i valori da inserire nel contratto SLA per questo processo.

Se le stime cambiassero, per esempio, con più interruzioni l’anno o un costo orario più alto, il punto di equilibrio si sposterebbe verso la soluzione C. Per questo l’esercizio va ripetuto a ogni revisione della BIA.

Come strutturare le garanzie di servizio per limitare le perdite finanziarie

Dopo aver definito le metriche, occorre renderle vincolanti. Un SLA efficace non si limita a dichiarare una percentuale di disponibilità: stabilisce cosa viene garantito, come viene misurato e cosa accade quando l’impegno non è rispettato.

Quali clausole e penali inserire nei contratti con i fornitori di infrastruttura

Nei contratti con provider di connettività, data center e servizi cloud è opportuno prevedere alcuni elementi fondamentali, tra cui:

• disponibilità garantita espressa in percentuale, con finestra di misurazione (mensile o annuale) ed esclusioni, come le manutenzioni programmate;
• tempi di risposta e di risoluzione differenziati per livello di gravità del guasto;
• RTO e RPO contrattuali coerenti con quelli definiti internamente;
• crediti di servizio o penali progressivi in base alla durata dell’interruzione;
• obblighi di reportistica e comunicazione tempestiva degli incidenti;
• diritto di audit sui sistemi di continuità operativa;
• clausole di uscita in caso di violazioni ripetute dei livelli di servizio.

Va però tenuto presente che il rimborso previsto dal fornitore in caso di disservizio – i.e. il cosiddetto credito di servizio – di solito non supera il canone mensile pagato che, raramente basta a coprire ciò che il fermo è costato davvero all’azienda.

Pertanto, per i servizi più critici conviene quindi negoziare limiti di rimborso più alti, oltre a valutare una copertura assicurativa che copra la differenza.

Come stimare il danno economico in caso di mancato rispetto dei livelli di servizio

Anche con un buon contratto, resta da capire quanto vale una violazione. Il metodo più solido si articola in tre passaggi:

1. Documentare l’evento: orari di inizio e fine, servizi coinvolti, cause dichiarate, log e ticket di segnalazione.
2. Applicare il costo orario di fermo ai processi colpiti, distinguendo perdite dirette e indirette.
3. Confrontare il danno con la penale contrattuale, per capire se il ristoro copre la perdita e con quale scarto.

Il risultato è utile anche in prospettiva: un fornitore che genera ripetutamente scarti elevati tra penale e danno reale giustifica una revisione delle condizioni o la valutazione di alternative al momento del rinnovo.

Come mitigare i rischi di inattività tramite l’architettura di rete

Le clausole contrattuali compensano il danno dopo che si è verificato, mentre l’architettura serve a evitarlo. Le due leve vanno usate insieme.

Come la ridondanza dei sistemi riduce l’esposizione ai blocchi operativi

Il principio di base è eliminare i single point of failure, cioè i componenti il cui guasto blocca l’intero servizio. Gli interventi più comuni sono:

• doppia connettività con provider e percorsi fisici differenti;
• apparati di rete ridondati (firewall, switch, router) in configurazione active-active o active-passive;
• alimentazione ridondata con gruppi di continuità e generatori;
• replica dei dati e dei sistemi su un secondo sito o in cloud, con procedure di failover testate;
• monitoraggio proattivo, per individuare le anomalie prima che diventino interruzioni.

È importante ricordare che ogni livello di ridondanza ha un costo, quindi, va applicato in proporzione alla criticità dei processi: i sistemi con RTO più stringente giustificano soluzioni più sofisticate, mentre per quelli meno critici possono bastare backup e ripristino manuale.

Anche il miglior piano di continuità perde valore se non viene collaudato, pertanto, si consiglia di svolgere test periodici di failover.

Come presentare l’analisi dei costi di downtime per approvare nuovi budget IT

Si tratta della fase più delicata, dato che il responsabile IT deve essere in grado di parlare il linguaggio della direzione, e alcuni accorgimenti aiutano:

• Tradurre il rischio in euro – Presentare il costo orario di fermo per processo e la perdita attesa annua, non solo dati tecnici.
• Mettere a confronto gli scenari – Situazione attuale e relativo rischio vs. situazione dopo l’investimento, con costo e riduzione dell’esposizione.
• Collegare la spesa agli obiettivi di business – Continuità delle vendite, tutela dei clienti chiave, conformità normativa.
• Proporre priorità e fasi – Partire dagli interventi con il miglior rapporto tra costo e riduzione del rischio.
• Indicare indicatori di verifica – Disponibilità effettiva, numero e durata degli incidenti, rispetto di RTO e RPO.

Di fatto, un’analisi chiara e quantificata sposta la discussione dal “quanto costa proteggersi” al “quanto costa non farlo”.