Monitorizarea SLA și SLO

1) Termeni și roluri

SLA (Service Level Agreement) - obligație contractuală externă față de client (clauze de penalizare, credite).
SLO (Service Level Obiectiv) - țintă nivel de servicii interne care acceptă execuția SLA.
SLI (Service Level Indicator) - indicator măsurat, pe baza căruia sunt evaluate SLO/SLA.
Eroare Buget - procentul permis de „indisponibilitate/erori” pentru perioada: 'Buget = 1 − SLO'.
Domeniul de aplicare: măsurat prin ochii utilizatorului (end-to-end). În microservicii, atât la nivelul componentelor, cât și la nivelul traseului end-to-end.

2) selecție SLI: ce anume să măsurați

Criteriul este corelația cu experiența utilizatorului și valoarea afacerii.

• Disponibilitate: procentaj de solicitări de succes. „SLI = succes/toate”.
• Latență: proporția cererilor este mai rapidă decât pragul T. „SLI = P (latență ≤ T)”.
• Calitate: proporție de răspunsuri corecte (fără 5xx/functe. erori).
• Date actualizate - Latență de replicare/ETL ≤ minute X.
• Performanța procesului de afaceri: ponderea plăților/înregistrărilor de succes.

Anti-modele: numărați doar 200 ca „succes”, ignorând greșelile de afaceri; măsură în rețeaua de testare în loc de rețeaua de utilizatori.

3) Formule și ferestre de observare

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

• „P95 ≤ T” → este mai bine formulat ca o parte: „SLI =% din cereri ≤ T”.
• Exemplu: „99% din interogările de căutare ≤ 300 ms în 28 de zile”.
• Fereastră glisantă: 28 sau 30 de zile (echilibru de sensibilitate și stabilitate). Pentru incidente - ferestre suplimentare: 1 h, 6 h, 24 h.

4) Bugetul de eroare și controlul ratei de schimbare

Calcul: la 'SLO = 99. 9% 'buget =' 0. 1% "erori/indisponibilitate pe perioadă.

• Buget> 50%: lansări și experimente de plan.
• Buget 10-50%: numai eliberări cu risc scăzut, înăsprirea canarilor.
• Buget <10%: eliberarea înghețării, cauza rădăcinii, îmbunătățirea fiabilității.
• Conexiune cu versiuni progresive: canar/feature-steaguri „mănâncă” bugetul în doze, cu auto-rollback sub degradare.

5) Politicieni de alertă: de la praguri la rata de ardere

De ce nu a „daupal SLO - ridica alerta”: prea târziu. Am nevoie de proactivitate.

• 'BR = (eroare observată într-o fereastră scurtă/eroare permisă în această fereastră)'.
• If 'BR> 1' - bugetul este consumat mai repede decât în mod normal.

• Alertă rapidă (zgomotul este sensibil, captează dezastre): fereastră 5-10 minute, prag BR 14-20 ×.
• Alertă lentă (captează degradarea târâtoare): fereastra 1-6 ore, pragul BR 2-4 ×.
• Combinați condițiile: rapid sau lent lucrat - paginare de gardă.
• Niveluri: pager pentru SLO-urile utilizatorilor, bilete/notificări pentru degradarea gri a SLI-urilor interne.

6) Observabilitatea și sursele adevărului

Jurnalele - diagnosticul cauzelor.
Metrica - SLI-uri numerice (succes/eroare, percentile de latență, fracții, contoare).
Trasee - prin căi, localizarea segmentelor „fierbinți”.
Sintetice - probe active de la periferie (region-conștient).
Evenimente reale - telemetrie ROM/client, valori de afaceri (conversie, plăți de succes).

Cerințe: o singură imagine în tablourile de bord ale lansărilor și incidentelor, adnotări „versiune/canar/pavilion”.

7) Design SLO: șablon pas cu pas

1. Descrieți calea critică (de exemplu, "depunere prin card').
2. Definiți SLI: succes/eroare, prag de latență, completitudine.
3. Sunt de acord SLO: 28 de zile țintă + excepții (ferestre programate).
4. Link către SLA: obligație legală ≦ SLO efectiv.
5. Atribuiți un proprietar de serviciu, RACI și canal de alertă.
6. Definiți politici de alertă (două ferestre BR) și auto-rollback.
7. Implementați raportarea: recenzii săptămânale ale bugetului, recenzii post-incident.
8. Revizuirea SLO trimestrială (schimbare de sarcină/arhitectură).

8) exemple SLO (șabloane)

• Disponibilitate: '≥ 99. 95% "(28d, cu excepția ferestrelor anunțate ≤ 30 min/lună).
• Latenţă: '≥ 99%' răspunsuri '≤ 400 ms'.
• Succesul operațiunilor de afaceri: '≥ 98. 5% "autorizații de succes (se iau în considerare filtrele de fraudă).

• Latență: "≥ 99%" cereri "≤ 300 ms'.
• Relevanța cache-ului: „≤ 5 min” lag 99% din timp.

• Livrare: '≥ 99. 9% "pentru" ≤ 60 "(end-to-end, cu retras).
• Pierdere: '≤ 0. 01% "mesaje (idempotență/deduplicare activată).

9) Multi-regiune și multi-chiriaș

SLO „prin cohortă”: țară, furnizor de plăți, segment VIP, dispozitiv.
SLO-uri locale la margine: valori de la punctele cele mai apropiate de utilizator (edge/PoP).
Agregare: SLO total nu ar trebui să ascundă eșecurile în cohortele importante.
Furnizori de comutare: rute automate de rezervă la nivelul porții SLO.

10) Tablouri de bord și raportare

Tablou de bord lansare: versiune, canar (% trafic), SLI (succes/latență), BR, adnotări de pavilion.
Tabloul de bord de operare: buget de ardere pe zi, incidente de top, MTTR, cohorte de probleme.
Rapoarte săptămânale: soldul bugetar, tendințele BR, datoria tehnică (blocaje), planul de îmbunătățire.

11) Procese: Incidente, RCA și îmbunătățiri

Managementul incidentelor: alerta → evaluarea BR → scara canarilor/steagurilor → rollback/fix.
RCA (cauza principală): fapte/termene/ipoteze/corecții/verificarea efectului de către SLI.
Lecții învățate: postmortems non-punitive, elemente de acțiune obligatorii cu proprietarii și termene limită.
Închiderea buclei: modificări ale testelor, steaguri, limite, cache-uri, retribuții, cote.

12) Conformitate și audit

SLO/SLI ca artefacte de control (policy-as-code, jurnale imuabile).
Legătura cu cerințele (de exemplu, disponibilitatea tranzacțiilor de plată).
Dovezi: minute de alertă, rapoarte de buget, jurnale de lansare/rollback.

13) Greșeli frecvente și cum să le evitați

“99. 99% sau moartea": obiective de neatins → zgomot constant de alertă. Alegeți SLO-uri realiste.
Mediile globale ascund scufundările locale → introduc cohorte.
Metrics not e2e: SLO-uri ridicate în timpul degradării reale pe client → adăugați RUM/sintetice.
Alerte pe un singur prag → comutați la rata de ardere cu două ferestre.
Nu există nici o legătură la modificările → versiunile nu sunt adnotate, nu există nici o auto-rollback.

14) Lista de verificare a implementării Mini

• Căile critice și SLI/SLO sunt descrise.
• Fereastra de monitorizare și excludere este setată.
• Sunt configurate alerte BR cu două ferestre (rapid și lent).
• Tablouri de bord de lansări și operațiuni cu adnotări de versiuni/steaguri.
• Politica bugetului de eroare afectează versiunile.
• Revizuiri regulate ale bugetului și RCA-uri post-incidente.
• Documentație și proprietarii de scorecard.

15) Exemplu de calcul (specific)

Disponibilitate API SLO: 99. 9% în 28 de zile → buget = 0. 1%.
Timp de 7 zile acumulate 0. 06% din erori → folosit 60% din bugetul săptămânal.
Pe o fereastră scurtă de 15 minute, se observă 2% din erori. Valabil pe această fereastră este '0. 1% × (15 min/40320 min) ≈ 0. 000037%`.
Burn Rate ≫ 1 (zeci de ×) → un pager rapid este declanșat, canarul se rostogolește înapoi la 1%, steagul caracteristicii UX degrade-payments pornește, RCA începe.

16) Linia de jos

Monitorizarea SLA/SLO nu este doar un număr din raport, ci un mecanism de gestionare a riscului de schimbări și a calității serviciilor. SLI-uri corecte, SLO-uri realiste, gestionarea bugetului de erori, alerte cu două ferestre și e2e-observabilitate transformă valorile în soluții de lucru: eliberați valoarea mai repede și mențineți experiența utilizatorului previzibilă.