Операции и Управление → Алерты по емкости систем

Алерты по емкости систем

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, запросы/сек, лимиты провайдера.

Внешние провайдеры (платежи/KYC/провайдеры игр)

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-алерты не трогать.