Valutare SLA hosting e cloud: continuità, backup e penali

Criteri per valutare gli SLA di hosting e cloud

Per valutare uno SLA di hosting o cloud occorre separare disponibilità del servizio, recupero dei dati e rimedi economici. Una percentuale di uptime non garantisce da sola un backup recuperabile, mentre un credito non ripristina il servizio. La scelta richiede clausole verificabili su ciascun aspetto, riferite al prodotto effettivamente acquistato.

Uno SLA (Service Level Agreement) è il contratto tra fornitore e cliente. 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. Indica anche 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. Lo stesso test vale per un servizio di hosting e per un servizio cloud.

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. Secondo AWS include dettagli dei servizi e disposizioni sulla disponibilità. Definisce anche le responsabilità, le procedure di escalation e i termini di cancellazione.

Un contratto multilivello integra più livelli di servizio in un unico documento. È usato dai fornitori che servono clienti a tariffe o livelli diversi.

Non tutti gli accordi hanno però valore di mercato. IBM e AWS ricordano che uno SLA può essere stipulato anche tra dipartimenti o unità della stessa organizzazione. Un esempio è tra team di sviluppo e aree di business, sulla cadenza di implementazione. Documenti interni di questo tipo non si confrontano con l'offerta di un fornitore.

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.

Uno SLA cloud va poi adeguato al modello di fruizione: SaaS, PaaS o IaaS. Lo indica il Manuale di abilitazione al cloud (v1.4) tra gli aspetti da tenere in considerazione nella redazione. Lo stesso fornitore può pubblicare documenti distinti per modello e per servizio: il confronto regge solo a parità di modello.

Per i servizi cloud qualificati destinati alla pubblica amministrazione, ACN ha adottato il Regolamento Cloud con Decreto Direttoriale n. 21007/24 del 27 giugno 2024, applicabile dal 1 agosto 2024. I servizi qualificati devono rispondere a requisiti e SLA definiti in quel regolamento.

Un esempio italiano di SLA a più livelli è Sistema Cloud Toscana, che pubblica due livelli differenziati: Base e Plus. Gli indicatori sono espressi in giorni, ore, minuti o percentuali rispetto a un periodo di osservazione trimestrale.

Nello SLA di Aruba Business i termini di responsabilità e garanzia entrano in vigore al momento della sottoscrizione di ciascun contratto di servizio e restano attivi per tutta la durata dello stesso. La validità temporale del documento va quindi verificata prima di mettere a confronto le percentuali di due fornitori.

Mettendo a confronto i nomi, AWS e IBM usano le stesse tre categorie: cliente, servizio, multilivello. Sistema Cloud Toscana adotta un modello multilivello a due livelli, Base e Plus, con indicatori trimestrali. Uniontel elenca tre modelli cloud: IaaS, PaaS e SaaS. Il Manuale di abilitazione al cloud indica che gli aspetti da considerare nella redazione dello SLA possono essere adeguati a questi modelli di fruizione. Il confronto richiede di allineare modello di fruizione e periodo di osservazione.

Il riferimento da registrare è il documento contrattuale applicabile al prodotto acquistato, insieme alla sua versione e al periodo di validità. Una guida generale del fornitore aiuta a interpretare le clausole, ma non sostituisce gli impegni del singolo servizio. Vanno controllati anche gli allegati richiamati dal contratto e le condizioni che stabiliscono quale testo prevale in caso di contrasto.

La scheda di valutazione deve separare continuità, backup e rimedi, senza usare una voce come prova delle altre. Per ciascun impegno occorre annotare servizio coperto, valore dichiarato, periodo di misura ed esclusioni. Dove il contratto richiede una scelta o una configurazione del cliente, va registrata anche quella: offerte apparentemente simili possono proteggere componenti diverse e attribuire responsabilità diverse.

Continuità di hosting e cloud: perimetro e periodo dell'uptime

Le percentuali di disponibilità vanno tradotte in tempo di indisponibilità. Il Manuale di abilitazione al cloud 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; 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.

Uniontel traduce altre soglie: 90% di uptime equivale a 36,5 giorni di indisponibilità l'anno; 99% a 3,65 giorni; 99,95% a 4,38 ore. Uniontel ricorda di verificare nel contratto se è prevista una penale per mancato funzionamento del servizio.

Il periodo di riferimento va letto accanto alla percentuale, distinguendo impegni mensili, trimestrali e annuali. Tradurre le soglie in tempo di indisponibilità aiuta a comprenderle, ma non rende equivalenti le clausole. Un fermo concentrato in un periodo breve può avere un peso diverso secondo l'intervallo usato per verificare il rispetto dello SLA.

Sistema Cloud Toscana distingue la disponibilità su base trimestrale per istanza attiva su singolo sito: 99,00% nel livello Base e 99,50% nel Plus. Per istanze attive contemporaneamente su più siti, la disponibilità è 99,60% Base e 99,90% Plus.

Il solo numero non basta. Tra le metriche da considerare nella definizione degli SLA cloud, il Manuale indica 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. Vanno stimati a parte e pesati sul monte ore annuo.

Sistema Cloud Toscana prevede che le attività di manutenzione programmata che possono causare fermi si svolgano solo negli orari indicati per livello di criticità. Per il livello non critico la finestra indicata inizia dalle 20:00 del lunedì.

Uno SLA cloud va letto anche rispetto ai cambi di infrastruttura. Per i provider cloud i cambiamenti infrastrutturali sono molto più frequenti e avvengono in modo trasparente. 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.

Aruba Business dichiara il 99,95% annuo per disponibilità dei nodi fisici e accessibilità internet dell'infrastruttura Public e Virtual Private Cloud, con il 100% annuo per elettricità e/o aria condizionata. Per l'hosting, il 99,95% annuo riguarda DNS server, web server, database server e mail server. Gli impegni vanno associati ai rispettivi servizi, senza trasferire automaticamente una garanzia da un perimetro all'altro.

Il confronto deve mantenere visibili sia il periodo di osservazione sia la componente protetta. Una soglia sull'infrastruttura non equivale automaticamente alla disponibilità dell'applicazione, e una traduzione del downtime non è una garanzia commerciale. Prima di preferire una percentuale, occorre verificare che i contratti conteggino gli stessi eventi e prevedano esclusioni compatibili con l'uso aziendale.

Il confronto interno ad Aruba Business mostra la differenza di perimetro: hosting e Public e Virtual Private Cloud riportano entrambi il 99,95% annuo. Nell'hosting si misurano DNS, web, database e mail server; nel cloud, nodi fisici e accessibilità internet dell'infrastruttura virtuale. La percentuale coincide, ma il componente garantito cambia: va scelto quello pertinente al servizio che sostiene l'attività aziendale.

Uptime e downtime annuo: equivalenze chiave

Backup di hosting e cloud: clausole da verificare

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, diritti di accesso e consultazione. Aggiunge conformità alle normative vigenti e modalità e tempi di comunicazione del provider in caso di data breach.

Sono voci da cercare nel contratto e negli eventuali documenti che richiama. Se una clausola non è esplicita, occorre chiarire per iscritto quale impegno si applica prima di considerarlo nella scelta.

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.

Per il backup vanno verificati frequenza dei salvataggi, conservazione delle copie e tempo di ripristino, insieme ai dati effettivamente inclusi. La frequenza aiuta a valutare quante modifiche recenti potrebbero andare perse; la conservazione determina quanto indietro si può tornare. Il tempo di ripristino va distinto dal tempo necessario per riaprire una segnalazione o ricevere assistenza.

Sistema Cloud Toscana nomina i servizi di vStorage o Backup tra le voci con livelli di servizio. Per questi servizi vanno richiesti frequenza, conservazione e tempo di ripristino.

Per rendere verificabile il recupero, occorre precisare da quale evento decorre il tempo di ripristino e quale risultato ne segna la conclusione. Rendere disponibile una copia non equivale necessariamente a riattivare l'applicazione. Vanno inoltre chiariti i compiti del fornitore e quelli del cliente, comprese le verifiche necessarie prima di tornare a usare i dati.

La replica e il backup rispondono a esigenze diverse. Una copia replicata può propagare anche una modifica indesiderata, mentre il recupero richiede una versione utilizzabile dei dati.

Aruba Business descrive replica e backup geografico per i dati del web hosting su storage SAN dedicati. La valutazione deve quindi partire dall'oggetto del salvataggio: perimetro dei dati, frequenza, conservazione e ripristino vanno verificati nelle condizioni dell'offerta scelta, senza dedurli dalla sola descrizione tecnica.

Sul lato hosting Aruba Business ospita i dati del web hosting su storage SAN dedicati con replica e backup di tipo geografico, sfruttando la rete di data center del gruppo Aruba.it. I dati del mail hosting sono ospitati su storage NAS dedicati con replica sincrona di tipo geografico.

Supporto: distinguere copertura, risposta e risoluzione

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.

Tra i parametri elencati da AWS ci sono anche i tempi di consegna, accanto a tempi di attività, risposta e risoluzione. Nel confronto vanno tenuti distinti: un tempo di consegna non è un tempo di ripristino.

Il tempo di risposta misura quanto passa prima che qualcuno prenda in carico la segnalazione. Il tempo di risoluzione misura quanto passa prima che il servizio torni operativo.

Una risposta rapida è utile, ma non compensa da sola una risoluzione lenta. La continuità richiede di valutare insieme presa in carico, ripristino e copertura del supporto, evitando di scambiare la disponibilità dell'assistenza per un tempo garantito di chiusura.

Nello SLA a livello di cliente, secondo AWS, rientrano le procedure di escalation. Al confronto vanno 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 serve a capire se gli obiettivi dichiarati sono raggiungibili o restano sulla carta.

Sistema Cloud Toscana offre un esempio numerico affiancabile. La copertura della gestione guasti bloccanti è 24x7x365 sia per Base sia per Plus. Per i guasti non bloccanti, il Base copre 9:00-17:00 lun-ven e 9:00-13:00 sab festivi esclusi; il Plus 7:30-19:30 lun-ven e 7:30-14:00 sab festivi esclusi.

Per il service desk, change e richieste informative seguono gli stessi orari.

I tempi di risoluzione sono: guasto bloccante grave 2 ore nel 100% dei casi in entrambi i livelli; guasto bloccante 6 ore nel 100% Base e 2 ore nel 100% Plus; guasto non bloccante 8 ore nel 95% e 24 ore nel 100% Base, 4 ore nel 95% e 12 ore nel 100% Plus.

I tempi di risposta per richieste di change, informative o altro sono 8 ore nel 95% e 24 ore nel 100% Base; 4 ore nel 95% e 12 ore nel 100% Plus. Sono valori da inserire nella colonna del fornitore.

Per i servizi FM di gestione istanze, Sistema Cloud Toscana prevede lo stesso SLA dei servizi IaaS e PaaS a cui si applicano. Va riportato accanto alle metriche di supporto.

Per nome, Uniontel definisce i propri SLA come tempo di intervento in caso di fermo sistemi o guasti non bloccanti; il valore numerico e la copertura oraria vanno richiesti nel contratto. AWS include procedure di escalation e tempi di risposta e risoluzione nello SLA per cliente.

Sul lato hosting, la copertura oraria dichiarata va riportata accanto ai tempi di risoluzione, perché un'assistenza limitata ai giorni lavorativi cambia il valore effettivo dell'impegno.

Penali e crediti: calcolo, condizioni e rimedi

Uno SLA definisce le misure da adottare quando gli standard pattuiti non vengono soddisfatti. Indica 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.

Uniontel ricorda di verificare se lo SLA contrattuale prevede una penale in caso di mancato funzionamento del servizio. È un controllo da fare prima di confrontare i rimedi economici.

Nel confronto la domanda non è solo quanta disponibilità viene promessa, ma cosa si ottiene quando la promessa cade.

Un credito di servizio va distinto da un rimborso e da un risarcimento: la sua funzione dipende dalle condizioni contrattuali. Per valutarlo occorre registrare l'evento che lo attiva, la base economica su cui viene calcolato e il modo in cui può essere utilizzato. La sola presenza della parola penale non permette di stimare il rimedio ottenibile.

Un credito crescente può rendere il rimedio più sensibile alla gravità della violazione, ma non coincide necessariamente con il danno subito dall'azienda. Il confronto economico deve tenere separati il valore contrattuale recuperabile e il costo operativo del fermo. Anche un credito significativo può lasciare scoperti effetti come lavoro interrotto o vendite perse.

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.

Sul lato hosting iWebLab calcola il credito sul canone mensile del solo servizio interessato e non può eccedere il 50% di tale canone per ciascun periodo di riferimento. La richiesta va trasmessa tramite il sistema di assistenza nell'area riservata entro 30 giorni dal termine del periodo di riferimento, indicando il servizio interessato e il periodo di indisponibilità lamentato.

Lo SLA di AWS Shield Advanced prevede, per ciascun intervallo di 24 ore in Tempo Coordinato Universale con un'interruzione delle Risorse Designate che contribuisce al mancato rispetto dell'Impegno di Servizio, un credito pari alla media degli addebiti giornalieri per AWS Shield Advanced nel ciclo di fatturazione mensile interessato. I crediti non sono trasferibili né applicabili ad altro account.

Per AWS Shield Advanced, la richiesta deve pervenire entro la fine del secondo ciclo di fatturazione successivo all'incidente. Deve includere le parole Richiesta di credito SLA nell'oggetto, date e orari delle interruzioni e log che documentino gli errori, rimuovendo o oscurando le informazioni riservate o sensibili. La mancata presentazione della richiesta e delle informazioni richieste comporta l'inidoneità al credito.

Salvo diversa previsione del Contratto AWS, inclusi gli SLA delle Risorse Designate, il credito è l'unico ed esclusivo rimedio per l'indisponibilità delle risorse designate per la protezione di AWS Shield Advanced. Questa condizione va valutata insieme all'importo del credito e alla procedura per richiederlo.

Monitoraggio: verificare cosa misura lo SLA

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 le metriche misurate, la periodicità e gli strumenti (dashboard, report periodici). Va verificato se i dati sono accessibili al cliente e se esistono registrazioni storiche utilizzabili in caso di contestazione su un disservizio passato.

Sistema Cloud Toscana misura gli indicatori in giorni, ore, minuti o percentuali rispetto a un periodo di osservazione trimestrale. La disponibilità è differenziata tra istanze su singolo sito e istanze su più siti.

Il periodo di osservazione va riportato nella scheda senza cancellare quello previsto dal contratto. Un'equivalenza annuale aiuta a interpretare la soglia, ma non modifica l'intervallo con cui si accerta una violazione. Per valutare offerte diverse servono anche lo stesso perimetro di misura e una lettura delle rispettive esclusioni.

Il punto di misura cambia il significato della disponibilità. Un'infrastruttura raggiungibile può ospitare un'applicazione che non risponde correttamente, mentre un errore applicativo può dipendere da componenti gestiti dal cliente. Occorre quindi identificare l'operazione verificata, il risultato considerato valido e il confine delle responsabilità, prima di usare quel dato come misura della continuità aziendale.

Lo stesso criterio vale per hosting e cloud. Uno SLA che misura il server non misura necessariamente il servizio usato dal cliente. Va verificato da quale punto di osservazione è calcolata la percentuale e su quale componente.

Le registrazioni devono permettere di ricostruire inizio, fine e natura del disservizio. Prima di scegliere, va chiarito come si confrontano i dati del cliente con quelli del fornitore e come si gestiscono eventuali divergenze. Un indicatore consultabile senza una cronologia utilizzabile rende più difficile documentare una contestazione.

Per l'hosting iWebLab pubblica l'oggetto delle verifiche: richiesta HTTPS verso il nodo che ospita il servizio, connessione ai servizi SMTP e IMAP del nodo di posta, interrogazione dei nameserver autoritativi, raggiungibilità di rete di VPS e server dedicati. Per VPS e server dedicati il sistema operativo e i servizi interni all'istanza restano di competenza del cliente: è il perimetro da confrontare con il punto di misura dichiarato dagli altri fornitori.

SLA e KPI: distinguere obblighi e indicatori

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 e impegni contrattuali non sono equivalenti.

Per ogni metrica bisogna risalire alla clausola che stabilisce l'impegno e verificare quali documenti fanno parte del contratto. La collocazione in un allegato tecnico non esclude da sola un obbligo, così come una dichiarazione commerciale non basta da sola a definire il rimedio. Il confronto deve collegare valore promesso, modalità di misura, responsabilità ed effetti dell'eventuale violazione.

Anche i livelli Base e Plus di Sistema Cloud Toscana vanno confrontati solo per le metriche che il contratto rende vincolanti. Un indicatore di monitoraggio non produce crediti.

Le metriche fuori dagli impegni vincolanti vanno confrontate a parte, come informazioni sulla qualità dichiarata e non come clausole su cui fondare il confronto.

Nella scheda conviene separare gli impegni contrattuali dagli indicatori informativi, mantenendo per ciascuno il riferimento alla clausola pertinente. Un dato operativo può aiutare a valutare la qualità del servizio, ma non deve essere presentato come una garanzia economica. Questa distinzione evita di premiare un'offerta solo perché pubblica più metriche.

Scheda di valutazione degli SLA di hosting e cloud

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

La prima parte della scheda deve identificare il servizio e il componente la cui disponibilità viene garantita. Per un sito occorre distinguere infrastruttura, servizio web e applicazione; per la posta, il perimetro deve corrispondere alle funzioni utilizzate. Vanno poi affiancati percentuale, periodo contrattuale, esclusioni e condizioni di manutenzione, così che una soglia più alta non nasconda una copertura meno pertinente.

Sul fronte dati e sicurezza va riportato se il backup è incluso o venduto a parte, con frequenza, periodo di conservazione e tempi di ripristino. Vanno indicati i livelli di crittografia per dati in transito e a riposo, chi può accedere ai dati e consultarli e la conformità alle normative applicabili. Vanno verificate anche le modalità e i tempi di comunicazione del provider in caso di data breach.

Sul fronte operativo e contrattuale vanno confrontati tempo di risposta e tempo di risoluzione per ciascun livello di severità. Vanno verificate procedure di escalation e orari di copertura del supporto.

Per ogni categoria di guasto la scheda deve riportare separatamente risposta e risoluzione, insieme alla quota di casi cui si applica ciascun obiettivo. Va verificato da quando decorre il conteggio e se esistono condizioni che lo sospendono. Richieste informative e modifiche vanno tenute separate dagli incidenti: rispondere a una domanda non equivale a ripristinare un servizio.

Uniontel definisce i propri SLA come tempo di intervento in caso di fermo sistemi o guasti non bloccanti. Va chiesto il valore numerico e la copertura oraria corrispondente.

Vanno letti i rimedi previsti (crediti di servizio, supporto aggiuntivo) con condizioni di attivazione, base di calcolo e tetti. Vanno infine confrontate metriche monitorate, frequenza della reportistica e strumenti di verifica disponibili per il cliente. Va distinto quali metriche sono impegni vincolanti e quali semplici indicatori.

Alla scheda di ciascun fornitore vanno aggiunti il modello di fruizione (SaaS, PaaS, IaaS) e le date di inizio e fine del contratto previste dalla panoramica contrattuale (AWS). Sono i riferimenti che dicono a quale documento si applicano le percentuali e i crediti messi a confronto.

Accanto a ogni valore va riportato il suo periodo di osservazione, senza attribuire a tutti i servizi quello di un singolo contratto. Vanno annotati anche eventuali richiami allo SLA di altri servizi e le esclusioni della manutenzione programmata, verificando che valgano per la configurazione acquistata.

Solo le voci che il fornitore mette per iscritto in queste categorie entrano nel confronto. Tutto il resto resta una dichiarazione da verificare.

Per Aruba Business, la voce hosting riporta il 99,95% annuo sulla disponibilità di DNS, web, database e mail server; elettricità e climatizzazione vanno associate al perimetro previsto dallo SLA. Per iWebLab, che verifica hosting web, posta, DNS, CDN, VPS e server dedicati, la voce rimedi registra un credito sul canone mensile del servizio interessato, con tetto del 50% per periodo di riferimento.

Per Sistema Cloud Toscana il capitolo 7 del Capitolato Tecnico (Allegato 1) contiene ulteriori indicatori e approfondimenti.

La scheda deve includere anche gli eventi esclusi dal conteggio. iWebLab elenca, tra gli altri, malfunzionamenti di applicazioni o configurazioni gestite dal cliente, superamento dei limiti di risorse del piano e problemi della connettività del cliente. Queste condizioni vanno confrontate con le responsabilità interne dell'azienda: il rimedio contrattuale non sostituisce la gestione delle componenti lasciate a suo carico.

Il confronto dei crediti richiede basi di calcolo distinte: iWebLab usa il canone mensile del servizio interessato, con tetto del 50% per periodo e richiesta entro 30 giorni dal termine. AWS Shield Advanced usa la media degli addebiti giornalieri del servizio nel ciclo mensile interessato, per ciascun intervallo di 24 ore qualificante. Importi, eventi coperti e termini di richiesta vanno letti insieme.

La scelta finale deve collegare ogni impegno a un'esigenza aziendale: servizio disponibile, dati recuperabili e rimedio attivabile. Per gli aspetti decisivi occorre ottenere condizioni scritte prima dell'acquisto, invece di dedurre garanzie dalla tecnologia impiegata o dall'orario dell'assistenza. La scheda diventa utile quando rende visibili responsabilità, esclusioni e conseguenze del disservizio, oltre ai valori dichiarati.