Alertare și răspuns eșec

(Secțiunea: Tehnologie și infrastructură)

Scurt rezumat

Alertarea puternică este un semnal de încălcare a valorii utilizatorului și nu doar o „metrică roșie”. "Pentru iGaming, porțile SLO (latență, disponibilitate, conversie de plată, Time-to-Wallet), regulile multi-burn, rolurile clare la apel, escaladare, ChatOps și runbooks sunt importante. Scopul este de a vedea rapid abaterea, de a-i informa pe cei care pot corecta și de a stabili cunoștințele pentru a reacționa și mai rapid și mai ieftin data viitoare.

1) Elementele de bază: de la metrici la acțiune

SLI → SLO → Alert - calitate măsurată → nivel țintă → „bugetul este în stare”.
Severitatea (SEV): SEV1 - critică (venituri/RGG la risc), SEV2 - gravă, SEV3 - moderată, SEV4 - minoră.
Impact/Urgență: cine suferă (toate/regiune/chiriaș/canal) și cât de urgent (TTW↑, p99↑, eroare- rate↑).
Acționabilitate: pentru fiecare alarmă - o acțiune specifică (runbook + proprietar).

2) Taxonomia semnalului

ТехSLO: API de latență p95/p99, rată de eroare, saturație (CPU/IO/GPU), decalaj de coadă.
BusinessSLO: conversia plăților (attempt→success), Time-to-Wallet (TTW), succesul pariurilor, lansarea jocului.
Rute de plată: valori specifice PSP (timeout/declin spikes).
Față/mobil: metrica RUM (LCP/INP), rata de avarie, sintetica scenariului (login/depunere/rată/ieșire).

3) Politica de alertare: SLO și burn-rate

Exemple SLI/SLO

Disponibilitate plăți-api ≥ 99. 9 %/30d p95 '/depozit '≤ 250 ms/30d

Conversia payments_attempt→success de referință "≥ − 0. 3 %/24h

TTW p95 ≤ 3 min/24h

Multi-window/Multi-burn (идея PromQL)

Ardere rapidă: încălcarea SLO 5-10 × mai repede decât în mod normal (pagina de alertă în 5-15 minute).
Ardere lentă: ardere lentă a bugetului (bilet + analiză în 1-3 ore).

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) Reducerea zgomotului și calitatea semnalului

Sursa corectă a adevărului: să se modifice prin agregate (reguli de înregistrare), și nu prin expresii grele „brute”.
Deduplicare - Grupuri Alertmanager prin „serviciu/regiune/severitate”.
Ierarhie: prima alertă la business/SLI, mai jos - măsurători tehnice ca diagnostic.
Suprimarea: în timpul planificării-întreținere/eliberare (adnotare), în timpul incidentelor din amonte.
Cardinalitate: Nu utilizați 'user _ id/session _ id' în etichetele de alertă.
Alerte de testare: declanșatoare regulate de „antrenament” (canale de verificare, roluri, link-uri runabook).

5) Alertmanager rutare și escaladare

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 = pagina → PagerDuty/SMS; restul este Slack/bilet. Inhibarea suprimă „hype ”-ul nivelurilor inferioare cu VES active de mai sus.

6) Grafana Alerting (ca strat suplimentar)

Reguli centralizate de alertă pe tablouri de bord (Prometheus/Loki/Cloud).
Puncte de contact: PagerDuty/Slack/Email, Politici de notificare pe dosar.
Tăceri: lucrări planificate, migrații, eliberări.
Instantanee cu o captură automată a panoului din bilet.

7) Procesele on-call și live

Rotație: prima linie (SRE/platformă), a doua linie (proprietarul serviciului), a treia (DB/Plăți/Sec).
Reacții SLA: recunoaștere ≤ 5 min (SEV1), diagnostic ≤ 15 min, comunicare la fiecare 15-30 min.
Duty canale: '# incident-warroom', '# stare-actualizări' (fapte numai).
Runbooks: link în fiecare alertă + comenzi rapide ChatOps ('/rollback ', '/freeze', '/scale ').
Alarme de antrenament: lunar (verificare persoane, canale, relevanță hoinar).

8) Incidente: Ciclul de viață

1. Detectarea (alertă/raport/sintetice) → Confirmați la apel.
2. Triaj: determinați SEV-ul/afectat/ipoteza, deschideți camera de război.
3. Stabilizare: rulouri/rollback/scalare/phicheflags.
4. Comunicații: șablon de stare (a se vedea mai jos), ETA/pașii următori.
5. Închidere: confirmarea recuperării SLO.
6. Post-Incident Review (RCA): După 24-72 de ore, fără taxe, articole de acțiune.

• Ce este rupt/afectat (regiune/chiriaș/canal)
• Când a început/SUV
• Măsuri temporare (atenuare)
• Următoarea actualizare a stării în N minute
• Contact (Manager incidente)

9) Specificul iGaming: „durere” zone și alerte

Plăți/TTW: cota de PSP timeout, creșterea defecțiunilor de cod, TTW p95> 3m.
Vârfuri de turneu: API p99/ora de începere a jocului/lag coadă; promovarea limitelor/auto-scară.
Concluziile fondurilor: SLA de controale backhoe/manuale, limite pe țări.
Furnizori de jocuri: disponibilitate prin studio, timp de inițializare sesiune, picătură de lansare.
RG/Conformitate: explozii de sesiuni lungi/” dogon”, depășind pragurile - nu o pagină, ci un bilet + notificare către echipa RG.

10) Exemple de reguli (opțional)

Latență ridicată 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"

Coada de plumb „pe”

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"

Conversia plăților scufundată

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 și automatizare

Alerte de postare automată cu butoane de acțiune: Stop canar, Rollback, Scale + N.

Abrevieri de comandă: '/incident start ', '/status update', '/call ', '/grafana '

Roboții înăspresc contextul: cele mai recente implementări, graficul de dependență, exemplare, bilete asociate.

12) Munca post-incident (RCA)

Factbox: Cronologie, ce a văzut/încercat, ce a funcționat.
Cauza principală: motive tehnice și organizatorice.
Detectări și defensive: Care semnale au ajutat/au eșuat.
Elemente de acțiune: sarcini specifice (SLO/alerte/coduri/limite/teste/runabook).
Date scadente și proprietari: termeni și responsabilități; sesiune de urmărire în 2-4 săptămâni.

13) Lista de verificare a implementării

1. Definiți SLI/SLO pentru fluxurile cheie (API/Payments/Games/TTW).
2. Configurați reguli de înregistrare și alerte multi-burn + rutare Alertmanager.
3. Introduceți de gardă cu rotație, SLO de reacție și escaladări.
4. Link alerts to runbooks and ChatOps commands.
5. Configurați ferestre de suprimare/silențioase, adnotări de lansare/lucru.
6. Asigurați-alarme de învățare și scenarii de joc-zi (picătură PSP, creștere p99, coadă lag creștere).
7. Measure Alert Quality: MTTA/MTTR,% zgomotos/fals, acoperire prin SLO.
8. RCA regulate și revizuirea pragurilor/proceselor.
9. Introduceți starea de comunicare de afaceri/suport (șabloane).
10. Documentul totul ca cod: reguli, rute, link-uri runabook.

14) Anti-modele

Alertarea prin „fiecare metric” → alert-fetig, ignora.
Nu SLO → nu este clar ce este „normal” și ce este „pe foc”.
Fără suprimare/inhibare → duplicatelor de avalanşă.
Pagina pe timp de noapte pentru evenimente minore (SEV nu este comparabil cu Impact).
Alerte fără runbook/proprietar.
Acțiuni „manuale” fără ChatOps/audit.
Nu există elemente RCA/acțiune → incidente repetate.

Rezumat

Alertarea și răspunsul este un proces, nu un set de reguli. Link-ul SLO cu alerte multi-arde, construi o escaladare clară la apel, adăugați ChatOps și hoinărit live, desfășoară în mod regulat RCA-uri și sesiuni de formare. Apoi, incidentele vor fi mai puțin frecvente, mai scurte și mai ieftine, iar lansările vor fi mai previzibile chiar și în orele fierbinți ale iGaming.