Operațiunile și gestionarea → de alertă în funcție de capacitatea sistemului

Alerte privind capacitatea sistemului

1) De ce aveți nevoie de ea

Alertele capacitive avertizează că se apropie de limitele tehnice cu mult înainte de incident: "suntem 80% din plafon - este timpul să scalăm. "Pentru afacerile alimentare, este vorba direct despre bani: pariuri/depozite ratate, scăderi de sesiune, întârzieri ale jocurilor live și eșecuri ale furnizorilor = venituri pierdute, reputație, amenzi și kickback-uri.

Obiective:

Previzibil rezista la sarcini de vârf (evenimente, turnee, fluxuri, campanii mari).
Activaţi scalarea automată la timp şi planificaţi ridicarea capacităţii.
Reduceți zgomotul și treziți-vă „în afaceri” atunci când SLO/banii sunt în pericol.
Oferiți inginerilor recomandări exacte prin intermediul runbook.

2) Concepte de bază

Capacitate: debit maxim stabil (RPS/TPS, conexiuni, IOPS, debit).
Headroom: marja între sarcina curentă și limitele.
SLO/SLA: niveluri țintă de disponibilitate/timp de răspuns; alertele trebuie să fie „SLO-conștient”.
Burn-rate: viteza de „ardere” a bugetului SLO de erori/latență.
Filigran ridicat/scăzut: niveluri superioare/inferioare pentru acționări și auto-recuperare.

3) Arhitectura semnalului și sursele de date

Telemetrie: metrica (Prometheus/OTel), busteni (ELK/ClickHouse), urme (OTel/Jaeger).
Abordare strat: alerte pe straturi (Edge → API → servicii de afaceri → cozi/fluxuri → baze de date/cache-uri → magazine de fișiere/obiecte → furnizori externi).
Context: caracteristici steaguri, lansări, campanii de marketing, turnee, geo-aliniere.
Anvelope incidente: Alertmanager/PagerDuty/Opsgenie/Slack; legare la runbook şi matrice de escaladare.

4) Măsurători cheie după strat (ce să monitorizeze și de ce)

Edge/L7

RPS, latență 95-/99-percentilă, rată de eroare (5xx/4xx), conexiuni deschise.
Rate-limite/cote, picături на CDN/WAF/Firewall.

API- шлюз/Backend-for-Frontend

Saturație prin piscină de lucru/lucrător, coadă de cerere, termene la downstreams.
Fracția de degradare (căderi, întrerupătoare de circuit).

Cozi/Streaming (Kafka/Iepure/Pulsar)

Întârzierea decalajului/consumatorului, rata de creștere a restanțelor, debitul (msg/s, MB/s).
Partition skew, reechilibrarea Churn, ISR (pentru Kafka), retray/bunicul-mai târziu.

Lucrători asincroni

Timpul de lucru, lungimea cozii, procentul de sarcini SLA expirate.
Procesor de saturație/memorie/FD la bazine.

Cache (Redis/Memcached)

Raportul de succes, latența, evacuările, memoria utilizată, clienții/operatorii conectați.
Clustere: sloturi/replici, evenimente failover.

БД (PostgreSQL/MySQL/ClickHouse)

Conexiuni active vs max, așteptări de blocare, decalaj replicare, tampon/cache lovit.
IOPS, citire/scriere latență, punct de control/culoare, bloat/fragmentare.

Obiect/Stocare fișiere

PUT/GET latență, 4xx/5xx, ieșire, cereri/sec, limitele furnizorului.

Furnizori externi (Plăți/LCC/Furnizori de jocuri)

Limite TPS, ferestre QPS, rată de eroare/timeout, coadă de retragere, „cost per apel”.

Infrastructura

Procesor/memorie/FD/IOPS/saturație de rețea pe noduri/păstăi/ASG.
Evenimente HPA/VPA, păstăi în așteptare, container OOM/Throttling.

5) Tipuri de alerte capacitive

1. Praguri statice

Simplu și simplu: 'db _ connections> 80% max'. Bun ca un semnal de semnal.

2. Praguri adaptive (dinamice)

Bazat pe sezonalitate și tendință (ferestre rulante, descompunere STL). Permiteți prinderea „neobișnuit de mare pentru această oră/zi a săptămânii”.

3. Orientat spre SLO (burn-rate)

Acestea sunt declanșate atunci când rata de eroare-buget de alimentație va pune în pericol SLO în orizontul X oră.

4. Prognostic (prognoză-alerte)

„După 20 de minute în tendința actuală, coada va ajunge la 90%”. Se utilizează predicția liniară/robustă/profetică pe ferestre scurte.

5. Multi-semnal

Declanșați cu combinația: 'queue _ lag ↑' + 'consumer _ cpu 85%' + 'autoscaling la max' → „intervenția manuală este necesară”.

6) Politici de prag și anti-zgomot

Filigran de înaltă/joasă:

Sus: avertizare 70-75%, Creta 85-90%. Jos: histerezis 5-10 pp Pentru a nu „vedea pragul”.

Ferestre de timp și supresii:

„pentru: 5m' pentru criterii”, pentru: 10-15m' pentru avertismente. Modul de noapte: traseu non-critic pentru a conversa fără paginare.

Gruparea evenimentelor:

Grup după serviciu/cluster/geo pentru a nu produce carduri incidente.

Suprimarea dependenței:

În cazul în care furnizorul KYC este afară și erorile API se datorează paging proprietarul integrării, nu toți consumatorii.

Timp de comercializare ferestre:

În timpul perioadei de stocare, ridicați pragurile de zgomot pentru „creșterea preconizată”, dar lăsați alerte SLO intacte.

7) Exemple de reguli (pseudo-Prometeu)

Conexiuni DB:


ALERT PostgresConnectionsHigh
IF (pg_stat_activity_active / pg_max_connections) > 0. 85
FOR 5m
LABELS {severity="critical", team="core-db"}
ANNOTATIONS {summary="Postgres connections >85%"}

Kafka lag + auto-scalare la limita:


ALERT StreamBacklogAtRisk
IF (kafka_consumer_lag > 5_000_000 AND rate(kafka_consumer_lag[5m]) > 50_000)
AND (hpa_desired_replicas == hpa_max_replicas)
FOR 10m
LABELS {severity="critical", team="streaming"}

Burn-rate SLO (latență API):


ALERT ApiLatencySLOBurn
IF slo_latency_budget_burnrate{le="300ms"} > 4
FOR 15m
LABELS {severity="page", team="api"}
ANNOTATIONS {runbook="wiki://runbooks/api-latency"}

Redis memorie și evikshens:


ALERT RedisEvictions
IF rate(redis_evicted_keys_total[5m]) > 0
AND (redis_used_memory / redis_maxmemory) > 0. 8
FOR 5m
LABELS {severity="warning", team="caching"}

Furnizor de plată - Limite:


ALERT PSPThroughputLimitNear
IF increase(psp_calls_total[10m]) > 0. 9 psp_rate_limit_window
FOR 5m
LABELS {severity="warning", team="payments", provider="PSP-X"}

8) SLO abordare și prioritate de afaceri

De la semnal la impactul asupra afacerii: Alertele de capacitate ar trebui să se refere la riscul pentru SLO (valori specifice ale jocurilor/geo/GGR, conversia depozitelor).
Mai multe niveluri: avertismente pentru serviciul de gardă; Creta - pagina proprietar domeniu; SLO-drop - incident major și echipa „rezumat” canal.
Caracteristici de degradare: reducerea automată a sarcinii (numai pentru citire parțială, reducerea caracteristicilor grele, reducerea frecvenței emisiunilor de jackpot, oprirea animațiilor „grele” în jocurile live).

9) Auto-scalare și „corect” declanșează

HPA/VPA: țintă nu numai prin CPU/Memorie, ci și prin metrici de afaceri (RPS, coadă de așteptare, latență p99).
Termene de încălzire: luați în considerare limitele de pornire la rece și furnizor (ASG spin-up, constructori de containere, cache-uri de încălzire).
Guardrails: condiții de oprire în creșterea erorilor asemănătoare avalanșelor; protecție împotriva „problemei scalim”.
Capacity-playbooks: unde și cum să adăugați un ciob/petrecere/replica, cum să redistribuiți traficul pe regiuni.

10) Proces: de la proiectare la funcționare

1. Limit mapping: colectați limite de blocare „adevărate” pentru fiecare strat (max conns, IOPS, TPS, furnizorii de cote).
2. Selectarea metricii predictorului: care semnale indică „odihnă în N minute” mai întâi.
3. Prag de proiectare: mare/scăzut + SLO-burn + compus.
4. Runbook pentru fiecare cretă: pași de diagnostic („ce să deschizi”, „ce comenzi”, „unde să escaladezi”), trei opțiuni de acțiune: traversare rapidă, scalare, degradare.
5. Testare: simulări de sarcină (haos/zile de joc), porniri uscate de alerte, verificarea anti-zgomot.
6. Revizuire și adopție: proprietar de semnal = proprietar de serviciu. Nici un proprietar - nici o pagină.
7. Retrospective și tuning: analiza săptămânală a falsului/ratării; metric „MTTA (ack), MTTD, MTTR, Raport zgomot/semnal”.

11) Anti-modele

CPU> 90% ⇒ panică: fără corelație cu latența/cozile, acest lucru poate fi normal.
„Un prag pentru toți”: diferite regiuni/zone de timp - profile de trafic diferite.
Alertă fără runbook: pagină fără scurgeri clare de acțiune la apel.
Orbirea furnizorilor: cotele/limitele externe sunt adesea primele care „sparg” scripturile (PSP, KYC, anti-fraudă, furnizori de jocuri).
Fără histerezis: „tăierea” la limita de 80 %/79%.

12) Caracteristici ale platformelor iGaming/financiare

Program vârfuri: prime time, finala turneului, meciuri majore; Promovați replicile țintă și umpleți cache-urile în avans.
Fluxuri live și jackpot-uri: explozii de evenimente de difuzare → limite pe brokeri/site-uri web.
Plăți și KYC: ferestre furnizor, scoring anti-fraudă; păstrați rute de rezervă și depozite „grace-mode”.
Geo-balance: eșecuri ale furnizorilor locali - pentru a devia traficul într-o regiune învecinată, unde există o încăpere.
Responsabilitate: cu riscul de a pierde pariuri/jackpot-uri - pagina instant pentru echipa de domeniu + alerta de afaceri.

13) Tablouri de bord (set minim)

Prezentare generală a capacităţii: înălţime cu strat, top 3 zone riscante, burn-rate SLO.
Stream & Queues: lag, creșterea restanțelor, saturația consumatorilor, starea HPA.
DB & Cache: conexiuni, repl-lag, latență p95/p99, raport de succes, evacuări.
Furnizori: TPS/ferestre/cote, termene/erori, costul apelului.
Release/Feature context: releases/phicheflags lângă curbe.

14) Lista de verificare a implementării

Lista de limite și proprietari „adevărați”.
Predictor metrics map + asociații între straturi.
Praguri statice + histerezis.
SLO-burn-alerte pe căi critice (depozit, pariu, lansare joc live).
Alerte predictive pe coadă/fluxuri/conexiuni.
Suprimarea/întreținerea ferestrei; politica anti-zgomot.
Runbook 'și cu comenzi, grafice, filtre de degradare.
Analiza săptămânală a pozitivelor false și a tuningului.
Cont pentru campanii de marketing și calendarul evenimentelor.

15) Exemplu model runbook (abreviat)

Semnal: 'StreamBacklogAtRisk'

Obiectiv: Pentru a preveni creșterea decalajului> 10 milioane și întârzierea tratamentului> 5 min.

Diagnostic (3-5 min):

1. Verificați 'hpa _ desired/max', accelerație/oom în gropi.

2. View 'rate (lag)', partiționare (skew).

3. Verificați broker (ISR, sub-replicat, rețea).

Acțiuni:

Creșterea replicilor de consum cu + N, creșterea maximă în zbor.
Activați fondul prioritar pe „subiecte critice”.
Reduceți temporar frecvența tratamentelor secundare/îmbogățirii.
Dacă „ASG la max” - solicitați o ridicare temporară din nor; în paralel - permite degradarea funcțiilor grele.
Rollback: Reveniți la profilul normal de trafic după "lag <1 milion '15 minute.
Escaladare: proprietarul clusterului Kafka, apoi platforma SRE.

16) KPI și calitatea semnalului

Acoperire:% din căile critice închise prin alerte capacitive.
Zgomot/Semnal: Nu mai mult de 1 pagină falsă pe apel/săptămână.
MTTD/MTTR: incidentele capacitive sunt detectate ≤5 min înainte de grevele SLO.
Economii proactive: numărul de incidente prevenite (prin postmortem).

17) Pornire rapidă (valori implicite conservatoare)

DB: avertizare 75% din conexiuni/IOPS/lat; creta 85%, histerezis 8-10 pp

Cache: 'hit <0. 9 „Și” evacuări> 0 „> 5 min - avertizare;” used _ mem> 85% '- Creta.
Cozi: 'lag' inaltime> 3 σ din media pentru 30d + 'hpa at max' - Creta.
API: 'p99> SLO1. 3 „10 min - avertisment;” burn-rate> 4 '15 min - Creta.
Furnizori: „debit> 90% cotă” - avertizare; 'timeouts> 5%' - Creta.

18) ÎNTREBĂRI FRECVENTE

Î: De ce nu doar „CPU> 80%”?
R: Fără context de latență/coadă, este zgomot. Procesorul în sine nu este egal cu riscul.

Î: Avem nevoie de praguri adaptive?
R: Da, pentru sezonalitatea zilnică/săptămânală - reducerea pozitivelor false.

Î: Cum să luați în considerare marketingul/evenimentele?
R: Calendarul campaniei → adnotări pe grafice + ajustare temporară anti-zgomot, dar nu atingeți alerte SLO.