Alertinq və uğursuzluqlara cavab
(Bölmə: Texnologiya və Infrastruktur)
Qısa xülasə
Güclü alertinq yalnız «qırmızı metrika» deyil, istifadəçi dəyərinin pozulmasının siqnalıdır. iGaming üçün SLO geytaları (gizlilik, əlçatanlıq, ödəniş çevirmə, vaxt-to-Wallet), multi-burn qaydaları, on-call, eskalasiya, ChatOps və runbooks rolları vacibdir. Məqsəd sapmanı tez görmək, düzəldə bilənlərə məlumat vermək və növbəti dəfə daha sürətli və daha ucuz reaksiya vermək üçün bilikləri düzəltməkdir.
1) Əsaslar: metrikdən hərəkətə
SLI → SLO → Alert: ölçülə bilən keyfiyyət → hədəf səviyyəsi → şərtlər «büdcə yanır».
Severity (SEV): SEV1 - kritik (gəlir/GGR təhlükə altında), SEV2 - ciddi, SEV3 - mülayim, SEV4 - kiçik.
Impact/Urgency: kim əziyyət çəkir (bütün/region/tenant/kanal) və nə qədər təcili (TTW ↑, p99 ↑, error-rate ↑).
Actionability: Hər həyəcan - xüsusi hərəkət (runbook + sahibi).
2) Siqnalların taksonomiyası
ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
BusinessSLO: ödənişlərin konvertasiyası (attempt → success), Time-to-Wallet (TTW), bahislərin müvəffəqiyyəti, oyunların başlaması.
Ödəniş marşrutları: PSP-spesifik metriklər (timeout/decline spikes).
Ön/mobil: RUM-metrika (LCP/INP), qəza-rate, sintetik ssenarilər (giriş/depozit/dərəcə/çıxarış).
3) Alertinq siyasəti: SLO və burn-rate
SLI/SLO nümunələri
Mövcudluq 'payments-api' ≥ 99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d
Dönüşüm 'payments _ attempt → success' ≥ baseline − 0. 3% / 24h
TTW p95 ≤ 3 dəq/24h
Multi-window / Multi-burn (идея PromQL)
Fast burn: SLO-nun pozulması normadan 5-10 × daha sürətli (5-15 dəq ərzində alert page).
Slow burn: büdcənin yavaş tükənməsi (bilet + 1-3 saat ərzində analiz).
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) Səs-küy azaldılması və siqnalların keyfiyyəti
Doğru həqiqət mənbəyi: ağır «xam» ifadələrlə deyil, aqreqatlara (recording rules) görə alertasiya.
Deduplication: Alertmanager qruplaşdırır 'service/region/severity'.
Hiyerarxiya: əvvəlcə biznes/SLI-də, aşağıda - diaqnostika kimi texnometrika.
Supressiya: planned-maintenance/reliz (annotasiyalar) zamanı, upstream hadisələri zamanı.
Kardinallıq: Alert etiketlərində 'user _ id/session _ id' istifadə etməyin.
Test həyəcanları: müntəzəm «təlim» triggerləri (kanalların, rolların, runabuk linklərinin yoxlanılması).
5) Alertmanager: marşrutlaşdırma və eskalasiya
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" ]Fikir: SEV = page → PagerDuty/SMS; qalan - Slack/bilet. İnhibisiya daha yüksək aktiv SEV-də aşağı səviyyələrin «səs-küyünü» yatırır.
6) Grafana Alerting (əlavə təbəqə kimi)
Mərkəzləşdirilmiş Alert rules dashboard (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silences: planlı işlər, miqrasiyalar, buraxılışlar.
Snapshots avto ekran paneli ilə bir bilet.
7) On-call və «canlı» proseslər
Rotasiya: 1-ci xətt (SRE/platforma), 2-ci xətt (xidmət sahibi), 3-cü (DB/Payments/Sec).
SLA reaksiyalar: tanınması ≤ 5 dəq (SEV1), diaqnostika ≤ 15 dəq, rabitə hər 15-30 dəq.
Növbətçi kanallar: '#incident -warroom', '#status -updates' (yalnız faktlar).
Runbooks: link hər alert + sürətli ChatOps komandaları ('/rollback ', '/freeze', '/scale ').
Təlim həyəcanları: aylıq (insanları, kanalları, runabuk-aktuallığını yoxlamaq).
8) Hadisələr: həyat dövrü
1. Detekt (alert/report/sintetika) → Acknowledge on-call.
2. Triaj: SEV müəyyən/təsir/hipotez, açıq war-room.
3. Stabilizasiya: rulbuk/geri/miqyaslı/fiziki.
4. Rabitə: status şablonu (aşağıya bax), ETA/aşağıdakı addımlar.
5. Bağlanması: SLO bərpa təsdiqi.
6. Post-Incident Review (RCA): 24-72 saat sonra, ittiham olmadan, action items.
- Nə qırıldı/kimə təsir etdi (region/tenant/kanal)
- Nə zaman başladı/SEV
- Müvəqqəti tədbirlər (mitigation)
- Növbəti status yenilənməsi N dəqiqə sonra
- Əlaqə (Hadisə meneceri)
9) iGaming xüsusiyyətləri: «ağrılı» zonalar və alertlər
Payments/TTW: PSP vaxtlarının payı, kod arızalarının artması, TTW p95> 3m.
Turnirlərin zirvələri: p99 API/oyun başlama vaxtı/queue lag; limitlərin təbliğatı/avto skayl.
Vəsaitlərin çıxarılması: SLA backofis/əl yoxlamaları, ölkələr üzrə limitlər.
Oyun provayderləri: studiya əlçatanlığı, sessiyanın başlanğıc vaxtı, buraxılışların düşməsi.
RG/Compliance: uzun sessiyalar/» doqon» sıçrayışları, həddi aşmaq - peyc deyil, bilet + RG komandasına bildiriş.
10) Qaydaların nümunələri (əlavə)
Yüksək gecikmə 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"Nəticə növbəsi «yanır»
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"Ödənişlərin çevirilməsi dayandırıldı
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) ChatOps və avtomatlaşdırma
Stop canary, Rollback, Scale + N.
Komanda ixtisarları: '/incident start ', '/status update', '/call
Botlar konteksti gücləndirir: son deploes, asılılıq qrafiki, treys nümunələri (exemplars), əlaqəli biletlər.
12) Post-insident işi (RCA)
Faktlar: gördüyünüz/sınadığınız, nə işlədiyiniz.
Root cause: texniki və təşkilati səbəbləri.
Detections & Defenses: hansı siqnallar kömək/uğursuz.
Action items: konkret tapşırıqlar (SLO/alertlər/kodlar/limitlər/testlər/runabook).
Due dates & owners: vaxt və məsuliyyətli; follow-up-seans 2-4 həftə sonra.
13) Giriş çek siyahısı
1. Əsas axınlar üçün SLI/SLO (API/Payments/Games/TTW) təyin edin.
2. recording rules və multi-burn alerts + Alertmanager marşrutlaşdırma konfiqurasiya.
3. Rotasiya, SLO reaksiyaları və eskalasiyaları ilə on-call daxil edin.
4. Runbooks və ChatOps komandalarına alertlər bağlayın.
5. Sıxışdırma/səssiz pəncərələri, relizlərin/işlərin izahlarını konfiqurasiya edin.
6. Təlim həyəcan və game-day script edin (PSP düşməsi, p99 böyüməsi, queue lag böyüməsi).
7. Alert Quality ölçün: MTTA/MTTR,% noisy/false, SLO coverage.
8. Müntəzəm RCA və eşik/proseslərin yenidən baxılması.
9. Biznes/sapport (şablonlar) ilə status-kommunikasiya daxil edin.
10. Hər şeyi kod kimi sənədləşdirin: qaydalar, marşrutlar, runabuk linkləri.
14) Anti-nümunələr
«Hər metrika» üzrə alertinq → alert-fetiq, ignor.
No SLO → «norma» və «yanan» nə aydın deyil.
Depressiya/inhibisiyanın olmaması → dublikatların uçması.
Page gecə kiçik hadisələr üçün (SEV Impact ilə müqayisə edilə bilməz).
Runbook/sahibi olmadan alertlər.
ChatOps/audit olmadan «əl» hərəkətləri.
RCA/Action items → hadisələrin təkrarı yoxdur.
Nəticələr
Alertinq və reaksiya qaydalar toplusu deyil, bir prosesdir. SLO-nu multi-burn-alertlərlə əlaqələndirin, aydın on-call-eskalasiya qurun, ChatOps və canlı Runabook-i əlavə edin, müntəzəm olaraq RCA və təlim-məşq edin. Sonra hadisələr daha az, daha qısa və daha ucuz olacaq və buraxılışlar hətta isti iGaming saatlarında proqnozlaşdırıla bilər.