Capacity Planning — это прогнозирование потребности в ресурсах: CPU, RAM, диске, сети, базе данных, очередях и даже людях в команде. Его цель проста: не допустить деградации сервиса при росте нагрузки и не переплачивать за избыточную инфраструктуру.
Почему тема важна:
- нехватка ресурсов ведёт к отказам, росту latency и падению конверсии
- избыток ресурсов увеличивает расходы без реальной пользы
- без метрик масштабирование превращается в реакцию “по факту”, а не в управляемый процесс
Что нужно измерять для capacity planning:
- Utilization — загрузка CPU, памяти, диска, сети
- Latency — время ответа API, БД, очередей
- Throughput — количество запросов, транзакций, сообщений в секунду
- Error Rate — доля ошибок при росте нагрузки
- Saturation — признаки упора в лимиты: очередь запросов, iowait, connection pool exhaustion
- Business-метрики — активные пользователи, заказы, пиковые часы, сезонность 📈
Главный принцип: смотреть не на одну метрику, а на связку нагрузка → потребление ресурсов → деградация сервиса.
Как строится прогноз:
- собираем исторические данные за недели и месяцы
- ищем тренды: рост трафика, сезонные пики, маркетинговые всплески
- определяем точку насыщения системы
- считаем запас мощности с учётом отказоустойчивости
- моделируем сценарии: обычный день, релиз, распродажа, инцидент
Простой пример:
Если API при 2 000 RPS загружает CPU на 55%, а при 3 500 RPS latency начинает резко расти, то реальная ёмкость системы ближе не к “100% CPU”, а к точке, где ухудшается SLA. Именно её и надо брать за ориентир, а не абстрактный максимум.
Что часто делают неправильно:
- ориентируются только на средние значения, игнорируя p95/p99
- не учитывают сезонность и разовые пики
- считают только серверы, забывая про БД, кеш, брокеры и внешние API
- не закладывают резерв на отказ ноды или зоны доступности
- прогнозируют “в процентах CPU”, а не в бизнес-нагрузке
Практический подход:
- мониторинг: Prometheus, Grafana, Datadog, Zabbix
- нагрузочное тестирование: k6, JMeter, Gatling
- алерты по saturation и SLA, а не только по uptime
- регулярный пересмотр модели после релизов и архитектурных изменений 🛠️
Хороший capacity planning отвечает на 3 вопроса:
- когда текущих ресурсов перестанет хватать
- какой компонент станет bottleneck первым
- сколько нужно мощности, чтобы пережить рост без потери качества 🚀
Итог:
capacity planning — это не “таблица для менеджера”, а инструмент снижения рисков, контроля бюджета и стабильного роста продукта. Чем раньше вы связываете метрики с реальной нагрузкой, тем меньше сюрпризов в продакшене 🔍
Подборку каналов про IT стоит посмотреть тем, кто следит за практиками SRE, DevOps, архитектурой и инженерной эффективностью.