Operacje i → Zapobieganie incydentom

Zapobieganie incydentom

1) Dlaczego go potrzebujesz

Najlepszą reakcją na incydent jest nie posiadanie jednego. W przypadku iGaming/fintech, każda minuta przestoju traci zakłady/depozyty, grzywny od dostawców, ryzyko reputacyjne. Zapobieganie systemowe zmniejsza wskaźnik awarii zmiany, stabilizuje SLO i uwalnia czas dowodzenia, aby rozwijać, a nie gasić pożary.

• Zminimalizuj prawdopodobieństwo wystąpienia incydentów na ścieżkach krytycznych (depozyt, zakład, uruchomienie gry, wycofanie).
• Przechwycić degradację przed uderzeniem w SLO i portfel.
• Ograniczyć promień awarii (promień wybuchu) i przyspieszyć odzyskiwanie.

2) Podstawowe zasady zapobiegania

1. Pierwszy budżet SLO i błąd: Zmiany nie są uwalniane, jeśli ryzykują zniszczenie SLO i spalenie budżetu.
2. Defense in depth: warstwy ochrony - od schematów i konfiguracji danych do zasad sieciowych i phicheflags.
3. Projekt awarii: wyłączniki, timeouts, rekolekcje jitter, idempotencja, degradacja.
4. Małe i odwracalne zmiany: małe przyrosty + szybki zwrot (flagi funkcji/kanarka).
5. Obserwowalność według projektu: mierniki/kłody/ślady dla każdego krytycznego etapu i połączenia.

3) Mapa ryzyka i ścieżki krytycznej

Zrób „mapę bólu” według domen: Płatności, Zakłady, Gry, KYC, Promocje, Jackpoty, Zawartość.

• Wskaźniki biznesowe (konwersja, GGR, średnia kontrola).
• Techniczne SLO (latency p95/p99, uptime, success rate).
• Zależności (wewnętrzne/zewnętrzne), limity/kwoty.
• Zachowanie w trybie bezpiecznym (które wyłączamy/upraszczamy).
• Właściciel książki startowej.

4) Bariery ochronne (bariery ochronne)

Timeouts i breakers: usługa wywoływania ma czas krótszy niż suma wewnętrznych; wyłącznik otwiera się po zwiększeniu błędów/opóźnień.
Izolacja grodziowa: oddzielne baseny połączeń/pracowników dla podrzędnych strumieni.
Ograniczenie i ciśnienie wsteczne: ochrona przed lawinami i burzami retray.
Ficheflagi degradacji: „tryb minimalny” - łatwe odpowiedzi, repliki pamięci podręcznej, wyłączanie ciężkich funkcji.
Wielokrotny sprzedawca i feilover: alternatywny PSP/KYC, przełączanie trasy.
Walidacja konfiguracji: schematy/linery/zasady bezpiecznej zmiany funkcji i limitów.

5) Zarządzanie zmianami

Bramy przed zwolnieniem: testy, bezpieczeństwo, CDC (umowy konsumenckie), kompatybilność systemu.
Wydanie kanaryjskie + autogatuje: 1% → 10% → 100%; auto-stop na p99/poziom błędu/wzrost budżetu spalania.
Flagi funkcji: natychmiastowe zachowanie rolki/przełącznika bez wdrożenia.
Zwolnij kalendarz: unikaj szczytowych okien sportowych/turniejowych i konserwacji u dostawców.
Kontrole po wdrożeniu: automatyczna synchronizacja, porównanie metryk przed/po z progami.

6) Badanie jako środek zapobiegawczy

Jednostka/umowa/integracja: OpenAPI/Umowy AsyncAPI, CDC vs. Dostawca/moka.
Obciążenie & stres: profile ruchu na czas początkowy; testy na podłączenie/IOPS/limity kwot.
Moczenie/długotrwałe: wycieki zasobów, rosnące opóźnienia na horyzoncie godzina/dzień.
Chaos/gra-days: Broker/PSP/KYC drop, luka regionalna, „powolny dostawca”.
Ćwiczenia odzyskiwania katastrof: regularne szkolenia w zakresie zmiany regionów i przywracania baz danych.

7) Wczesne wykrycie degradacji

Alerty pojemności: zagłówek, opóźnienia w kolejce, połączenia z bazą danych, eksmisja w pamięci podręcznej.
Prędkość spalania SLO: sygnał w niebezpiecznym tempie „spalania” budżetu.
Progi adaptacyjne: sezonowość/wzory dzienne w celu zmniejszenia fałszywości.

Alerty kompozytowe: "lag" + HPA przy maksymalnym + otwartym obwodzie "

Zdrowie dostawcy: kwoty/terminy/błędy dla każdego dostawcy + koszt połączeń.

8) Współpraca z zewnętrznymi dostawcami

OLA/SLA i SLO: powiązanie porozumień z naszymi celami.
Playbooks feilover: PSP-X ⇆ PSP-Y trasy, token cache, grace deposit tryby.
Piaskownice i kontrakty: Przepływ testów przed każdą dużą zmianą.
Okna dostawcy: adnotacje na deskach rozdzielczych i automatyczne zasady tłumienia.

9) Dane, konfiguracje i tajemnice

Polityka zmian: przegląd kodu dwóch par oczu, walidacja programów/JSON/YAML.
Sekrety: KMS/Secrets Manager, rotacja, separacja przez środowisko/rola.
Flagi/limity: zmiana za pomocą interfejsu API z audytem i natychmiastowym zwrotem.
Migracje: „two-step” (rozszerzyć → migrate → contract), całkowita kompatybilność wsteczna.

10) Szkolenie i gotowość zespołu

Szkolenie dyżurne: symulacje incydentów, obowiązki w cieniu, scentralizowana książka startowa i.
Jednolite formaty komunikacji: szablony statusu/przekazania/incydentu-aktualizacji.
Bezpieczna kultura: postmortem bez winy, powodów mechanistycznych i działań zapobiegawczych.

11) Deski rozdzielcze zapobiegawcze (minimum)

Ryzyko i gotowość: SLO/budget, headroom by layer, „top vulnerable connections”.
Zmiana bezpieczeństwa: procent kanarów, kopnięć, wpisów „po zwolnieniu”, CTR autogatów.
Panel dostawcy: p95/błąd/kwoty/koszt dla każdego dostawcy, czas odpowiedzi wsparcia dostawcy.
Chaos/DR Gotowość: częstotliwość ćwiczeń, czas zmiany regionu, sukces odzyskiwania.
Config/SecOp: flaga/limit/tajne zmiany, anomalie.

12) Przykłady wpisów zapobiegawczych

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13) Lista kontrolna profilaktyki (dziennie/przed szczytami)

• Aktualny kalendarz szczytowy (mecze, turnieje, kampanie, okna dostawców).
• Headroom by API/DB/cache/kolejki, HPA/VPA gotowość, cache rozgrzewka.
• Stan dostawców (kwoty, limity, degradacja w ciągu 24 godzin), konfiguracja feilera.
• Bramy kanaryjskie są włączone, flagi funkcji rollback są dostępne dla właścicieli.
• Wpisy SLO/Capacity są aktywne, tłumienie jest przepisywane do planowanych prac.
• Runbook "i zaktualizowane, potwierdzone dyżurem, działające kanały eskalacji.

14) Anty-wzory (czego unikać)

„Big Night Releases” bez kanarka lub flagi.
Wspólne baseny blokujące głowę linii.
Przekłady na operacje nieidempotentne i na timeouts wąskich gardeł.
Brak histerezy w wpisach → piła wzdłuż progu.
Ślepa wiara w sprzedawcę SDK bez obserwacji i zarządzania czasem.
"Zróbmy Prod' bez sceny/piaskownicy i CDC.

15) Zapobieganie KPI

Zmień wskaźnik awarii (cel ≤ 10-15% lub cel).
Wskaźnik wykrywania zdarzeń poprzedzających zdarzenie: odsetek incydentów odwróconych na etapie degradacji.
Średni czas między incydentami (MTBI) МTTR.
Ochrona zasięgu:% ścieżek krytycznych z flagami/wyłącznikami/timeouts/canary.
Chaos/DR kadencja: Częstotliwość i sukces ćwiczeń.
Gotowość dostawcy: średni czas przełączania na dostawcę kopii zapasowych.

16) Szybki start (30 dni)

Tydzień 1: mapa ścieżki krytycznej, SLO i właściciele; zawierać wpisy SLO-spalić i alerty pojemności.
Tydzień 2: Bramy Kanaryjskie + Phicheflags; podstawowe skrypty chaosu (dostawca/kolejka).
Tydzień 3: deski rozdzielcze „Zmień bezpieczeństwo” i „Panel sprzedawcy”, playbooks feilover.
Tydzień 4: ćwiczenia DR (częściowe), plan retrospektywny i utwardzający na kwartał.

17) Szablony (fragmenty)

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

P: Co wdrożyć najpierw, jeśli zasoby są ograniczone?
Odp.: Wpisy SLO-spalić na ścieżkach krytycznych, bramy kanaryjskie i phicheflags rollback; następnie - mapa ryzyka i dostawca fałszywe.

P: Skąd wiesz, że zapobieganie „działa”?
Odp.: Wskaźnik awarii zmian spada, odsetek zapobieganych incydentów wzrasta, MTTR i hałas alarmowy spada, liczba stron „nocnych” spada.

P: Czy potrzebujemy regularnych ćwiczeń chaosu?
Odp.: Tak. Bez szkolenia, feuillower i DR są prawie zawsze dłuższe i bardziej bolesne niż wydają się na papierze.