Операції та Управління → Алерти по ємності систем

Алерти по ємності систем

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

Saturation по воркерам/ворк-пулу, черга запитів, 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 на вузлах/подах/ASG.
HPA/VPA події, pending pods, контейнерні OOM/Throttling.

5) Типи ємнісних алертів

1. Статичні пороги

Прості і зрозумілі: `db_connections > 80% max`. Гарні як «сигнал-маяк».

2. Адаптивні (динамічні) пороги

Базуються на сезонності і тренді (rolling windows, STL-декомпозиція). Дозволяють ловити «незвично високо для цієї години/дня тижня».

3. SLO-орієнтовані (burn-rate)

Спрацьовують, коли швидкість проїдання error-budget поставить під удар SLO в горизонті X годин.

4. Прогностичні (forecast-alerts)

«Через 20 хвилин при поточному тренді черга досягне 90%». Використовують лінійний/Robust/Prophet-подібний прогноз на коротких вікнах.

5. Складені (multi-signal)

Тригеррят при комбінації: 'queue _ lag ↑'+'consumer _ cpu 85%'+'autoscaling at max'→ «потрібна ручна інтервенція».

6) Порогові політики і анти-шум

• Вгору: попередження 70-75%, крит 85-90%. Вниз: гістерезис 5-10 п.п. Щоб не «пиляти по порогу».

• `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-підхід і бізнес-пріоритет

Від сигналу до впливу на бізнес: алерти по ємності повинні посилатися на 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 хв.

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: не більше 1 помилкового пейджу на on-call/тиждень.
MTTD/MTTR: ємнісні інциденти детектуються за ≤5 хв до SLO-ударів.
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: Чи потрібні адаптивні пороги?
A: Так, для добової/тижневої сезонності - знижують помилкові спрацьовування.

Q: Як враховувати маркетинг/івенти?
A: Календар кампаній → анотації на графіках + тимчасове коригування анти-шуму, але SLO-алерти не чіпати.