Bieg torrent

Kasyno 24/7 i praktyki dyżurów

1) Cele operacji 24/7

Business SLO: login ≥ 99. 9%, depozyt ≥ 99. 85%, wskaźnik/rozrachunek ≥ 99. 9%, p95 WS RTT ≤ 120 ms.

Cele incydentu: MTTD ≤ 1 min (syntetyczne), MTTR ≤ 15-30 min dla przepływów pieniężnych.

Jakość wsparcia: <3% biletów odbywa się drugiego dnia bez odpowiedzi, CSAT wsparcia ≥ 90%.

2) Organizacja dyżurów: modele i harmonogramy

Modele

Follow-the-sun: 3 geo-zespoły (Europe/Americas/APAC), minimalne obciążenie nocne.

Rotacja nocna w regionie: tydzień nocnych zmian na osobę raz na N tygodnie (odszkodowanie/czas wolny).

Na bazie komórki: cło według ogniw produktowych (marki/rynki) + ogółem L1.

Role w zmianie

L1 Dyżur (domyślnie komandor incydentu) - akceptuje alert, współrzędne, utrzymuje kontakt z obsługą.

Inżynierowie domeny L2 - płatności, gra-gateway/WS, baza danych/portfel, platforma SRE.

Oficer komunikacji - strona statusu, partnerzy/dostawcy, aktualizacje wewnętrzne.

Menedżer obowiązków - eskalacja biznesu, ustalanie priorytetów, wyjątki (VIP/regulator).

Szablon zmiany (12 × 7 lub 8 × 5 + zmiany)

Zmiana: 8/10/12 godzin. Zmiana zmiany 15-30 min „ciepłe przekazanie”.

Postępuj zgodnie z zasadą 2 kolejnych nocy maksymalnie i nie więcej niż 7 dyżurów w 14-dniowym oknie.

Każda zmiana ma Roster: duty, reserve, call manager, contact L2.

3) Klasyfikacja incydentów i SLA

SEV	Przykład	Wpływ	Reakcje SLA	Rozwiązania SLA
SEV-1	Ogromna awaria depozytu, logowanie niedostępne	Utrata dochodów/ryzyko regulacyjne	≤ 5 min	≤ 30 min do stabilizacji
SEV-2	Duże opóźnienie zakładów, opóźnienie dostawcy gier	Zmniejszona konwersja	≤ 10 min	≤ 2 h
SEV-3	Częściowa awaria promo/raportów	Ograniczony wpływ	≤ 30 min	≤ 8 h
SEV-4	Drobne błędy/wpisy jakościowe	Brak natychmiastowego wpływu	Zgodnie z planem	Zgodnie z planem

4) Ostrzeganie bez hałasu

Zasady: objawowe wpisy SLO → źródło przyczynowe → kontekst.

Сибтота: 'login _ success _ ratio', 'deposit _ success _ by _ psp ",' ws _ rtt _ p95 ',' game _ launch _ success '.

Мривина: 'db _ conn _ saturate, "' queue _ lag ا', 'psp _ timeout ا',' provider _ launch _ latency α '.

Ochrona przed hałasem: wymagane naruszenia sekwencyjne ≥ 3, automatyczne podtrzymywanie przy zwolnieniu, deduplikowanie i grupowanie.

Zestaw obowiązków: krytyczny - PagerDuty/Opsgenie; Reszta to Slack/mail.

Tekst alarmowy: "Co/Gdzie/Ile/Działanie. "Przykład:

💡 SEV-2: sukces depozytu DE/PSP-A 97. 1% <99% 10m. Wpływ: UE. Prawdopodobna przyczyna: PSP timeout Książka startowa: „PD-42”.

5) Runbook'i eskalacje

Runbook Mini szablon

1. Wykrywanie: linki do desek rozdzielczych (SLO, przyczynowy), ślad, dzienniki.

2. Szybkie kontrole: zdrowie PSP/dostawców, DR-region syntetyki, DB/cache status.

3. Środki tymczasowe: funkcje-flagi/kill-switch, limity stawek, przełączanie PSP/dostawca, degradacja ciężkich funkcji.

4. Eskalacja: kto L2/L3, kontakt 24 × 7 dostawca.

5. Kryteria strefy zielonej: SLO normalne N minuty, kolejki

6. Komunikaty: szablon stanu, rynki/marki, ETA/następna aktualizacja.

Drabina schodów ruchomych

T0-5 min: L1 akceptuje, przypisuje IC, uruchamia książkę startową.

T5-10 min: nazywamy profil L2 + oficer łączności.

T10-15 min: Menedżer obowiązków/produkt, w razie potrzeby legalny/zgodny.

Zewnętrzny: dostawca PSP/gier - zgodnie z przepisami (kanał SLA, bilet, połączenie).

6) Komunikacja i strona statusu

Wewnętrzne aktualizacje co 10-15 minut dla SEV-1/2 (# war-room channel, szablon wiadomości).

Strona statusu: aktualny status, rynki dotknięte, środki tymczasowe, następna aktualizacja w X min.

Uwaga po incydencie dla wsparcia/podmiotów powiązanych/partnerów: co się stało, jak zrekompensować.

Szablony z góry: krótkie, bez „wewnętrznej kuchni”, bez poczucia winy.

7) Praca z zewnętrznymi zależnościami (PSP/gry/CDN)

Katalog kontaktowy 24 × 7: PSP A/B, dostawcy gier, CDN/WAF, chmura.

Monitorowanie SLA: syntetyka na depozytach/uruchamianiu gier, automatyczne wyzwalacze biletów.

Zasady pracy awaryjnej: trasa do PSP-B na 'sukces <99% 10 min', zmiana dostawcy gier na 'TTFS> 800ms'.

Skrzynka odbiorcza: podpis HMAC, idempotencja, ponowne odtwarzanie z kolejki po degradacji dostawcy.

8) GameDay i treningi

Tygodniowe ćwiczenia na tablopie (30-45 minut): czytanie wykresów, podejmowanie decyzji.

Miesięczne napędy techniczne DR (60-90 min): awaria PSP, opóźnienie dostawcy, kropla bazy danych WS/klastra.

Ćwiczenia KPI: czas rozpoznać przyczynę, jakość komunikacji, poprawność decyzji na phicheflags.

9) Przekazanie i dokumentacja

Lista kontrolna ciepłego przekazania (15-20 min):

Obecne zagrożenia (wzrost opóźnień, limity PSP, uwolnienia na gorąco).
Puste bilety/eskalacje.
Tymczasowe phicheflags/limity i kiedy wycofać.
Podsumowanie incydentów związanych z przesunięciem (SEV/czas/działania/ryzyko rezydualne).
Dokumentacja: baza danych na żywo zakładek, kontakty, schematy, „karta przepływu” pieniądze/gry.

10) Opieka zdrowotna i zrównoważony rozwój

Artykuł 8/8/8: praca/sen/osobisty. Nocne zmiany → wolne.

System kumpli dla początkujących, obowiązek cienia 2-3 tygodnie.

Bezpieczeństwo psychologiczne: „nienaganny” retro, wsparcie dla poważnych incydentów.

Audyt obciążenia: ≤ 2 „przebudzenia” na noc średnio na inżyniera - cel; powyżej → recykling wpisu/architektury.

11) Wskaźniki wydajności operacyjnej

MTTD/MTTR według domeny (login/deposit/WS/games).

Jakość alarmu:% hałaśliwy/zamknięty brak działania, średnia liczba wpisów/przesunięcie.

Wskaźnik awarii zmiany:% incydentów spowodowanych zwolnieniami; średni czas pomiędzy porażkami.

Toil: udział powtarzalnych zadań ręcznych → plan automatyzacji.

Wpływ dostawcy: udział SEV-2/1 ze względu na partnerów zewnętrznych (argument za SLA/migracją).

12) Narzędzia i panele „obsługującego”

„Czerwona” deska rozdzielcza SLO: login/deposit/bets/launch games, 5xx/429, p95, regions.

Panele przyczynowe: DB/kolejki/pamięć podręczna, PSP/dostawcy, CDN/WAF.

Dyspozytor dyżurny: aktywne incydenty, timery aktualizacji, linki do runbooka i phicheflags.

Timeline - kto co zrobił, kiedy, w odniesieniu do SLO.

13) Typowe scenariusze i szybkie poprawki

A. Depozyty spadają w DE w PSP-A

Działania: Marshrut kanaryjski → PSP-B 50%; podnieść czas korzystania z haków webowych; Dodaj JS Challenge w WAF z botów.

Komunikaty: „Degradacja depozytów DE za pośrednictwem PSP-A” strona stanu.

Wyjście: sukces ≥ 99% 15 min, kolejka retray

B. Wzrost p95 WS w grach APAC na żywo

Działania: zwiększyć repliki bram WS, włączyć ciepłą pulę węzłów; komunikaty o limitach emisji; Dostawca - bilet RTT.

Wyjście: p95 WS RTT ≤ 120 ms 20 min.

C. Dostawca gier Lag (TTFS> 1. 2 s)

Działania: przełączyć lobby na alternatywne stoły/studia, włączyć pamięć podręczną metadanych; aktualizacja statusu.

Wyjście: TTFS <800 ms, reklamacje.

14) Lista kontrolna gotowości 24/7

Obroty i zmiany są zatwierdzane, „drugi numer” na każdej zmianie.
Wpisy SLO + przyczyny, anty-hałas, jednolite wzory wiadomości.
Pełna książka startowa i z „szybkimi dźwigniami” (phicheflags, PSP/dostawcy, limity).
Kontakty 24 × 7 partnerów zewnętrznych, wywołać test raz na kwartał.
Strona stanu i zewnętrzne szablony aktualizacji.
GameDay/DR ćwiczenia na harmonogramie, retrospektywy bez oskarżeń.
Narzędzia dyżurne: deski rozdzielcze, linia czasu, dziennik rozwiązań.
Polityka kompensacyjna/czasowa, limit przebudzenia w nocy, wsparcie zdrowotne.
Proces powypadkowy: RCA w 48 godzin, zadania naprawcze z właścicielami i terminy.

15) Wzór pośmiertny (nienaganny)

1. Krótko mówiąc: co się stało kiedy, co SEV, wpływ i zakres.

2. Linia czasu: wykrywanie → eskalacja → działanie → stabilizacja.

3. Przyczyny: te/procesy/ludzie/dostawcy (5 Dlaczego).

4. Co zadziałało/co nie działało: wpisy, ranbooki, komunikacja.

5. Pozycje działania: techniczne, procesowe, partnerskie - odpowiedzialne i terminy.

6. Zapobieganie: testy/monitoring/wiertła, SLO/zmiany alarmowe.

Wznów streszczenie

Udane operacje kasyna 24/7 to dyscyplina SLO, odpowiednio zaprojektowana alarmująca bez hałasu, wyraźne książki startowe i eskalacje, regularne ćwiczenia i szacunek dla dyżurów. Powiązaj panele SLO z szybkimi dźwigniami (phicheflags, przełączanie PSP/dostawca, degradacja ciężkich funkcji), utrzymuj komunikację z graczami i partnerami, mierz wydajność (jakość MTTD/MTTR/alert) - a Twoja platforma będzie stabilna przez całą dobę, a zespół - wydajna i stabilna.