Первые морозы: как отопительный сезон роняет сайты магазинов

MAATRIX

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

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

К чёрной пятнице, Новому году или 8 марта готовятся по расписанию: дата известна за месяцы, есть время на нагрузочное тестирование и докупку мощности к конкретному часу. Погодный пик устроен иначе — сразу по трём пунктам.

Во-первых, неопределённость по дате. Первые устойчивые заморозки в Москве могут прийти в середине октября или в начале ноября, в Сибири — уже в сентябре, на юге — в декабре, и год на год не приходится: тёплая осень легко сдвигает пик на три-четыре недели. Планировать «нагрузочный тест на 15 октября» бессмысленно — конкретной даты, к которой стоит готовиться, попросту нет.

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

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

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

Механика нагрузки при погодном пике похожа на любой резкий рост трафика, но с несколькими характерными для этой ниши особенностями.

• Резкий, а не постепенный рост. Трафик может вырасти в несколько раз за несколько часов, а не нарастать сутками, как перед плановой распродажей, — у команды нет времени «поймать тренд» и среагировать вручную до того, как нагрузка станет заметной.
• Концентрация на конкретных категориях каталога. Основная нагрузка идёт не на весь сайт равномерно, а на узкий набор страниц: обогреватели, тепловентиляторы, масляные радиаторы у одних магазинов; пуховики, зимняя обувь, термобельё — у других. Если эти страницы не кешируются агрессивно, именно они первыми упираются в лимиты бэкенда.
• Высокая доля намеренных визитов. Пользователь, которому холодно сегодня вечером, не листает каталог из любопытства — он ищет конкретную модель и сразу переходит к оформлению. Доля чекаута в трафике выше, чем в обычный день, а чекаут — самая тяжёлая для бэкенда часть воронки: запись в базу, проверка остатков, расчёт доставки, платёжный шлюз.
• Рост запросов о наличии «прямо сейчас». Фильтры «в наличии», «доставка сегодня», проверка остатков по городу — это активные запросы к базе и складским API, а не отдача из кеша, и именно они чаще всего становятся узким местом раньше просмотра каталога.
• Географическая концентрация в первые часы. Похолодание приходит в конкретный регион раньше остальных, поэтому первая волна трафика часто идёт из ограниченного набора городов — полезный сигнал (см. следующий раздел), но и повышенная нагрузка на конкретные региональные склады.

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

Мониторинг погодных трендов как триггер для проверки готовности

Раз календарь не помогает предсказать день пика, эту роль может взять на себя прогноз погоды — не как маркетинговый инструмент, а как источник сигнала для инфраструктуры. Идея простая: превратить отслеживание прогноза в тот же тип триггера, что и алерт по CPU, только на несколько часов раньше.

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

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

#!/bin/bash
# /opt/scripts/weather-trigger.sh
# запускается по cron каждые 3-4 часа в сезон (сентябрь-ноябрь)
CITIES=("moscow:524901" "novosibirsk:1496747" "ekaterinburg:1508291")
THRESHOLD_DROP=8   # порог резкого похолодания в градусах, подберите под свою аудиторию и регион

for entry in "${CITIES[@]}"; do
    NAME="${entry%%:*}"
    CITY_ID="${entry##*:}"
    FORECAST=$(curl -s "https://api.openweathermap.org/data/2.5/forecast?id=${CITY_ID}&appid=${OWM_API_KEY}&units=metric")
    MIN_TEMP=$(echo "$FORECAST" | jq '[.list[0:8][].main.temp_min] | min')
    CURRENT_AVG=$(echo "$FORECAST" | jq '[.list[0:8][].main.temp] | add / length')

    DROP=$(echo "$CURRENT_AVG - $MIN_TEMP" | bc)
    if (( $(echo "$DROP >= $THRESHOLD_DROP" | bc -l) )); then
        curl -s -X POST "https://api.telegram.org/bot${TG_BOT_TOKEN}/sendMessage" \
             -d chat_id="${TG_CHAT_ID}" \
             -d text="Погодный триггер: в ${NAME} резкое похолодание в прогнозе (падение ${DROP}°C). Проверьте чек-лист готовности."
    fi
done

Оговорка: это не предсказание точного объёма трафика — точность прогноза ограничена и зависит от региона и API. Задача скрипта не включить резерв на полную мощность автоматически, а дать команде на 12-24 часа больше времени, чем «мы узнали о всплеске, когда сайт уже начал тормозить».

Резервные мощности, готовые к активации без долгой раскачки

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

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

Что конкретно стоит держать наготове:

• Собранный и протестированный образ приложения (Docker-образ в реестре, AMI/снапшот VM) — готовый к запуску артефакт, прошедший smoke-тест заранее, а не «код в репозитории, который ещё нужно собрать и задеплоить».
• Заранее прописанный скрипт масштабирования — playbook (Ansible, Terraform apply с изменённым числом инстансов), который добавляет мощность одним запуском, без ручной настройки каждого нового сервера.
• Прогретый или быстро прогреваемый кеш каталога — если кеш холодный, первые же минуты после старта нового инстанса создают ту же нагрузку на базу, от которой резерв должен защищать.
• Проверенную процедуру подключения нового инстанса к балансировщику — регистрация в пуле бэкендов, health-check, прогрев соединений к базе.

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

Автомасштабирование без привязки к календарю

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

Отсюда два практических требования. Во-первых, метрика масштабирования должна отражать нагрузку именно на «зимние» разделы сайта, а не общую загрузку CPU по кластеру — общая загрузка размывает сигнал, если остальной каталог продолжает работать в обычном режиме. Полезно масштабировать по RPS на конкретные пути каталога или по длине очереди чекаута.

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

Пример конфигурации с постоянно включённым правилом и явным потолком:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: catalog-checkout-service
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: catalog-checkout-service
  minReplicas: 3
  maxReplicas: 20
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Pods
          value: 5
          periodSeconds: 60
  metrics:
    - type: Pods
      pods:
        metric:
          name: checkout_queue_length
        target:
          type: AverageValue
          averageValue: "10"

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

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

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

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

#!/bin/bash
# /opt/scripts/warm-cache.sh
# прогрев критичных категорий: обогреватели, тепловентиляторы, куртки
URLS=(
  "https://shop.example/catalog/obogrevateli/"
  "https://shop.example/catalog/teplovenilyatory/"
  "https://shop.example/catalog/kurtki-zimnie/"
)
for url in "${URLS[@]}"; do
    curl -s -o /dev/null -w "%{http_code} %{time_total}s %{url}\n" "$url"
done

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

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

Runbook на одну страницу, а не знание в голове одного инженера. Что проверить при получении погодного триггера, кто принимает решение о ручном включении резерва, какая команда запускает масштабирование. Без зафиксированного runbook активация резерва зависит от того, кто именно дежурит в момент похолодания и помнит ли он все шаги наизусть.

Чек-лист по срокам: от тренда до активации

Подготовку разумно разложить не по датам (их нет), а по стадиям сигнала — от общего сезонного ожидания до конкретного прогноза на завтра.

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

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