Alarmowanie i reagowanie na awarie
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
Silne ostrzeganie jest sygnałem naruszenia wartości użytkownika, a nie tylko "czerwoną metryką. "Dla iGaming, bramki SLO (opóźnienie, dostępność, konwersja płatności, Time-to-Wallet), zasady multi-burn, jasne dyżury, eskalacja, ChatOps i ról runbooks są ważne. Celem jest, aby szybko zobaczyć odchylenie, poinformować tych, którzy mogą skorygować i naprawić wiedzę, aby zareagować jeszcze szybciej i taniej następnym razem.
1) Podstawy: Od metryki do działania
SLI → SLO → Alert - mierzona jakość → poziom docelowy → „budżet jest na” warunek.
Nasilenie (SEV): SEV1 - krytyczne (dochody/GGR zagrożone), SEV2 - poważne, SEV3 - umiarkowane, SEV4 - niewielkie.
Wpływ/Pilny charakter: kto cierpi (wszystko/region/najemca/kanał) i jak pilne (TTW, p99, błąd - wskaźnik na).
Możliwość działania: dla każdego alarmu - konkretna akcja (runbook + właściciel).
2) Taksonomia sygnału
ТевSLO: p95/p99 latency API, error-rate, saturate (CPU/IO/GPU), queue lag.
• SLO: konwersja płatności (próba → sukces), Time-to-Wallet (TTW), sukces zakładów, uruchomienie gry.
Trasy płatności: mierniki specyficzne dla PSP (skoki czasowe/spadkowe).
Front/mobile: RUM metrics (LCP/INP), crash-rate, scenariusz syntetyczny (login/deposit/rate/output).
3) Polityka ostrzegania: SLO i wskaźnik spalania
Przykłady SLI/SLO
Dostępność płatności-api ≥ 99. 9 %/30d p95 '/depozyt' ≤ 250 ms/30d
Konwersja 'payments _ attempt → success ≥ baseline − 0. 3 %/24h
TTW p95 ≤ 3 min/24h
Multi-Window/Multi-Burn (идей PromQL)
Szybkie oparzenie: naruszenie SLO 5-10 × szybciej niż normalnie (strona alarmowa w 5-15 minut).
Powolne spalanie: powolne wypalanie budżetu (bilet + analiza w ciągu 1-3 godzin).
yaml
API success proxy metric (recording rule in advance)
record: job:http:success_ratio expr:
sum(rate(http_requests_total{status=~"2.. 3.."}[5m]))
/ sum(rate(http_requests_total[5m]))
Fast burn (99. 9% SLO)
alert: PaymentsSLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page", service: "payments-api" }
annotations:
summary: "SLO fast burn (payments-api)"
runbook: "https://runbooks/payments/slo"
Slow burn alert: PaymentsSLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket", service: "payments-api" }4) Redukcja szumów i jakość sygnału
Właściwe źródło prawdy: do zmiany przez agregaty (zasady zapisu), a nie przez ciężkie „surowe” wyrażenia.
Deduplicacja - grupy Alertmanager według „usługi/regionu/dotkliwości”.
Hierarchia: pierwszy alert do biznesu/SLI, poniżej - metryki techniczne jako diagnostyka.
Tłumienie: podczas planowanej konserwacji/uwalniania (adnotacja), podczas incydentów w górnym biegu.
Cardinality: Nie używaj 'user _ id/session _ id' w etykietach alarmowych.
Alerty testowe: uruchamiacze regularnego „treningu” (kanały kontrolne, role, linki runabook).
5) Alertmanager Routing i eskalacja
yaml route:
group_by: [service, region]
group_wait: 30s group_interval: 5m repeat_interval: 2h receiver: sre-slack routes:
- matchers: [ severity="page" ]
receiver: pagerduty-sre continue: true
- matchers: [ service="payments-api" ]
receiver: payments-slack
receivers:
- name: pagerduty-sre pagerduty_configs:
- routing_key: <PD_KEY>
severity: "critical"
- name: sre-slack slack_configs:
- channel: "#alerts-sre"
send_resolved: true title: "{{.CommonLabels. service }} {{.CommonLabels. severity }}"
text: "Runbook: {{.CommonAnnotations. runbook }}"
inhibit_rules:
- source_matchers: [ severity="page" ]
target_matchers: [ severity="ticket" ]
equal: [ "service" ]Idea: SEV = strona → PagerDuty/SMS; Reszta to Slack/bilet. Hamowanie hamuje „hype” niższych poziomów z aktywnym SEV powyżej.
6) Grafana Alerting (jako dodatkowa warstwa)
Scentralizowane zasady ostrzegania na deskach rozdzielczych (Prometheus/Loki/Cloud).
Punkty kontaktowe: PagerDuty/Slack/Email, Zasady powiadamiania na folder.
Cisza: planowane prace, migracje, wydania.
Migawki z automatycznym zrzutem ekranu panelu w bilecie.
7) Procesy dyżurne i żywe
Obrót: pierwsza linia (SRE/platforma), druga linia (właściciel usługi), trzecia (DB/Payments/Sec).
Reakcje SLA: rozpoznanie ≤ 5 min (SEV1), rozpoznanie ≤ 15 min, komunikacja co 15-30 min.
Kanały służbowe: '# incydent-warroom', '# status-updates' (tylko fakty).
Runbooks: link w każdym wpisie + szybkie polecenia ChatOps ('/rollback ', '/freeze', '/scale ').
Alarmy szkoleniowe: co miesiąc (sprawdzanie osób, kanały, znaczenie runabook).
8) Incydenty: Cykl życia
1. Wykrywanie (alert/raport/syntetyka) → Potwierdzenie dyżuru.
2. Triage: określić SEV/affected/hipotezę, otwarty pokój wojenny.
3. Stabilizacja: rolki/rolki/skalowanie/ficheflagi.
4. Komunikaty: szablon stanu (patrz poniżej), ETA/kolejne kroki.
5. Zamknięcie: potwierdzenie odzysku SLO.
6. Przegląd po incydencie (RCA): Po 24-72 godzinach, bez opłat, pozycje działań.
- Co jest uszkodzone/dotknięte (region/najemca/kanał)
- Po uruchomieniu/SEV
- Środki tymczasowe (łagodzenie skutków)
- Następna aktualizacja stanu w N minut
- Kontakt (kierownik incydentu)
9) Specyfika iGaming: strefy „bólu” i wpisy
Płatności/TTW: udział czasu PSP, wzrost awarii kodu, TTW p95> 3m.
Szczyty turnieju: p99 API/czas rozpoczęcia gry/opóźnienie kolejki; promocja limitów/automatycznej skali.
Wnioski z funduszy: SLA backhoe/manual checks, limity w podziale na kraje.
Dostawcy gier: dostępność przez studio, czas inicjalizacji sesji, spadek startu.
RG/Zgodność: wybuchy długich sesji/” dogon”, przekraczające progi - nie strona, ale bilet + powiadomienie zespołu RG.
10) Przykłady reguł (fakultatywne)
Wysoka opóźnienie p95 (API)
promql alert: HighLatencyP95 expr: histogram_quantile(0. 95,
sum by (le, service) (rate(http_request_duration_seconds_bucket{service="api"}[5m]))) > 0. 25 for: 10m labels: { severity: "page", service: "api" }
annotations:
summary: "p95 latency > 250ms"
runbook: "https://runbooks/api/latency"Kolejka ołowiu „on”
promql alert: WithdrawalsQueueLag expr: max_over_time(queue_lag_seconds{queue="withdrawals"}[10m]) > 300 for: 10m labels: { severity: "page", service: "payments-worker" }
annotations:
summary: "Withdrawals lag >5m"
runbook: "https://runbooks/payments/queue"Konwersja płatności zanurzona
promql alert: PaymentConversionDrop expr:
(sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m])))
< (payment_conv_baseline - 0. 003)
for: 20m labels: { severity: "page", domain: "payments" }
annotations:
summary: "Payment conversion below baseline -0. 3%"
runbook: "https://runbooks/payments/conversion"11) Chatopy i automatyzacja
Automatyczne wysyłanie wpisów za pomocą przycisków akcji: Stop canary, Rollback, Scale + N.
Skróty poleceń: '/incydent start ', '/status update', '/call
Boty dokręcić kontekst: najnowsze rozmieszczenia, wykres zależności, przykłady, bilety powiązane.
12) Praca po incydencie (RCA)
Factbox: Timeline, co widziało/próbowało, co działało.
Przyczyna: przyczyny techniczne i organizacyjne.
Wykrywanie i obrona: Które sygnały pomogły/nie powiodły się.
Pozycje działania: określone zadania (SLO/alerty/kody/limity/testy/runabook).
Termin & właściciele: warunki i obowiązki; sesja następcza za 2-4 tygodnie.
13) Lista kontrolna wdrażania
1. Zdefiniuj SLI/SLO dla strumieni kluczowych (API/Płatności/Gry/TTW).
2. Skonfiguruj zasady nagrywania i alerty wielopalnikowe + routing Alertmanager.
3. Wpisz dyżur z rotacją, reakcją SLO i eskalacją.
4. Powiązanie wpisów z poleceniami Runbooks i ChatOps.
5. Konfigurować tłumienie/ciche okna, zwolnić/pracować adnotacje.
6. Ucz się alarmów i scenariuszy gry-day (PSP drop, p99 rise, kolejka lag rise).
7. Measure Alert Quality: MTTA/MTTR,% noisy/false, coverage by SLO.
8. Regularne RCA i przegląd progów/procesów.
9. Wprowadź status komunikacji biznesowej/wsparcia (szablony).
10. Dokumentuj wszystko jako kod: zasady, trasy, linki runabook.
14) Anty-wzory
Ostrzeganie przez „every metric →” alert-fetig, ignoruj.
Nie SLO → nie jest jasne, co jest „normalne” i co jest „w ogniu”.
Brak tłumienia/hamowania → duplikaty lawiny.
Strona w nocy dla drobnych zdarzeń (SEV nie jest porównywalna z Impact).
Wpisy bez książki startowej/właściciela.
„Ręczne” działania bez ChatOps/audytu.
Brak pozycji RCA/działania → powtórzyć incydenty.
Podsumowanie
Alertowanie i reagowanie to proces, a nie zbiór zasad. Link SLO z wielopalnikowych wpisów, zbudować wyraźną eskalację dyżurów, dodać ChatOps i live runabook, regularnie prowadzić RCA i sesje treningowe. Wtedy incydenty będą rzadziej, krótsze i tańsze, a wydania będą bardziej przewidywalne nawet w gorących godzinach iGaming.