Opóźnienie i utrata PSP-X

(Sekcja: Technologia i infrastruktura)

Krótkie podsumowanie

Chaos Engineering to naukowa metoda produkcji: formułujesz hipotezę stabilności, zakłócasz środowisko w sposób kontrolowany i udowadniasz, że wartość użytkownika (SLO/metryki biznesowe) jest zachowana. W przypadku iGaming są to kontrole płatności (PSP), inicjalizacja gry, kolejki ołowiu, wielowymiarowe i szczytowe obciążenia - w warunkach opóźnień, awarii i „burzy” retras - zanim stanie się to z żywymi użytkownikami.

1) Zasady inżynierii chaosu

1. Stan stacjonarny do hipotezy. Określ kurs: Dostępność, p95/p99, TTW, konwersja płatności.
2. Mały promień wybuchu. Eksperyment pierwszy w postoju/kanarka, 1-5% ruch/1-2 poda/jeden region.
3. Najpierw obserwowalność. Mierniki/kłody/ścieżki + adnotacje eksperymentalne.
4. Poręcze ochronne - abort. Ciężkie progi SLO/business KPI do automatycznego wyłączenia.
5. Powtarzalność i automatyzacja. Eksperymenty jako kod (IaC/GitOps), plan dnia gry.
6. Nienaganna kultura. Eksperyment nie jest poszukiwaniem winy, ale poszukiwaniem słabości.

2) Wskaźniki stanu stacjonarnego i sukcesu

TexSLI: API p95/p99, wskaźnik błędów, nasycenie (CPU/IO), opóźnienie kolejki (wypłaty/depozyty), dostawcy opóźnień.
Business SLI: konwersja 'próba → sukces', TTW p95, sukces 'gra init', udział awarii PSP kodem.

3) Klasy eksperymentów (co „break”)

Sieć: opóźnienie/jitter/utrata pakietu/blackhole, awarie DNS, anomalie MTU.
Рескрса: przepustnica CPU, ciśnienie pamięci/OOM, IOPS dysku/przestrzeń, wyczerpanie pliku-deskryptora.
Procesy i miejsca: zabijanie/eksmisja strąków, awaria węzłów, awaria strefy/regionu.
Zależności: timeouts/errors PSP, niedostępny dostawca gier, degradacja CDN/pamięci podręcznej.
Kolejki/streaming: Kafka opóźnienie wzrostu, pauza konsumencka, party/lider luka.
Data/DB: opóźnienia replikacji, degradacja indeksu, tryb tylko do odczytu.
Zwolnienia/ficheflags: migracja brakuje, błędne konfiguracje, kill-switch.
Front/RUM: kropla LCP/INP, awarie klienta na szczycie.
Dane/ML: cechy starzenia, wzrastający model opóźnienia, spadające żetony/s, degradacja jakości.

4) Proces: od hipotezy do poprawy

1. Sformułować hipotezę (określone SLO/business KPI + oczekiwane zachowanie ochrony).
2. Zaprojektuj eksperyment: rodzaj awarii, czas trwania, promień wybuchu, szyny ochronne/przerwanie.
3. Przygotuj obserwowalność: zwolnienie/eksperyment porównaj deski rozdzielcze, adnotacje.
4. Uruchom pod kontrolą IM/TL, powiadom dyżur/firmę (jeśli dotyczy).
5. Wynik pomiaru: SLO, p95/p99, TTW, konwersja, opóźnienia, przekładki.
6. Utwórz elementy akcji: limity, timeouts, retrains with jitter, outlier-ejection, PDB/HPA/KEDA, pullback flow.
7. Automatyzuj (włączaj do pakietu gry-day reg/CI kontroli infrastruktury).

5) Bariery ochronne i kryteria zatrzymania

• Aktywowane szybkie spalanie SLO (np. 14 × budżet na godzinę),
• Twoja konwersja płatności jest większa niż 0. 3 pkt.,
• TTW p95> 3 min z rzędu 10-15 min,
• szybkość błędów> 1. 5% i rośnie w dwóch oknach.
• Komunikacja: wstępnie zatwierdzony szablon kanału/statusu, „czerwony przycisk” w ChatOps ('/experiment abort ').

6) Przykłady eksperymentalne (kubernety/chmura)

6. 1 Opóźnienia sieci do PSP (depresja kanaryjska)

Cel: sprawdzić przekaźniki/timeouts/routing.
Wtrysk: + 200ms RTT i 3% utrata pakietu dla 'payments-api' → 'pspX'.

yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius

Oczekiwane: p95 '/depozyt' <250 ms, wskaźnik błędów <1%, konwersja ≥ wartość wyjściowa − 0. 3 pp; w przypadku awarii, automatyczne przełączanie trasy PSP.

6. 2 Awaria węzła i PDB

Cel: Sprawdź PDB/anty-powinowactwo/HPA.
Wtrysk: spuścić/zakończyć jeden węzeł za pomocą strąków 'games-api'.

Czekanie: brak utraty dostępności, szczyt p99 nie wykracza poza SLO, autoskaler dostaje wskazówki, PDB zapobiega „podwójnej whammy”.

6. 3 Kafka lag КАНА

Cel: stabilne wypłacanie środków przy gromadzeniu wiadomości.
Wstrzyknięcie: Zamrozić konsumentów przez 5-10 minut, a następnie włączyć.

Oczekiwanie: KEDA skaluje pracowników, TTW p95 pozostaje ≤ 3 min po resorpcji, bez duplikatów (idempotencja, klucze).

6. 4 dostawca gier usterka DNS

Przeznaczenie: awaryjne/buforowanie/przekładki.
Wtrysk: NXDOMAIN/timeout dla domeny 'providerA. przykład ".

Oczekiwanie: szybki folback na ' B', w interfejsie użytkownika - tryb degradacji i baner statusu; „sukces w grze init” ≥ 99. 5%.

6. 5 Tylko do odczytu DB

Cel: Zapisz zachowanie utraty.
Wtrysk: Przełącznik do odczytu tylko przez 10-15 min.

Czekanie: błędy procesów kodowych, trasy krytyczne są ograniczone, kolejki wstrzymują żądania, nie ma strat/podwójnych odpisów.

7) Automatyzacja i gitopy

Eksperymenty jako kod: skryptów/parametrów/barier w Git, przegląd przez PR.
Plan dnia gry: harmonogram, właściciele, mierniki, warunki przerwania, lista kontrolna komunikacji.
Adnotacje w Grafanie: początek/koniec eksperymentu, konfiguracja, końcowe SLO.

8) Obserwowalność podczas chaosu

Przykłady: od p95/p99 do określonego "trace _ id'.
Лова: бола 'experiment _ id',' fault _ type ',' retry _ attempt ',' degrade _ mode = true '.
Ślady: zewnętrzne połączenia są oznaczone "usterką. wstrzyknięte = true ', retras/timeouts są widoczne.
Deski rozdzielcze: „SLO-card”, wydanie/porównanie eksperymentów, Płatności/Gra init/Kolejki.

9) Szczegóły iGaming: co najpierw sprawdzić

1. Płatności i TTW: PSP timeouts, route folback, idempotence.
2. Inicjalizacja gier: niedostępność/wolność studiów, awarie CDN.
3. Kolejki ołowiu/bonusu: opóźnienie wzrostu, ponowne przetwarzanie.
4. Multi-region: awaria strefy/POP, zmiana lidera, replikacja bazy danych.
5. Szczyty: automatyczna skala, ograniczenie prędkości, wyłącznik, bufory rozgrzewające.
6. RG/Zgodność: prawidłowe rejestrowanie w przypadku awarii, brak PII w telemetrii.

10) Zarządzanie

Kalendarz i okna: eksperymenty poza turniejami szczytowymi, koordynacja z biznesem.
Рола: Experiment Lead, Observer (SRE), Business Rep; IM w infolinii.
Polityka w zakresie danych: brak PII w artefakcie; Sklepy WORM do audytu.
Granice prawne: Wykluczyć scenariusze, które naruszają SLA bez porozumienia.

11) Gra-day: szablon skryptu

12) Typowe znaleziska i działania

Zbyt agresywne retreaty → żądania burzy → dodać czasy/jitters/limity.
Brak wyrzutu zewnętrznego → trucizna instancja psuje p99 → umożliwienie uboju.
Delikatne migracje → tylko do odczytu łamie przepływ → rozszerzyć → migrate → kontrakt + phicheflags.
Niewłaściwy sygnał HPA → skala późno → przełączyć na metryki RPS/lag.
Pamięć podręczna wspólna dla wersji → rollbacks psuje dane → klucze wersji.

13) Chaos praktyka listy kontrolnej dojrzałości

1. Stan stacjonarny i SLO są opisane, deski rozdzielcze są gotowe.
2. Eksperymenty jako kod, przegląd/audyt w Git.
3. Guardrails/abort zautomatyzowane (Alertmanager/ChatOps).
4. Obserwowalność: przykłady, korelacja śladu/dziennika, adnotacje.
5. Kwartalny dzień gry, scenariusze obejmują płatności/gry/kolejki/wielobranżowe.
6. Pozycje działań po eksperymencie są częścią planu sprintu; monitorowanie wydajności.
7. Zasady retray/timeout/circuit-breaker w config repo.
8. Egzekwowane polityki bezpieczeństwa/PII, artefakty bez danych wrażliwych.
9. Automatyczne remediowanie przez SLO (rollback/scale/redoute) testowany chaos.
10. Wskaźniki procesu:% zakończone bez przerwy, MTTR na ćwiczenia, zmniejszenie incydentu klasy.

14) Anty-wzory

"Breaking everything in the prod' bez SLO/guardrails/observability.
Eksperymenty bez hipotez i wymiernych celów.
Duży promień wybuchu podczas pierwszego startu.
Przekłady bez czasu/jitter → kaskadowa tolerancja błędów.
Chaos zamiast zapobiegania: leczyć objawy, ignorować przyczyny korzenia.
Brak pozycji RCA/działania po ćwiczeniach.
Eksperymenty w godzinach szczytu bez akceptacji biznesowej.

Podsumowanie

Inżynieria chaosu jest metodycznym dowodem odporności: z wyprzedzeniem odtwarzasz prawdziwe awarie, mierzysz wpływ na SLO i metryki biznesowe oraz wzmacniasz architekturę - od przekaźników i wyłączników po wielowymiarową orkiestrę i automatyczną remediację. Dzięki regularnej dyscyplinie gry i poręczy, platforma iGaming zachowuje p95/p99, konwersję i TTW nawet w najgorętszych okresach.