Developer

Capacity planning и FinOps: ресурсы, стоимость, прогнозирование

↑ Этап 8 · Senior: надёжность, безопасность, платформа

По желанию~5 мин чтенияУровень: senior

Зачем это на собесе

Управление ресурсами и стоимостью на уровне инфраструктуры: прогноз, rightsizing, FinOps-практики.

Capacity planning

Процесс: измерить → смоделировать → запланировать → проверить → пересмотреть.

  1. Метрики нагрузки (RPS, активные пользователи, события, размер данных) и ресурсы (CPU, память, диск/IOPS, сеть, соединения, лимиты облака/квоты).
  2. Связь «бизнес-метрика → ресурс» (юнит-экономика ёмкости): «1000 RPS = 8 vCPU, 12 ГБ; 1 млн заказов = 80 ГБ БД».
  3. Прогноз роста: тренд (линейный/экспоненциальный), сезонность, маркетинговые события, релизы; сценарии (базовый, оптимистичный, пик).
  4. Запас (headroom): под пик, отказ зоны (N+1/N+2), задержки масштабирования; целевая загрузка 50–70% пиковая по CPU.
  5. Нагрузочные тесты для проверки модели и поиска узких мест (k6, Gatling, Locust), тест отказов.
  6. Заказ/подготовка мощностей: сроки (облако — минуты, on-prem — недели/месяцы), квоты провайдера, лимиты IP/ENI/аккаунтов.
  7. Регулярный пересмотр (ежемесячно/ежеквартально), алерты на приближение к пределам.

Метрики для прогноза (Prometheus):

predict_linear(node_filesystem_avail_bytes{mountpoint="/var/lib/postgresql"}[7d], 60*86400) < 0        # диск закончится за 60 дней
avg_over_time(sum(rate(http_requests_total[5m]))[30d:1h])                                               # динамика RPS
quantile_over_time(0.95, (1 - avg by (instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])))[30d:1h])  # p95 загрузки CPU

Узкие места (часто неочевидные): число соединений БД, файловые дескрипторы, порты NAT/conntrack, IOPS/пропускная способность дисков и сети, лимиты облачных API, пулы потоков, размер кэшей, индексы/таблицы, rate limits внешних сервисов, время cold-start, квоты IP-адресов, лимиты Kubernetes (pods per node, IPs per node).

Закон масштабирования: не линеен — есть насыщение (Amdahl, универсальный закон масштабируемости Гюнтера); определить точку, после которой рост нагрузки резко снижает производительность.

Автомасштабирование как часть плана

HPA/KEDA + Cluster Autoscaler/Karpenter, autoscaling groups, scale-to-zero для dev; запас на скорость реакции (прогрев, время старта нод), scheduled scaling на известные пики, лимиты max (защита от лавинного роста стоимости).

FinOps

Культура и практика управления облачными расходами вместе с инженерией и финансами: стоимость — метрика качества решений.

Фазы: Inform (видимость и распределение затрат), Optimize (снижение), Operate (процессы и управление).

Видимость

  • теги/метки на всех ресурсах (env, team, service, cost-center, owner); обязательность — политиками (SCP, Kyverno, Terraform checks); в Kubernetes — метки подов/namespace и распределение затрат (Kubecost/OpenCost);
  • отчёты и дашборды (AWS Cost Explorer/CUR, Yandex Billing, GCP Billing export в BigQuery), showback/chargeback по командам;
  • Unit economics: стоимость на пользователя/заказ/транзакцию/запрос (а не только общий счёт);
  • бюджеты, алерты, обнаружение аномалий расходов.

Оптимизация

РычагОписание
Rightsizingподгонка типов/размеров под фактическое использование (метрики p95), уменьшение requests/limits, VPA-рекомендации
Выключение неиспользуемогоdev/test по расписанию (ночью, выходные), «осиротевшие» диски, снапшоты, IP, LB, NAT, неиспользуемые образы
Модели оплатыReserved/Savings Plans/committed use для стабильной базовой нагрузки (скидки 30–70%), Spot/Preemptible для stateless/batch/CI (до 90% дешевле; обработка прерываний, PDB, множество типов инстансов)
Автоскейлингплатить за нужное, scale-to-zero, bin packing (Karpenter консолидация)
Хранениеlifecycle (hot → cold → archive), удаление старых данных/логов/бэкапов, правильный класс (gp3 вместо io2), сжатие, дедупликация, TTL
Сетьegress и межзональный/межрегиональный трафик, NAT Gateway (VPC endpoints), CDN, сжатие, размещение связанных сервисов в одной зоне (баланс с HA)
Архитектуракэширование, асинхронность, серверлесс для нерегулярных нагрузок, выбор managed против self-hosted, ARM (Graviton) ~20–40% дешевле, эффективные языки/рантаймы, AOT
Наблюдаемостьобъём логов/метрик/трейсов (sampling, retention, кардинальность) — часто крупная статья расходов
Лицензииopen-source альтернативы, учёт лицензий ОС/БД
Kubernetesrequests близко к факту, плотность упаковки, ноды нужного размера, spot-пулы, выключение кластеров dev
Мультиоблако/провайдерсравнение цен, переговоры, коммитменты

Операционные процессы

  • владельцы расходов (команды) видят и отвечают за свои затраты; регулярные FinOps-ревью (раз в месяц/квартал), цели по снижению/эффективности;
  • cost как часть ревью архитектуры и PR (Infracost: оценка стоимости изменений Terraform в PR);
  • guardrails: квоты, бюджеты, запрет дорогих типов без согласования, лимиты автоскейлинга;
  • автоматизация: очистка, расписания, политики lifecycle, теги-энфорсмент;
  • метрики FinOps: стоимость на единицу (unit cost), доля тегированных затрат (> 95%), покрытие коммитментами (60–80%), утилизация коммитментов и инстансов, waste (% неиспользуемого), тренд расходов к росту бизнеса.

Баланс стоимости, надёжности и скорости

  • избыточная надёжность (multi-region, N+2) стоит дорого; уровень определяется SLO и бизнес-ценностью;
  • «дёшево» ≠ эффективно: стоимость инженерного времени, риски простоя; оптимизировать сначала крупные статьи (обычно 20% ресурсов = 80% счёта);
  • не ломать наблюдаемость и безопасность ради экономии.

On-premise

Capacity planning более жёсткий: закупка, стойки, питание, охлаждение, сеть, сроки поставки; запас 20–30%, амортизация, TCO (железо + энергия + люди + площадка + лицензии) против облака; гибридные сценарии (базовая нагрузка on-prem, пики в облаке — cloud bursting).

Артефакты и практика

  • документ ёмкости сервиса: текущая нагрузка/ресурсы, лимиты и узкие места, прогноз, план масштабирования, ответственные;
  • дашборды ёмкости и стоимости, алерты по прогнозам;
  • capacity review перед большими событиями (запуск, маркетинг, сезон), нагрузочные тесты «Black Friday»;
  • runbook масштабирования (как быстро добавить мощность, лимиты провайдера);
  • учёт технического долга (неэффективный код дорогой в эксплуатации).

Вопросы с ответами

Вид графа

Обратные ссылки