SLO/SLA i mierniki

SLO/SLA i mierniki

1) Warunki i hierarchia

SLI (Service Level Indicator) - wymierny wskaźnik „jak widzi nas użytkownik”: udział udanych wniosków, opóźnienia p95, świeżość danych, udział z powodzeniem przetwarzanych partii itp.

SLO (Service Level Objective) - docelowa wartość SLI w przedziale obserwacji (28/30/90 dni). Przykład: "99. 9% żądań/koniec wynagrodzenia ≤ 400 ms"

Budżet błędu - 1 − SLO. Na SLO 99. 9% budżet błędu = 0. 1% czasu/żądań.
SLA (Umowa) - prawnie istotny poziom usług: obejmuje SLO, pomiary, wyjątki, rekompensaty/grzywny.

2) Zasady projektowania

Objawy> wewnętrzne wskaźniki. SLIs powinny odzwierciedlać rzeczywiste doświadczenie użytkownika.
Niewielka liczba kluczy SLIs. Do obsługi - 2-5 głównych: sukces, opóźnienie, przepustowość/świeżość, poprawność.
Pokrycie ścieżek krytycznych. Każdy scenariusz biznesowy (realizacja transakcji, login, webhook, pobieranie ETL) ma własny zestaw SLI/SLO.
Ścisła semantyka „sukcesu”. Nie „kod 200”, ale „użytkownik otrzymał odpowiedź na czas i wynik jest ważny”.
Rozdzielenie zewnętrznych i wewnętrznych układów SLO. Wewnętrzne - bardziej rygorystyczne; zewnętrzny SLA ≤ 1-2 dziewięć dolnych.

3) Katalog SLI (odniesienie)

3. 1 API/Usługi online

Sukces: 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Opóźnienie: p95/p99 'http _ server _ duration _ seconds' drogą/metodą/najemcą

Przepustowość: „RPS ”/limity/kwoty

Poprawność: odsetek ważnych odpowiedzi (podpisy, schematy, niezmienne)

3. 2 haki/asynchroniczne dostawy

Dostawa: odsetek zdarzeń potwierdzonych w sekundach T i ≤ N przekładni

Klienci: odsetek abonentów bez długiego opóźnienia (na najemcę)

3. 3 Dane/ETL/DWH

świeżość: 'teraz − last_successful_ingest_ts'

Kompletność: "ingested _ rows/ expected_rows'

Poprawność: odsetek rejestrów, które przeszły kontrole jakości

Rurociągi: udział miejsc pracy ukończonych przed upływem terminu

3. 4 SDK mobilne/klienckie

Sukces klienta: odsetek sesji bez błędów śmiertelnych

Latalność w obie strony: p95 od prośby do renderu

Cache trafienia: procent podawany z pamięci podręcznej (jako objaw wydajności)

4) Wzory i przykłady celów

• „SLI _ req _ avail = 1 − (failed_requests/ total_requests)”
• "SLO _ req _ avail = 99. 95% 'przez 30 dni → budżet błędu = 0. 05% wniosków.

• "czas pracy = (obs_window − czas przestoju )/ obs_window'

• „SLO _ latency = p95 (trasa = ”/pay„) ≤ 400 ms ”na 7-dniowych plasterkach, z wyłączeniem podgrzewaczy pamięci podręcznej (1%)

• "SLO _ świeżość (zestaw danych =" zamówienia ") ≤ 10 min 'p99 w 24 godziny.

5) Budżet błędu i zarządzanie zmianami

Budżet (B): „B = 1 − SLO”.
Oparzenie - stosunek rzeczywistych błędów do dopuszczalnych błędów.

• Overspend (spalić> 1) → funkcja zamrozić, skupić się na niezawodności.
• W szybkości spalania> X w krótkim oknie - incydent i cap. środki.
• Planowanie: Udział sprintu w niezawodności koreluje z oparzeniami w minionym okresie.

6) Ostrzeganie: szybkość spalania i zasady multi-window

Pomysł: łapiemy szybkie przecieki i powoli dryfujemy.

• Krytyczny: „2% budżetu w ciągu 1 godziny” (szybki ogień).
• Ostrzeżenie: „5% budżetu w ciągu 6 godzin” (pełzająca degradacja).

• Krótkie okno (minuta-godzina) dla szybkich incydentów.
• Długie okno (6-24 godziny) dla trendów.
• Opóźnienie: alert o p99> próg ≥ 5 min, z tłumieniem klapowania i komunikacją z instancjami śladowymi.

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) Wielopoziomowy i segmentacja

SLI/SLO są liczone według najemców/planów/regionów, w przeciwnym razie mediana „zatuszuje” awarie.
Minimalna liczba zdarzeń o znaczeniu statystycznym (szyny ochronne).
SLA może się różnić w taryfach (na przykład, "Pro 99. 9%, Free 99. 5%»).

8) Związek z obserwowalnością i śladami

Wskaźniki SLI - od histogramów/liczników z wzorcami → przejście na „złe” szlaki.
Logi są źródłem powodów: timeouts, kody błędów biznesowych, limity.
Dla danych - link z lineage: „która praca opóźniła świeżość metryki”.

9) Umowy i SLA

• SLI/metoda pomiaru/definicje okien.
• Wyjątki (planowana praca, siła wyższa).
• Procedura incydentu i komunikacji (strona statusu, RFO/RCA).
• Kredyty serwisowe i żądanie zamówienia.
• Jurysdykcja, okres ważności, warunki rewizji.

• Nigdy publicznie nie obiecuj SLO bardziej rygorystyczne niż pozwalają na to architektura i praktyki operacyjne.
• Oddzielne wewnętrzne układy SLO i zewnętrzne jednostki SLA.

10) Koszty i priorytety

Cena dziewiątek nie rośnie liniowo. «99. 9% → 99. 99%" = inna klasa architektury (N + 1, multi-zone, asset-to-asset).
Umieść SLO na najcenniejszych akcji użytkownika.
Kontroluj koszt telemetrii - obniżenie ilości, repliki i składowanie według klas.

11) Procedury i sprawozdawczość

Raporty tygodniowe: wykonanie SLO przez usługodawcę/najemcę, wydatki budżetowe, główne przyczyny, plany poprawy.
Po incydencie RCA: łączymy się z kawałkami budżetu; ustawiamy zadania, aby wyeliminować przyczyny roota.
Fichfriz: kryteria włączenia/wycofania.

12) Szablony (na szybki start)

12. 1 karta SLO (przykład)

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. Tabela zapadalności 2 SLO

13) Przykłady zasad (fragmenty)

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 dla danych i ML (cechy)

Końcowe dane SLO: świeżość p99, kompletność p99, czas „regeneracji” po awarii.
Umowy na dane: przewidywane programy, wolumeny, terminy; naruszenie danych → incydent.
ML: SLO dla opóźnienia wnioskowania, SLA dla dostępności stor funkcji, monitorowanie dryfu (jakość modelu jest osobnym tematem, poza SLA).

15) Integracja z bezpieczeństwem i prywatnością

dzienniki SLI bez PII/tajemnic; tokenizacja/maskowanie.
Zmiany audytu SLO/SLA i publikacje raportów w dziennikach niezmiennych.
Dla ścieżek regulacyjnych (płatności/PII) - oddzielne, bardziej rygorystyczne SLO.

16) Listy kontrolne

Przed rozpoczęciem usługi/funkcji

• Sukces/opóźnienie/przepustowość/świeżość SLIs zdefiniowane.
• zdefiniowane SLO i okna; oblicza się budżet błędu.
• Ustawić alerty prędkości spalania (krótkie + długie).
• Deski rozdzielcze RED + przykłady → trasy; Książki wypadkowe.
• Sekcje wielopoziomowe i progi znaczenia.
• Fichfreeze i procedura sprawozdawcza.

Operacja

• Raport tygodniowy SLO/spalanie, plany utwardzania.
• Ponowna ocena SLO w przypadku zmian architektury/obciążenia.
• Okresowe „incydenty wiertła” i aktualizacje runibooka.
• Monitoruj koszt telemetrii i liczbę SLI.

17) Runbook 'а

Runbook: Szybki wzrost p99/pay

1. Alert p99> próg → otwórz deskę rozdzielczą → przejdź przez wzorzec, aby śledzić.
2. Znajdź wąską rozpiętość KLIENTA/SERWERA, porównaj regiony/wersje.
3. Włącz degradację (cache/limit/fallback), powiadom polecenie zależności.
4. Po stabilizacji - RCA, zadania optymalizacji, aktualizacji pomiarów SLO.

Spis startowy: wydatki budżetowe> 50% na tydzień

1. Zamrozić funkcje, podnieść priorytet niezawodności.
2. Klastrowanie błędów: według tras/najemców/zależności.
3. Wprowadzenie korekt → potwierdzenie odzyskiwania trendu.
4. Korekta retrospektywna i alarmowa/progowa.

18) FAQ

P: Ile SLO potrzebujesz?
Odp.: Minimum na krytycznych scenariuszach użytkownika: sukces + opóźnienie. Wszystko inne nie jest konieczne.

P: Który jest lepszy - dostępność na czas lub na życzenie?
Odp.: Na żądanie - więcej metryki użytkownika. Czas jest wygodny dla komponentów sieciowych/infra.

P: Dlaczego p95, a nie średnia?
Odp.: Środkowy ukrywa ogon; użytkownik czuje p95/p99.

P: Jak nie „dokręcić śrub” za dużo?
Odp.: Zacznij od realistycznych celów (dane historyczne), a następnie dokręć w miarę dojrzewania.

• „Obserwowalność: kłody, mierniki, ślady”
• „Rozprowadzone ślady”
• „Audyt i niezmienne kłody”
• „Webhook gwarancji dostawy”
• „W tranzycie/w odpoczynku szyfrowanie”
• „Pochodzenie danych (rodowód)”