Accordo sul Livello di Servizio

1. Ambito di applicazione

Il presente Accordo sul Livello di Servizio ("SLA") è incorporato per riferimento nei Termini di Servizio e disciplina gli impegni di livello di servizio che assumiamo nei confronti dei clienti che utilizzano i Servizi descritti di seguito.

1.1 Servizi coperti

Il presente SLA si applica alle seguenti categorie di Servizi:

• Server virtuali privati (VPS), inclusi tutti i livelli Linux KVM
• Server Remote Desktop Protocol (RDP)
• Server dedicati (DS)
• Server GPU (GPU)
• Server di storage e backup
• Server di streaming
• Server di gioco

1.2 Servizi con impegni adeguati

L'hosting condiviso e cPanel prevede gli impegni di uptime di cui alla Sezione 2, ma con misurazione adeguata all'architettura del livello condiviso (l'obiettivo di misurazione pertinente è la disponibilità dell'host condiviso, non la disponibilità del contenitore per singolo cliente).

1.3 Servizi non coperti

L'hosting email e SMTP prevede impegni di disponibilità separati pubblicati sulle rispettive pagine di prodotto. I Servizi beta e in anteprima esplicitamente etichettati come tali non sono coperti dal presente SLA.

2. Impegno di Uptime

2.1 Piani standard

I piani standard — VPS-1 fino a VPS-8, RDP-Basic e RDP-Pro, tutti i livelli Storage, Game-S e Game-M, Streaming-1 — prevedono un impegno di uptime mensile del 99,9%.

Un uptime mensile del 99,9% corrisponde a un massimo di 43 minuti e 50 secondi di downtime in un mese di calendario di 30 giorni, o 44 minuti e 38 secondi in un mese di 31 giorni.

2.2 Piani Pro, Premium, Dedicati, GPU

I piani di livello superiore — VPS-16, RDP-Power, tutti i livelli Dedicati (DS-Lite fino a DS-Beast), tutti i livelli GPU (GPU-Lite fino a GPU-Beast), Game-L, Streaming-2 — prevedono un impegno di uptime mensile del 99,99%.

Un uptime mensile del 99,99% corrisponde a un massimo di 4 minuti e 23 secondi di downtime in un mese di calendario di 30 giorni, o 4 minuti e 28 secondi in un mese di 31 giorni.

3. Metodologia di Misurazione

3.1 Monitoraggio esterno

L'uptime è misurato da nodi di monitoraggio esterni gestiti da fornitori di uptime di terze parti (UptimeRobot, Better Uptime o equivalenti). Attualmente manteniamo tre (3) nodi di monitoraggio indipendenti situati in regioni geograficamente distinte per evitare misurazioni con punto singolo di guasto.

3.2 Intervallo di sondaggio

Ogni nodo di monitoraggio interroga l'endpoint primario di ciascun Servizio ogni cinque (5) minuti.

3.3 Rilevamento a maggioranza

Il downtime viene registrato quando almeno due dei tre nodi di monitoraggio segnalano il Servizio come non raggiungibile nella stessa finestra di sondaggio. Ciò evita di attribuire interruzioni di rete locali al nodo di monitoraggio a un incidente MurmurHost.

3.4 Accumulo di downtime

Un "minuto di downtime" è qualsiasi minuto intero durante il quale il rilevamento a maggioranza si trova nello stato di non raggiungibilità. I minuti parziali vengono arrotondati per eccesso a minuti interi ai fini del calcolo del credito.

3.5 Misurazione lato cliente

I clienti possono utilizzare la propria infrastruttura di monitoraggio per corroborare le richieste di downtime. Laddove la misurazione lato cliente diverga in modo sostanziale dal nostro monitoraggio, condivideremo i nostri dati di misurazione e cercheremo di concordare il periodo di downtime effettivo.

4. Crediti di Servizio

4.1 Fasce di credito

Se un Servizio coperto scende al di sotto del suo impegno di uptime mensile, il cliente ha diritto a un credito di servizio calcolato come percentuale della tariffa mensile per il Servizio interessato:

4.2 Applicazione

I crediti di servizio vengono applicati alla fattura successiva del Servizio interessato. Se il cliente termina il Servizio interessato prima della fattura successiva, il credito viene erogato come rimborso con il metodo di pagamento originale, soggetto ai termini di elaborazione della Politica di Rimborso.

4.3 Limite massimo

Il credito totale per qualsiasi Servizio interessato in un singolo mese non può superare il 100% della tariffa mensile di quel Servizio. I crediti di servizio costituiscono l'unico ed esclusivo rimedio del cliente per qualsiasi mancato rispetto degli impegni di uptime ai sensi del presente SLA.

5. Esclusioni

Quanto segue non conta come downtime ai fini della Sezione 2:

5.1 Manutenzione programmata

Manutenzione annunciata con almeno quarantotto (48) ore di preavviso tramite il pannello clienti e la pagina di stato su /status. Le finestre di manutenzione ordinaria sono generalmente programmate durante le ore non di punta per la giurisdizione pertinente.

5.2 Forza maggiore

Atti di Dio, disastri naturali, guerra, disordini civili, azioni governative, terrorismo o eventi comparabili al di fuori del nostro ragionevole controllo.

5.3 Colpa del cliente

Downtime causato da errata configurazione del cliente, bug software controllati dal cliente, superamento delle allocazioni di risorse del piano o operazioni eseguite dal cliente (come riavvio volontario, reinstallazione del sistema operativo o modifica della configurazione che disabilita l'accesso remoto).

5.4 Interruzioni di rete di terze parti

Downtime causato da interruzioni di rete di terze parti al di fuori della nostra rete e al di fuori dei nostri accordi di peering, incluse interruzioni del proprio ISP del cliente, del fornitore di transito o della rete dell'ultimo miglio.

5.5 Azioni relative all'AUP

La sospensione ai sensi dell'AUP non conta come downtime. Le sospensioni AUP contestate e annullate in appello non vengono conteggiate retroattivamente come downtime; il rimedio del cliente in tal caso è documentato nell'AUP.

6. Prestazioni di Rete

6.1 Obiettivi di latenza

Ci impegniamo a rispettare obiettivi di latenza mediana tra la nostra rete perimetrale e i principali internet exchange regionali, misurati mensilmente:

6.2 Perdita di pacchetti

Ci impegniamo a una perdita di pacchetti inferiore allo 0,1% sul traffico intra-datacenter misurato su qualsiasi finestra mobile di 5 minuti, esclusi gli intervalli interessati da mitigazione DDoS attiva.

6.3 Throughput

Ci impegniamo a garantire un throughput alla velocità di porta configurata sul Servizio, al netto del tipico overhead di incapsulamento e transito. Un throughput sostenuto sostanzialmente inferiore alla velocità di porta (dopo aver escluso la congestione di transito al di fuori della nostra rete) è considerato un mancato rispetto delle prestazioni di rete.

7. Tempi di Mitigazione DDoS

7.1 Attacchi volumetrici

Gli attacchi DDoS volumetrici che colpiscono i Servizi dei clienti vengono rilevati e contrassegnati dal nostro edge di scrubbing anycast entro sessanta (60) secondi dall'inizio dell'attacco. La mitigazione è automatica e non richiede azione da parte del cliente.

7.2 Attacchi a livello applicativo

Gli attacchi a livello applicativo (L7) richiedono regole specifiche per l'applicazione. Forniamo regole standard all'edge per modelli comuni; le regole adattate all'applicazione specifica del cliente (percorsi URL, firme delle richieste) sono responsabilità del cliente, opzionalmente configurabili tramite Cloudflare o BunnyCDN all'edge dell'applicazione.

7.3 Capacità per livello di piano

La capacità di scrubbing volumetrico scala con il livello del piano ed è documentata su /features/ddos-protection. Attacchi sostenuti al di sopra della capacità di scrubbing del piano possono innescare una conversazione sull'upgrade piuttosto che un credito di servizio.

8. SLA di Provisioning

8.1 Servizi basati su KVM

I piani KVM VPS, RDP, condivisi e cPanel completano il provisioning entro cinque (5) minuti dalla conferma del pagamento. La conferma è il momento in cui il pagamento in criptovaluta raggiunge le conferme di soglia descritte nella relativa pagina dei metodi di pagamento; per i pagamenti con carta dove supportati, la conferma è il regolamento presso il processore.

8.2 Dedicati e GPU

I piani dedicati e GPU di magazzino completano il provisioning entro ventiquattro (24) ore dalla conferma del pagamento. Le build dedicate personalizzate (multi-GPU, configurazioni RAID esotiche, modelli NIC specifici) vengono segnalate al momento dell'ordine e possono richiedere 1-3 giorni lavorativi.

8.3 Ordini all'ingrosso

Gli ordini all'ingrosso (più di cinque Servizi in una singola transazione) richiedono il coordinamento con il team di vendita. I tempi di consegna vengono concordati al momento dell'ordine e fanno parte dello SLA specifico dell'ordine.

8.4 Crediti per mancato provisioning

Se il provisioning supera l'obiettivo pertinente di oltre il 25%, il cliente ha diritto a un credito di servizio di un mese sul Servizio interessato. Ciò si aggiunge a qualsiasi credito relativo all'uptime maturato ai sensi della Sezione 4.

9. Tempi di Risposta del Supporto

9.1 Definizioni di gravità

• Critico: server giù, dati inaccessibili, incidente di sicurezza in corso
• Alto: prestazioni degradate, interruzione parziale, irraggiungibilità intermittente
• Normale: domanda di configurazione, richiesta di funzionalità, chiarimento di fatturazione che non influisce sul funzionamento del servizio
• Basso: feedback sulla documentazione, domanda di processo, richiesta non sensibile al tempo

9.2 Obiettivi di risposta

9.3 Canali di supporto

I ticket sono accettati tramite il pannello clienti e via email a [email protected]. La chat 24/7 (dove disponibile, caricata in modo lazy secondo la documentazione in /features) è per richieste generali; i problemi di gravità Critico dovrebbero sempre essere aperti anche come ticket per garantire il tracciamento.

10. Come Richiedere i Crediti

10.1 Finestra di richiesta

I crediti di servizio devono essere richiesti entro trenta (30) giorni dall'incidente che ha dato origine al credito. I crediti non richiesti entro questa finestra sono decaduti.

10.2 Procedura di richiesta

Per richiedere un credito, inviare un'email a [email protected] con le seguenti informazioni:

• Email dell'account e identificatore del Servizio interessato
• Data e ora dell'incidente in UTC
• Motivo della richiesta (mancato uptime, mancato provisioning, mancate prestazioni di rete)
• Eventuali dati di monitoraggio esterni che il cliente ha a sostegno dell'incidente

10.3 Elaborazione

Accusiamo ricevuta delle richieste entro quarantotto (48) ore. La risoluzione sostanziale richiede in genere sette (7) giorni lavorativi. I crediti approvati vengono applicati alla fattura successiva o, su richiesta del cliente, erogati come rimborso ai sensi della Sezione 4.2.

11. Finestre di Manutenzione

Gli avvisi di manutenzione vengono pubblicati sulla pagina di stato su /status e inviati via email a tutti i clienti interessati. La finestra di avviso standard è di quarantotto (48) ore. La manutenzione di emergenza — necessaria per affrontare un problema attivo di sicurezza o stabilità — può essere eseguita senza avviso preventivo; in tal caso, viene pubblicato un post-mortem sulla pagina di stato entro cinque (5) giorni lavorativi.

12. Modifiche al Presente SLA

Possiamo aggiornare periodicamente il presente SLA. Le modifiche sostanziali che riducono il livello di servizio garantito dal presente SLA richiedono un preavviso di trenta (30) giorni tramite la procedura di cui alla Sezione 15 dei Termini di Servizio. Le modifiche che migliorano gli impegni o chiariscono il linguaggio hanno effetto immediato alla pubblicazione. La data "Ultimo aggiornamento" in cima al presente documento riflette la modifica più recente.