Operacje i → Wskaźniki kontroli zarządzania i SLA

Audyt mierników i SLA

1) Dlaczego go potrzebujesz

Jeśli mierniki są złe - decyzje będą błędne, SLA zostaną naruszone „na papierze” lub odwrotnie, aby ukryć problemy. Audyt mierników i SLA gwarantuje, że obietnice dla użytkowników i partnerów są porównywalne, niezawodne i legalnie bezpieczne.

• Podać pojedyncze „źródło prawdy” (SSOT) i powtarzalne obliczenia.
• Zmniejszenie rozbieżności między deskami rozdzielczymi/raportami/rozliczeniami.
• Niech SLA będą oparte na dowodach.
• Wykrywanie degradacji w pomiarach już w usługach.

2) Podstawowe pojęcia i granice odpowiedzialności

Metryczne: mierzona ilość (RPS, p95, CR, GGR, wskaźnik sukcesu).
KPI/OKR: cele, z którymi powiązane są wskaźniki.
SLO: docelowa jakość usług (na przykład "p99 ≤ 400 ms 99. 9% czasu").
SLA: obietnica zewnętrzna; istotne pod względem prawnym, oparte na SLO.
OLA: wewnętrzne porozumienie między zespołami/sprzedawcami, wspiera SLA.
SSOT: system/przechowywanie, którego dane są uważane za odniesienia do sprawozdawczości.

3) Taksonomia mierników (warstw)

1. Infrastruktura: procesor/pamięć/IO/Net, strąki/węzły, HPA/VPA.
2. Platforma: kolejki/strumienie (lag, przepustowość), DB/bufory (połączenia, trafienie), API (p95/p99, 5xx).
3. Przepływy biznesowe: wpłaty/wypłaty, zakłady, uruchomienia gier, autoryzacje, KYC.
4. Produkt/marketing: konwersje, ARPPU/LTV, kampanie.
5. Jakość procesów: MTTA/MTTR, wskaźnik awarii zmiany, zakres listy kontrolnej.

Zasada: Każda metryka musi mieć warstwę, właściciela i wzór.

4) Źródła danych i „prawdziwe”

Telemetria online: Prometheus/OTel, logi (ELK/ClickHouse), ślady.
Zdarzenia i rachunkowość: Kafka/Outbox, DWH/Data Marts (Query/ClickHouse).
Artefakty ręczne: pośmiertne, bilety, rejestry incydentów.
Rejestry zewnętrzne: raporty dostawcy (PSP/KYC/studios), rozliczenia.

Rozwiązywanie konfliktów: w przypadku rozbieżności „online vs DWH” stosuje się rozporządzenie priorytetowe (na przykład w przypadku SLA - agregaty z DWH z możliwością śledzenia źródeł).

5) Proces audytu mierników (pętla kontrolna)

1. Inwentaryzacja: katalog mierników/SLO/SLA (nazwa, właściciel, warstwa, wzór, źródło, częstotliwość obliczeń).
2. Weryfikacja wzoru: uzgodnienie zapytań SQL/promo z definicją (testy jednostkowe obliczeń).
3. Pobieranie próbek i ponowne sprawdzanie: zdarzenie próbkowania/linie logarytmiczne i uzgadnianie ręczne.
4. Odwzorowanie konturowe: porównanie desek rozdzielczych online i raportów DWH.
5. Zmiana kontroli: przegląd formuły dla schematu/wersji logicznych.
6. Audyt SLA: weryfikacja poprawności zespołów i wyjątków (planowana konserwacja, siła wyższa).
7. Sprawozdanie i ulepszenia: wykaz wykrytych rozbieżności i poprawek wraz z terminami.

6) Definicje i wzory (próbki)

• „success = żądania - (5xx + timeouts + circuit_open)”
• „success _ rate = success/requests”

• SSOT rejestruje pojedynczą definicję okna (walcowanie 5m/1h) i agregacji (HDR/TDigest).

• „SLO _ availability _ month = (uptime - permissible _ exceptions )/total _ time”

• "SLA _ miesiąc = 99. 90% czasu uptime przez okno UTC, z wyłączeniem planowanych okien (T-48 powiadomienie), udowodnionych wypadków u operatorów tranzytowych (dokumenty) ".

7) Jakość danych: kontrole i wpisy

• Молнота (kompletność): 'received _ events/ expected_events ≥ 0. 99`.
• Aktualność: opóźnienie obciążenia ≤ N minut.
• Wyjątkowość: bez duplikatów kluczy (idempotence-key).
• spójność-Kwoty/waluta/znaki.
• Liniowość - liczniki nie są „cofnięte”.

ALERT MetricsIngestionLagHigh
IF dwh_ingest_lag_minutes > 15 FOR 10m

ALERT EventsCompletenessDrop
IF (events_received / events_expected) < 0. 99 FOR 15m

ALERT DuplicateEventsSpike
IF rate(events_duplicates_total[10m]) > baseline_7d 2

8) Audyt SLA/OLA: metodologia

1. Zbierz kalendarz wyjątków: planowane okna, uzgodniona degradacja, akty sprzedawców.
2. Obliczanie czasu uptime: według jednej strefy czasowej, w oparciu o SSOT.
3. Pojednanie z incydentami: linia czasu, bilety, pośmiertne.
4. Przypisanie: własne awarie, dostawca, tranzyt, DDoS, rutynowa konserwacja.
5. Obwód SLA: doświadczenie użytkownika (E2E) vs jeden specyficzny interfejs API.
6. Sprawozdawczość: sprawozdanie miesięczne/kwartalne: rzeczywiste, odchylenia, rekompensaty (w stosownych przypadkach), środki naprawcze.

9) Kontrola odtwarzalności obliczeń

Wersioning formuły: repozytorium Git ze specyfikacjami SQL/PromQL/dock.
Badania jednostkowe mierników: na danych syntetycznych (przypadki krawędzi: luki, duplikaty, granice daty).
Rodowód danych: od deski rozdzielczej do tabel źródłowych i zdarzeń.
Migawki: zamrażanie danych dla cutoff tak, że ponowne obliczenia są porównywalne.

10) Pobieranie próbek

Dziennie: 10-20 zdarzeń według kluczowych przepływów (depozyt/stawka/CCL) - ręczna weryfikacja śledzenia.
Co tydzień: 1% próbki do porównania „online vs DWH” w kruszywach.
Co miesiąc: zestaw incydentów z efektem SLA - szczegółowa rekonstrukcja.

Date/Window: 2025-10-01.. 2025-10-07
Metric: SLO_api_p99
Source A: Prometheus (rolling 5m)
Source B: DWH snapshot (1h buckets)
Deviation: + 6. 2% (A above B)
Reason: different aggregation windows
Action: align window in both contours to 5m/rolling
Term/Owner: 2025-11-10/squad-observability

11) Kontrola desek rozdzielczych i wpisów

Jednolity słownik mierników: słownik prawy na desce rozdzielczej.
Adnotacje uwolnień/zdarzeń: aby zobaczyć przyczynę odchyleń.
Porównanie przed/po wydaniu: automatyczne panele regresji.
Duplikaty/rozbieżności: identyfikacja "dwóch różnych p99s' - edycja wzorów/okien.
Dostępność panelu: prawa, rezerwa, łącze/kontrola wersji.

12) Zarządzanie zmianą metryczną

Proces RFC - zmiana formuły/okna/źródła - poprzez RFC z oceną oddziaływania SLA/sprawozdawczości

Migracja „expand → migrate → contract”: tymczasowo zachować obie wersje, porównać, a następnie wyłączyć starą.
Komunikaty: z wyprzedzeniem powiadom produkt/firmę o zmianach wartości „zgodnie z nową metodą”.

13) Szczegóły iGaming/fintech

Piki popytu: mierniki muszą wytrzymać ładunki wybuchowe (agregacje nie „przyklejają się”).
Dostawcy: SLA zależy od sprzedawców OLA → przechowywać swoje raporty, statusy incydentów i kwoty.
Koszt: „cost _ per _ 1k _ calls” i „cost of success” to panele obowiązkowe.
Antyfraud/ryzyko: wrażliwość na opóźnienia i „fałszywe pozytywy” metryki.

14) Deski kontrolne (minimalny zestaw)

Metrics Health: kompletność/terminowość/duplicates, ingest-lag, обимка ETL.
Dowody SLO/SLA: obliczone SLO, rzeczywiste SLA, wyjątki, odniesienia do incydentów/aktów.
Online vs DWH Porównaj: Wskaźnik p95/p99/Success, odchylenia i trendy.
Sprzedawca SLA: czas uptime/kwoty/terminy/koszty w podziale na dostawców.
Release Impact: regresja mierników po obliczeniach/uwzględnieniu funkcji.

15) Lista kontrolna (operacyjna)

• Katalog mierników/SLO/SLA z właścicielami i formułami jest aktualny.
• SSOT jest zdefiniowany dla każdego raportu/panelu.
• Badania jednostkowe wzorów są zielone, rurociągi obliczeniowe są udokumentowane.
• Wpisy dotyczące jakości danych są aktywne (kompletność/linia czasowa/duplikaty).
• Rozbieżność „online vs DWH” ≤ dopuszczalny próg (np. ≤ 2%).
• Uzgodnione wyjątki SLA są udokumentowane i załączone do sprawozdania.
• Pobrano próbki kontrolne i sporządzono świadectwa.
• Wszystkie zmiany wzoru przeszły RFC i migrację.

16) Przykłady (fragmenty)

api_p99_ms:release:ratio =
(api_latency_p99_ms{release="after"} / api_latency_p99_ms{release="before"})

sql
SELECT event_date,
COUNT() AS received,
SUM(expected_count) AS expected,
COUNT()::decimal / NULLIF(SUM(expected_count),0) AS completeness
FROM events
JOIN expected_events USING (event_date, event_type)
WHERE event_type IN ('deposit','bet_placed','kyc_completed')
AND event_date BETWEEN:from AND:to
GROUP BY 1;

ALERT DwhVsOnlineDrift
IF abs(dwh_kpis{metric="api_p99"} - online_kpis{metric="api_p99"}) > 0. 02 online_kpis
FOR 30m
LABELS {severity="warning", team="observability"}

17) Anty-wzory

Dwie różne „te same” formuły metryczne na różnych panelach.
Zmiana metryki bez migracji i powiadomienia - „skoki” w OKR/SLA.
Raporty w lokalnym programie Excel jako „true” (niemożliwe do odtworzenia).
Mieszanie stref czasowych i kalendarzy w obliczeniach SLA.
Wyjątki SLA nie są udokumentowane.
Nie ma wpisów dotyczących jakości pomiarów.

18) Okres zapadalności pomiaru KPI

Szybkość dryfowania w InternecieDWH (cel ≤ 2%).
Metrics Health Uptime.
Formuła Time-to-Fix.
Wskaźnik sporów SLA.
Zasięg SLO/SLA (odsetek ścieżek krytycznych z formalnie opisanym SLO/SLA).

19) Role i obowiązki

Właściciel metryki/usługi: formuła, źródło, deska rozdzielcza, wpisy.
Obserwowalność/SRE: SSOT/platforma, testy formuły, alerty jakości danych.
Dane/BI: DWH, odtwarzalność raportów, rodowód.
Prawnicy/menedżerowie partnerzy: umowy SLA i wyjątki.
Kierownik incydentu: Przypisanie i powiązanie incydentów SLA.

20) Szybki start (30 dni)

Tydzień 1: Wskaźniki inwentaryzacji/SLO/SLA i właściciele; przypisać SSOT.
Tydzień 2: Zawiera alerty jakości danych i panel „Online vs DWH”.
Tydzień 3: przeprowadzić próbki kontrolne, wyrównać okno p95/p99.
Tydzień 4: sformalizować proces RFC dla formuł, przygotować miesięczny raport SLA z załącznikami.

21) FAQ

P: Co to jest SSOT dla SLA?
A: Przechowywanie z powtarzalnymi obliczeniami (DWH) i pełną linią; panele internetowe - do kontroli operacyjnej, a nie do czynności prawnych.

P: Jak radzić sobie z "dwoma p99s'?
Odp.: Naprawić metodę okna/agregacji w katalogu mierników, migrować panele, dodać alert do dryfu.

P: Jak rozważyć planowane prace?
Odp.: Zachować kalendarz wyjątków i automatycznie odliczyć je od SLA zgodnie z zasadami umowy; przechowywać artefakty potwierdzające.