Операциялар жана башкаруу → Системалардын сыйымдуулугу боюнча алерттар

Системалардын сыйымдуулугу боюнча алерттар

1) Эмне үчүн керек

Сыйымдуулуктагы алерталар окуяга чейин эле техникалык лимиттерге жакындап калганын эскертишет: "Биз шыптын 80% га жакындап калганбыз - масштабдоого убакыт келди". Азык-түлүк бизнеси үчүн бул түздөн-түз акча жөнүндө: өткөрүлгөн тарифтер/депозиттер, сессиялардын тамчылары, live-оюндардын кечигүүлөрү жана провайдерлердин ийгиликсиздиктери = жоголгон киреше, репутация, айыптар жана кайтарымдар.

• Эң жогорку жүктөрдү (иш-чаралар, турнирлер, агымдар, чоң кампаниялар) күтүүгө болот.
• Өз убагында авто скейлинг киргизүү жана capacity uplift пландаштыруу.
• SLO/акча тобокелге салып жатканда ызы-чууну азайтуу жана "бизнес" ойготуу.
• Runbook аркылуу инженерлерге так сунуштарды берүү.

2) Негизги түшүнүктөр

кубаттуулугу (Capacity): максималдуу туруктуу кубаттуулугу (RPS/TPS, байланыштар, IOPS, throughput).
Headroom: учурдагы жүк менен чектердин ортосундагы запас.
SLO/SLA: максаттуу жеткиликтүүлүк/жооп убактысы; Алерталар "SLO-aware" болушу керек.
Burn-rate: ылдамдыгы "өрттөп" SLO-бюджет каталар/жашыруун.
High/Low Watermark: жогорку/төмөнкү баскычтары жана auto калыбына келтирүү үчүн.

3) Архитектура сигналдар жана маалымат булактары

Телееметрия: метрика (Prometheus/OTel), Логи (ELK/ClickHouse), Tracking (OTel/Jaeger).
Катмарлуу мамиле: катмарларга алерталар (Edge → API → бизнес кызматтары → кезектер/агымдар → DD/кэштер → файлдык/объекттик сактагычтар → тышкы провайдерлер).
Контекст: phicheflages, релиздер, маркетинг кампаниялары, турнирлер, гео-макет.
Жол кырсыгы: Alertmanager/PagerDuty/Opsgenie/Slack; runbook жана эскалация матрицасына байлоо.

4) Негизги катмарларды өлчөө (эмне мониторинг жана эмне үчүн)

Edge / L7

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

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

Worker/Work-Pool боюнча Saturation, суроо-талап кезеги, downstream үчүн убакыт.
Деградациянын үлүшү (fallbacks, circuit-breakers).

Кезектер/Стриминг (Kafka/Rabbit/Pulsar)

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (Kafka үчүн), ретра/чоң ата-лейтер.

Асинхрондук воркерлер

Милдеттерди күтүү убактысы, кезектин узундугу, мөөнөтү өтүп кеткен SLA милдеттеринин пайызы.
Pool боюнча CPU/Memory/FD Сатуранс.

Кэш (Redis/Memcached)

Hit ratio, latency, evictions, used memory, туташтырылган кардарлар/ops/s.
Кластерлер: уячалар/репликалар, failover events.

БД (PostgreSQL/MySQL/ClickHouse)

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

Объект/файл сактоо

PUT/GET latency, 4xx/5xx, egress, суроолор/сек, провайдер лимиттери.

Тышкы провайдерлер (төлөмдөр/КУС/оюн провайдерлери)

TPS чеги, QPS терезелер, error rate/timeout, кезек retrains, "cost per call".

Инфраструктура

CPU/Memory/FD/IOPS/түйүндөрүндө тармак сатурациясы/ASG.
HPA/VPA окуялар, pending pods, контейнер OOM/Throttling.

5) Сыйымдуулуктун түрлөрү

1. Статикалык босоголор

Жөнөкөй жана түшүнүктүү: 'db _ connections> 80% max'. "Сигнал-маяк" сыяктуу жакшы.

2. Адаптивдүү (динамикалык) босоголор

Алар сезондук жана тенденцияга (rolling windows, STL-декомпозиция) негизделген. Алар "жуманын бул саат/күнү үчүн адаттан тыш жогору" кармоого мүмкүндүк берет.

3. SLO багытталган (burn-rate)

error-budget жеп ылдамдыгы X саат горизонт SLO сокку качан иштейт.

4. Прогностикалык (forecast-alerts)

"Учурдагы тренд менен 20 мүнөттөн кийин кезек 90% га жетет". Кыска терезелерде сызыктуу/Robust/Prophet окшош божомолду колдонушат.

5. Компоненттер (multi-signal)

'queue _ lag ↑' + 'consumer _ cpu 85%' + 'autoscaling at max' → "кол менен интервенция керек".

6) Босого саясаты жана анти-ызы

• Жогору: эскертүү 70-75%, крит 85-90%. Төмөн: histeresis 5-10 p.p. эмес, "эшикти кесип".

• 'for: 5m' критиктер үчүн, 'for: 10-15m' эскертүүлөр үчүн. Night-mode: пейджингсиз чатта сындуу эмес роутинг.

• Окуя карталарын көбөйтпөө үчүн кызмат/кластер/гео боюнча топтоо.

• Эгерде KYC провайдери аутто жана API каталарынын натыйжасы бардык керектөөчүлөрдүн эмес, интеграциянын ээсинин пейджим.

• Акциялар учурунда "күтүлгөн өсүш" үчүн ызы-чуунун босогосун жогорулатуу, бирок SLO-алерттерди тийбеген бойдон калтыруу.

7) Эрежелердин мисалдары (псевдо-Prometheus)

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

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

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

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

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-мамиле жана бизнес артыкчылыктуу

бизнеске таасир сигнал From: дараметин Алерта SLO (белгилүү оюндар/гео/GGR метрика, депозиттик которуу) үчүн тобокелге шилтеме керек.
Көп баскычтуу: on-call кызматы үчүн эскертүү; крит - домен ээсинин пейдж; SLO-күзүндө - негизги окуя жана командалык "бириктирилген" канал.
Ficheflags деградация: жүктү автоматтык түрдө азайтуу (жарым-жартылай read-only, оор чектерди кыскартуу, джекпот-бродкастардын жыштыгын азайтуу, жандуу оюндарда "оор" анимацияларды өчүрүү).

9) Авто-скейлинг жана "туура" триггерлер

HPA/VPA: максаттуу гана CPU/Memory эмес, ошондой эле бизнес-метрика (RPS, queue lag, p99 latency).
Warm-up таймингдер: муздак баштоо жана провайдердин лимиттерин эске алуу (ASG spin-up, контейнер билдери, кэш жылытуу).
Guardrails: көчкү каталардын өсүшү менен токтоо шарттары; "skeilim көйгөйүнө" каршы коргоо.
Capacity-playbooks: кайда жана кантип кошуу үчүн шард/партия/реплика, региондор боюнча жол бөлүштүрүүгө кантип.

10) Процесс: долбоорлоодон ишке чейин

1. Картага лимиттерди: ар бир катмар боюнча "чыныгы" bottleneck-лимиттерди чогултуу (max conns, IOPS, TPS, провайдерлердин quotas).
2. Метрик-алдын ала тандоо: кандай сигналдар баарынан мурда "N мүнөттөн кийин жыгылабыз".
3. Босоголордун дизайны: high/low + SLO-burn + курама.
4. Runbook ар бир крит боюнча: диагностикалык кадамдар ("ачуу үчүн", "кандай команда", "эскалациялоо үчүн"), үч иш-аракеттер: тез айланып өтүү, масштабдоо, деградация.
5. Сыноо: жүк симуляциялары (chaos/game days), "кургак учуруулар", ызы-чууга каршы текшерүү.
6. Ревью жана асырап алуу: сигналдын ээси = сервистин ээси. ээси жок - эч кандай пейдж.
7. Ретроспективалар жана тюнинг: жалган/өткөрүлбөгөн жумалык талдоо; метрика "MTTA (ack), MTTD, MTTR, Noise/Signal ratio".

11) Анти-үлгүлөрү

CPU> 90% ⇒ паника: latency/queues менен эч кандай байланышы жок, бул нормалдуу болушу мүмкүн.
"Бардыгы үчүн бир босого": ар кандай аймактар/убакыт зоналары - ар кандай трафик профилдери.
Runbook жок Alert: так иш-аракет жок пейдж on-call чарчайт.
Провайдерлерге сокур болуу: тышкы квоталар/лимиттер көбүнчө биринчи "бузулган" сценарийлер (PSP, KYC, антифрод, оюн провайдерлери).
Гистерезис жок: 80 %/79% чегинде "кесүү".

12) iGaming/каржы аянтчалары өзгөчөлүктөрү

График боюнча чокулар: прайм-тайм, турнирлердин финалдары, чоң матчтар; алдын ала максаттуу репликаларды жогорулатуу жана кэштерди толтуруу.
Live стримдер жана джекпот: жайылтуучу иш-чаралардын жарылуусу → брокерлер/вебсокеттердеги лимиттер.
Төлөмдөр жана KYC: терезелер провайдерлер, анти-жол-эсеби; запастык маршруттарын жана "грейс-режими" депозиттерин сактоо.
Гео-балансы: жергиликтүү провайдердин ийгиликсиздиктери - трафикти кошуна аймакка алып баруу, ал жерде headroom бар.
Жоопкерчилик: коюмдарды/джекпотторду жоготуу коркунучу болгондо - домендик команданын тез пейдж + бизнес-эскертүү.

13) Dashboard (минималдуу топтому)

Capacity Overview: катмарлары боюнча headroom, жогорку 3 тобокелдик сайттар, burn-rate SLO.
Stream & Queues: lag, backlog growth, consumer saturation, HPA state.
DB & Cache: connections, repl-lag, p95/p99 latency, hit ratio, evictions.
Providers: TPS/терезелер/квоталар, timeouts/errors, чалуулардын баасы.
Release/Feature context: релиздер/ийри жакын phicheflages.

14) Киргизүү чек-тизмеси

• "Чыныгы" лимиттердин жана ээлеринин тизмеси.
• Метрикалык алдын ала карта + катмарларынын ортосундагы байланыш.
• Статикалык босоголор + гистерезис.
• SLO-BURN-Алерт маанилүү жолдор боюнча (депозиттик, коюм, жандуу оюндарды ишке киргизүү).
• Кезектеги прогностикалык коркунучтар/агымдар/коннектилер.
• Suppression/maintenance терезелер; каршы ызы-чуу саясаты.
• Runbook 'жана командалар, графиктер, деградация phicheflags менен.
• Жумалык талдоо жалган жана тюнинг.
• Маркетинг кампанияларын жана иш-чаралардын календарын эсепке алуу.

15) Runbook үлгү мисал (кыскартылган)

Сигнал: 'StreamBacklogAtRisk'

Максаты: lag өсүшүнө жол бербөө> 10 миллион жана дарылоо кечигүү> 5 мин.

1. Текшерүү 'hpa _ desired/max', тамак-жылы throttle/oom.

2. Көрүү 'rate (lag)', партия боюнча бөлүштүрүү (skew).

3. Текшерүү брокер (ISR, under-replicated, network).

• + N боюнча consumer-replicas жогорулатуу, max-in-flight жогорулатуу.
• "Критикалык топиктер" үчүн артыкчылыктуу бассейнди киргизүү.
• Убактылуу кайра иштетүү/enrichment жыштыгын азайтуу.
• Эгер 'ASG at max' - булуттан убактылуу uplift сурап; параллель - оор функциялардын деградациясын камтыйт.
• Артка кайтаруу: "кадимки трафик" профилине кайтып келүү 'lag <1 млн' 15 мүнөттөн кийин.
• Эскалация: Kafka кластеринин ээси, андан кийин SRE платформасы.

16) KPI жана сигналдардын сапаты

Coverage: Сыйымдуулуктагы алерталар менен жабылган критикалык жолдордун%.
Noise/Signal: on-call/жумага 1 жалган пейдж ашык эмес.
MTTD/MTTR: сыйымдуулугу окуялар SLO сокку чейин ≤ 5 мүнөт аныкталат.
Proactive saves: алдын инциденттердин саны (postmortems боюнча).

17) Тез баштоо (эскичил демейки)

БД: эскертүү 75% коннектилер/IOPS/lat; крит 85%, гистерезис 8-10 п.п.
Кэш: 'hit <0. 9 'I' evictions> 0 '> 5 мин - эскертүү;' used _ mem> 85% '- крит.
кезек: 'lag' өсүү> 3 σ орто 30d + 'hpa at max' - крит.
API: `p99 > SLO1. 3 '10 мин - эскертүү;' burn-rate> 4 '15 мин - крит.
Провайдерлер: 'throughput> 90% квота' - эскертүү; 'timeouts> 5%' - крит.

18) FAQ

Q: Эмне үчүн жөн эле "CPU> 80%"?
A: latency контекстинде жок/кезек ызы-чуу болуп саналат. CPU өзү тобокелге барабар эмес.

Q: Адаптивдүү босоголор керекпи?
A: Ооба, күнүмдүк/жумалык сезондук үчүн - жалган аткарууну азайтат.

Q: Кантип маркетинг/иш-чараларды эске алуу керек?
A: үгүт календары → графиктеги түшүндүрмөлөр + ызы-чууга каршы убактылуу тууралоо, бирок SLO алерталары тийбейт.