Сезон кончился: как не платить за пиковые мощности оставшиеся одиннадцать месяцев

MAATRIX

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

Знакомый сценарий: почему «потом» превращается в никогда

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

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

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

Шаг 1. Дата понижения — строка в календаре, а не «после разберёмся»

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

Практически это выглядит так:

• В момент запуска пиковой конфигурации сразу ставится задача или календарное напоминание на дату через 1-2 недели после ожидаемого окончания сезона — с явной формулировкой «проверить нагрузку и понизить тариф», а не расплывчатым «посмотреть на сервер».
• Задача ставится на конкретного человека, а не «на команду» — ответственность без имени в карточке обычно означает, что задачу выполнит никто.
• Дата выбирается с запасом после формального конца сезона, а не день в день: у большинства сезонных проектов есть «хвост» — часть трафика приходит с задержкой (доставки, возвраты, опоздавшие заявки), и понижать тариф в последний день пиковой активности рано.
• Если есть возможность — задача автоматизируется технически, а не только организационно: скрипт или запись в cron, которая в заданный день не понижает тариф сама (это должно быть осознанное решение человека), а присылает жёсткое напоминание с конкретными цифрами текущей нагрузки, чтобы решение принималось сразу, а не откладывалось на «посмотрю попозже».

Ключевая идея — перенести решение из состояния «когда-нибудь, когда будет время» в состояние «конкретного дня, к которому есть конкретный список действий». Пока решение не привязано к дате, оно теряет конкуренцию за внимание команды абсолютно всегда.

Шаг 2. Прежде чем понижать — сверьтесь с метриками, а не с календарём

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

Типичная ошибка в обе стороны:

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

Чтобы отличить настоящий спад от временного затишья, смотрите не на одну точку, а на окно данных:

• Берите период не короче одной-двух недель, а не «вчера было тихо». Одна ночь или один выходной день ничего не доказывают — нагрузка почти всегда неровная в пределах недели.
• Сравнивайте будни и выходные отдельно — если проект розничный, спад по будням при живых выходных ещё не значит, что сезон закончился.
• Смотрите не только на средние значения, но и на пиковые за период: средняя загрузка CPU в 20% ни о чём не говорит, если раз в день случается всплеск до 90% — именно пиковые значения определяют, можно ли понижать тариф безопасно.
• Проверяйте не только CPU и память, но и то, что реально было причиной апгрейда — если сезон гонял диск (много записи, временные файлы, экспорт отчётов) или сеть (внешние интеграции, вебхуки), спад должен быть виден именно там, а не только в среднем CPU.

Практически удобно поднять для этого простой дашборд или хотя бы выгрузку за нужный период из уже стоящего мониторинга — большинство панелей управления и Zabbix/Prometheus/Grafana-стеков умеют показывать почасовые максимумы за произвольный диапазон, этого обычно достаточно, чтобы принять решение не на глазок.

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

Шаг 3. Понижаем поэтапно, а не одним резким шагом

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

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

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

Отдельно стоит развести ресурсы по тому, насколько легко их менять:

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

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

Экономика: во сколько на самом деле обходится «оставить как есть»

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

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

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

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

Соотношение «пиковый вдвое дороже базового» — условное, у кого-то разрыв меньше, у кого-то в разы больше, особенно если на пике добавлялись не только CPU/RAM, но и отдельные дорогие ресурсы вроде выделенных IP, повышенного объёма трафика или дополнительных дисков. Смысл не в конкретных цифрах, а в том, что цена промедления линейно растёт с числом месяцев простоя решения — и именно поэтому даунгрейд стоит планировать как задачу с датой и ответственным, а не оставлять на усмотрение того, кто когда-нибудь откроет биллинг.

Чек-лист для следующего сезона: из разового решения — в отлаженный процесс

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

[ ] Дата понижения назначена ДО конца сезона, с запасом на хвост нагрузки
[ ] Ответственный за понижение указан по имени, не «команда»
[ ] Напоминание поставлено (календарь / таск-трекер / cron-уведомление)
[ ] Метрики за 1-2 недели после ожидаемого спада собраны и проверены:
    [ ] CPU/RAM: p95 в комфортных пределах
    [ ] Диск: реальный рост данных за сезон учтён (не уменьшать вслепую)
    [ ] Сеть: пиковые значения, не только средние
[ ] Снимок/бэкап сделан перед первым шагом понижения
[ ] Понижение выполнено поэтапно (минимум 2 ступени для заметного разрыва)
[ ] На каждой ступени выдержан период наблюдения (3-5 дней с выходным)
[ ] Финальная базовая конфигурация зафиксирована как «межсезонная норма»
[ ] Цифры этого цикла (даты, конфигурации, наблюдения) записаны для следующего сезона

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

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