Capacity Planning: как не упасть в день распродажи

Вы - владелец кофейни. Обычно к вам заходит триста человек в день и трёх бариста с тремя кофемашинами хватает. Но вдруг наступает "Чёрная пятница" и в 8 утра у вас выстраивается очередь из 5000 человек. Кофемашины перегреваются, бариста в панике, клиенты уходят злые и к вам больше не вернутся. У вас полный провал с capacity planning :)

Capacity Planning (планирование ёмкости) это не про "добавить серверов когда станет плохо". Это про предсказать, подготовить и автоматизировать добавление так, чтобы пиковая нагрузка стала рядовым рабочим днем.

Что такое "ёмкость" в мире SRE?

Ёмкость это способность системы обрабатывать: - определённый объём трафика (RPS, запросов в секунду) - определённое количество пользователей (DAU/MAU) - определённый объём данных (ГБ/сутки) - с требуемым уровнем производительности (SLO по задержке)

НО!! При этом: - Не превышая бюджет - Не нарушая SLO (пользователи не должны страдать) - С запасом на непредвиденное

Основы Capacity Planning

1. Спрос (Demand): "Что от нас хотят?"

Это нагрузка, которую создают пользователи:

Метрики спроса: - Трафик: RPS (requests per second), QPS (queries per second) - Пользователи: DAU (daily active users), MAU (monthly active users)
- Данные: ГБ/день, сообщений/секунду - Бизнес-метрики: заказов/час, платежей/минуту

Спрос редко бывает ровным. Он имеет паттерны: - Суточные циклы: ночью спад, днём пик - Недельные: понедельник vs воскресенье - Сезонность: чёрная пятница, Новый год - Событийность: запуск новой фичи, рекламная кампания, конференция

2. Поставка (Supply): "Что мы можем дать?"

Это ресурсы, которые вы можете выделить:

Ключевые ресурсы: - Вычислительные: vCPU, ядра, GPU - Память: RAM (критично для БД, кэшей) - Хранилище: Дисковое пространство, IOPS - Сеть: Пропускная способность, лимиты трафика - Лимиты провайдеров: Rate limits API, квоты облаков

3. Использование (Utilization): "Насколько эффективно мы используем?"

Утилизация = Использованные ресурсы / Доступные ресурсы

Золотые правила утилизации: - CPU: 60-70% - здоровый уровень, 80-90% - тревога, 95%+ - паника - Память: Зависит от приложения, но swapping = смерть - Диск I/O: 80% обычно максимум - Сеть: Зависит от SLA провайдера

Не заьывайте, что разные сервисы имеют разные профили: - API-шлюз: CPU-intensive - База данных: memory/IO-intensive
- Очередь сообщений: network-intensive - Кэш: memory-intensive

Методики Capacity Planning

Линейная экстраполяция (простой рост)

Текущая нагрузка: 1000 RPS
Рост: 5% в неделю
Через 6 месяцев: 1000 × (1,05)^26 ≈ 3560 RPS

^26 - здесь сложный процент (compound interest): каждую неделю рост применяется к уже увеличенному значению предыдущей недели.

Плюсы: Просто, понятно Минусы: Не учитывает сезонность, события, насыщение

Анализ временных рядов (сезонность + тренды)

Обычно используются инструменты вроде Prophet или Holt-Winters:

from prophet import Prophet

# Анализ недельной сезонности + рост
model = Prophet(
    yearly_seasonality=True,
    weekly_seasonality=True,
    daily_seasonality=True
)
model.fit(data)
future = model.make_future_dataframe(periods=90)
forecast = model.predict(future)

Что обнаруживает: - "Каждое лето нагрузка падает на 15%" - "В пятницу вечером +40% к трафику" - "После запуска новой фичи "X" рост ускорился с 3% до 7% в неделю"

Event-driven планирование

Самый важный метод для SRE! Работа с бизнесом:

Вопросы бизнесу: - "Когда запускаете рекламную кампанию?" - "Планируете ли выход в новый регион в Q3?" - "Будет ли прямой эфир CEO в четверг?"

Пример расчета:

Текущая нагрузка: 2000 RPS
Ожидаемый рост от кампании: +300% (по историческим данным)
Пиковая нагрузка: 2000 × 4 = 8000 RPS
Необходимые ресурсы: текущие × 4

Нагрузочное тестирование + моделирование

# Запуск нагрузочного теста
k6 run --vus 1000 --duration 30m script.js

# Результаты:
# - Максимальная нагрузка: 1500 RPS
# - Предел системы: 1800 RPS (начались таймауты)
# - Рекомендуемая нагрузка: 1200 RPS (с запасом 33%)

K6 - горячо рекомендую! :)

Как на практике планируют Capacity

1: измеряем и собираем данные

# Ключевые метрики для capacity planning
- http_requests_total
- container_cpu_usage_seconds_total
- container_memory_usage_bytes
- node_filesystem_avail_bytes
- container_network_receive_bytes_total

Дашборд Capacity Planning должен показывать: - Текущую утилизацию всех ключевых ресурсов - Тренды роста (неделя/месяц/квартал) - Оставшийся headroom ("до лимита осталось X дней") - Соотношение спрос/поставка

2: анализируем узкие места (bottleneck analysis)

Вопросы: 1. Что ограничивает масштабирование? CPU? Память? Сеть? Диск? 2. Есть ли single point of failure? Где? 3. Масштабируется ли база данных горизонтально? 4. Есть ли лимиты у внешних зависимостей (API провайдеров)?

Пример bottleneck анализа:

Система: Платежный шлюз
Текущая нагрузка: 100 платежей/сек
Лимиты:
- CPU: выдерживает до 500/сек (не bottleneck)
- База данных: 150/сек на запись (BOTTLENECK!)
- Платежный провайдер: 200/сек (лимит API)
Вывод: Узкое место - БД и внешний провайдер

3: прогнозируем и моделируем

Сценарии прогнозирования: 1. Базовый: продолжение текущего тренда 2. Оптимистичный: новая фича "выстрелит" 3. Пессимистичный: конкурент запускает аналогичный продукт 4. Событийный: чёрная пятница, Зеленый день

Формула для расчета:

Необходимые ресурсы = (Текущая нагрузка × Коэффициент роста) / (Текущая утилизация × Целевая утилизация)

Пример:

Текущая нагрузка: 1000 RPS
Ожидаемый рост за квартал: 50% → 1500 RPS
Текущая утилизация CPU: 70%
Целевая утилизация: 60% (запас 40%)
Необходимый прирост: (1500 / 1000) × (0,7 / 0,6) = 1,5 × 1,17 = 1,75x
Вывод: Нужно увеличить имеющиеся мощности в 1,75 раза

4: планируем и ~~просим денег~~ бюджетируем

Capacity Plan - документ должен включать:

# Capacity Plan: сервис XYZ, Q3 2026

## Текущее состояние
- Нагрузка: 2000 RPS
- Ресурсы: 20 нод × 4 CPU × 8 GB RAM
- Утилизация CPU: 65%
- Утилизация памяти: 55%

## Прогноз на квартал
- Ожидаемый рост: +40% (до 2800 RPS)
- События: запуск на Марсе (+30% нагрузки)

## Требуемые инвестиции
1. Увеличение кластера: +10 нод (итого 30)
2. Увеличение IOPS для БД: с 3000 до 5000
3. Резервирование дополнительного CDN-трафика

## Бюджет
- Инфраструктура: +2500000 руб/мес
- CDN: +500000 руб/мес
- Итого: +3000000 руб/мес

## Риски
1. Ограничения платежного провайдера (макс 2500 транзакций/сек)
2. Лимиты платежного шлюза

5: Реализовываем и мониторим

  1. За 2 месяца: заказать оборудование/резервировать облачные ресурсы
  2. За 1 месяц: настроить автомасштабирование, провести нагрузочное тестирование
  3. За 2 недели: протестировать процедуры масштабирования
  4. Во время события: мониторинг 24/7, готовность к ручному вмешательству
  5. После события: анализ, корректировка моделей на будущее

Особые случаи Capacity Planning

Случай 1: черная пятница / зеленый день / 11.11 и т.п.

Подготовка: - Нагрузочное тестирование на 5-10x от обычной нагрузки - Автомасштабирование с агрессивными настройками - Резервные мощности pre-warmed (уже запущены) - План "ручного управления" на случай сбоя автомасштабирования

Пример плана:

День -30: Нагрузочное тестирование
День -7: Pre-warm 50% дополнительных мощностей
День -1: Полный pre-warm резервных мощностей
День 0: Мониторинг 24/7, готовность к ручному вмешательству
День +1: Постепенное scale-down

Случай 2: запуск в новый регион

Вопросы, которые нужно задать: - Какой % трафика перейдёт в новый регион? - Нужна ли репликация данных? - Какие лимиты у платежного шлюза в этом регионе? - Какая задержка между регионами?

Случай 3: миграция на новый техстек

Пример: Переход с монолита на микросервисы - Планируем параллельный запуск - Канареечное развертывание - Сравнение производительности старой и новой архитектуры - План отката на случай проблем

Как понять, что у вас все хорошо с Capacity Planning?

Количественные метрики:

  1. Forecast Accuracy: насколько прогноз совпал с реальностью Точность = 1 - |(Прогноз - Реальность)| / Реальность
  2. Utilization Rate: средняя утилизация ресурсов (цель: 60-70%)
  3. Headroom Days: "сколько дней осталось до лимита при текущем росте"
  4. Cost per Transaction: стоимость обработки одной транзакции (должна снижаться)

Качественные показатели:

  • Zero surprise incidents: никаких неожиданных исчерпаний ресурсов
  • Business confidence: бизнес доверяет вашим прогнозам
  • SLA compliance: SLO выполняются даже при пиковых нагрузках
  • Budget adherence: фактические затраты в пределах бюджета

Где и как можно ошибиться

Планирование "по среднему"

Средняя нагрузка: 1000 RPS
Пиковая нагрузка: 5000 RPS (в 17:00)
Ошибка: Планируем на 1000 RPS
Результат: Система падает каждый день в 17:00

Игнорирование или неучитывание зависимостей

Планируете масштабирование приложения, но забываете про: - Базу данных (она не scale horizontal) - Кэш Redis (лимит памяти) - Внешние API (rate limits) - Сеть (пропускная способность между AZ)

Не учитывание времени масштабирования

Автомасштабирование: 5 минут на запуск новой ноды
Пик нагрузки: наступает за 1 минуту
Результат: 4 минуты деградации сервиса
Решение: pre-warm или predictive scaling

Планирование в вакууме (все, как мы любим)

SRE планируют ёмкость без учета: - Бюджетных ограничений - Планов бизнеса (новые фичи, рынки) - Кадровых возможностей (кто будет управлять новой инфраструктурой?)

Capacity Planning всегда должен быть диалогом с бизнесом

Ежемесячная встреча Capacity Review:

Участники: SRE, продукт, финансы
Повестка:
1. Обзор прошедшего месяца: факт vs прогноз
2. Предстоящие события бизнеса
3. Прогноз на следующий месяц/квартал
4. Требуемые инвестиции
5. Риски и mitigation планы

Хорошо и более продуктивно говорить не "нам нужно больше CPU дайте денег", а примерно так :) : "для поддержки роста на 40% в Q3 и запуска на Марсе требуется увеличение бюджета на инфраструктуру на 20000000 рублей в месяц, что позволит обрабатывать дополнительные 800000 транзакций/день".

Capacity Planning это управление рисками

Хороший Capacity Planning это не про идеальные прогнозы (их никогда и никто не сможет реализовать). Это про:

  1. Знание своей системы: где узкие места? Что масштабируется, а что нет?
  2. Понимание бизнеса: какие у бизнеса планы? Какие намечаются события?
  3. Управление компромиссами: надёжность vs стоимость, автоскейлинг vs pre-warm
  4. Готовность к неожиданностям: headroom, ручное override, планы на случай "если всё пойдёт не так"

Правило для SRE: Всегда планируйте с запасом, но не слишком большим. Потому что слишком маленький запас это риск для бизнеса, а слишком большой запас это риск для вашего бюджета (и вашей карьеры). Подумайте, изучите практики и инструменты. "На глаз" - нормальные SRE так не делают.

Задача нормального SRE найти баланс между "достаточно для роста" и "не слишком дорого".

Единственная система, которая никогда не испытывает проблем с ресурсами это та, которой никто не пользуется :)