Əməliyyat və İdarəetmə → Sistemlərin tutumuna görə alert

Sistem tutumuna görə alertlər

1) Niyə lazımdır

Tutumlu alertlər hadisədən çox əvvəl texniki limitlərə yaxınlaşmaq barədə xəbərdarlıq edir: «Biz tavanın 80% -ni əhatə edirik - genişlənməyin vaxtıdır». Ərzaq biznesi üçün bu birbaşa pula aiddir: buraxılmış dərəcələr/depozitlər, oturumların düşməsi, canlı oyunların gecikməsi və provayderlərin uğursuzluqları = itirilmiş gəlir, nüfuz, cərimələr və geri qaytarmalar.

Məqsədlər:

Pik yüklərə (tədbirlər, turnirlər, axınlar, böyük kampaniyalar) dözmək proqnozlaşdırıla bilər.
Avtomatik skeylinq vaxtında daxil və capacity uplift planlaşdırın.
SLO/pul riski olduqda səs-küyü azaltın və «iş» oyandırın.
Runbook vasitəsilə mühəndislərə dəqiq tövsiyələr verin.

2) Əsas anlayışlar

Tutum (Capacity): maksimum davamlı bant genişliyi (RPS/TPS, konnektlər, IOPS, throughput).
Headroom: cari yük və limitlər arasında ehtiyat.
SLO/SLA: hədəf əlçatanlıq/cavab vaxtı səviyyələri; alertlər «SLO-aware» olmalıdır.
Burn-rate: SLO-büdcə səhvləri/gecikmə «yandırma» sürəti.
High/Low Watermark: Yuxarı/aşağı səviyyələri və avtomatik bərpa üçün.

3) Siqnalların arxitekturası və məlumat mənbələri

Teleemetriya: metriklər (Prometheus/OTel), loqlar (ELK/ClickHouse), izlər (OTel/Jaeger).
Laylı yanaşma: laylar üzrə alertlər (Edge → API → biznes xidmətləri → növbələr/axınlar → DB/caches → fayl/obyekt anbarları → xarici provayderlər).
Kontekst: ficheflages, relizlər, marketinq kampaniyaları, turnirlər, geo-nizam.
Hadisə-şina: Alertmanager/PagerDuty/Opsgenie/Slack; runbook və eskalasiya matrisi.

4) Qatlar üzrə əsas metriklər (nə izləmək və niyə)

Edge / L7

RPS, 95-/99-persentil latency, error rate (5xx/4xx), open connections.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

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

Worker/Work Pool Saturation, sorğu növbəsi, downstream timeouts.
Deqradasiya payı (fallbacks, circuit-breakers).

Növbələr/Axın (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (Kafka üçün), retray/baba leyter.

Asinxron işçilər

Tapşırıqların gözləmə müddəti, növbə uzunluğu, vaxtı keçmiş SLA tapşırıqlarının faizi.
Hovuzlarda Saturation CPU/Memory/FD.

Caches (Redis/Memcached)

Hit ratio, latency, evictions, used memory, bağlı müştərilər/ops/s.
Klasterlər: slots/replikalar, failover events.

БД (PostgreSQL/MySQL/ClickHouse)

Active connections vs max, lock waits, replication lag, buffer/cache hit.
IOPS, read/write latency, checkpoint/flush, bloat/fragmentation.

Obyekt/fayl saxlama

PUT/GET latency, 4xx/5xx, egress, sorğular/san, provayder limitləri.

Xarici provayderlər (ödənişlər/KUS/oyun provayderləri)

TPS limitləri, QPS pəncərələri, error rate/timeout, retraj növbəsi, «cost per call».

Infrastruktur

CPU/Memory/FD/IOPS/Network saturation/pod/ASG.
HPA/VPA hadisələr, pending pods, konteyner OOM/Throttling.

5) Tutumlu alertlərin növləri

1. Statik eşiklər

Sadə və anlaşılır: 'db _ connections> 80% max'. «Siqnal-mayak» kimi yaxşıdır.

2. Adaptiv (dinamik) eşiklər

Mövsümlük və trendə əsaslanır (rolling windows, STL-dekompozisiya). «Həftənin bu saatı/günü üçün qeyri-adi yüksək» tutmağa imkan verir.

3. SLO-yönümlü (burn-rate)

Error-budget yemək sürəti X saat üfüqündə SLO-ya zərbə vurduqda işləyir.

4. Proqnostik (forecast-alerts)

«Cari tendensiya ilə 20 dəqiqədən sonra növbə 90% -ə çatacaq». Qısa pəncərələrdə/Robust/Prophet oxşar proqnoz istifadə edin.

5. Kompozit (multi-signal)

'queue _ lag ↑' + 'consumer _ cpu 85%' + 'autoscaling at max' → "əllə müdaxilə etmək lazımdır.

6) Sərhəd siyasətləri və anti-səs

High/Low Watermark:

Yuxarı: 70-75% xəbərdarlıq, 85-90% krit. Aşağı: histerezis 5-10 pp «Qapı kəsmək» üçün.

Müvəqqəti pəncərələr və sıxışdırma:

'for: 5m' kritlər üçün, 'for: 10-15m' xəbərdarlıqlar üçün. Night-mode: çağrı olmadan chat qeyri-kritik route.

Hadisələrin qruplaşdırılması:

Hadisə kartlarını artırmamaq üçün xidmət/klaster/geo qruplaşdırın.

Dependency-aware suppression:

KYC provayderi kənarda və API səhvləri nəticədirsə, bütün istehlakçıların deyil, inteqrasiya sahibinin peycimi.

Müvəqqəti marketinq pəncərələri:

Promosyonlar dövründə «gözlənilən artım» üçün səs-küy həddini artırın, lakin SLO-alertləri toxunulmaz buraxın.

7) Qaydaların nümunələri (psevdo-Prometheus)

BD konnektləri:


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 + limitdə avto skeylinq:


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 (API gecikmə):


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

Redis yaddaş və evikşen:


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"}

Ödəniş provayderi - limitlər:


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 yanaşma və biznes prioriteti

Siqnaldan biznesə təsir: potensial alertlər risk to SLO-ya istinad etməlidirlər (xüsusi oyunlar/geo/GGR metrikləri, depozit dönüşümü).
Çox səviyyəli: on-call xidməti üçün xəbərdarlıqlar; krit - domen sahibinin peyck; SLO-düşmə - major hadisə və komanda «birləşmiş» kanal.
Ficheflags deqradasiya: Avtomatik yükü azaltmaq (qismən read-only, ağır fiqurların azaldılması, cekpot brodkast tezliyinin azaldılması, canlı oyunlarda «ağır» animasiyaların söndürülməsi).

9) Avtomatik skeylinq və «düzgün» triggerlər

HPA/VPA: hədəf yalnız CPU/Memory deyil, həm də biznes metrik (RPS, queue lag, p99 latency).
Warm-up tayminqləri: soyuq başlanğıc və provayder limitlərini nəzərə alın (ASG spin-up, konteyner bilderləri, cache qızdırma).
Guardrails: uçqun kimi artan səhvlər üçün stop şərtləri; «skeylim problem» qarşı müdafiə.
Capacity-playbooks: harada və necə şard/partiya/replika əlavə etmək, regionlar üzrə trafiki bölüşdürmək üçün necə.

10) Proses: dizayndan istismara qədər

1. Limitlərin xəritəsi: hər qat üçün «həqiqi» bottleneck-limitləri toplamaq (max conns, IOPS, TPS, provayderlərin quotas).
2. Metrik proqnozların seçimi: hansı siqnallar 'n dəqiqədən sonra yıxılacağımızı "göstərir.
3. Eşik dizaynı: high/low + SLO-burn + kompozit.
4. Hər krit Runbook: diaqnostika addımları («nə açmaq», «hansı əmrlər», «harada eskalasiya etmək»), üç hərəkət variantı: sürətli dolama, miqyas, deqradasiya.
5. Test: yüklərin simulyasiyası (chaos/game days), «quru başlanğıclar», anti-səs testi.
6. Revyu və övladlığa götürmə: siqnal sahibi = xidmət sahibi. Sahibi olmadan - peyc yoxdur.
7. Retrospektivlər və sazlama: yalan/buraxılmış həftəlik təhlil; metrika «MTTA (ack), MTTD, MTTR, Noise/Signal ratio».

11) Anti-nümunələr

CPU> 90% ⇒ panik: latency/queues ilə heç bir korrelyasiya normal ola bilər.
«Hamı üçün bir eşik»: müxtəlif regionlar/vaxt zonaları - fərqli trafik profilləri.
Runbook olmadan alert: aydın hərəkət olmadan peyj on-call tükənir.
Provayderlərə korluq: xarici kvotalar/limitlər tez-tez ssenariləri ilk «pozur» (PSP, KYC, antifrod, oyun provayderləri).
Histerezis yoxdur: 80 %/79% sərhəddə «kəsmə».

12) iGaming/Maliyyə Platformalarının Xüsusiyyətləri

Cədvəl üzrə zirvələr: praym-taym, turnirin finalı, böyük matçlar; əvvəlcədən hədəf replikaları artırmaq və caches doldurmaq.
Canlı axınlar və cekpotlar: broker/vebsoketlərdə yayım tədbirlərinin → limitləri.
Ödənişlər və KYC: provayderlərin pəncərələri, anti-frod skor; ehtiyat marşrutları və «grace-rejimi» depozitləri saxlamaq.
Geo-balans: provayderin lokal uğursuzluqları - trafiki qonşu bölgəyə aparmaq, burada headroom var.
Məsuliyyət: bahis/cekpot itkisi riski ilə - domen komandasına ani page + biznes xəbərdarlığı.

13) Daşbordlar (minimum dəsti)

Capacity Overview: qatlara görə headroom, ən yaxşı 3 risk sahələri, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: konnektlər, repl-lag, p95/p99 latency, hit ratio, evictions.
Providers: TPS/Windows/kvotalar, timeouts/errors, zəng dəyəri.
Release/Feature context: relizlər/əyrilərin yanında fitness.

14) Giriş çek siyahısı

«Real» limitləri və sahibləri siyahısı.
Metrik proqnozlar xəritəsi + təbəqələr arasında əlaqələr.
Statik eşik + histerezis.
Kritik yollarda SLO-burn-alertlər (depozit, bahis, canlı oyunların başlaması).
Proqnostik risklər/axınlar/konnektlər.
Suppression/maintenance pəncərə; anti-səs siyasəti.
Runbook 'və komandalar, qrafiklər, parçalanma parçaları ilə.
Həftəlik yanlış nəticələr təhlili və sazlama.
Marketinq kampaniyalarının və tədbirlərin təqviminin uçotu.

15) Nümunə şablon runbook (qısaldılmış)

Siqnal: 'StreamBacklogAtRisk'

Məqsəd: lag artımının qarşısını almaq> 10 milyon və emal gecikməsi> 5 dəq.

Diaqnostika (3-5 dəqiqə):

1. Yoxlayın 'hpa _ desired/max', throttle/oom pod.

2. Baxın 'rate (lag)', partiyalar üzrə bölgü (skew).

3. Brokeri yoxlayın (ISR, under-replicated, network).

Fəaliyyət:

+ N consumer-replicas artırmaq, max-in-flight qaldırmaq.
«Kritik topiklər» üçün prioritet hovuzu daxil edin.
Müvəqqəti ikincil emal/enrichment tezliyini azaltmaq.
Əgər 'ASG at max' - buluddan müvəqqəti uplift tələb edin; paralel - ağır funksiyaların deqradasiyasını daxil edin.
Geri qaytarma: 'lag <1 milyon' 15 dəqiqədən sonra «normal trafik» profilinə qayıdın.
Eskalasiya: Kafka klasterinin sahibi, sonra SRE platforması.

16) KPI və siqnalların keyfiyyəti

Coverage: Tanker alertləri ilə örtülmüş kritik yolların% -i.
Noise/Signal: on-call/həftədə ən çox 1 saxta peyj.
MTTD/MTTR: SLO zərbələrindən ≤ 5 dəqiqə əvvəl tutumlu insidentlər aşkar edilir.
Proactive saves: qarşısı alınan hadisələrin sayı (postmortemlər üzrə).

17) Sürətli başlanğıc (konservativ defoltlar)

BD: 75% konnektlərin/IOPS/lat xəbərdarlığı; krit 85%, histerezis 8-10 pp.
Caches: 'hit <0. 9 'I' evictions> 0 '> 5 dəq - xəbərdarlıq;' used _ mem> 85% '- krit.
Növbələr: 'lag' artım> 3 σ orta 30d + 'hpa at max' - girit.
API: `p99 > SLO1. 3 '10 min - xəbərdarlıq;' burn-rate> 4 '15 min - krit.
Provayderlər: 'throughput> 90% kvota' - xəbərdarlıq; 'timeouts> 5%' - krit.

18) FAQ

Q: Niyə sadəcə «CPU> 80%»?
A: latency/növbə konteksti olmadan səs-küy var. CPU özü riskə bərabər deyil.

Q: Adaptiv eşiklər lazımdır?
A: Bəli, gündəlik/həftəlik mövsümlük üçün - yanlış işləmələri azaldır.

Q: Marketinq/tədbirləri necə nəzərə almaq olar?
A: Kampaniya təqvimi → qrafiklərdəki izahlar + anti-səs müvəqqəti tənzimlənməsi, lakin SLO alertləri toxunmur.