SLA, SLO i niezawodność KPI

1) Terminy i różnice

SLI (Service Level Indicator) - wymierny wskaźnik jakości (na przykład odsetek udanych wniosków, opóźnienie p95).
SLO (Service Level Objective) - docelowa wartość SLI na okno czasu (na przykład, "success ≥ 99. 9% w ciągu 28 dni").
Budżet błędu - Dopuszczalny wskaźnik awarii SLO wynosi '1 − SLO'.
SLA (umowa o poziomie usług) - zobowiązania umowne z grzywnami/kredytami (zewnętrznymi).
Niezawodność KPI - mierniki procesów operacyjnych (MTTD/MTTA/MTTR/MTBF,% automatyczne łagodzić, pokrycie alarmowe, itp.).

2) Jak wybrać SLI (na podstawie złotych sygnałów)

1. Opóźnienie - p95/p99 dla kluczowych punktów końcowych.
2. Ruch - RPS/RPM/przepływ wiadomości.
3. Błędy - udział błędów 5xx/business (na przykład wyklucz spadek płatności z powodu błędu PSP).
4. Nasycenie - nasycenie zasobów (CPU/RAM/IO/lag).

• Koreluje z doświadczeniem postrzeganym przez użytkownika.
• Technicznie dostępny i stabilny w pomiarze.
• Kontrolujemy (działania na rzecz poprawy są możliwe).
• Niski koszt zbiórki.

3) Wzory i przykłady

3. 1 Dostępność

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Przykład: SLO 99. 9% w ciągu 30 dni → budżet błędu = 0. 1%, co odpowiada 43 min 12 sekund niedostępności.

3. 2 Opóźnienie

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Płatności (poziom działalności)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Wadliwy budżet i stopa spalania

Błąd budżetowy - twój „zbiornik paliwa” na innowacje (wydania, eksperymenty).

• szybki kanał (wykrywanie w ~ 1 h),
• powolny kanał (trend przez ~ 6-12 h/24 h).

• Jeśli szybkość spalania> 14. 4 w 1 godzinę - SEV-1 (będziemy jeść dzienny budżet w ~ 100 minut).
• Jeśli szybkość spalania> 6 w 6 godzin - SEV-2 (szybka degradacja).

5) Ostrzeganie przez SLO (multi-window, multi-burn)

Wskaźnik błędu: odsetek naruszeń 5xx lub opóźnień.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Przykłady SLI/SLO według domeny

6. 1 Brama/krawędź API

SLI-Błędy: 5xx wskaźnik odpowiedzi <0. 1% (28d).
SLI-Latency: p95 ≤ 250 ms (dzień).
SLO: Dostępność ≥ 99. 95% (kwartał).

6. 2 Płatności

SLI-Success: płatność za udane (z wyłączeniem awarii klienta) ≥ 99. 8% (28d).
SLI-Latency: zezwolenie ≤ 2 sekundy na 99% (dzień).
SLO: Time-to-Wallet p95 ≤ 3 мий (24h).

6. 3 bazy danych (PostgreSQL)

SLI-Lag: lag replikacji p95 ≤ 1 sek (dzień).
SLI-Errors: Błąd zapytania ≤ 0. 05% (28d).
Dostępność klastra SLO ≥ 99. 95%.

6. 4 kolejki/Streaming (Kafka)

SLI-Lag: konsumenckie wiadomości lag p95 ≤ N (godzina).
SLI-Trwałość - potwierdzenie ≥ 99 pozycji. 99% (28d).
SLO: dostępność brokerów ≥ 99. 9%.

7) Proces niezawodności KPI

MTTD (średni czas do wykrycia)

MTTA (... Aby potwierdzić)

MTTR (... Aby przywrócić)

MTBF (... Między awariami)

% incydentów z automatycznym łagodzeniem

Zasięg SLO/alarmowy górnych ścieżek ruchu (cel ≥ 95%)

Udział wydań z etapem kanaryjskim

Zużycie błędnego budżetu według zespołów/cech

8) Jak umieścić SLO realistyczne

1. Pomiar aktualnej wiarygodności wyjściowej (3-4 tygodnie).
2. Zdefiniuj „wrażliwe” ścieżki użytkownika (login, deposit, game).
3. Weź pod uwagę koszt każdego odchylenia (czas, pieniądze, reputacja).
4. Wybierz ambitny, ale możliwy do osiągnięcia cel (poprawa poziomu odniesienia o 10-30%).
5. Kwartalny przegląd.

• Natychmiast „pięć dziewiątek” bez uzasadnienia.
• SLO według mierników niewidocznych dla użytkownika (na przykład procesor bez komunikacji z UX).
• Zbyt dużo SLO → aerozol ostrości.

9) SLO i sprawozdawczość budżetowa

• Zakończenie na SLO: rzeczywisty cel vs, trendy, pewność siebie.
• Podsumowanie zużycia błędów: ile budżet jest „spalony” niż przez kogo (zwolnienie/incydent).
• Pięć głównych przyczyn degradacji, plan CAPA i status zadania.
• Wpływ na działalność: konwersja, ND, retencja, LTV.

10) Komunikacja z polityką uwolnienia

Budżet błędu <50% → darmowe wersje.
50-80% → „tryb ostrożności”: tylko obliczenia niskiego ryzyka/kanarkowe.

11) SLA (umowne) - szablony pozycji

Obowiązek dostępności: na przykład 99. 9 %/miesiąc.
Force Majeure: DDoS poza rozsądną kontrolą, dostawcy osób trzecich.
Okno pomiarowe i obszar odpowiedzialności: źródła mierników, metoda obliczeniowa.
Kredyty/kary: tabela poziomów (na przykład, niedostępność 60-120 minut → kredyt X%).
Procedury eskalacji i powiadamiania: terminy, kanały.
Dane i prywatność: maskowanie, przechowywanie, przechowywanie.
Plan zapobiegania powtarzaniu (CAPA) w przypadku naruszenia przepisów.

12) Narzędzia pomiarowe

Metryka pasywna: Prometeusz/Mimir/Thanos, eksporterzy.
Dzienniki: Loki/ELK do liczenia sukcesów/błędów na poziomie biznesowym.
Syntetyka: próbki aktywne (login/deposit/game) według cron.
Odwzorowanie: Tempo/Jaeger dla p99 wąskich gardeł.
Płatności/Finanse: naziemne źródła prawdy dla płatności SLI.

13) Przykłady zapytań (szablony)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

klucz> Dopracuj filtry, aby wykluczyć „spadek przez klienta”.

14) FinOps i niezawodność

Koszt na 9: Koszt dodania dziewięciu rośnie wykładniczo.
Krzywa korzyści: optymalna, gdy wzrost przychodów/spadek strat ≥ koszt dodatkowego „9”.
Portfel SLO: różne poziomy dla różnych ścieżek (płatności krytyczne są „droższe”, sprawozdawczość jest „tańsza”).

15) SLO/Alert Quality - Lista kontrolna

• SLI koreluje z UX i metrykami biznesowymi.
• Okno i agregacja są spójne (toczenie 28d/kwartał).
• Ostrzeżenia dla wielu okien, brak klapek, routing oparty na rolach.
• Dokumentacja: właściciel, formuła, źródła, książka startowa.
• Panel demo SLO z błędnym budżetem i wskaźnikami spalania.
• Regularne przeglądy celów (kwartalne).
• Badania syntetyczne kluczowych scenariuszy.

16) Plan realizacji (4 iteracje)

1. Tydzień 1: inwentaryzacja ścieżek użytkownika, projekty SLI, podstawowe deski rozdzielcze.
2. Tydzień 2: formalizacja SLO, budżetowanie, alerty (szybkie/powolne spalanie).
3. Tydzień 3: integracja z procesem incydentu/zwolnienia, zasady zamrażania.

4. Tydzień 4 +: Umowne SLA, Opinie kwartalne, „koszt na 9” Finops Model

17) Mini-FAQ

Czy potrzebuję jednego SLO na usługę?
Lepsze 2-3 kluczowe (sukces + opóźnienie) zamiast dziesiątki drugorzędnych.

Co jeśli budżet jest wyczerpany?
Freezing uwalnia, koncentrując się na stabilizacji i CAPA, usuwając funkcje eksperymentalne.

Jak uniknąć konfliktu między prędkością uwolnienia a niezawodnością?
Plan uwalnia „na budżet”, wdrożyć kalkulacje kanaryjskie i flagi funkcji.

Wynik

Niezawodność nie jest kontrolowana przez zestaw rozbieżnych mierników, ale przez system: SLI → SLO → błąd budżetu → spalić alert → proces incydentu → CAPA → SLA. Standaryzacja definicji, źródeł danych i sprawozdawczości, powiązanie celów z doświadczeniem użytkownika i ekonomią oraz regularne przeglądy dziewiątek opartych na rzeczywistym ROI.