Budżet błędów i zarządzanie SLO

1) Dlaczego SLO i budżet na błędy

SLO (Cel poziomu usług) - docelowy poziom jakości postrzegany przez użytkownika; SLI - mierzona metryka; Budżet błędu - tolerancja dla odchyleń na okno (zwykle 30/90 dni).
Budżet błędu zamienia niezawodność z „abstrakcji” w zarządzany zasób: gdy budżet szybko się spala, zamrażamy funkcje i chinim; gdy budżet jest zdrowy - można przyspieszyć wydania.

2) Wybór SLI: Co liczy się jako „dobry”

Kryterium: „udane z punktu widzenia użytkownika”.

2. 1 Klasyczne SLIs

Dostępność jest procentem udanych wniosków (z wyłączeniem anulowanych przez klienta).
"success = http_status" {2xx, 3xx, 404} i bez czasu "(404 można uznać za odczytany sukces API, jeśli oczekuje się semantyki).
Opóźnienie: odsetek wniosków jest szybszy niż próg (na przykład p95 ≤ 300 ms).
„good _ latency = duration_ms ≤ 300”.
Świeżość/Staleness: „dane nie starsze niż X minut” (pamięć podręczna, katalogi, współczynniki).
Jakość: poprawność wyniku (przechodzące walidatory biznesowe/niezmienne backendy).

2. 2 Granice i segmenty

SLI należy liczyć za pomocą ważnych części: „trasa”, „najemca/marka”, „region/jurysdykcja”, „dostawca _ płatności”. Więc nie „rozmazać” awarii jednego krytycznego uchwytu w całym systemie.

3) Wzory i budżet

3. 1 Wniosek oparty (preferowany dla API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Oparte na czasie (dla usług w tle/streaming)

SLO_uptime = good_minutes / total_minutes

3. 3 Przykład celów

API ogólne: 99. 9% dostępność w 30 dni → budżet = 0. 1%.
Krytyczne długopisy płatnicze: 99. 95%; katalogi/wyszukiwanie: 99. 5%.
Opóźnienie: p95 ≤ 300 ms na '/v1/payments ', p99 ≤ 800 ms.

4) Oprzyrządowanie SLI

4. 1 Zasady

Logs/trails → RED (Rate/Errors/Duration) metryki z wyraźnymi wiadrami.
Należy umieścić 'lokator', 'region', 'route _ class' (bez PII).
Policz dwie metryki: „sukces” i „całkowity”, a dla opóźnień, „szybki” i „całkowity”.

4. 2 Przykład Prometeusza (stawka na 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alerty według szybkości spalania (multi-window, multi-burn)

5. 1 Pomysł

Patrzymy, jak szybko spala się budżet w stosunku do celu. Jeśli prędkość jest wysoka na krótkim i długim oknie, sygnalizujemy.

5. 2 Profile progowe (dla SLO 99. 9%)

Przywoływanie: szybkość spalania ≥ 14. 4 × (10% budżetu na 1 godzinę i 5% na 6 godzin).
Bilet: szybkość spalania ≥ 6 × (2% w ciągu 6 godzin i 1% w ciągu 24 godzin).

5. 3 Przykładowe reguły (Prometeusz, pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

Podobnie dla 6h/24h na bilet.

6) Urząd Budżetu: Procesy

6. 1 Bramy uwolnienia

Jeśli saldo budżetu wynosi <25%, a tendencja jest ujemna - „code-freeze” na funkcjach, priorytetem jest SRE/stabilność.
Wydania kanaryjskie muszą mieć oddzielny kawałek SLO ("wdrożenie. środowisko =” kanaryjskie”).

6. 2 Priorytetowe określenie zaległości

Dystrybucja zdolności dowodzenia proporcjonalnie do wskaźnika spalania i wpływu przychodów.
Uzasadnij dług techniczny metrykami: „fix zmniejszy stopę spalania o Y%”.

6. 3 Po incydencie

Każdy incydent - RCA i „fix, który nie może być zwinięty z powrotem” (aktywny), kontrola „wrócił do SLO”.

7) SLO jako kod

7. 1 Przykład manifestu SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Generowanie reguł

Użyj generatorów (slo-generator, pyrra, lenistwo) do automatycznego tworzenia reguł, desek rozdzielczych i raportów.

8) degradacja i ochrona SLO

Load shedder: dać szybkie odpowiedzi bez „drogich” zależności na szczycie.
Cache & stale: „stale-while-revalidate” дла.
Limity szybkości/równoczesności: chroni backendy; ważne trasy - priorytet.
Circuit/Timeout: szybkie timeouts i „fallback” gałęzie.
Flagi funkcji: wyłączanie ciężkich funkcji za pomocą jednego przycisku.

9) Obserwowalność SLO

Deski rozdzielcze: SLO rzeczywisty vs cel, saldo budżetu, stopa spalania, wkład tras/dostawców.
Korelacja: od „otworu” SLO → do przykładowego → konkretny ślad → dzienniki/profile.
Raporty: co tydzień - trendy, konsumpcja budżetowa, główne przyczyny degradacji.

10) Antypattery

Jeden „globalny” SLO dla całej → maski problemy. Segment.
«99. 99% na wszystko" z wyłączeniem kosztów i rzeczywistości. Wybierz cele z doświadczenia użytkownika.
Wpisy CPU/hałdy zamiast szybkości spalania/SLO.
Ignorowanie przekierowań 4xx/long, które psują UX.
Nieprzezroczyste okno (kalendarz walcowania vs) - porównanie „jabłek z pomarańczami”.

11) Szczegóły dotyczące iGaming/Finance

Ścieżki pieniężne (depozyty/wypłaty): poszczególne SLO powyżej ogólnego poziomu (np. 99. 95% dostępności; p95 ≤ 250 ms).
Dostawcy PSP/KYC: SLO dla każdego dostawcy + wpisy dotyczące ich wkładu w spalanie; automatyczne przełączanie trasy (smart routing).
Jurysdykcje/najemcy: SLO i budżety według „regionu/jurysdykcji/marki”, tak aby problem lokalny nie „zalewał” globalnej metryki.
Gra odpowiedzialna: SLO za okres stosowania limitów/samodzielnego wykluczenia (formuły zgodności).
Audyt/regulacja: prowadzenie raportów SLO i incydentów; przejrzystość audytów wewnętrznych.

12) Lista kontrolna gotowości Prod

• Zdefiniowano SLIs (dostępność/opóźnienie/jakość/świeżość) oraz segmenty (trasa/najemca/region).
• Cele (SLO) są realistyczne, dostosowane do potrzeb biznesowych; Są toczące się okna 30/90 dni.
• Wpisy według stawki spalania z wieloma oknami (przywołanie/bilet).
• SLO jako kod (generator reguły/deski rozdzielczej); sprawozdania budżetowe.
• Bramy uwolnień są związane z resztą budżetu; sekcje kanaryjskie.
• Mechanizmy degradacji (shedder, cache stale, obwód, limity) są wdrażane i testowane.
• Korelacja mierników i ścieżek, czytelne księgi startowe.
• Szlaki finansowe/jurysdykcyjne - oddzielne SLO/wpisy; PSP/KYC są zdezagregowane.
• Regularne retro incydentów i oparte na oparach inwestycje niezawodności.

13) TL; DR

Zdefiniuj SLIs według wartości użytkownika, ustaw realistyczne SLO i zarządzaj za pomocą budżetu błędów i szybkości spalania za pomocą wielu okien. Włącz kod SLO-as, bramki uwalniania i degradacji zgodnie z planem. segment według trasy/najemcy/regionu; w przypadku ścieżek pieniężnych utrzymać ściślejsze cele i oddzielne wpisy.