Планирование мощностей

1) Что такое планирование мощностей и зачем оно нужно

Планирование мощностей (capacity planning) — это систематический процесс оценки и обеспечения ресурсов, необходимых для достижения целевых SLO при минимальной стоимости. Речь не только о CPU/памяти, но и о пропускной способности сетей, хранении, БД/кешах, очередях/шине событий, внешних провайдерах (платежи/KYC/антифрод), а также людских ресурсах (on-call, поддержка).

• Выполнять SLO/SLAs даже в пиках и деградациях.
• Минимизировать TCO и простой капитала (overprovisioning).
• Сократить риск инцидентов от исчерпания ресурсов (saturation → p99/ошибки).
• Обеспечить предсказуемость релизов и кампаний (маркетинг, турниры, топ-матчи).

2) Входные данные и источники истины

Наблюдаемость: RPS/конкаррентность, p50/p95/p99, error-rate, saturation (CPU, mem, disk IOPS, сетевые pps/mbps), длины очередей, rate лимитов.
Бизнес-события: календари кампаний, сезонность (вечера/выходные/мега-ивенты), регионы/юрисдикции.
Техдолг/фичи: roadmap релизов, архитектурные изменения (например, шифрование, новое логирование).
Провайдеры: квоты и throughput платежных/KYC/почтовых/антифрод сервисов.
Инциденты прошлого: где узкое место (БД, кеш, L7-балансировщик, шина, CDN, диск).

3) Базовые понятия и формулы

Headroom — запас по емкости: `headroom = (макс_устойчивый_RPS − фактический_RPS) / макс_устойчивый_RPS`.
Целевое значение в пике 20–40% (для критичных потоков).
Saturation — отношение занятого ресурса к доступному (CPU%, память/GC, соединения, file descriptors, IOPS, глубина очереди).
Throughput устойчивый — скорость, при которой p99 и error-rate выполняют SLO длительно (не разовый всплеск).
Capacity Unit (CU) — нормированная единица мощности для сервиса (например, X RPS на один pod vCPU=1, RAM=2 GiB).
Системный лимит — max без деградации: `N_pods × CU`. Важно учитывать shared зависимости (БД/кеш/шина).

4) Модель спроса: прогнозирование

Статистические ряды: недельная/суточная сезонность, праздники, спортивные финалы, региональные пики.
Когорты: по странам, платежным провайдерам, устройствам, VIP-сегментам.
Событийные дельты: влияние кампаний/пушей/релизов/SEO.
“Что если” (scenario planning): +50% к трафику в 19:00–22:00; выпадение провайдера A → перераспределение на B (+30% к латентности).
Real-time корректировки: nowcasting по лид-метрикам (оживление сессий, очередь на матч, корзины).

5) Модель предложения: где “ломается” цепочка

Конвейер запроса: Edge/CDN → L7-балансировщик → приложение → кеш → БД → внешние API → очередь/шина → обработчики/ETL.

• Емкость (CU/инстанс), масштабируемость (горизонт./вертик.), пределы (коннекты, pps, IOPS), запаздывания.
• Политики отказа (rate limit, circuit breaker, деградация).
• SLO локальные и их вклад в e2e-SLO.

6) Запас и бюджет ошибок

Привязываем headroom к error budget: меньше бюджета → больше запаса.
Для критичных потоков (оплата/верификация) — headroom выше, для второстепенных — ниже.
Холодные/теплые резервы: активируемые при пике/аварии.

7) Масштабирование: тактика

HPA (по метрикам нагрузки): RPS, latency, длина очереди, пользовательские SLIs (better than CPU%).
VPA: корректировка ресурсов подам (аккуратнее с stateful и p99 GC).
KEDA/адаптеры: масштабирование по внешним источникам (Kafka lag, Redis list length, CloudQueue depth).
Warm pools/прогрев: заранее поднятые инстансы, чтобы избежать холодного старта.
Подход “Load-as-Code”: политики автоскейла/лимитов/таймаутов/ретраев версионируются и проходят review.

8) Очереди, backpressure и управление хвостом

Цель — не допустить лавинообразного роста p99.
Ограничиваем параллелизм и размер очереди, вводим временные окна и идемпотентность.
Hedging/Retry-budget: ограничивать общий бюджет времени пользователя и системы.
Graceful degradation: отключение второстепенных фич при перегрузке.

9) БД, кеши и хранилище

БД: лимит коннектов, журналирование/FSync, индексы, план запросов, replica lag, hot-keys/таблицы, max TPS для транзакций.
Кеши: hit-ratio по сегментам, “шторм промахов” при релизе/инвалидции, распределение ключей.
Сторадж: IOPS/throughput, задержки, компрессия, TTL, очистка старых партиций/снапшотов.
Схема миграций: expand→migrate→contract без останавливающих блокировок.

10) Потоки событий и ETL

Kafka/шина: пропускная способность партиций, lag, ISR, compaction, лимиты продюсеров/консьюмеров.
ETL/батчи: окна запуска, бюджеты времени выполнения, влияние на прод-сторану (throttle I/O).
Идемпотентность и exactly-once-like для критичных флоу (платежи/балансы).

11) Сеть и периметр

L4/L7 балансировщики: connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge: пропускная, кэш-политика для снижения origin-нагрузки.
Внутрисетевые лимиты: pps/mbps в VPC/подсети, egress-стоимость (FinOps).

12) Мультирегион, DR и юрисдикции

Стратегии: active-active (GSLB/Anycast), active-passive (горячий/теплый/холодный DR).
N+1 по регионам: выдержать потерю AZ/региона при сохранении SLO core-потоков.
Юридическая локализация: разделение трафика/данных по странам, разные лимиты и SLO на провайдеров.
Тесты DR: регулярные game-days с реальным переносом нагрузки.

13) Внешние провайдеры: квоты и маршруты

Платежи/KYC/антифрод/почта/SMS: квоты TPS, burst, дневные лимиты.
Мульти-провайдер: маршрутизация по латентности/успеху, SLO per провайдер, авто-фейловер.
Контракты SLA: соответствие e2e-SLO, каналы эскалации, статус-вебхуки.

14) FinOps: стоимость и эффективность

TCO: compute + storage + network egress + лицензии/провайдеры + дежурства.
Unit Economics: стоимость 1k запросов/1 депозитной операции/1 KYC.
Оптимизация: right-sizing, spot/префиксные скидки, кэш-хитрейт, дедуп логов/трассировок, холодные уровни хранения.
Перенос нагрузки во времени: не критичные батчи в “ночные” окна и дешевые регионы.

15) Дашборды и отчетность (минимальный набор)

• Текущая нагрузка vs устойчивый throughput по звеньям.
• Headroom по сервисам и регионам; прогноз на 24/72 часа.
• KPI FinOps: $/1k запросов, $/депозит.

• Топ-узкие места (p99, saturation, lag), запас по DR.

• Успешность/латентность и лимиты провайдеров; доля трафика по маршрутам.

• План апгрейдов/индексов/оптимизаций, ожидаемая экономия/рост емкости.

16) Процессы и роли

RACI: Платформенная (инфра/кластера/балансировщики), БД/Данные (индексы, репликации), Сервисные команды (профилирование/кэш), SRE (SLO, алерты), Sec/Compliance (крипто/журналы), Финансы (бюджет).
Ритм: еженедельные capacity-review (дорожная карта, прогноз, риски), ежемесячные FinOps-сводки, ежеквартальные DR-тесты.
Change Management: крупные кампании/релизы проходят capacity-gate (чек-лист ниже).

17) Чек-лист выпуска и кампаний (capacity-gate)

• Прогноз нагрузки на пик и “+x% аварийный хвост”.
• Доступный headroom для core-потоков (платежи/KYC/логин).
• Провайдерам подтверждены квоты; альтернативные маршруты активны.
• HPA/KEDA пороги и warm-pool настроены.
• Очереди/лимиты и деградации проверены (плейбуки готовы).
• Канареечные доли и авто-откат включены.
• Дашборды/алерты (burn-rate, saturation, p99) проверены.
• План DR и контакты эскалаций актуальны.

18) Анти-паттерны

“CPU < 70% — все хорошо”: игнорирование пределов зависимостей (коннекты БД, IOPS, очереди).
Централизованный “черный ящик” без метрик per-звено — невозможно понять, где лимит.
Отсутствие кэш-стратегии — промахи при релизе убивают origin.
Хардкод лимитов ретраев без бюджетов — шторм запросов.
“Один провайдер платежей” — точка отказа на пике.
Игнорирование теплых резервов — холодный старт как причина инцидентов.
Нет периодических DR-тестов — план не работает, когда он нужен.

19) Мини-калькуляции (пример)

Сервис X: устойчиво 350 RPS на pod (vCPU=1, RAM=2 GiB). Цель — 5 000 RPS, headroom 25%.
Нужная мощность = `5000 / 0.75 = 6667 RPS`.
Подов = `ceil(6667 / 350) = 20`. Плюс warm-pool 15% → еще 3 pod.
БД: лимит 12k TPS, текущий кредит 9k TPS, прогноз пик 10.5k TPS → запас 1.5k (14%). Требуется: индексы/шардинг/реплики или кэширование для снижения до 8.5k.
Провайдер A (KYC): квота 120 rps, пик 95 rps, кампания +40% → 133 rps > квоты → маршрутизация 70% A / 30% B.

20) Шаблон внедрения capacity planning

1. Описать e2e-путь и узкие места.
2. Ввести CU и измерить устойчивый throughput каждого слоя.
3. Настроить метрики saturation и p99 на всех звеньях.
4. Сформировать календарь событий/кампаний/релизов.
5. Построить прогноз по когортам и сценарии “что если”.
6. Закрепить headroom per-поток и per-регион (привязка к error budget).
7. Настроить HPA/VPA/KEDA + warm-pools, лимиты/ретраи/очереди.
8. Проверить провайдерские квоты, включить мульти-маршруты.
9. Собрать дашборды и еженедельный ритм capacity-review.
10. Ежеквартально — DR-учения и пересмотр модели.

21) Итог

Планирование мощностей — это управляемая связка прогнозов, архитектурных ограничений и стоимости, а не “прибавить CPU”. Когда каждый слой e2e-пути имеет измеренную емкость, а headroom и стратегии деградации связаны с SLO и error budget, то пиковые нагрузки, кампании и аварии перестают быть сюрпризом. Такой подход снижает риск инцидентов, стабилизирует бизнес-метрики и оптимизирует затраты.