SLO/SLA e metriche

SLO/SLA e metriche

1) Termini e gerarchie

SLI (Service Level Indicator) è un indicatore misurabile dì come ci vede l'utente ": percentuale di richieste di successo, p95 latitanza, freschezza dei dati, percentuale di batch elaborate con successo, ecc.
SLO (Service Level Objective) - Valore di destinazione SLI all'intervallo di osservazione (28/30/90 giorni). L'esempio è "99. Il 9% delle richieste/share termina con 400 ms".
Error budget — 1 − SLO. Con la SLO 99. Budget di errore del 9% = 0. 1% di tempo/query.
SLA (Agreement) è un livello di servizio giuridicamente rilevante che include SLO, misurazione, espulsioni, compensazioni/multe.

2) Principi di progettazione

Sintomi> metriche interne. La SLI deve riflettere la reale esperienza utente.
Numero ridotto di SLI chiave. Per il servizio - 2-5 principali: successo, latitanza, larghezza di banda/freschezza, correttezza.
Copertura dei percorsi critici. Per ogni script aziendale (checkout, login, webhook, ETL) è il tuo set SLI/SLO.
La severa semantica del successo. Non «codice 200», ma «l'utente ha ricevuto la risposta entro il termine e il risultato è valido».
Separazione tra SLO esterni e interni. L'interno è più rigoroso; La SLA esterna è a 1-2 nove.

3) Directory SLI (arbitro)

3. 1 API/servizi online

Successo: 'SLI _ success = 1 - (5xx + timeout + business _ errore )/all _ sollests'

Latitanza: p95/p99 'http _ server _ duration _ seconds'attraverso percorsi/metodi/affittuari

Larghezza di banda: «RPS »/limiti/quote

Correttezza: percentuale di risposte validi (firme, schemi, invarianti)

3. 2 Consegne web/asincroni

Spedizione: percentuale di eventi confermati in T secondi e ≤ N retrai

Clienti: numero di abbonati senza ritardi prolungati (per-tenente)

3. 3 Dati/ETL/DWH

Freschezza (freshness): 'now - last _ successful _ ingest _ ts'

Completezza: 'ingested _ rows/expected _ rows'

Correttezza: percentuale di record sottoposti a test di qualità

Pipline - Percentuale di quelli completati prima della deadline

3. 4 SDK mobile/client

Numero di sessioni senza errori fatali

Latenza round-trip: p95 da query a render

Cash hit: percentuale di risorse dalla cache (come sintomo della performance)

4) Formule e esempi di obiettivi

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95% 'per 30 giorni di errore budget = 0. Il 05% delle richieste.

• `uptime = (obs_window − downtime) / obs_window`

• 'SLO _ latency = p95 (route = »/share») ≤ 400 ms'su tagli di 7 giorni, con esclusione dei riscaldamenti cache (1%)

• 'SLO _ freshness (dataset =» orders») ≤ 10 min'p99 in 24 ore.

5) Errore budget et e gestione delle modifiche

Budget (B): «B = 1 - SLO».
Budget (burn) - Rapporto tra errori effettivi e errori validi.

• Sovrapprezzo (burn> 1) Fichfreese, fuoco sull'affidabilità.
• Con burn rate> X in una breve finestra - incidente e cap. le misure.
• Pianificazione: la quota dello sprint sull'affidabilità è correlata con il burn nel periodo precedente.

6) Alerting: burn rate e regole multi-finestre

L'idea è di catturare fughe veloci e una deriva lenta.

• Critico: «2% del budget dell'ora» (fuoco rapido).
• Avviso: «5% del budget in 6 ore» (degrado strisciante).

• Finestra breve (minuto-ora) per incidenti rapidi.
• Finestra lunga (6-24 ore) per i trend.
• Latenza: alert p99> soglia di ≥5, soppressione del flapping e collegamento con gli esemplari delle piste.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Multi-tenant e segmentazione

SLI/SLO sono considerati come affittacamere/piani/regioni, altrimenti la mediana «coprirà» i fallimenti.
Numero minimo di eventi di rilevanza statistica.
SLA può variare in termini di tariffe (ad esempio, "Pro 99. 9%, Free 99. 5%»).

8) Relazione con osservabilità e tracciabilità

Le metriche SLI - da istogrammi/contatori con exemplars → il passaggio a «cattive» roulotte.
I loghi sono la causa dei timeout, dei codici degli errori aziendali, dei limiti.
Per i dati, il collegamento con il lineage, «Quale jobs ha trattenuto la metrica di freschezza».

9) Contratti e SLA

• Definizioni SLI/metodo di misurazione/finestra.
• Eccezioni (lavoro programmato, forza maggiore).
• Procedura di incidenti e comunicazioni (status page, RFO/RCA).
• Rimborsi (service credits) e ordine della richiesta.
• Giurisdizione, periodo di validità, termini di revisione.

• Non promettere mai un SLO pubblico più rigoroso di quanto l'architettura e le pratiche operative possano fare.
• Separare le SLO interne e le SLA esterne.

10) Costo e priorità

Il prezzo delle ragazze non è lineare. «99. 9% → 99. 99%" = un'altra classe di architettura (N + 1, multisone, asset-asset).
Mettere SLO sulle azioni utente più preziose.
Controllo dei costi di telemetria: downsampling, quote, repliche e storage per classe.

11) Procedure e rapporti

Resoconti settimanali: esecuzione di SLO per servizi/affittacamere, budget, migliori motivi, piani di miglioramento.
RCA post-insidioso: collegato a pezzi di budget; portiamo l'obiettivo di risolvere le cause principali.
Phichfreese: criteri di inclusione/ritiro.

12) Modelli (per un avvio rapido)

12. 1 Scheda SLO (esempio)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 Tabella «Maturità SLO»

13) Esempi di regole (sezioni)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO per dati e ML (caratteristiche)

Dati SLO completi: freschezza p99, completezza p99, tempo di riprogettazione dopo un guasto.
Contratti dati: schemi previsti, volumi, deadline; Violazione dei dati →.
ML: SLO per la latitanza dell'inferno, SLA per la disponibilità di fich store, monitoraggio della deriva (la qualità del modello è un tema separato, fuori dalla SLA).

15) Integrazione con la sicurezza e la privacy

Loghi SLI senza PII/segreti; Tornizzazione/occultamento.
Verifica delle modifiche SLO/SLA e delle pubblicazioni di report su registri invariati.
Per i percorsi regolatori (pagamenti/PII) sono SLO separati e più rigorosi.

16) Assegno fogli

Prima di avviare il servizio/fici

• Definiti SLI «successo/latitanza/larghezza di banda/freschezza».
• SLO e finestre impostate; è stato calcolato il bilancio degli errori.
• Sono stati configurati i burn-rate alert (breve + lungo).
• Dashboard RED + exemplars pista runibuki incidenti.
• Tagli multiarendici e soglie di importanza.
• Procedura di ficfrese e segnalazione.

Utilizzo

• Report settimanale SLO/burn, piani hardening.
• Rivalutazione SLO quando l'architettura/carico cambia.
• Periodici «incidenti-esercitazione» e aggiornamento runibook.
• Controllo del costo della telemetria e della quantità di SLI.

17) Runbook’и

Runbook: crescita rapida p99/pay

1. Alert r99. La soglia è quella di aprire il dashboard.
2. Trova un CLIENT/SERVER span ristretto, confronta le regioni/versioni.
3. Attiva la degradazione (cache/limite/follback), avvisa il comando della dipendenza.
4. Dopo la stabilizzazione - RCA, attività di ottimizzazione, aggiornamento delle misurazioni SLO.

Runbook: budget> 50% in una settimana

1. Congelare i fili, dare priorità all'affidabilità.
2. Clustering degli errori: percorsi/affittuari/dipendenze.
3. Estrarre le correzioni, confermare la ripresa del trend.
4. Retrospettiva e regolazione degli alert/soglie.

18) FAQ

Alle:, quanti SLO servono?
O: Minimo per script critici utente: successo + latitanza. Tutto il resto è necessario.

C: Cosa c'è di meglio nella disponibilità in base al tempo o alle richieste?
Le richieste sono di una metrica più personalizzata. Tempo utile per i componenti di rete/infra.

Perché p95 e non la media?
Il medio nasconde la coda; l'utente percepisce p95/p99.

Come non «arrotondare» troppo forte?
Cominciate con obiettivi realistici (dati storici), poi rafforzate la maturità.

• Osservabilità: fogli, metriche, tracciabili
• Tracciati distribuiti
• Controllo e registri invariati
• Garanzia di spedizione Web Hook
• Crittografia In Transit/At Rest'
• Origine dati