Мощность на одну неделю: как вырасти и не переплатить за год

MAATRIX

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

Два способа получить мощность и почему их нельзя сравнивать на глаз

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

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

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

Стоимость постоянного апгрейда: считать не только тариф

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

Базовая формула:

годовая_переплата_постоянного_апгрейда = (тариф_повышенный - тариф_базовый) × 12

Но реальная переплата обычно выше, потому что тариф — не единственный ресурс, который растёт вместе с апгрейдом:

• Диск. Более мощный тариф часто идёт с большим объёмом диска, который вы не используете 350+ дней в году, но платите за него как за занятый.
• Трафик. Если у тарифа есть порог включённого трафика или он растёт вместе с планом, повышенный тариф иногда тянет за собой и более дорогой лимит по сети.
• Сопутствующие ресурсы. Резервные IP, снепшоты по расписанию, объём бэкапов — часть провайдеров считает их отдельно и привязывает стоимость к тарифному плану, а не к фактическому потреблению.
• Стоимость лицензий, которые считаются по ядрам или памяти, если на сервере стоит софт с такой моделью лицензирования — здесь переплата за год иногда оказывается больше, чем сама разница в тарифе.

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

Стоимость временного масштабирования: тариф — только часть счёта

Прямая экономия временного масштабирования считается похожей формулой, но с поправкой на реальную длительность пика в долях месяца:

годовая_переплата_временного_масштабирования =
    (тариф_повышенный - тариф_базовый) × (дней_на_пике / 30) × число_пиков_в_год

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

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

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

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

Точка окупаемости: с какого числа дней пика выгоднее держать тариф постоянно

Полная формула, которая сводит обе стороны расчёта вместе:

ΔC = тариф_повышенный - тариф_базовый   (разница в месяц)
D  = суммарное число дней в году на повышенном тарифе
k  = коэффициент премии за короткий срок (1, если провайдер считает посуточно
     пропорционально месячной цене; больше 1, если есть минимальный период биллинга)
n  = число операций переключения в год (обычно 2 × число пиков — вверх и вниз)
O  = стоимость одного переключения (время специалиста + риск простоя)

Годовая_переплата_временного = ΔC × (D / 30) × k + n × O
Годовая_переплата_постоянного = ΔC × 12

Точка окупаемости (D, при котором варианты равны по цене):
D = 30 × (12 - n×O / ΔC) / k

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

Условный пример, чтобы показать саму механику, а не выдать точную цифру для вашего случая: повышенный тариф дороже базового на 4000 рублей в месяц (ΔC = 4000), провайдер считает посуточно без премии (k = 1), переключение туда и обратно занимает у администратора суммарно два часа при ставке 2000 рублей в час, то есть одна операция апгрейд+даунгрейд стоит 4000 рублей (n×O = 4000 при одном пике в год). Тогда:

D = 30 × (12 - 4000/4000) / 1 = 30 × 11 = 330 дней

В этом конкретном примере точка окупаемости — 330 дней в году на повышенном тарифе, то есть почти весь год: даже с учётом стоимости переключения временное масштабирование остаётся выгоднее постоянного апгрейда практически при любом реалистичном числе дней пика, потому что разница в тарифе (ΔC) в этом примере кратно больше, чем стоимость самого переключения (n×O). Соотношение резко меняется, если переключений в год много (не один пик, а десять), а разница между тарифами небольшая — тогда стоимость операций может съесть всю экономию уже при нескольких десятках дней пика. Пересчитайте D по формуле выше со своими цифрами: именно ΔC, k, n и O у вас определяют результат, а не общее правило вида «до месяца — временно, дальше — постоянно».

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