Цена простоя на пике распродажи: как считать сезонный множитель

MAATRIX

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

Почему усреднённая цена часа обманывает

Стандартная формула выглядит так:

Средняя цена часа простоя = Выручка за год / (365 × 24)

Она годится для одной задачи — прикинуть порядок величины расходов на страхование или общий бюджет на надёжность. Но у неё есть скрытое допущение: что бизнес зарабатывает равномерно каждый час года. Для сервиса с выраженной сезонностью — интернет-магазина, билетного агрегатора, SaaS с квартальными пиками продлений, EdTech перед началом учебного года — это допущение неверно почти всегда.

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

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

Как считать сезонный множитель

Идея простая: вместо одной усреднённой цифры считаем, во сколько раз пиковый час "плотнее" по деньгам, чем средний час года. Это и есть сезонный множитель.

Сезонный множитель (по выручке) =
    Выручка за пиковый час (или окно) / Средняя выручка за час за год

Дальше цена простоя на пике:

Цена часа простоя на пике = Средняя цена часа простоя × Сезонный множитель

Пошагово:

1. Возьмите historical-данные за прошлые аналогичные события. Выгрузка из аналитики (Yandex Metrika, Google Analytics), платёжного шлюза и CRM за прошлогоднюю распродажу или сезонный пик — по часам, не по дням. Дневная гранулярность здесь слишком грубая: внутри самого "горячего" дня распродажи первые один-два часа обычно кратно плотнее остального дня.
2. Постройте почасовое распределение выручки за характерный период — неделю пика и обычную неделю. Возьмите отношение выручки самого нагруженного часа к среднему часу обычной недели, приведённому к тому же масштабу (год/52 недели/168 часов).
3. Посчитайте множитель отдельно для выручки и отдельно для трафика (или числа заказов). Это не всегда одно и то же число — и разница между ними важна (см. следующий раздел).
4. Не берите один множитель на весь пиковый день. Постройте профиль по часам: множитель в первый час флеш-распродажи и множитель в её последний час могут отличаться в разы. Для расчёта цены риска берите максимум профиля, а не его среднее.
5. Если своей истории пиков ещё нет (новый бизнес, первый крупный запуск), используйте консервативную оценку по аналогии с похожими нишами и явно пометьте её как предположение, которое нужно будет уточнить после первого реального пика.

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

Множитель 40 в этом примере — не преувеличение методики, а прямое следствие того, что бизнес физически зарабатывает почти половину недельной выручки за несколько часов распродажи. Для менее выраженной сезонности множитель может быть 3–5, для агрегаторов билетов на конкретное событие — на порядок выше. Число всегда нужно считать по своей истории, а не брать чужое как ориентир.

Множитель по выручке и множитель по трафику — не одно и то же

Здесь скрывается частая ошибка: приравнивать рост трафика к росту цены простоя. Это не так по двум причинам, которые тянут в разные стороны.

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

Выручка может расти сильнее среднего чека. Из-за скидок средний чек на распродаже часто ниже обычного, но количество заказов растёт быстрее, чем падает чек, — итоговая выручка в час всё равно кратно выше среднего. При этом маржа с заказа ниже: скидка 30% съедает часть прибыли. Отсюда следует правило, которое легко упустить.

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

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

Что упускает цена простоя, посчитанная только по выручке

Прямая потерянная выручка — это только часть ущерба от простоя на пике. Часто именно неучтённые статьи оказываются больше самой выручки.

• Впустую потраченный маркетинговый бюджет. Реклама на распродажу оплачена и запущена заранее. Если сайт лежит в момент клика по объявлению, деньги на трафик потрачены, а конверсии не будет — вернуть их нельзя, кампанию придётся перезапускать заново, уже дороже из-за конкуренции в пиковый период.
• Отток на конкурентов именно в момент максимального спроса. Пользователь, который не смог оформить заказ на распродаже, обычно не ждёт — он открывает вкладку конкурента с тем же предложением. Это не отложенная покупка, а фактически подаренная сделка.
• Нагрузка на поддержку и репутационные издержки. Всплеск обращений, негативные отзывы и посты по свежим следам сбоя — на виду у максимальной аудитории, потому что в этот час на сайте была вся ваша база, а не её средний срез.
• Штрафы и компенсации по SLA, если у вас B2B-клиенты с договорными гарантиями доступности — отдельная тема, которую стоит считать отдельно от прямой потери выручки. Подробнее — в статье про SLA и реальные убытки.
• Стоимость "тушения пожара". Инцидент на пике почти всегда требует больше людей и более срочных действий, чем плановый инцидент в спокойный период, — а значит, дороже по человеко-часам именно тогда, когда команда и так перегружена.

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

Как использовать множитель при планировании надёжности

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

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

Из этого вытекает несколько практических выводов для планирования:

• Резервная мощность не обязана быть постоянной. Если бизнес сезонный, разумно держать горячий резерв или расширенную ёмкость именно на период пиков, а не круглый год — это снижает средние расходы на инфраструктуру, сохраняя защиту именно там, где цена риска максимальна. Разницу между холодным, тёплым и горячим резервом и их стоимостью удобно сопоставить со статьёй про три варианта резерва.
• Заморозка изменений перед пиком должна быть жёстче, чем обычно. Code freeze, отказ от рискованных релизов и миграций за 1–2 недели до известного пика — дешёвый способ снизить вероятность инцидента именно тогда, когда его цена максимальна.
• Нагрузочное тестирование должно моделировать именно пиковый профиль, а не средний трафик, умноженный на "хороший запас". Если множитель по трафику в вашем случае — 8, тестировать нужно нагрузку, кратную восьми, а не полутора.
• Мониторинг и дежурство в пиковые окна должны быть плотнее. Время реакции на инцидент (MTTR) само по себе умножается на сезонный множитель при переводе в деньги — час простоя без реакции на пике не то же самое, что час простоя без реакции ночью в межсезонье.
• Бюджет на автомасштабирование стоит закладывать заранее, а не как аварийную меру во время пика — включение дополнительных мощностей "по факту" перегрузки почти всегда происходит с задержкой, а задержка на пике стоит дорого именно из-за множителя.

Практический чек-лист подготовки к пиковому окну

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

1. За 4–6 недель: выгрузить историю прошлого пика по часам (выручка, заказы, RPS, ошибки 5xx) и посчитать множитель по выручке и по трафику отдельно.
2. За 3–4 недели: провести нагрузочное тестирование с профилем, повторяющим пиковый час, — со всплеском в первые минуты, а не плавным ростом. Проверить не только веб-сервер, но и узкие места: базу данных, очереди, платёжные интеграции, кэш.
3. За 2 недели: объявить code freeze на некритичные изменения, зафиксировать дежурство и эскалацию — кто первым реагирует и кто принимает решение об откате.
4. За 1 неделю: развернуть дополнительную ёмкость или подготовить скрипты быстрого масштабирования и проверить, что автомасштабирование реально срабатывает по нужным метрикам, а не только по CPU.
5. За 1–2 дня: прогнать чек-лист отката, чтобы в момент инцидента не разбираться, что именно и как откатывать.
6. Во время пика: усиленный мониторинг с понижёнными порогами алертов — то, что в обычный день терпит, в пиковый час может стоить упомянутого выше множителя.
7. После пика: зафиксировать фактические цифры — реальный множитель, нагрузку, инциденты и их длительность. Это следующая точка данных для расчёта на будущий год.

Отдельно про инфраструктуру: если планируете временно поднимать мощности под пик, удобнее делать это на серверах с гибким апгрейдом конфигурации без переезда — расширение на 1–2 недели пика тогда не требует миграции данных, только временного изменения тарифа.

Ограничения методики

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

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