Tizimlar sig’imi bo’yicha operatsiyalar va boshqaruv → Alertlar

Tizimlarning sig’imi bo’yicha alertlar

1) Nima uchun bu zarur?

Sig’imli alertlar voqea sodir bo’lishidan ancha oldin texnik chegaralarga yaqinlashishi haqida ogohlantirmoqda: «Biz shiftning 80 foizini kengaytirish vaqti keldi». Oziq-ovqat biznesi uchun bu to’g’ridan-to’g’ri pul to’g’risida: o’tkazib yuborilgan stavkalar/depozitlar, sessiyalarning to’kilishi, live-o’yinlarning kechikishi va provayderlarning rad etilishi = yo’qotilgan daromad, obro’, jarima va qaytarmalar.

Maqsadlar:

Eng yuqori yuklarga (tadbirlar, turnirlar, oqimlar, katta kampaniyalar) chidash mumkin.
Avtomatik skeylingni oʻz vaqtida yoqish va capacity uplift dasturini rejalashtirish.
SLO/pul xavfi bo’lganda shovqinni kamaytirish va «ish bo’yicha» uyg’otish.
Runbook orqali muhandislarga aniq tavsiyalar berish.

2) Bazaviy tushunchalar

Sig’imi (Capacity): maksimal barqaror o’tkazish qobiliyati (RPS/TPS, konnektlar, IOPS, throughput).
Headroom: joriy yuk va limitlar orasidagi zaxira.
SLO/SLA: foydalanish/javob berish vaqtining maqsadli darajalari; alertlar «SLO-aware» bo’lishi kerak.
Burn-rate: SLO-byudjetdagi xato/yashirin «yoqish» tezligi.
High/Low Watermark: ishga tushirish va avto tiklash uchun yuqori/pastki darajalar.

3) Signallar arxitekturasi va ma’lumotlar manbalari

Teleemetriya: metrika (Prometheus/OTel), logi (ELK/ClickHouse), trastirovka (OTel/Jaeger).
Qatlamli yondashuv: qatlamlar bo’yicha alertlar (Edge → API → biznes-servislar → navbatlar/oqimlar → DB/keshlar → fayl/obyekt saqlovchilari → tashqi provayderlar).
Kontekst: fitnalar, relizlar, marketing kampaniyalari, turnirlar, geo-nizom.
Hodisa-shina: Alertmanager/PagerDuty/Opsgenie/Slack; runbook va eskalatsiya matritsasiga bogʻlash.

4) Qatlamlar bo’yicha asosiy metriklar (nimani va nima uchun monitoring qilish kerak)

Edge / L7

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

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

Vorkerlar/vork-pullar bo’yicha saturation, so’rovlar navbati, daunstrimlarga timeouts.
Degradatsiya ulushi (fallbacks, circuit-breakers).

Navbatlar/Striming (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (Kafka uchun), retrai/ded-leyter.

Asinxron vorkerlar

Vazifalarni kutish vaqti, navbat uzunligi, muddati oʻtgan SLA vazifalari foizi.
Pullarda Saturation CPU/Memory/FD.

Keshlar (Redis/Memcached)

Hit ratio, latency, evictions, used memory, ulangan mijozlar/ops/s.
Klaster: slotlar/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 ombori

PUT/GET latency, 4xx/5xx, egress, so’rovlar/sek, provayder limitlari.

Tashqi provayderlar (to’lovlar/KTS/o’yinlar provayderlari)

TPS limitlari, QPS derazalar, error rate/timeout, retraylar navbati, «cost per call».

Infratuzilma

CPU/Memory/FD/IOPS/Network saturation uzel/pod/ASG.
HPA/VPA hodisalar, pending pods, konteyner OOM/Throttling.

5) Sig’imli alertlar turlari

1. Statik chegaralar

Oddiy va tushunarli:’db _ connections> 80% max’. «Mayoq-signal» kabi yaxshi.

2. Adaptiv (dinamik) chegaralar

Mavsumiylik va trendga asoslanadi (rolling windows, STL-dekompozisiya). «Haftaning shu soati/kuni uchun gʻayrioddiy darajada baland» tutishga imkon beradi.

3. SLO yoʻnaltirilgan (burn-rate)

Error-budget ovqatlanish tezligi X soat ufqida SLOga ta’sir qilganda ishga tushadi.

4. Prognostik (forecast-alerts)

«20 daqiqadan so’ng joriy tendentsiyada navbat 90 foizga etadi». Qisqa oynalarda chiziqli/Robust/Prophet kabi prognozlardan foydalaniladi.

5. Kompozit (multi-signal)

’queue _ lag ↑’ +’consumer _ cpu 85%’+’autoscaling at max’→’qo’l intervensiyasi kerak.

6) Chegara siyosati va shovqinga qarshi

High/Low Watermark:

Yuqoriga: ogohlantirish 70-75%, krit 85-90%. Pastga: gisterezis 5-10 p.p. «Eshikni teshmaslik» uchun.

Vaqtinchalik oynalar va bostirishlar:

’for: 5m’ kritlar uchun,’for: 10-15m’ogohlantirishlar uchun. Night-mode: Noto’g’ri chatni payjingsiz o’tkazish.

Hodisalarni guruhlash:

Hodisa kartalarini koʻpaytirmaslik uchun server/klaster/geo boʻyicha guruhlash.

Dependency-aware suppression:

Agar KYC provayderi autda bo’lsa va API xatolari barcha iste’molchilarning emas, balki integratsiya egasining peyjimidir.

Vaqtinchalik marketing oynalari:

Aksiyalar davrida «kutilayotgan o’sish» uchun shovqin chegaralarini ko’taring, lekin SLO-alertlarni tegmagan holda qoldiring.

7) Qoidalar namunalari (psevdo-Prometheus)

BD konnektlari:


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 + avto-skeyling chegarasida:


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 latentligi):


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

Redis xotira va evikshenlar:


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

To’lovlar provayderi - limitlar:


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 yondashuvi va biznes ustuvorligi

Signaldan biznesga ta’sirga: sig’imi bo’yicha alertlar risk to SLO (aniq o’yinlar/geo/GGR metrikalari, depozit konvertatsiyasi) ga murojaat qilishlari kerak.
Ko’p darajali: on-call servis uchun ogohlantirishlar; krit - domen egasining peyji; SLO - major hodisasi va jamoaviy «yig’ma» kanal.
Buzilish ficheflaglari: yuklamani avtomatik ravishda kamaytirish (qisman read-only, og’ir fichlarni qisqartirish, jekpot-brodkastlarning chastotasini kamaytirish, jonli o’yinlarda «og’ir» animatsiyalarni o’chirish).

9) Avto-skeyling va "to’g" ri "triggerlar

HPA/VPA: target nafaqat CPU/Memory, balki biznes-metrik (RPS, queue lag, p99 latency).
Warm-up tayminglar: sovuqni boshlash va provayder limitlarini hisobga olish (ASG spin-up, konteyner bilderlari, keshlarni isitish).
Guardrails: xatolar ko’chki ko’payganda to’xtash shartlari; «skeylim muammosidan» himoya qilish.
Capacity-playbooks: shard/partiyani/replikani qayerda va qanday qo’shish, trafikni mintaqalar bo’yicha qayta taqsimlash.

10) Jarayon: loyihalashdan foydalanishgacha

1. Limitlarni xaritalash: har bir qatlam (max conns, IOPS, TPS, quotas provayderlar) bo’yicha «haqiqiy» bottleneck-limitlarni yig’ish.
2. Metrik-bashoratlarni tanlash: «N daqiqadan so’ng yiqilib tushaman» degan signallar.
3. Ostonalar dizayni: high/low + SLO-burn + kompozit.
4. Har bir krit uchun Runbook: diagnostika qadamlari («nima ochish kerak», «qanday buyruqlar», «qayerda eskalatsiya qilish kerak»), uchta harakat varianti: tez aylanish, kattalashtirish, degradatsiya.
5. Test: yuklamalarni simulyatsiya qilish (chaos/game days), alertlarni «quruq ishga tushirish», shovqinga qarshi tekshirish.
6. Revyu va farzandlikka olish: signal egasi = servis egasi. Egasiz page yoʻq.
7. Retrospektivlar va tyuning: yolg’on/o’tkazib yuborilganlarni har haftalik tahlil qilish; «MTTA (ack), MTTD, MTTR, Noise/Signal ratio» metrikasi.

11) Anti-patternlar

CPU> 90% ⇒ vahima: latency/queues bilan bog’lanmasdan, bu normal bo’lishi mumkin.
«Hamma uchun bitta chegara»: turli mintaqalar/taym-zonalar - turli trafik profillari.
Runbook’siz alert: aniq harakatsiz peyj on-call’ni tugatadi.
Provayderlarga nisbatan ko’rlik: tashqi kvotalar/limitlar ko’pincha ssenariylarni birinchi bo’lib «buzadi» (PSP, KYC, antifrod, o’yin provayderlari).
Histerezis yo’q: 80 %/79% chegarada «kesish».

12) iGaming/moliyaviy platformalarning xususiyatlari

Jadval bo’yicha cho’qqilar: praym-taym, turnirlar finali, yirik o’yinlar; maqsadli replikalarni oldindan oshirish va keshlarni to’ldirish.
Live-oqimlar va jekpotlar: brokerlar/vebsoketlarda keng ko’lamli tadbirlar → limitlar portlashi.
To’lovlar va KYC: provayderlar oynalari, antifrod-skoring; zaxira yo’nalishlarni va depozitlarning «grace-rejimi» ni saqlab turish.
Geo-balans: provayderning mahalliy muvaffaqiyatsizliklari - trafikni headroom mavjud bo’lgan qo’shni mintaqaga olib borish.
Mas’uliyat: stavkalarni/jekpotlarni yo’qotish xavfi bo’lganda - domen buyrug’i uchun tezkor peyj + biznes-ogohlantirish.

13) Dashbordlar (minimal to’plam)

Capacity Overview: qatlamlar bo’yicha headroom, 3 ta xavfli uchastka, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: konnektlar, repl-lag, p95/p99 latency, hit ratio, evictions.
Providers: TPS/oyna/kvotalar, timeouts/errors, qoʻngʻiroqlar qiymati.
Release/Feature context: egri chiziqlar yonidagi relizlar/ficheflaglar.

14) Joriy etish chek-varaqasi

«Haqiqiy» limitlar va egalar ro’yxati.
Metrik bashorat xaritasi + qatlamlar orasidagi aloqalar.
Statik chegaralar + gisterezis.
SLO-burn-alertlar tanqidiy yo’llarda (depozit, stavka, jonli o’yinni boshlash).
Prognostik alertlar navbatda/oqimlar/konnektlar.
Suppression/maintenance; siyosatning shovqiniga qarshi.
Runbook’va buyruqlar, grafiklar, degradatsiya ficheflaglari.
Yolg’on ishlanmalarni har hafta tahlil qilish va sozlash.
Marketing kampaniyalari va tadbirlar taqvimini hisobga olish.

15) Runbook namunasi (qisqartirilgan)

Signal: ’StreamBacklogAtRisk ’

Maqsad: lag> 10 mln.

Diagnostika (3-5 daqiqa):

1. Pod’hpa _ desired/max’, throttle/oom’ni tekshirish.

2. ’rate (lag)’, partiyalar bo’yicha taqsimlanishini (skew) ko’rish.

3. Brokerni tekshirish (ISR, under-replicated, network).

Amallar:

consumer-replicas + N ga ko’paytirish, max-in-flight ko’tarish.
Ustuvor pulni «tanqidiy topiklar» ga kiritish.
Ikkilamchi ishlov berish chastotasini vaqtincha pasaytirish/enrichment.
Agar’ASG at max’bo’lmasa - bulutdan vaqtinchalik uplift so’rash; parallel ravishda - og’ir funksiyalarning tanazzulini kiritish.
Orqaga qaytish: «oddiy trafik» profiliga qaytish’lag <1 mln’15 daqiqadan keyin.
Eskalatsiya: Kafka klaster egasi, keyin SRE platformasi.

16) KPI va signallar sifati

Coverage: sig’imli alertlar bilan yopilgan og’ir yo’llar%.
Noise/Signal: on-call/haftada 1 tadan ko’p bo’lmagan soxta peyj.
MTTD/MTTR: sig’imli hodisalar SLO zarbalaridan ≤ 5 daqiqa oldin aniqlanadi.
Proactive saves: Oldini olingan hodisalar soni (postmortemalar bo’yicha).

17) Tez boshlash (konservativ defoltlar)

DQ: 75% konnektlarning oldini olish/IOPS/lat; krit 85%, gisterezis 8-10 p.p.
Kesh:’hit <0. 9’I’evictions> 0’> 5 min - ogohlantirish;’used _ mem> 85%’- krit.
Navbatlar:’lag’o’sish> O’rtachadan 3 σ 30d +’hpa at max’- krit.
API: `p99 > SLO1. 3’10 min - ogohlantirish;’burn-rate> 4’15 min - krit.
Provayderlar:’throughput> 90% kvota’- ogohlantirish;’timeouts> 5%’- krit.

18) FAQ

Q: Nega shunchaki «CPU> 80%» ni ololmaysiz?
A: latency/navbat kontekstisiz bu shovqin. CPU o’z-o’zidan xatarga teng emas.

Q: Moslashuvchan chegaralar kerakmi?
A: Ha, bir kunlik/bir haftalik mavsumiylik uchun - yolg’on ishlanmalarni kamaytiradi.

Q: Marketing/tadbirlarni qanday hisobga olish kerak?
A: Kampaniyalar taqvimi → grafiklardagi izohlar + shovqinga qarshi vaqtinchalik tuzatishlar, lekin SLO alertlariga tegmaslik.