Monitoraggio SLA e SLO

1) Termini e ruoli

SLA (Service Level Agreement) è un obbligo contrattuale esterno nei confronti del cliente (clausole di penalizzazione, prestiti).
SLO (Service Level Objective) è un target interno del servizio che supporta l'esecuzione di SLA.
SLI (Service Level Indicator) è un indicatore misurato basato su SLO/SLA.
Errore Budget è una percentuale valida dì indisponibilità/errore "nel periodo" Budget = 1 - SLO ".
Scope - Misurato con gli occhi dell'utente (end-to-end). Nei microservizi, sia a livello di componente che di percorso.

2) Scelta SLI: esattamente cosa misurare

I criteri sono correlati all'esperienza utente e al valore aziendale.

• Disponibilità: percentuale di richieste di successo. 'SLI = successo/tutto'.
• Latenza: percentuale di query più veloce della soglia T'SLI = P (latency ≤ T) '.
• Qualità: percentuale di risposte corrette (senza 5xx/funzione. errori).
• Rilevanza dati: ritardo della replica/ETL ≤ X minuti.
• Performance del processo aziendale: percentuale di pagamenti e registrazioni completi.

Anti-pattern: considerare solo 200 ki come «successo», ignorando gli errori aziendali; misurare la rete di prova anziché quella utente.

3) Formule e finestre di sorveglianza

• `Availability = (OK_requests / All_requests) × 100%`.

• "P95" T "è meglio definire come una quota:" SLI =% delle richieste di T ".
• Esempio: «99% delle richieste di ricerca ≤ 300 ms in 28 giorni».
• Finestra scorrevole: 28 o 30 giorni (equilibrio sensibilità/stabilità). Per gli incidenti, finestre: 1 ora, 6 ore, 24 ore.

4) Errore Budget e controllo della velocità di cambiamento

Calcolo a "SLO = 99. 9% 'budget =' 0. 1% 'errori/indisponibilità durante il periodo.

• Budget> 50%, rilasci ed esperimenti del piano.
• Il budget è del 10-50%, solo rilasci a basso rischio, strette canarie.
• Budget <10%: congelamento dei rilasci, causa radice, miglioramento dell'affidabilità.
• Collegamento con rilasci progressivi: canary/feature-flags «mangiano» il budget in modo dosato, con decadimento automatico.

5) Regole alert: dalle soglie al burn rate

Perché non «alzare l'alert SLO», è troppo tardi. Mi serve proattività.

• 'BR = (errore osservato per una breve finestra/errore valido per questa finestra)'.
• Se 'BR> 1', il budget è più veloce della norma.

• Alert rapido (il rumore è sensibile, cattura disastri): finestra 5-10 min, soglia BR 14-20 x.
• Alert lento (cattura il degrado del cursore): finestra 1-6 h, soglia BR 2-4 x.
• Condizioni di combinazione: ha funzionato veloce o lento - paging on-call.
• Livelli: cercapersone per SLO personalizzati, ticket/notifiche per degrado SLI interno grigio.

6) Osservabilità e fonti di verità

I loghi sono la diagnosi delle cause.
Le metriche sono SLI numerici (successo/errore, percento di latitanza, quote, contatori).
Le roulotte sono percorsi passanti, la localizzazione dei segmenti caldi.
Sintetico - campioni attivi dalla periferia (region-aware).
Gli eventi reali sono RUM/telemetria dei clienti, metriche aziendali (conversione, pagamenti riusciti).

Requisiti: un quadro unico nei dashboard di release e incidenti, annotazioni «versione/canarino/bandiera».

7) Progettazione SLO: modello passo passo

1. Descrivere il percorso critico (ad esempio, deposito con carta).
2. Definisci SLI: successo/errore, soglia di latenza, completezza.
3. Concordare SLO: obiettivo per 28 giorni + eccezioni (finestre pianificate).
4. Collegare a SLA l'obbligo legale di eseguire il SLO effettivo.
5. Assegnare il proprietario (service owner), il RACI e il canale alert.
6. Definire le regole alert (BR a due finestre) e i ritiri automatici.
7. Implementare i report: revisioni settimanali del budget, rivisitazioni post-incidenti.
8. Rivedere lo SLO trimestrale (modifica del carico/architettura).

8) Esempi SLO (modelli)

• Disponibile: '≥ 99. 95% '(28d, escluse le finestre dichiarate).
• La latitanza è il 99% delle risposte.
• Il successo delle operazioni aziendali è stato '98. 5% 'autorizzazioni di successo (filtri fraud presi in considerazione).

• La latitanza è il 99% delle richieste.
• Rilevanza cache: 5 minuti di ritardo nel 99% dei casi.

• Consegna: '≥ 99. 9% 'per' 60 s '(end-to-end, con retrai).
• Perdita: '≤ 0. 01% 'messaggi (idampotenza/deduplicazione abilitata).

9) Multi-regione e multi-tenente

SLO per coorti: paese, fornitore di pagamenti, segmento VIP, dispositivo.
SLO locali sul bordo: metriche dai punti più vicini all'utente (edge/PoP).
Aggregazione: un SLO condiviso non deve nascondere errori su coorti importanti.
Commutazione provider: percorsi fallback automatici a livello di gate SLO.

10) Dashboard e rapporti

Dashboard di lancio: versione, canarino (% del traffico), SLI (successo/latitanza), BR, annotazioni delle bandiere.
Dashboard operativi: bilancio burn-down per giorni, incidenti top, MTTR, coorti problematici.
Report settimanali: bilancio residuo, trend BR, debito tecnico (colli di bottiglia), piano di miglioramento.

11) Processi: incidenti, RCA e miglioramenti

Alert

RCA (causa radice): fatti/timeline/ipotesi/correzione/convalida dell'effetto SLI.
Lezioni imparate: post mortem non mortem, action items obbligatori con proprietari e scadenze.
Cortocircuito: modifiche a test, flag fic, limiti, cache, retrai, quote.

12) Compilazione e verifica

SLO/SLI come artefatti di controllo (policy-as-code, fogli immutabili).
Collegamento ai requisiti (ad esempio, disponibilità dei pagamenti).
Le prove sono i verbali degli alert, i bilanci, i registri dei resoconti e dei rimborsi.

13) Errori frequenti e come evitarli

“99. Il 99% o la morte". Seleziona SLO realistici.
Le medie globali nascondono gli insuccessi locali.
Metriche non e2e: alto SLO quando il cliente è effettivamente degradato, è possibile aggiungere RUM/sintetico.
Gli alert hanno una sola soglia per passare al burn rate a due finestre.
Nessun collegamento con le modifiche. Il rilascio non è annotato, non c'è nessun ritorno automatico.

14) Mini-assegno di implementazione

• Sono descritti i percorsi critici e i loro SLI/SLO.
• È stata impostata una finestra di osservazione ed esclusione.
• Sono configurati gli alert BR a due finestre (veloci e lenti).
• Dashboard di release e operazioni con annotazioni di versione/flag.
• Il criterio errore budget influisce sulle release.
• Revisioni regolari del bilancio e RCA post-incidente.
• Documentazione e proprietari di prestazioni.

15) Esempio di calcolo (particolare)

API SLO: 99. 9% in 28 giorni, bilancio = 0. 1%.
Si è accumulato un 7 in 0 giorni. Il 06% degli errori è speso per il 60% del budget settimanale.
La finestra corta di 15 min mostra il 2% degli errori. Valida per questa finestra: '0. 1% x (15 min/40320 min) ≈ 0. 000037%`.
Burn Rate 1 (decine di x) attiva un cercapersone veloce, il canarino si ritira all '1%, il flag fich «degrade-payments-UX» viene attivato da RCA.

16) Totale

Il monitoraggio SLA/SLO non è solo un numero del report, ma un meccanismo di gestione del rischio di cambiamento e della qualità del servizio. La SLI corretta, la SLO realistica, la gestione error budget, la burn-rate alert a due finestre e l'osservabilità e2e trasformano le metriche in soluzioni di lavoro, rilasciando più rapidamente valore e mantenendo l'esperienza utente prevedibile.