Server e SLA: cosa garantisce davvero il provider
Lo SLA (Service Level Agreement) e l'impegno contrattuale del provider sulla qualità del servizio. Molti acquistano "uptime 99,9 percento" senza capire cosa significhi davvero, cosa sia incluso o escluso, e quali siano le penali. Vediamo come leggere uno SLA e cosa pretendere.
Le percentuali di uptime tradotte
Uptime annuo significa tempo massimo di indisponibilita all'anno: 99 percento = circa 3 giorni 15 ore; 99,9 percento = circa 8 ore 45 minuti; 99,95 percento = circa 4 ore 22 minuti; 99,99 percento = circa 52 minuti; 99,999 percento = circa 5 minuti. Ogni "9 in più" cambia di una classe l'infrastruttura richiesta e i costi.
Cosa copre lo SLA tipico
Lo SLA standard copre uptime della rete e disponibilità dell'host, non la disponibilità applicativa. Se il tuo Apache crasha per un tuo errore, il provider non e responsabile. Se la rete del datacenter ha un guasto, si. Leggi attentamente la definizione di "downtime": alcuni provider lo calcolano solo se l'intero datacenter e down, escludendo guasti localizzati.
Esclusioni comuni
- Manutenzioni programmate (con preavviso).
- Cause di forza maggiore (catastrofi naturali, attacchi DDoS volumetrici).
- Errori del cliente (mis-configurazioni).
- Problemi di rete a monte (carrier upstream).
- Brute force, DDoS applicativi.
Tempi di risposta e di intervento
SLA seri specificano Response Time (quanto impiega il supporto a rispondere) e Resolution Time (quanto a risolvere). Categorie tipiche: P1 (server down, 15 min response), P2 (servizio degradato, 1 h), P3 (problemi minori, 4 h). Verifica disponibilità 24/7 vs orari ufficio.
Penali e crediti
Il rispetto dello SLA si misura con service credit: percentuale di rimborso sulla fattura mensile se l SLA non e rispettato. Esempio: uptime 99,5-99,9 = 10 percento credit; 99,0-99,5 = 25 percento; sotto 99 = 100 percento. I credit non rimborsano il danno economico subito: per quello servono assicurazioni cyber dedicate.
Procedura passo-passo per leggere uno SLA
- Leggi la definizione esatta di "downtime".
- Identifica esclusioni e cause non coperte.
- Verifica orari del supporto e canali di apertura ticket.
- Controlla tempi di response e resolution per priorità.
- Esamina le penali e modalita di richiesta credit.
- Verifica come viene misurato l'uptime (monitor esterno o interno?).
- Annota il tempo di preavviso per manutenzioni.
- Chiedi storico di uptime degli ultimi 12 mesi.
Errori comuni e come risolverli
- Pensare che 99,99 e standard: lo e per cloud enterprise, non per VPS economici.
- Assumere copertura DDoS: spesso esclusa, va negoziata.
- Non richiedere mai service credit: vanno reclamati, non sono automatici.
- Confondere uptime di rete con uptime applicativo: il provider non gestisce le tue app.
Domande frequenti
D: Uptime 100 percento esiste?
R: No nella pratica; oltre 99,99 si parla solo di architetture multi-region.
D: Come misurare uptime real?
R: Monitor esterno indipendente (UptimeRobot, Pingdom).
D: Posso negoziare SLA?
R: Per grandi clienti enterprise si; per contratti retail di solito no.
Approfondimento tecnico: metriche di misurazione
Come si misura davvero il rispetto di uno SLA? I provider seri pubblicano metodologia: probe esterni multi-region, soglia di "downtime" (es. 3 check consecutivi falliti), esclusioni esplicite. Le misurazioni interne del provider sono spesso più favorevoli di quelle che faresti tu da fuori. La best practice client-side: monitor indipendenti (UptimeRobot, Pingdom) da regioni distinte, log datati di ogni incident, screenshot di error page, ticket aperti con timestamp.
Le credit clause hanno spesso clausole nascoste: massimo del credit, richiesta entro N giorni dall'incident, prova documentale a carico del cliente. Conserva tutto, automatizza l'invio di richiesta credit.
Scenari d'uso reali
Un e-commerce con SLA 99,9 percento e provider che ha avuto 12 ore down in un'anno: pretende credit di 25 percento mensile.
Un cliente enterprise negozia SLA personalizzato: 99,99 percento + tempo di response 15 minuti 24/7 + penali più pesanti.
Una startup accetta SLA 99,5 percento del provider economico, mitigando con architettura multi-region propria.
Checklist operativa SLA
- Definizione di downtime chiara.
- Esclusioni e cause non coperte mappate.
- Tempi di response/resolution documentati.
- Modalita di richiesta credit definite.
- Monitor esterno indipendente per misurare.
- Storico incident conservato.
- Review annuale dello SLA con il provider.
Risorse e riferimenti
ISO/IEC 20000 service management standard. ITIL framework. Pubblicazioni provider su SLA: AWS, Azure, GCP. Strumenti monitoring esterno: UptimeRobot, Pingdom, StatusCake. Per analisi penali, supporto legale e contract management essenziale.
Considerazioni economiche e organizzative
Implementare correttamente quanto descritto in questo articolo su server e sla richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.
Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.
Glossario rapido dei termini chiave
RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).
Hai bisogno di aiuto?
Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.