Планирование мощностей на год вперёд по метрикам

MAATRIX

«Наверное, через год нам понадобится сервер помощнее» — с такой фразы обычно начинается либо разумный план, либо паническая закупка железа в последний момент. Разница между этими двумя сценариями не в удаче, а в том, есть ли у вас данные за прошедший период или вы гадаете на глаз. Планирование мощностей на длительный горизонт — это не искусство, а довольно скучная методика: собрать историю роста, посчитать реальный темп и спроецировать его вперёд с вилкой неопределённости.

Почему интуиция про «побольше со временем» подводит

Интуитивная оценка будущей потребности в ресурсах почти всегда основана на одном из двух источников: субъективном ощущении «дела идут в гору» или экстраполяции последнего яркого впечатления («на прошлой неделе было очень много трафика»). Оба источника систематически искажены.

Проблема ощущения в том, что рост сервиса обычно неравномерный: недели тишины сменяются всплесками, и память запоминает всплески ярче, чем усреднённый фон. Итог — либо переоценка (закупаем железо под разовый пик), либо недооценка (пропускаем медленный, но стабильный рост между всплесками).

Проблема экстраполяции последнего впечатления в том, что одна точка данных — это не тренд. Если перед оценкой был пик от рекламной кампании, оценка «на год вперёд» получится завышенной в разы; если оценка делалась в тихий период — заниженной. А если бюджет утверждают раз в год на совещании из того, что участники помнят, эта ошибка встраивается в план сразу на год.

Объективная альтернатива — не полагаться на память и ощущения, а поднять фактические данные о том, как ресурсы использовались за длительный период, и посчитать реальный темп роста по ним. Это не гарантирует точного попадания в цифру через год, но переводит оценку из категории «мнение» в категорию «измерение с понятной погрешностью», а с бюджетом и закупками именно вторая категория обычно работает надёжнее.

Какие метрики роста собирать и хранить

Для содержательной проекции на год вперёд нужна история минимум по трём типам метрик — конкретный набор зависит от профиля нагрузки, но принцип общий:

Объём данных. Размер базы данных, объём файлового хранилища, число строк в ключевых таблицах. Это то, что растёт почти монотонно и редко откатывается назад — самый удобный тип метрики для проекции.

-- Postgres: размер базы по дням, если снимать регулярно
SELECT pg_size_pretty(pg_database_size('myapp_prod'));

# для файлового хранилища — снимать периодически и складывать в историю
du -sh /var/lib/app-storage | awk '{print $1}'

Число пользователей и запросов. Активные пользователи в день/месяц, число HTTP-запросов, число фоновых задач в очереди. Эта метрика колеблется сильнее объёма данных (сезонность, дни недели), поэтому для тренда её лучше усреднять по неделе или месяцу, а не смотреть на дневные значения.

Потребление вычислительных ресурсов. Средняя загрузка CPU, использование RAM, IOPS диска, исходящий трафик. Здесь важно смотреть не на пиковые значения (они реагируют на кратковременные всплески), а на устойчивый уровень — например, 95-й перцентиль по неделе.

Ключевое условие — метрики должны быть агрегированными и накапливаться достаточно долго, чтобы на них был виден тренд, а не шум. Один месяц данных для проекции на год — это слишком короткая база; полгода-год истории дают несравнимо более надёжную картину.

Здесь работает тот же общий принцип, что и в вопросе о том, сколько хранить логи: детальные данные дорого хранить долго, а агрегаты — дёшево. Разница в том, что для capacity planning всё ровно наоборот по приоритету: подробные логи отдельных запросов можно ротировать через недели, а вот агрегированные метрики роста (число пользователей за месяц, средний объём базы за неделю) занимают на порядки меньше места и хранить их стоит годами, а не месяцами — именно они дают материал для долгосрочной проекции.

Практическая настройка: если у вас уже есть Prometheus или Grafana Loki для операционного мониторинга, retention там обычно настроен на недели-месяцы ради живого дашборда, а не для годовой аналитики. Для capacity planning стоит отдельно выгружать агрегаты (например, раз в неделю кроном) в отдельную таблицу или CSV с долгим хранением:

#!/bin/bash
# weekly-capacity-snapshot.sh - раз в неделю через cron
DATE=$(date +%Y-%m-%d)
DB_SIZE=$(psql -tAc "SELECT pg_database_size('myapp_prod')")
ACTIVE_USERS=$(psql -tAc "SELECT count(distinct user_id) FROM events WHERE created_at > now() - interval '7 days'")
DISK_USED=$(df --output=used -B1 /var/lib/postgresql | tail -1)
echo "$DATE,$DB_SIZE,$ACTIVE_USERS,$DISK_USED" >> /var/log/capacity-history.csv

Такой файл за год — это 52 строки, несколько килобайт, и при этом полноценная база для годовой проекции.

Как выявить реальный темп роста

Имея историю в несколько десятков-сотен точек, задача — оценить темп роста, а не проектировать по одной формуле не глядя на данные. Два базовых сценария:

Линейный рост. Если абсолютный прирост между периодами примерно одинаковый (условно, +5 ГБ данных в месяц каждый месяц), рост линейный. Простая оценка — взять средний прирост за последние N периодов и умножить на число периодов до горизонта планирования.

Экспоненциальный рост. Если прирост сам растёт (в январе +5%, в феврале +6%, в марте +7% от текущего объёма), это экспоненциальная динамика, характерная для растущих сервисов с органическим привлечением пользователей. Здесь линейная экстраполяция сильно недооценит будущую потребность — нужно смотреть на темп роста в процентах за период, а не в абсолютных числах.

Практический способ отличить одно от другого без сложной статистики — построить график в логарифмической шкале по оси Y. Если точки на нём ложатся примерно на прямую линию — рост экспоненциальный с постоянным темпом; если на прямую линию ложатся точки на обычной (линейной) шкале — рост линейный.

# грубая оценка темпа роста по истории (Python, без внешних библиотек статистики)
history = [
    ("2025-09", 120_000_000_000),  # размер БД в байтах по месяцам
    ("2025-10", 128_000_000_000),
    ("2025-11", 137_000_000_000),
    # ... и так далее
    ("2026-08", 210_000_000_000),
]

first_val = history[0][1]
last_val = history[-1][1]
periods = len(history) - 1

# средний темп роста за период (геометрическое приближение)
growth_rate = (last_val / first_val) ** (1 / periods) - 1
print(f"Средний темп роста: {growth_rate * 100:.2f}% за месяц")

Важная оговорка: этот расчёт даёт средний темп за весь наблюдаемый период. Если в последние три месяца темп заметно ускорился или замедлился по сравнению с началом периода, разумнее опираться на темп за последние несколько месяцев, а не усреднять по всей истории — недавняя динамика обычно репрезентативнее старой для проекции на ближайший год.

Проекция на горизонт планирования с вилкой неопределённости

Получив темп роста, следующий шаг — спроецировать его вперёд на нужный горизонт (обычно год) и получить не одну цифру, а диапазон.

Для линейного роста: ожидаемое значение через год = текущее значение + средний прирост за период × число периодов в году.

Для экспоненциального роста: ожидаемое значение через год = текущее значение × (1 + темп роста за период) ^ число периодов в году.

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

Такая таблица — это не строгий прогноз с доверительными интервалами (для этого нужна более серьёзная статистика и больше данных), а рабочий инструмент для разговора с руководством и для бюджетирования: вместо «нам, наверное, понадобится побольше» вы приносите три конкретных сценария с числами и обоснованием, откуда они взялись.

Практический ориентир (не измеренная величина, а логика подхода): если пессимистичный и оптимистичный сценарии расходятся в разы, это сигнал, что данных за прошлый период недостаточно для уверенной проекции или что бизнес находится в фазе, где старый тренд ненадёжен — и это тоже полезный вывод, отдельный от самой цифры.

Отдельно стоит учесть шаги (ступенчатость) в стоимости инфраструктуры — переход на следующий тариф VPS часто не плавный, а скачкообразный по цене и объёму ресурсов. Полезно заранее прикинуть, какую конфигурацию сервера рассчитать под нагрузку на каждой ключевой точке горизонта (через 3, 6, 12 месяцев), а не только на конечную дату — это покажет, сколько раз за год придётся переезжать на следующий тариф и когда именно.

Честные ограничения метода экстраполяции

Экстраполяция прошлого тренда — сильный, но не всесильный инструмент, и стоит явно проговорить, где он ломается.

Предположение о неизменности характера роста. Метод опирается на то, что механизм, породивший прошлый тренд, продолжит работать так же в будущем. Это разумное предположение по умолчанию, но оно рушится при качественных изменениях бизнеса: запуск крупной новой функции (например, добавление видео в сервис, который раньше работал только с текстом), заметный маркетинговый рывок, выход на новый рынок или, наоборот, потеря крупного клиента. Ни один из этих сценариев статистическая экстраполяция прошлых данных не предсказывает — она в принципе не может увидеть то, чего ещё не было в истории.

Ложное ощущение точности. Цифра «210 ГБ через год» выглядит точной, но по сути это точка внутри широкого доверительного диапазона, который расчёт по нескольким точкам истории не в состоянии сузить. Стоит явно доносить до всех, кто видит эти числа, что это ориентир, а не гарантия.

Нелинейные эффекты на подходе к границам. Рост потребления ресурсов иногда ускоряется не только из-за роста бизнеса, но и из-за деградации системы вблизи ограничений — например, почти заполненный диск заставляет файловую систему работать медленнее на ту же операцию, что подстёгивает CPU и память. Такой эффект по спокойным историческим данным не экстраполировать — это отдельная задача про распознавание проблемы уже в моменте, а не про долгосрочную стратегию.

План — не догма. Из всего перечисленного следует практический вывод: годовой план по метрикам стоит пересматривать не один раз в год, а периодически — например, ежеквартально, сверяя фактические цифры с тем, что предсказывал план, и корректируя проекцию по свежим данным. Если план на год расходится с фактом уже через квартал, это сигнал пересчитать сценарии, а не молча ждать конца года, чтобы «план не подтвердился».

Как это выглядит на практике: пример проекции

Возьмём условный пример (числа иллюстративные, а не измеренные — у вас будут свои). SaaS-сервис с базой данных Postgres и очередью фоновых задач, накопивший год еженедельных снапшотов:

• размер базы данных вырос с 80 ГБ до 145 ГБ за год — средний темп около 5% в месяц;
• число активных пользователей в месяц выросло с 3 200 до 6 100 — темп около 5,5% в месяц, близко к темпу роста базы (логично: больше пользователей — больше данных);
• средняя загрузка CPU (95-й перцентиль по неделе) выросла с 35% до 58% при той же конфигурации сервера — рост в первую очередь за счёт возросшего числа одновременных запросов, а не только объёма данных.

Проекция на следующий год при сохранении темпа: база вырастет примерно до 260-280 ГБ (диапазон между базовым и оптимистичным сценарием), а CPU при том же железе выйдет за пределы комфортного диапазона (>80% 95-го перцентиля) уже в середине года — то есть апгрейд по CPU понадобится раньше, чем апгрейд по диску.

Вывод из такой проекции конкретный и пригодный для бюджета: заложить в план на первое полугодие переход на тариф с большим числом ядер, а решение по диску отложить до третьего квартала, когда будет понятнее, подтверждается ли текущий темп роста базы. Это ровно то, чем практическая проекция отличается от абстрактного «нужно больше ресурсов» — конкретный срок, конкретный ресурс, конкретное обоснование числами.

Бюджетирование под ожидаемую траекторию роста

Главная практическая ценность годовой проекции — не сама цифра, а возможность спланировать расходы на инфраструктуру заранее, а не судорожно искать бюджет в момент, когда сервис уже упирается в лимиты.

Если известно, что через 6-8 месяцев понадобится переход на более мощный тариф, а через год, возможно, понадобится второй сервер под растущую нагрузку, это можно:

• заложить в квартальный бюджет отдела как ожидаемую статью расходов, а не как экстренный запрос;
• зафиксировать более выгодную цену заранее, если хостинг предлагает скидку за предоплату длительного периода;
• спланировать миграцию на новый тариф в спокойное время (например, в низкий сезон по трафику), а не в момент, когда сервер уже задыхается под нагрузкой и переезд приходится делать в панике.

Экстренное масштабирование в последний момент обычно обходится дороже планового по двум причинам: во-первых, приходится покупать по текущей цене без скидок за предоплату, во-вторых, риск ошибок и простоя при переезде «на бегу», когда сервис уже перегружен, выше, чем при спокойной миграции по графику. Годовая проекция по метрикам не устраняет этот риск полностью, но резко снижает вероятность узнать о нехватке ресурсов постфактум, когда уже поздно договариваться о бюджете.

Частые вопросы