Obserwowalność i kontrola stanu

1) Cele i zasady

Cel: Zrozumienie „co się dzieje” i „dlaczego” w czasie rzeczywistym, aby zapobiec incydentom i szybko wyzdrowieć bez naruszania SLO lub inflacji OPEX.
Zasady: SLO-first, „złote sygnały” (opóźnienie, ruch, błędy, nasycenie), pojedynczy standard telemetrii (OpenTelemetry), minimalnie wystarczające szczegóły, wyjaśnienie, świadomość kosztów obserwacji.

2) Warstwy obserwowalności

1. Mierniki: agregaty dla SLI/SLO, pojemność i trendy (modele RED/USE).
2. Ślady: łańcuchy przyczynowe żądań, płatności i transakcji gier.
3. Dzienniki/wydarzenia: szczegółowy kontekst i audyt działań operatora/serwisu.
4. Syntetyka (czarna skrzynka): zewnętrzne sprawdzanie ścieżek API/WWW, pingi zdrowotne PSP/KYC.
5. RUM (prawdziwy użytkownik): metryki z przodu (TTFB, LCP, błędy JS), plasterki geo/urządzenia.
6. Telemetria niskiego poziomu: eBPF/CPU profilowanie/IO/alloc, opóźnienia percentyla sieciowego.

3) Zestaw SLI i złote sygnały

Opóźnienie: p50/p95/p99 na ścieżkach krytycznych (login, deposit, rate, withdrawal).
Błędy: udział 5xx/timeout/decrease (znormalizowany przez dostawców/banki).

Ruch/przepustowość: RPS/TPS, sesje aktywne, wydarzenia/sec

Nasycenie: obciążenie procesora/pamięci RAM/IO, głębokość kolejki, wykorzystanie puli, opóźnienie replikacji.
Business SLI: udane depozyty/% stawek za okno, odchylenia konwersji KYC/PSP, udział w obciążeniu zwrotnym.

4) Architektura telemetrii

Standardowy wtrysk: OpenTelemetry SDK/kolektor → normalizacja, pobieranie próbek, filtry prywatności → przechowywanie (TSDB, ślady, dzienniki).
Korelacja: ślad-id/span-id w dziennikach i miernikach (przykłady); pojedynczy identyfikator korelacji dla imprez płatniczych/gier.
Topologia: wykres usług, zależni zewnętrzni dostawcy z żywymi SLIs.
Zarządzanie kosztami: poziomy retencji, agregacje, pobieranie próbek dynamicznych, klasy przechowywania „na gorąco „/” na zimno „.

5) Metryka: Projektowanie i kardynalność

Reguły: niewielka liczba etykiet, zakaz wysokiej kardynalności (Z-Id, Z-Id) w serii czasowej; takie szczegóły - tylko w trasach/dziennikach.
RED/USE: Requests-Errors-Duration дла API; Wykorzystanie-Nasycenie-Błędy dla infrastruktury.
Przykłady: wiązanie wysokich percentyli do konkretnych przykładów śladowych.
Wskaźniki biznesowe: $/RPS, konwersja banku PSP/GEO, odporność dostawcy.

6) Odwzorowanie: Głębokość i pobieranie próbek

Kontekst: rzucamy kontekst śladowy przez przód → API → maklerzy → procesory → bazy danych/PSP.
Pobieranie próbek: podstawowy 1-10%, z anomaliami - dynamiczny wzrost zgodnie z zasadami (na podstawie ogona).
Focus: przepływ płatności (init → auth → przechwytywanie/rozliczanie), transakcje gry (zakład → rozliczanie), KYC (init → zweryfikować).
Adnotacje: PSP-kod odpowiedzi, bank-BIN/emitent-kategoria, region, stopa ryzyka.

7) Dzienniki i audyty

Logi strukturalne: JSON, poziom według profilu (INFO na prod, DEBUG w debug).
Filtry prywatności: maskowanie PII, zakaz surowych dokumentów KYC w logach.
Zdarzenia audytowe: kto/co/gdzie/kiedy/dlaczego, identyfikator biletu, wartości przed/po transakcji wysokiego ryzyka (premie, limity, routing PSP).
Niekwalifikowalność: WORM/immutable, signature, retention by policy.

8) Kontrola stanu (zdrowia)

Pobudzenie/gotowość/uruchamianie: prawidłowe próbki (nie sprawdzaj zewnętrznych zależności w umieralności).
Tryb degradacji: wyraźne flagi degradacji usługi, dzięki czemu wpisy i strona stanu są spójne.
Zdrowie budżetu: budżet na błąd oparzenia (szybkie/powolne okno), zagłówek według zasobów i kolejek.

9) Ostrzeganie i wczesne ostrzeganie

Wpisy SLO: w zależności od budżetu błędu (4-godzinne i 1-godzinne okna) zamiast „surowego” p95.
Anomalie: STL/IQR/detektory online dla 5xx wybuchów, autoryzacje PSP spadają w konkretnym GEO/banku.
Wskazówki przyczyny: łączymy wpisy z najnowszymi wydaniami/ficheflagami/planowanymi pracami.
Runbooks: każdy alert ma linki do odtwarzania, wykresy, „szybkie kontrole”.

10) Deski rozdzielcze (kto widzi co)

Exec: uptime/SLO, stopa spalania, udane depozyty/stawki, status dostawcy, prognoza przepustowości i $/RPS.
SRE/platform: RED/USE by service, kolejki/lag, pool-use, lag replikacji, CDN/WAF, profile eBPF.
Płatności/Ryzyko: sukces PSP/bank/GEO autoryzacji, miękkie/twarde spadki, czas KYC, wczesne sygnały obciążenia zwrotnego.
Obsługa/CS: panel stanu zdarzeń, SLA odpowiedzi, makro FAQ.

11) Obserwowalność FinOps

Zatrzymanie: 7-14 dni dla „surowych” torów, jednostek dłuższych; selektywnie - gorące usługi.
Pobieranie próbek/agregacja: pobieranie próbek dynamicznych przez anomalię, zmniejszanie liczby starych serii.
Polityka ingestyjna: odcięcie hałasu (pingi zdrowotne, nadmiarowe kłody), kwoty dla mierników wysokiej kardynalności.
Koszt KPI: $/GB ingest, $/trace, $/SLI deska rozdzielcza; okresowe recenzje najlepszych zjadaczy.

12) Prywatność i zgodność

PII/Finance: maskowanie, tokenizacja, minimalizacja danych w telemetrii.
Lokalizacja geograficzna: przechowywanie i przetwarzanie według jurysdykcji; eksport dziennika - tylko poprzez zatwierdzony przepływ pracy z szyfrowaniem i TTL.
Audyt dostępu do telemetrii: RBAC/ABAC, SoD do przesyłania, dziennik żądań.

13) Integracja z zarządzaniem incydentami i uwolnieniami

Strona stanu: automatyczna aktualizacja paszy z karty incydentu.
Brama uwolnienia: analiza kanaryjska SLI, automatyczne zwolnienie przy szybkości spalania> próg.
pośmiertnie: linia czasu ze szlaków/kłód, rzeczywiste SLIs i okna naruszenia.

14) Praktyka wdrażania (8-12 tygodni)

Ned. 1-2: wykaz ścieżek krytycznych i SLI; wybór stosu (OTel, TSDB, kłody, ślady); mapa zależności.
Ned. 3-4: Wdrożenie OTel w 3-5 kluczowych usługach (login/deposit/rate), podstawowe RED/USE, kontekst śledzenia w dziennikach.
Ned. 5-6: wpisy SLO i szybkości spalania; syntetyki zgodnie z PSP/KYC; pierwsze książki startowe; RUM do sieci web/mobile.
Ned. 7-8: pobieranie próbek dynamicznych, przykłady, mapa serwisowa; Deski rozdzielcze Exec/SRE/Payments.
Ned. 9-10: eBPF/profilowanie gorących wąskich gardeł; filtry prywatności; kwoty/zatrzymania.
Ned. 11-12: bramki uwalniające i auto-rollback przez SLI; Integracja ze statusowymi naukami na tablopie.

15) Wzory artefaktów

SLO-card usługi: SLI, cele, okna, budżet błędu, wpisy, właściciele.
Alert Spec: metryczny/stan, progi, deadup/cisza, odbiorcy, runbook.
Deska rozdzielcza Spec: publiczność, pytania, 6-8 widżetów, źródło danych, szybkość odświeżania.
Polityka telemetrii: jakie pola są dozwolone/zabronione, retencja, maskowanie, eksport.
Pakiet przeglądu kosztów: Top Series/Strumienie dziennika, Oferta próbkowania/TTL, Oczekiwane oszczędności.

16) Funkcja obserwacji KPI

MTTA/MTTR (poprawa po wdrożeniu SLO-alerting).
% incydentów wykrytych przez syntetyki/SLI przed reklamacjami użytkowników.
Odsetek zwolnień, które przeszły bramę przez SLI bez ręcznej interwencji.
Spadek USD/RPS na telemetrię przy jednoczesnym zachowaniu diagnostyki.
Śladowe pokrycie ścieżek krytycznych (> 90%).

Dokładność korelacji „aktualizacja stanu”

17) Antypattery

„Zaloguj wszystko” → eksplozja kosztów i hałasu.
Alerty na „surowe” mierniki zamiast SLO/szybkość spalania → pager-zmęczenie.
Wysoka kardynalność metryk (ID) → Burze TSDB.
Szlaki bez kontekstu biznesowego (PSP/bank/GEO) → brak wglądu.
Brak związku obserwowalności z uwolnieniami/incydentami → telemetria żyje oddzielnie.

Razem

Obserwowalność i kontrola stanu nie jest zbiorem narzędzi, ale zarządzanym systemem: poprawne SLI/SLO → znormalizowana telemetria i korelacja → SLO alert i runbooks → integracja z wersjami i komunikacją stanu → opłacalna obsługa i prywatność. Taka pętla daje wczesne sygnały, szybki RCA i odporność biznesu nawet w ekstremalnych szczytach ruchu.