Операциялар және басқару → Жүйелердің сыйымдылығы бойынша алерттар

Жүйелердің сыйымдылығы бойынша

1) Бұл не үшін қажет

Сыйымды алаңдар оқиғаға дейін техникалық лимиттерге жақындағаны туралы ескертеді: «біз төбеден 80% -ға жақындадық - масштабталатын кез келді». Азық-түлік бизнесі үшін бұл тікелей ақша туралы: өткізілген мөлшерлемелер/депозиттер, сессиялардың дропы, live-ойындардың кешігуі және провайдерлердің істен шығуы = жоғалған түсім, бедел, айыппұлдар мен қайтарымдар.

Мақсаттары:

Ең жоғары жүктемелерге (іс-шаралар, турнирлер, стримдер, үлкен науқандар) шыдауға болады.
Авто-скейлингті уақытында қосу және capacity uplift бағдарламасын жоспарлау.
SLO/ақша қаупі төнген кезде шуды азайтып, «іс бойынша» ояту.
Runbook арқылы инженерлерге нақты ұсыныстар беру.

2) Базалық ұғымдар

Сыйымдылық (Capacity): барынша тұрақты өткізу қабілеті (RPS/TPS, коннектілер, IOPS, throughput).
Headroom: ағымдағы жүктеме мен лимиттер арасындағы қор.
SLO/SLA: қол жетімділік/жауап беру уақытының мақсатты деңгейлері; алерталар «SLO-aware» болуы тиіс.
Burn-rate: «жағу» жылдамдығы SLO-бюджет қателер/жасырын.
High/Low Watermark: іске қосылу және авто қалпына келтіру үшін жоғарғы/төменгі деңгейлер.

3) Сигналдар архитектурасы және деректер көздері

Телееметрия: метрика (Prometheus/OTel), логи (ELK/ClickHouse), трассировка (OTel/Jaeger).
Қабаттық тәсіл: қабаттар бойынша алерталар (Edge → API → бизнес-сервистер → кезектер/ағымдар → ДБ/кэштер → файлдық/объектілік сақтау орындары → сыртқы провайдерлер).
Контекст: фичефлагтар, релиздер, маркетинг науқандары, турнирлер, гео-орналасу.
Инцидент-шина: Alertmanager/PagerDuty/Opsgenie/Slack; runbook және эскалация матрицасына байланыстыру.

4) Қабаттар бойынша негізгі метриктер (не мониторинг және не үшін)

Edge / L7

RPS, 95-/99-перцентиль latency, error rate (5xx/4xx), open connections.
Rate-limits/quotas, drops на CDN/WAF/Firewall.

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

Worker/Work-Pool бойынша Saturation, сұраулар кезегі, downstream timeouts.
Тозу үлесі (fallbacks, circuit-breakers).

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

Lag/consumer delay, backlog growth rate, throughput (msg/s, MB/s).
Partition skew, rebalancing churn, ISR (Kafka үшін), ретраи/атасы-лейтер.

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

Тапсырмаларды күту уақыты, кезек ұзындығы, мерзімі өткен SLA тапсырмалар пайызы.
Пулдарда Saturation 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, ретрайлер кезегі, «cost per call».

Инфрақұрылым

CPU/Memory/FD/IOPS/Network saturation.
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) Шекті саясат және шуға қарсы

High/Low Watermark:

Жоғары: ескерту 70-75%, крит 85-90%. Төмен: гистерезис 5-10 п.т. «Табалдырықтан кесу» үшін.

Уақытша терезелер мен басу:

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

Оқиғалар топтамасы:

Тосын оқиғалар карточкасын көбейтпеу үшін сервис/кластер/гео бойынша топтау.

Dependency-aware suppression:

Егер 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%"}

Kafka lag + авто-скейлинг шегінде:


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 жасырындылығы):


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

Redis жады және эвикшендер:


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-тәсіл және бизнес-басымдық

Дабылдан бизнеске әсерге: сыйымдылығы бойынша алерттар risk to SLO-ға (нақты ойындар/гео/метриктер GGR, депозит конверсиясы) сілтеме жасауға тиіс.
Көп деңгейлік: on-call сервисі үшін ескертулер; крит - домен иесінің пейдж; SLO-құлау - мажорлық оқиға және командалық «жиынтық» арна.
Тозу фичефлагтары: жүктемені автоматты түрде төмендету (ішінара read-only, ауыр фичтерді қысқарту, джекпот-бродкастардың жиілігін төмендету, live-ойындардағы «ауыр» анимацияларды сөндіру).

9) Авто-скейлинг және «дұрыс» триггерлер

HPA/VPA: тек CPU/Memory бойынша ғана емес, бизнес-метриктер бойынша да таргет (RPS, queue lag, p99 latency).
Warm-up таймингтер: суық бастау мен провайдердің лимиттерін ескеру (ASG spin-up, контейнерлік билдер, кэштерді жылыту).
Guardrails: қателердің көшкін тәрізді өсуі кезінде тоқтау шарттары; «скейлим проблемасынан» қорғау.
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 жоқ алерт: нақты әрекетсіз пейдж on-call-ды жұтады.
Провайдерлерге соқырлық: сыртқы квоталар/лимиттер сценарийлерді бірінші болып «бұзады» (PSP, KYC, антифрод, ойын провайдерлері).
Гистерезис жоқ: 80 %/79% шекарасында «кесу».

12) iGaming/қаржы платформаларының ерекшеліктері

Кесте бойынша шыңдар: прайм-тайм, турнирлердің финалдары, ірі матчтар; мақсатты репликаларды алдын ала арттыру және кэштерді толтыру.
Live-стримдер мен джекпоттар: кең хабар тарату іс-шараларының жарылыстары → брокерлер/вебсокеттердегі лимиттер.
Төлемдер және KYC: провайдерлердің терезелері, антифрод-скоринг; қосымша бағыттарды және депозиттердің «grace-режимін» сақтау.
Гео-баланс: провайдердің жергілікті сәтсіздіктері - трафикті headroom бар көрші аймаққа апару.
Жауапкершілік: ставкаларды/джекпоттарды жоғалту тәуекелі кезінде - домендік команданың жедел пейдж + бизнес-құлақтандыру.

13) Дашбордтар (ең аз жиынтық)

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

14) Енгізу чек-парағы

«Шынайы» лимиттер мен иелерінің тізбесі.
Метрик-болжамдар картасы + қабаттар арасындағы байланыс.
Статикалық табалдырықтар + гистерезис.
SLO-burn-сыни жолдарға алерталар (депозит, мөлшерлеме, live-ойынды іске қосу).
Кезектегі болжамды алерталар/ағындар/коннектілер.
Терезенің Suppression/maintenance; саясатқа қарсы шу.
Runbook 'және пәрмендері, кестелері, деградация фичефлагтары.
Жалған іске қосылуларды апта сайын талдау және тюнинг.
Маркетингтік науқандар мен іс-шаралар күнтізбесін есепке алу.

15) Runbook үлгісінің үлгісі (қысқаша)

'StreamBacklogAtRisk' сигналы

Мақсаты: lag> 10 млн-ның өсуіне және өңдеудің кешігуіне жол бермеу> 5 минут.

Диагностика (3-5 мин):

1. Бағандарда 'hpa _ desired/max', throttle/oom дегенді тексеру.

2. Қараңыз 'rate (lag)', партия бойынша таратылу (skew).

3. Брокерді тексеру (ISR, under-replicated, network).

Әрекеттер:

consumer-replicas + N ұлғайту, 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: Алдын алынған оқыс оқиғалар саны (постмортемалар бойынша).

17) Жылдам бастау (консервативті дефолттар)

БД: 75% коннектердің алдын алу/IOPS/lat; крит 85%, гистерезис 8-10 п.т.
Кэштер: 'hit <0. 9 'И' evictions> 0 '> 5 мин - ескерту;' used _ mem> 85% '- крит.
Кезектер: 'lag' өсу> 3 σ орташадан 30д + '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: Бейімделетін табалдырықтар қажет пе?
А: Иә, тәуліктік/апталық маусымдық үшін - жалған іске қосылуларды төмендетеді.

Q: Маркетинг/іс-шараларды қалай ескеруге болады?
A: Кампаниялар күнтізбесі → графиктегі аңдатпалар + шуға қарсы уақытша түзету, бірақ SLO алертіне тиіспеңіз.