Confrontare gli SLA di hosting e cloud: continuità, backup e penali

Cosa rende confrontabili due SLA per hosting e cloud

Uno SLA (Service Level Agreement) è il contratto tra fornitore e cliente che definisce servizio e livello di prestazioni, il modo in cui misurarle e approvarle e le conseguenze del mancato raggiungimento (IBM). Nel cloud elenca parametri come tempi di attività, consegna, risposta e risoluzione, e le azioni previste in caso di scostamento, per esempio supporto aggiuntivo o sconti sui prezzi (AWS). Due offerte sono confrontabili solo se contengono tutte e tre le parti: livello promesso, metrica di misura, conseguenza del mancato raggiungimento.

Il primo controllo riguarda il tipo di SLA. IBM ne distingue tre: a livello di cliente, a livello di servizio e multilivello. Lo SLA a livello di servizio descrive un servizio definito offerto a più clienti con lo stesso livello di servizio e assistenza: è il formato tipico dell'offerta standard pubblicata online. Quello a livello di cliente copre i servizi specifici usati da un singolo cliente e, secondo AWS, include dettagli dei servizi, disposizioni sulla disponibilità, definizione delle responsabilità, procedure di escalation e termini di cancellazione. Un contratto multilivello integra più livelli di servizio in un unico documento ed è usato dai fornitori che servono clienti a tariffe o livelli diversi. Confrontare lo SLA standard di un servizio con uno a livello di cliente significa mettere a confronto documenti di ambito diverso: prima della tabella va accertato se si confrontano condizioni valide per tutti o impegni negoziati.

Uptime e continuità: leggere le percentuali oltre il numero

Le percentuali di disponibilità vanno tradotte in tempo di indisponibilità. Il Manuale di abilitazione al cloud di Docs Italia riporta le equivalenze: 99,9% di uptime equivale a 8,77 ore di downtime l'anno, 99,99% a 52,60 minuti, 99,999% a 5,26 minuti e 99,9999% a 31,5 secondi. Tra 99,9% e 99,99% non cambia un decimale, ma si passa da quasi nove ore a meno di un'ora di indisponibilità annua: è questo il dato da confrontare con il costo operativo di un fermo.

Il solo numero non basta. Secondo il Manuale, tra le metriche da considerare nella definizione degli SLA cloud c'è la capacità del servizio, cioè il carico o il numero massimo di utenti che possono accedere e le opzioni per espanderlo: un impegno di disponibilità che non regge il picco non protegge la continuità. Va poi verificato se le finestre di manutenzione programmata sono escluse dal calcolo dell'uptime: in quel caso l'indisponibilità dichiarata non comprende gli interventi pianificati, da stimare a parte e pesare sul monte ore annuo.

Uno SLA cloud va letto anche rispetto ai cambi di infrastruttura. Il Manuale osserva che per i provider cloud i cambiamenti infrastrutturali sono molto più frequenti e avvengono in modo trasparente, e che può essere utile chiedere al fornitore di essere informati su aggiornamenti o cambiamenti rilevanti, per pianificare e avvisare gli utenti di possibili downtime. Un impegno di preavviso, con tempi e canali definiti, è quindi un elemento contrattuale da confrontare quanto la percentuale di uptime.

Tempi di indisponibilità annuali per livello di uptime

Backup, protezione dati e accesso: cosa deve entrare nello SLA

Uno SLA cloud completo copre sicurezza del dato e regole di accesso. Il Manuale di abilitazione al cloud elenca tra le metriche da definire: protezione del dato, livelli di crittografia, politiche di backup, permessi di accesso e consultazione, conformità alle normative vigenti, modalità e tempi di comunicazione del provider in caso di data breach. Sono voci da cercare una per una nel contratto: se mancano, quel tema non è coperto.

Il punto pratico è distinguere ciò che è incluso nello SLA da ciò che si vende a parte. Il backup può essere compreso nel servizio o essere un'opzione separata, con costi e livelli propri: prima del confronto va chiarito se la politica di backup fa parte dell'offerta valutata o è un servizio aggiuntivo da preventivare. Per ogni voce vanno verificati frequenza dei salvataggi, periodo di conservazione, tempo di ripristino e chi ha i permessi di accesso e consultazione del dato. Un esempio di soglie contrattuali esplicite è nel modello SLA per reti aziendali pubblicato da Purple.ai: crittografia TLS 1.2 o superiore per i dati in transito, AES-256 per i dati a riposo e finestre di patch da 24 a 48 ore per le vulnerabilità di sicurezza critiche. Sono i valori numerici che rendono verificabile un impegno di sicurezza altrimenti generico.

Livelli di crittografia raccomandati per dati in transito e a riposo

Supporto: tempi di risposta e risoluzione come metriche di continuità

I tempi di risposta e di risoluzione sono parametri tipici di uno SLA (AWS). Il Manuale di abilitazione al cloud considera il supporto una parte fondamentale del rapporto con il fornitore cloud e lo divide in due metriche fondamentali, a partire dal tempo di risposta. Nel confronto vanno tenuti separati: il tempo di risposta misura quanto passa prima che qualcuno prenda in carico la segnalazione; il tempo di risoluzione, quanto passa prima che il servizio torni operativo. Un fornitore con risposta rapidissima e risoluzione lenta resta esposto su un guasto prolungato, e la continuità dipende dal secondo valore, non dal primo.

Nello SLA a livello di cliente, secondo AWS, rientrano le procedure di escalation. Al confronto vanno quindi verificati modalità di contatto, copertura oraria (giorni lavorativi o 24x7), livelli di severità previsti per guasti e degradi del servizio e a quale severità corrispondono i diversi obiettivi di tempo. Chiedere chi risponde fuori orario e come si scala il problema quando il primo livello non chiude la segnalazione è il modo concreto per capire se gli obiettivi dichiarati sono raggiungibili o restano sulla carta.

Penali, crediti e rimedi: cosa succede quando l'SLA non è rispettato

Uno SLA definisce le misure da adottare quando gli standard pattuiti non vengono soddisfatti, indicando metriche di misurazione e misure o sanzioni da applicare (Manuale di abilitazione al cloud). AWS cita tra le azioni possibili supporto aggiuntivo e sconti sui prezzi. Nel confronto la domanda non è solo quanta disponibilità viene promessa, ma cosa si ottiene quando la promessa cade.

Un esempio di struttura a livelli è nel modello per reti aziendali pubblicato da Purple.ai, che prevede crediti di servizio dal 10% al 50% della fattura mensile, legati a tempi di inattività verificati o a violazioni dello SLA. Con crediti crescenti in base alla gravità della violazione, il rimedio è legato all'entità del danno; un credito fisso e minimo, in proporzione, incide molto meno sui costi sopportati dal cliente durante il fermo.

Tre condizioni vanno lette prima di firmare. La prima è l'attivazione del rimedio: chi presenta la richiesta, con quali prove documentali (per esempio report di monitoraggio o ticket) e in quali termini. La seconda è il calcolo: su quale base di fatturazione si applica il credito e con quale tetto massimo per periodo. La terza è l'esclusività: se il credito è l'unico rimedio o se restano aperti altri percorsi contrattuali. Un rimedio ben formulato ma attivabile solo con oneri probatori a carico del cliente, o con finestre di richiesta molto brevi, è difficile da incassare nella pratica.

Monitoraggio e verifica: come misurare le prestazioni del fornitore

Il Manuale di abilitazione al cloud indica tra le metriche da considerare la definizione delle modalità con cui il fornitore monitorerà e riporterà le prestazioni del sistema. AWS pone la domanda speculare: in che modo il cliente può monitorare le prestazioni del fornitore in base allo SLA. Nel confronto vanno chieste esplicitamente: quali metriche vengono misurate, con quale periodicità, con quali strumenti (dashboard, report periodici), se i dati sono accessibili al cliente e se esistono registrazioni storiche utilizzabili in caso di contestazione su un disservizio passato.

Il punto di misura cambia il risultato. Il modello pubblicato da Purple.ai per le reti aziendali fissa una disponibilità dal 99,9% al 99,95% misurata dal punto di vista dell'autenticazione dell'utente finale, non dal semplice ping dell'hardware: la stessa interruzione può non comparire in una misurazione infrastrutturale ed essere evidente per l'utente. Lo stesso criterio vale per hosting e cloud: uno SLA che misura il server non misura necessariamente il servizio usato dal cliente, quindi va verificato da quale punto di osservazione è calcolata la percentuale e su quale componente.

SLA o KPI? Allineare impegni contrattuali e indicatori operativi

SLA e KPI non sono la stessa cosa, e AWS affronta la differenza nella sua guida. Uno SLA contiene impegni vincolanti: livello atteso, metrica di misura e conseguenza del mancato raggiungimento. Un KPI è un indicatore per monitorare l'andamento del servizio; può essere riportato periodicamente al cliente senza generare obblighi né penali. In fase di confronto il rischio è costruire una tabella con valori presi da sezioni diverse del documento — obiettivi interni del fornitore, indicatori di monitoraggio, impegni contrattuali — e trattarli come equivalenti.

Per allineare le due cose, il metodo è risalire per ogni metrica al testo che la rende obbligatoria. Se la disponibilità del 99,99% compare in un allegato tecnico o in una pagina di marketing, non produce rimedi; se compare come impegno contrattuale con metrica di misurazione e credito associato, allora è comparabile con l'analoga clausola di un altro fornitore. Le metriche fuori dagli impegni vincolanti vanno confrontate a parte, come informazioni sulla qualità dichiarata, non come clausole su cui fondare il confronto.

Checklist per confrontare due offerte hosting o cloud

Prima di scegliere, la comparazione va costruita su campi omogenei, riportando per ciascun fornitore: percentuale di uptime e downtime annuo equivalente; se le finestre di manutenzione programmata sono escluse dal calcolo; capacità del servizio e opzioni di espansione; impegni di preavviso per aggiornamenti o cambi infrastrutturali rilevanti.

Sul fronte dati e sicurezza: se il backup è incluso o venduto a parte, con frequenza, periodo di conservazione e tempi di ripristino; livelli di crittografia per dati in transito e a riposo; permessi di accesso e consultazione del dato; conformità alle normative applicabili; modalità e tempi di comunicazione del provider in caso di data breach.

Sul fronte operativo e contrattuale: tempo di risposta e tempo di risoluzione per ciascun livello di severità; procedure di escalation e orari di copertura del supporto; rimedi previsti (crediti di servizio, supporto aggiuntivo) con condizioni di attivazione, base di calcolo e tetti; metriche monitorate, frequenza della reportistica e strumenti di verifica disponibili per il cliente; quali metriche sono impegni vincolanti e quali semplici indicatori. Solo le voci che il fornitore mette per iscritto in queste categorie entrano nel confronto: tutto il resto resta una dichiarazione da verificare.