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

MAATRIX

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

Как выглядит нагрузка от вирусного ролика

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

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

Профиль трафика резко смещается. Почти весь новый поток идёт с одного referrer (YouTube, TikTok, VK Клипы, Instagram) с сильным перекосом в мобильные устройства — аудитория блогеров чаще смотрит и переходит с телефона. Если мобильная версия сайта не тестировалась под нагрузкой отдельно, узкое место может оказаться там, где вы его не ждали.

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

Чем это отличается от планового пика

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

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

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

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

• Источник в аналитике. Проверьте referrer в реальном времени (Metrika, Google Analytics, логи веб-сервера) — резкий рост, сосредоточенный на одном источнике (youtube.com, tiktok.com), почти наверняка означает ролик.
• Целевые страницы. Если новый трафик идёт на одну-две конкретные страницы, а не размазан по сайту, это тоже характерно для ссылки из видео.
• Отсутствие однотипных запросов. В логах нет характерной для ботов регулярности интервалов, заголовков и попыток обращения к несуществующим URL.
• География и время суток совпадают с аудиторией платформы — для русскоязычного канала это одни часовые пояса, для англоязычного могут быть совсем другие, не совпадающие с вашей обычной аудиторией.

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

Что ломается первым

Пул соединений с базой данных. Каждый посетитель — несколько запросов к БД (каталог, карточка товара, персонализация, счётчики). Лимит соединений (max_connections в MySQL/PostgreSQL, лимит пулера) обычно настроен с запасом в разы, а не на порядок — при десятикратном росте параллельных пользователей именно его исчерпание чаще всего становится первой точкой отказа, раньше, чем закончится CPU или диск.

Воркеры веб-сервера и приложения. PHP-FPM с pm.max_children, настроенным под обычный трафик, начинает ставить запросы в очередь и отдавать 502/504, как только все воркеры заняты. То же с числом воркеров Gunicorn, Puma или Node-кластера.

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

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

Экстренные меры, если это происходит прямо сейчас

1. Включите или расширьте кеширование статики и HTML. Если уже есть CDN или обратный кеширующий прокси (Varnish, nginx с proxy_cache), максимально увеличьте TTL для страницы из ролика — даже кеш на минуту-две резко снижает нагрузку на бэкенд. Если кеша не было вообще, включить полностью статичное кеширование главной страницы или карточки товара на несколько минут — самая быстрая мера с наибольшим эффектом.
2. Отключите тяжёлую персонализацию и необязательную функциональность. Рекомендательные блоки, счётчики просмотров в реальном времени, тяжёлые виджеты — всё, что делает лишние запросы к базе на каждый заход, стоит временно выключить. Часть функциональности можно осознанно отключить на несколько часов — та же логика работает при подготовке к плановому пику, просто без времени на подготовку.
3. Увеличьте лимиты воркеров и пул соединений, если на сервере есть запас по CPU и RAM. Бездумное увеличение лимитов на уже исчерпанном сервере просто ускорит нехватку памяти вместо очереди запросов.
4. Увеличьте мощность сервера вертикально, если запаса не хватает. Апгрейд тарифа VPS обычно занимает минуты, а не часы, и не требует переписывать архитектуру. Если стек рассчитан на несколько узлов — добавьте инстанс за балансировщиком.
5. Разгрузите раздачу медиа отдельно от динамики — временно через CDN или отдельный статический хостинг, чтобы снять конкуренцию за воркеры и полосу.
6. Держите под рукой статичную «аварийную» версию страницы. Простой HTML-снапшот целевой страницы (снятый заранее через wget --mirror или сохранённый вручную) на отдельном лёгком хостинге — лучше, чем полностью недоступный сайт.
7. Не включайте агрессивную защиту от ботов. Трафик — живые люди, а не атака; жёсткая капча или общий rate limiting отсекут именно ту аудиторию, ради которой всё это происходит. Ограничивать имеет смысл только заведомо избыточные запросы фоновых краулеров.

Порядок действий стоит держать в виде короткого чек-листа заранее — в момент реального всплеска думать над последовательностью шагов уже некогда.

Как подготовиться заранее

• Кеширование по умолчанию, а не «когда понадобится». Если статика и HTML уже кешируются с разумным TTL в обычное время, вирусный всплеск требует только точечного усиления, а не настройки с нуля под давлением.
• Мониторинг с алертами по скорости роста, а не только по абсолютным порогам. Алерт «CPU выше 90%» срабатывает, когда проблема уже есть. Алерт на рост запросов в разы за 5–10 минут даёт шанс среагировать раньше, чем сервер начнёт отдавать ошибки.
• Возможность быстро повысить мощность без миграции. Если апгрейд требует переноса на другой сервер или долгого согласования, экстренная мера превращается в проект на день. Стоит заранее знать, какая конфигурация — следующий шаг вверх и что для этого нужно технически.
• Готовый статический снапшот ключевых страниц — обновлять раз в неделю и держать наготове.
• Понятная точка ответственности. Если сайтом занимается подрядчик или провайдер, стоит заранее знать, кто и как быстро реагирует на резкий рост нагрузки вне рабочих часов.

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

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

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

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

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