KPI infrastruktury i czas eksploatacji

Dlaczego go potrzebujesz?

KPI infrastruktury zmieniają „uczucia” dotyczące stabilności w wymierne cele, zarządzają ryzykiem i skupiają się na pracy. Odpowiednie mierniki łączą techniczne SLIs z wynikami biznesowymi (konwersja, Czas-do-portfela, LTV) i pozwalają zaplanować rozwój, obciążenie i udział innowacji vs niezawodność.

Podstawowe koncepcje: SLI, SLO, SLA i budżet błędów

SLI (Service Level Indicator) - mierzony wskaźnik jakości: odsetek udanych wniosków, opóźnienie p95, góra na przedział.
SLO (Cel poziomu usług) - cel SLI (na przykład, "sukces ≥ 99. 9% w ciągu 30 dni").
SLA (Umowa) - obietnica zewnętrzna z karami/kredytami. Zawsze pochodzi od SLO, ale nie równa.
Budżet błędu = '1 − SLO'. Jest to maksymalna dopuszczalna szybkość awarii na okno pomiarowe. Kiedyś podejmował decyzje o ryzykownych zwolnieniach i eksperymentach.

Przykład:

Dostępność SLO 99. 95% w ciągu 30 dni → budżet błędu 0. 05% ≈ 21. 6 minut „awarii” w miesiącu kalendarzowym.

Cztery złote sygnały i dodatkowe

1. Opóźnienie (p50/p90/p95/p99, ogon jest ważniejszy niż średnia).
2. Błędy (5xx/timeout/błędy biznesowe).
3. Ruch/przepustowość (RPS/QPS, MBp).
4. Nasycenie (CPU/RAM/IO/FD/połączenia/GC/kwoty).
Dodatkowe: zimny start, kolejki/zaległości, czas wdrożenia, zgodność SLO.

Model SLI dla różnych rodzajów usług

HTTP/API

Dostępność: '(udane 2xx/3xx − błędy logiczne )/( wszystkie żądania)'

Opóźnienie: „p95” dla udanych zapytań; Cel na gorących trasach.
Jakość: odsetek wniosków z poprawną „publicznością/zakresem” (bez błędów authZ).

Kolejki/asynchroniczne

Czas przetwarzania wiadomości: p95 end-to-end ≤ N seconds

Zaległości: mediana <X, ogon p99 <Y.
Błąd dostawy: ≤ Z ppm.

DB/Cache

Opóźnienie operacji: p95 get/put/commit.
Nasycenie: wykorzystanie puli połączeń, współczynnik trafienia w pamięci podręcznej.
Błędy: timeouts, impasy, burze eksmisji.

CDN/Static

Współczynnik trafienia: poziom docelowy ≥; degradacja → wzrost obciążenia na pochodzenie.
Dostępność POP: Anycast, awarie są kompensowane przez sąsiadów.

Płatności (Business SLI)

Czas do portfela p95, sukces depozytowy/wyjściowy%, wskaźnik awarii PSP.

Obliczanie dostępności i czasu wolnego od pracy

Dostępność usługi = 'udane żądania/wszystkie żądania' (najlepiej nie 'minuty uptime').
Alternatywą dla węzłów infrastrukturalnych jest „czas zielony/czas okna”.
Okno kalendarza: 28-31 dni, okno przesuwne: ostatnie 30/90 dni.
Godziny pracy/krytyczne okna: dla backoffice można uznać czas pracy zgodnie z harmonogramem (na przykład, 08: 00-22: 00 czasu lokalnego).

Skład zależności (uproszczony): Jeśli usługa A zależy od B i C, w przypadku niepowodzeń niezależnych:

„Dostępność (A) Av (B) × Av (C) × Av (A 'B, C)” - ważne jest, aby położyć SLO na granicach.

Przykładowy zestaw SLO (próbka)

Brama API: ≥ 99 dostępnych. 95 %/30d; p95 opóźnienie ≤ 120 ms; błąd ≤ 0. 2%.
Realizacja transakcji/płatności: powodzenie depozytu ≥ 98. 5 %/30d; Czas do portfela p95 ≤ 90 "; PSP-timeouts ≤ 0. 3%.
Baza danych: p95 odczytuje ≤ 10 ms; p95 zapisać ≤ 25 ms; replika lag p95 ≤ 150 си.
Pamięć podręczna: współczynnik trafienia ≥ 85%; sztormy eksmisyjne = 0/30 ".
Wypłaty: przetwarzanie p95 ≤ 5 min; oszustwa-upadki-pozytywne ≤ 0. 3%.

Zarządzanie budżetem błędów i zmianami

Jeśli budżet błędu jest wyczerpany o 50% + przed środkiem okna, wprowadza się „zamrożenie” funkcji/wersji, skupia się na stabilizacji.
Jeśli budżet jest wydawany powoli, można przyspieszyć eksperymenty/kanarki.
Podłącz zużycie budżetu do konkretnych wydań/incydentów za pomocą 'release _ id'.

Ostrzeganie: jak nie „dzwonić nocą” na próżno

Alerty tylko dla degradacji SLO i istotnych objawów, nie dla każdej metryki.
Multi-window, multi-burn rate: short window (5-15 min) + long window (1-6 h).
Przykład: „Szybkość spalania 14 × w 5 minut I 6 × w 1 godzinę” → strona dyżuru.
Ciche godziny dla sygnałów non-P1; routing własności.

Deski rozdzielcze i praktyki wizualizacji

Panel SLO: zgodność usług, pozostały budżet, mapy zależności.
Panel opóźnień: p50/p90/p95/p99, rozkład na trasach/najemcy/kraje/ASN.
Panel błędów: kody/przyczyny, korelacja z flagami wydań/funkcji.
Panel przepustowości: CPU/RAM/IO/network/FD/connections, trendy i prognozy.
Panel biznesowy: konwersja, czas do portfela, depozyty/wypłaty, wpływ zabezpieczeń (WAF/anty-boty).

Incydenty, MTTR i pośmiertne

Reakcja KPI:

MTTD (wykrywanie), MTTA (akceptować), MTTR/MTTC (odzyskiwanie/przechowywanie),% incydentów bez RCA na czas.
Playbooks: kto eskaluje, jak włączyć flagi/bloki funkcji, jak cofnąć wydanie, komunikację z firmą.
Postmortem (nienaganny): fakty, linia czasu, przyczyny (te/procesy), działania: natychmiastowe/długoterminowe, testy regresji, wpływ na SLO.

Wydajność, nasycenie i degradacja

Zagłówek: zagłówek zasobów docelowych (np. Procesor <70% p95, RAM <75% p95).
Gorące ścieżki: profilowanie tras krytycznych; „p99” jest ważniejsze niż średnia.
Tryby degradacji: tylko pamięć podręczna, tylko do odczytu, szlifowanie nieistotnych wniosków, „limit stawki „/kontyngent.

Wzory i przykłady obliczeń

1) Dostępność na żądanie


availability = (total_requests - error_requests) / total_requests

gdzie 'error _ requests' = 5xx + timeouts + business errors (configurable).

2) Budżet błędu (protokół)


error_budget_minutes = window_minutes (1 - SLO)

Przykład: 30 dni (43 200 min), SLO 99. 95% → 21. 6 min.

3) Szybkość spalania


burn_rate = observed_error_ratio / (1 - SLO)

Jeśli SLO 99. 9% (budżet 0. 1%) i błąd 1% → burn_rate = 10 ×.

4) Dostępność związków


A_total ≈ A_gw × A_auth × A_db × A_psp

Małe upadki mnożą się w całej A.

Zasady pomiaru i wyjątków

Nieplanowane okna (incydenty) - brane pod uwagę.
Planowane okna konserwacyjne - brane pod uwagę tylko wtedy, gdy SLA jest tak przepisany; dla SLO często nie są odejmowane (lub oznaczane oddzielnie jako „planowane _ przestoje”).
Syntetyka w porównaniu z rzeczywistymi użytkownikami: przydatne jest posiadanie obu kanałów (RUM + kontrole syntetyczne).

Przykłady artefaktów

KQL/PromQL (pomysły)

Błąd SLI (5xx + timeouts) w 5 minut:

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

p95 latencja - trasa:

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

Szybkość spalania 5m/1h:

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL (Payment Business SLI)

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

Zarządzanie zależnościami i kaskadami

Kontrakty SLO między zespołami: brama, bramka, bramka, portfel, PSP.
Polityka degradacji: po spadku zależności usługa wchodzi w tryb uproszczony.
Flagi funkcyjne: wyłączanie funkcji innych niż krytyczne, „szare uwalnianie” w celu zmniejszenia opóźnień ogonów.

Planowanie przepustowości i prognozy

Schomes. Prognoza RPS/MBp według trendów i wydarzeń (turnieje, mecze, promocje).
Badanie obciążenia „złotymi ścieżkami”, oddzielne testy dla PSP/wypłat.
Stado na szczycie: współczynnik docelowy 1. 3 × -2. 0 × oczekiwanego obciążenia.

Lista kontrolna implementacji SLO/KPI

1. Zidentyfikować krytyczne ścieżki użytkownika i negocjować SLI „z perspektywy klienta”.
2. Wybierz cele SLO i okno (30/90 dni); obliczyć budżet błędu.
3. Zbuduj kolekcję metryczną do bram/usług, znormalizuj kody/powody.
4. Konfiguruj alerty o szybkości spalania (krótkie + długie okno), routing i dyżury.
5. Wizualizacja zgodności SLO, kojarzy się z wydaniami/flagami funkcji.
6. Tworzenie budżetu przeciwko polityce zmian i proces zamrożenia.
7. Retrospektywy i RCA na każdym nadmiarze, testy regresyjne.
8. Przegląd SLO kwartalnie dla rzeczywistego wykorzystania budżetu i celów biznesowych.

Częste błędy

Zmierz „uptime by ping”, ignorując błędy aplikacji.
SLO są ustawione „w rezerwie” (99. 999%), ale nieosiągalne i rozwiązać nic.
Alerty na niskim poziomie mierników zamiast objawów użytkownika.
Nie ma mapy zależności → nie jest jasne, gdzie płonie.
Nie ma związku między SLO i wydania → nie jest jasne, kto „zjadł” budżet.
Ignoruj p99 ogony → dobra średnia, ale źle UX VIP użytkowników.

iGaming/specyficzne dla fintechu

Zaplanowane szczyty: mecze/wydarzenia/promocje - zwiększenie przepustowości z wyprzedzeniem, podgrzewanie pamięci podręcznej/CDN, zawierają specjalne profile limitów.
Business SLI: Time-to-Wallet, success deposit/withdrawal, „speed payout” p95; u źródła desek rozdzielczych.
PSP/partnerzy: indywidualne SLO/deski rozdzielcze przez dostawcę, automatyczne przełączanie trasy.
Antybiotyk/zwalczanie nadużyć finansowych: nie powinno być budżetu na błędy - oddzielne „legalne bloki” od „błędów technicznych”.
Regulacja: przechowywanie kłód, powtarzalność obliczeń SLO/SLA, raporty incydentów.

NAJCZĘŚCIEJ ZADAWANE PYTANIA

Czy muszę odjąć zaplanowane prace od SLO?
Zazwyczaj nie: SLO odzwierciedla doświadczenie doświadczone przez użytkownika. Można określić wyjątki dla SLA.

Dlaczego p95, nie średnia?
Środkowy maskuje ogony; UX definiuje ogony (p95/p99).

Czy mogę mieć jeden SLO dla całego produktu?
Potrzebujesz drzewa SLO: agregat według produktu i dzieci według ścieżek/komponentów krytycznych.

Razem

Silny system KPI infrastruktury to niestandardowe SLIs, realistyczne SLO, budżet błędów jako dźwignia kontroli zmian, dyscyplina inteligentnego ostrzegania i incydentów oraz RCA. Połączyć wskaźniki techniczne z metrykami biznesowymi, zautomatyzować kolekcję i wizualizację - a infrastruktura stanie się przewidywalna, a czas pracy będzie kontrolowany nawet w scenariuszach szczytowych.