GH GambleHub

High Availability и SLA

High Availability и SLA

1) Termini e relazioni con il business

SLI (Service Level Indicator) è un indicatore misurato del servizio (ad esempio, la percentuale di richieste di successo 2xx/3xx ≤ T ms).
SLO (Service Level Objective) - Destinazione SLI (ad esempio "99. 95% richieste «300 ms»).
SLA (Service Level Agreement) è un obbligo contrattuale per il cliente (multe/crediti in caso di violazione).
HA (High Availability) - Misure architettoniche e operative che consentono di eseguire SLO/SLA.

Principio: SLA si basa su SLO e SLO su SLI osservati. Non puoi promettere in SLA qualcosa che non stai misurando.

2) Nove e matematica della disponibilità

Disponibilità per il periodo = 'tempo di lavoro/tempo totale'. Punti di riferimento (anno):
DisponibilitàMax. semplice/anno
99. 0%3 giorni 15 ore
99. 5%1 giorno 20 ore
99. 9%8 h 45 m
99. 95%≈ 4 h 23 m
99. 99%≈ 52 m 34 c
99. 999%5 m 15 c

Composizione della disponibilità

Catena sequenziale (dipendenze da «percorso rosso»): «A _ total = A _ i» (ogni componente riduce il totale).
Asset parallelo del nodo: 'A _ total = 1 -AEQ (1 - A _ i)' (la riserva aumenta il totale).

3) Esattamente cosa misurare (SLI corretto)

Visione utente: completamento completamento delle operazioni chiave (login, deposito, assegno-out) e loro latitanza p99.
Corridoio orario: aggregate le finestre scivolose (5/30/60 min) e le regioni.
Eccezioni: «finestre pianificate» vengono considerate in SLO e in SLA solo se il contratto lo dice.

Tipi di SLI:
  • Disponibilità: percentuale di risposte ≤ T.
  • Qualità: p95/p99 latency.
  • ≤: «Il tasso di successo dei depositi è di 5 c».

4) Errore Budget e velocità di combustione

Error Budget = `1 − SLO`. Per 99. Il 95% della finestra mensile dà 0. 05% di errori/inattività.
Burn-rate: velocità di spesa del budget (ad esempio, 4 x significa che in 6 ore si mangia il limite diurno).
Criterio: in caso di combustione rapida, stop dei rilasci, attivazione sulla stabilizzazione, feature-freeze.

5) Architettura HA: dal sito alla regione

5. 1 Nodo/Servizio

N + 1: almeno una replica ridondante (Deployment 2, PDB, anti-affinity).
Isolamento delle risorse: limiti CPU/RAM/IO, priorità (PriorityClass).
Graceful shutdown/drain - Nessun dirupo durante il restart.

5. 2 Zona/Regione

Multi-AZ: repliche in diverse zone, bilanciamento a intersezione, alimentazione/rete indipendente.
Multi-region: attivo-attivo (più difficile: dati/consistenza) o attivo-passivo (più semplice: RPO superiore).
Dati: CC per denaro/ordine (quorum/RAFT), CE/AP per cache/vetrine.

5. 3 Livello di rete e perimetro

L7-LB с health-checks, retry/timeout/circuit-breaking.
GSLB/DNS/Anycast per il traffico globale, TTL breve.
Egress Control e canali di failover per i fornitori PSP/provider esterni.

6) Degrado al posto della caduta

Feature kill-switch (flag-flag) - Disattiva il percorso rosso e non critico.
Passaggio a percorsi semplificati: sincrono asincrone/coda, «elaborato».
Rate-limit/quote: è meglio limitare il traffico che far cadere tutti.
Modalità stale: restituisci la cache/dati statici quando origin non è disponibile.

7) Gestione delle dipendenze

Mappa delle dipendenze (service map): diretta/transitiva, criticità, SLO di ciascuno.
Connessioni vulnerabili: provider esterno senza SLA - si traduce in cache/coda/duplicato.
Isolamento bulkhead - diversi pool di connessioni/quote per percorsi lenti.
Timeouts> Retries - Timeout brevi, massimo 1 retrai per operazioni idipotenti.

8) Operazioni e modifiche

Cambio management: rilasci tramite canarini/blue-green, gate SLO, reimpostazione automatica.
Le finestre previste sono standardizzate - lunghezza, frequenza, comunicazioni.
Incidenti: ruoli (IC/Comms/Tech/DB), runbook e, postmortem con azioni correttive.
Security-Iven - In caso di compromissione - Modalità di panico (read-only/token/rotazione/blocco).

9) Osservabilità e alerting

Modello RED (Rate, Errors, Duration) per ogni percorso.
SLI-dashboard: disponibilità/latitanza per regione e per segmento client.
Burn-rate alert - veloci (1h, 14. 4 x), lenti (6 h, 2 x) - Segnale prima che la SLO crolli.
Varianti (Exceplars) - Passa dalle metriche alle piste attraverso trace _ id.
Sintetica: campioni da punti esterni (perimetro, flow di pagamento).

10) Test di tolleranza

Game-days: script di disattivazione AZ/regioni, degrado del database/cache, guasto dei provider esterni.
Strumenti Chaos: folt di rete (latency/loss), kill-pods, sovraccarico CPU/IO.
DR-drills: lavorazione RTO/RPO per i sistemi Tier-0 (vedere Bacapi e DR).

11) Progettazione SLA

Definizione di disponibilità: cosa è considerato un incidente (5xx, ora> T, errori di dominio).
Finestra di calcolo mese/trimestre; attivazione/esclusione dei lavori pianificati.
Crediti/multe: scala (ad esempio, 99. 9–99. 99% X%, sotto Y%).
Responsabilità del cliente: integrazione, retrai entro limiti ragionevoli, limiti.
Le notificazioni e la procedura dei click sono: data, formato, base di prova (fogli/metriche).
Forza Maggiore, formulazione legale e limiti.

Esempio (bozza):
  • "Disponibilità API SLI "500 ms di successo" non inferiore a 99. 95% nel mese del calendario. Le finestre pianificate (fino a 60 minuti/mes dichiarati in 48 ore) sono escluse. A 99. 90–99. 95% - prestito 5%; 99. 80–99. 90% — 10%; <99. 80% — 25%.»

12) Economia device

Ogni nove in più aumenta i costi in modo non lineare (regioni doppie, quorum, fornitori di dati, 24 x 7). Applicare il tiering SLO:
  • Tier-0 (soldi/ordini): 99. 95–99. 99%, multi-AZ, DR pronto.
  • Tier-1 (feci principali): 99. 9–99. 95%, multi-AZ.
  • Tier-2 (non critico): 99. 5–99. 9%, può essere degradato/fermato in caso di incidenti.

13) Pattern HA per strati

Perimetro: CDN/edge, multi-CDN o GSLB, WAF, rate-limit.
Bilanciamento: L7 con outlier-ejection, timeout/retrai, sticky/consistent-hash.
Applicazioni: skale orizzontale, readover/liveness, PDB, topology spread.
Dati: leader + replica, quorum per la CPU, cache L2, idempotency, PITR.
Code: mirroring/multiclaster, deadup, DLQ.
Segreti/confighi: GitOps, snapshot atomici, rollback.

14) Anti-pattern

SLA senza strumenti di misurazione e sintetici esterni.
Un'unica area/cluster come SPOF.
I retrai incontrollati sono →-DDoS.
Transazioni lunghe/mutex a caldo.
Migrazioni/rilasci «pesanti» senza canarini o piani di recupero.
La mancanza di runbook e di comunicazione con gli stakeholder durante l'incidente.

15) Assegno foglio di implementazione (0-60 giorni)

0-15 giorni

Definisci SLI utente critici, imposta SLO per Tier-0/1/2.
Attivare i burn-rate alert, SLO-dashboard, controlli sintetici perimetro.
Rimuovi SPOF: repliche, PDB, multi-AZ per fronti e database critici.

16-40 giorni

Immettere le release canarie con il gate SLO e il rientro automatico.
Mappa delle dipendenze + quote/pool/timeout/SAN per ogni «percorso rosso».
Regolazione delle finestre e delle comunicazioni pianificate, modelli di messaggio di emergenza.

41-60 giorni

Game-day: disattivazione AZ, fallimento del provider esterno, traffico «burst».
Riconteggio SLA e crediti effettivi, pubblicazione di report ai clienti.
La revisione del costo del 9 e la transizione del tiro.

16) Metriche di maturità

Il 95% delle rotte critiche ha SLI/SLO e burn-rate alert.
Gli errori SLO sono accompagnati dal congelamento automatico dei rilasci (policy).
Multi-AZ Tier-0 = 100%, DR-drills di successo 1/trimestre.

Tempo di rilevamento della mitigazione p50 <5 min, p95 <15 min

La correlazione «rilasciare incidenti» è in corso e diminuita (rollback ).
Rapporto pubblico su incidenti/crediti - entro n giorni lavorativi.

17) Esempi e snippet

Burn-rate alert (idea delle regole):
  • Veloce: "SLO 99. 95%, finestra 1 ora, burn 14. 4× → page on-call».
  • Lento: «finestra 6 ore, burn 2 x ticket & monitoraggio».
Envoy — circuit breaking/outlier:
yaml circuit_breakers:
thresholds:
- max_connections: 200 max_pending_requests: 100 max_requests: 1000 max_retries: 1 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50
Canario con analisi SLO (Argo Rollouts, idea):
yaml analysis:
templates:
- name: slo-burn metrics:
- name: error-rate successCondition: result < 0. 005 provider: prometheus
Esempio di SLI:

SLI: fraction_of_good_requests = good(HTTP 2xx/3xx ≤ 500ms) / all(requests)
SLO: ≥ 99. 95% per calendar month, per region

18) Conclusione

High Availability non è solo cluster e repliche, ma un insieme coerente di architetture, processi e metriche: SLI/SLO chiari, SLA realistico, nono con economia, degrado al posto della caduta, disciplina dei timeout/quote, release canarie, esercitazioni regolari e comunicazioni trasparenti. Rendete la disponibilità misurabile e gestibile - e questo sarà un vantaggio competitivo, non una lotteria.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Telegram
@Gamble_GC
Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.