Алертинг және ақауларға ден қою
(Бөлім: Технологиялар және Инфрақұрылым)
Қысқаша түйіндеме
Күшті алертинг - бұл жай ғана «қызыл метрика» емес, пайдаланушының құндылығын бұзу туралы сигнал. iGaming үшін SLO-гейттер (жасырындылық, қолжетімділік, төлем конверсиясы, Time-to-Wallet), multi-burn ережелері, on-call, эскалация, ChatOps және runbooks нақты рөлдері маңызды. Мақсаты - ауытқуды тез көру, түзете алатындарға хабарлау және келесі жолы одан да жылдам әрі арзан әрекет ету үшін білімдерін бекіту.
1) Негіздері: метрикадан әрекетке
SLI → SLO → Alert: өлшенетін сапа → мақсатты деңгей → «бюджет жанып тұр» шарттары.
Severity (SEV): SEV1 - сыни (түсім/GGR қауіп астында), SEV2 - елеулі, SEV3 - орташа, SEV4 - минор.
Impact/Urgency: кім зардап шегеді (барлығы/өңір/тенант/арна) және қаншалықты шұғыл (TTW ↑, p99 ↑, error-rate ↑).
Actionability: әрбір дабылға - нақты әрекет (runbook + иесі).
2) Сигналдардың таксономиясы
ТехSLO: p95/p99 latency API, error-rate, saturation (CPU/IO/GPU), queue lag.
БизнесSLO: төлем конверсиясы (attempt → success), Time-to-Wallet (TTW), ставкалардың табыстылығы, ойындардың іске қосылуы.
Төлем бағыттары: PSP-ерекше өлшемдер (timeout/decline spikes).
Фронт/мобайл: RUM-метрика (LCP/INP), crash-rate, сценарийдің синтетикасы (логин/депозит/мөлшерлеме/шығару).
3) Алертинг саясаты: SLO және burn-rate
SLI/SLO мысалдары
Қол жетімділік 'payments-api' ≥ 99. 9% / 30d p95 `/deposit` ≤ 250 ms / 30d
Конверсия 'payments _ attempt → success' ≥ baseline − 0. 3% / 24h
TTW p95 ≤ 3 мин/24h
Multi-window / Multi-burn (идея PromQL)
Fast burn: SLO бұзылуы нормадан 5-10 × жылдам (5-15 минут ішінде алерт-пейдж).
Slow burn: бюджеттің баяу күйіп кетуі (1-3 сағат ішінде тикет + талдау).
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) Шуды азайту және сигналдардың сапасы
Шындықтың дұрыс көзі: ауыр «шикі» емес, агрегаттар бойынша (recording rules).
Дедупликация: Alertmanager 'service/region/severity' бойынша топтайды.
Иерархия: алдымен бизнес/SLI, төменде - диагностика ретінде техметрика.
Супрессия: planned-maintenance/reliz (аннотация) кезінде, upstream-инциденттер кезінде.
Түбірлігі: 'user _ id/session _ id' дегенді алерт белгілерінде қолданбаңыз.
Тест-алерттар: тұрақты «оқу» триггерлері (арналарды, рөлдерді, рунабук-сілтемелерді тексеру).
5) Alertmanager: маршруттау және эскалация
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" ]Идея: SEV = page → PagerDuty/SMS; қалғаны - Slack/тикет. Ингибиция жоғары белсенді SEV кезінде төменгі деңгейдегі «шу» басады.
6) Grafana Alerting (қосымша қабат ретінде)
Орталықтандырылған Alert rules дашбордтарда (Prometheus/Loki/Cloud).
Contact points: PagerDuty/Slack/Email, Notification policies per folder.
Silences: жоспарлы жұмыстар, көшіру, релиздер.
Панельдің автоскриншоты бар Snapshots.
7) On-call және «тірі» процестер
Ротация: 1-ші желі (SRE/платформа), 2-ші желі (сервис иесі), 3-ші (DB/Payments/Sec).
SLA реакциялары: тану ≤ 5 мин (SEV1), диагностика ≤ 15 мин, коммуникация әрбір 15-30 минут.
Кезекші арналар: '#incident -warroom', '#status -updates' (тек фактілер).
Runbooks: сілтемесі + ChatOps жылдам пәрмені ('/rollback ', '/freeze', '/scale ').
Оқу дабылдары: ай сайын (адамдарды, арналарды, рунабук-өзектілікті тексеру).
8) Инциденттер: өмірлік цикл
1. Детект (алерт/репорт/синтетика) → Acknowledge on-call.
2. Триаж: SEV/қозғалған/гипотезаны анықтау, war-room ашу.
3. Тұрақтандыру: рулбуктар/кері шегіну/масштабтау/фичефлагтар.
4. Коммуникациялар: мәртебе үлгісі (төменде қараңыз), ETA/келесі қадамдар.
5. Жабу: SLO қалпына келтірілгенін растау.
6. Post-Incident Review (RCA): 24-72 сағаттан кейін, айыптаусыз, action items.
- Не бұзылды/кім қозғады (өңір/тенант/арна)
- Қашан басталды/SEV
- Уақытша шаралар (mitigation)
- Келесі мәртебені N минуттан кейін жаңарту
- Контакт (Оқиға менеджері)
9) iGaming ерекшелігі: «ауырсыну» аймақтары мен аллергиялар
Payments/TTW: PSP таймауттар үлесі, TTW p95> 3м код бойынша істен шығу өсімі.
Жарыстардың шыңдары: p99 API/ойын бастау уақыты/queue lag; лимиттерді/авто-скейлді насихаттау.
Қаражаттың қорытындылары: бэкофистің/қолмен тексерудің SLA, елдер бойынша лимиттер.
Ойын провайдерлері: студиялар бойынша қолжетімділік, сессияны бастау уақыты, ұшырулардың құлдырауы.
RG/Compliance: ұзақ сессиялардың/» догонның» жарылысы, шектен асуы - пейдж емес, тикет + RG-командасына хабарлама.
10) Ереже үлгілері (қосымша)
Жоғары латенттілік 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"Шығарылым кезегі «жанып тұр»
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"Төлемдердің конверсиясы
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 және автоматтандыру
Stop canary, Rollback, Scale + N.
Команда қысқартулары: '/incident start ', '/status update', '/call
Боттар контекст тартады: соңғы деплоилер, тәуелділік бағандары, трейс-мысалдар (exemplars), байланысты тикеттер.
12) Инциденттен кейінгі жұмыс (RCA)
Фактілер: таймлайн, не көрдіңіз/не істедіңіз, не істеді.
Root cause: техникалық және ұйымдастырушылық себептер.
Detections & Defenses: қандай сигналдар көмектесті/сәтсіз болды.
Action items: нақты тапсырмалар (SLO/алерттар/кодтар/лимиттер/тесттер/рунабук).
Due dates & owners: мерзімдері және жауапты; follow-up-сессиясы 2-4 аптадан кейін.
13) Енгізу чек-парағы
1. Негізгі ағындар үшін SLI/SLO анықтаңыз (API/Payments/Games/TTW).
2. recording rules және multi-burn алаңдарын + Alertmanager маршрутизациясын теңшеңіз.
3. Ротациямен, SLO реакциялармен және эскалациялармен on-call енгізіңіз.
4. Runbooks және ChatOps командаларына алерттерді байлаңыз.
5. Басу/тыныш терезелерді, релиздер/жұмыстар аңдатпаларын теңшеңіз.
6. Жаттығу дабылдары мен game-day сценарийлерін жасаңыз (PSP құлдырауы, p99 өсуі, queue lag өсуі).
7. Alert Quality: MTTA/MTTR,% noisy/false, SLO бойынша coverage өлшеңіз.
8. Тұрақты RCA және шектерді/процестерді қайта қарау.
9. Бизнеспен/саппортпен байланыс мәртебесін енгізіңіз (үлгілер).
10. Бәрін код ретінде құжаттаңыз: ережелер, бағыттар, рунабук-сілтемелер.
14) Қарсы үлгілер
«Әр метрика» бойынша алертинг → алерт-фэтиг, игнор.
SLO → жоқ, «норманың» не екені және «жанып жатқаны» түсініксіз.
Басудың/ингибицияның болмауы → телнұсқалардың көшкіні.
Пейдж түнде шағын оқиғалар үшін (SEV Impact-пен салыстыруға келмейді).
Runbook/иесі жоқ алерталар.
ChatOps/аудитсіз «қол» әрекеттері.
RCA/Action items → оқиғаларды қайталау жоқ.
Алертинг және ден қою - бұл ережелер жинағы емес, процесс. SLO-ны multi-burn-алерталарымен байланыстырыңыз, айқын on-call-эскалация жасаңыз, ChatOps және тірі рунабук-и қосыңыз, RCA мен жаттығуларды үнемі жүргізіңіз. Сонда оқиғалар азырақ, қысқа және арзан болады, ал релиздер тіпті iGaming ыстық сағаттарында да болжамды болады.