Шаред-хостинг в чёрную пятницу: вас отключат за чужого соседа

MAATRIX

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

Почему риск соседа именно в чёрную пятницу выше, чем в обычный день

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

Дешёвый shared-хостинг — это именно та инфраструктура, на которой массово живут маленькие интернет-магазины, лендинги под товарные ниши и одностраничники, для которых экономика тарифа в 200-500 рублей в месяц принципиальна. Это ровно та аудитория, которая активнее всего участвует в чёрной пятнице: скидки, акционные рассылки, реклама в соцсетях под распродажу. На типичном узле массового хостера, где соседствуют от нескольких десятков до нескольких сотен аккаунтов, доля именно e-commerce и промо-сайтов среди них в конце ноября статистически выше, чем в среднем по году, — просто потому, что многие небольшие магазины держат сайт на shared-тарифе постоянно, а не переезжают ради одной недели.

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

Что физически происходит на узле, когда трафик у соседа резко растёт

Механика та же, что и в обычный день шумного соседа, просто с большей вероятностью и большей интенсивностью. У всех аккаунтов на shared-узле общие CPU, оперативная память, дисковая подсистема и часто общий инстанс базы данных с отдельной схемой на каждый аккаунт. Когда у соседнего интернет-магазина трафик подскакивает в несколько раз против обычного дня — рекламная кампания под скидку сработала эффективнее, чем ожидалось, — каждый его запрос порождает процесс PHP-FPM, который занимает CPU и память на время выполнения. Если пул воркеров веб-сервера на узле не нарезан жёстко по аккаунтам, резкий рост числа воркеров у одного клиента реально снижает то, что физически достаётся остальным в ту же секунду.

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

Дальше есть три типичных сценария того, как это выглядит для вас:

• Плавная деградация. Страницы грузятся заметно дольше обычного — на 2-5 секунд вместо привычной доли секунды — без единой вашей ошибки в логах. Узел просто перегружен целиком.
• Резкий отказ по лимиту. Если на узле стоит CloudLinux LVE, вы можете увидеть не постепенное торможение, а HTTP 508 (Resource Limit Is Reached) или обрыв PHP-процесса — ваш собственный аккаунт упёрся в свой персональный лимит именно потому, что общая нагрузка на узле высокая, и CloudLinux в такие моменты ужимает лимиты агрессивнее.
• Полная недоступность узла. Если у хостера общая база данных на узел и она встаёт в блокировки или исчерпывает пул соединений из-за чужого магазина, может лечь не только ваш сайт, а весь узел целиком — включая панель управления, через которую вы могли бы что-то поменять.

Что при этом объединяет все три сценария — от вашего кода и вашей нагрузки они не зависят вообще.

Почему это несправедливо, но объяснимо: ваш сайт страдает без вашей вины

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

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

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

Как оценить риск своего узла заранее, до начала сезона

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

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

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

Замерьте отклик своего сайта внешним монитором заранее — за 2-3 недели до пика. Простой аптайм-монитор с интервалом в 5 минут или ручная проверка через curl с внешнего сервера дадут базовую линию нормального отклика:

curl -o /dev/null -s -w "time_total: %{time_total}s http_code: %{http_code}\n" https://ваш-сайт.ru/

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

Проверьте собственные графики ресурсов в панели (обычно раздел вроде «Statistics» или «Resource Usage» в cPanel) в моменты предполагаемых просадок. Если ваш собственный CPU и I/O в этот момент низкие, а сайт всё равно медленный — проблема снаружи вашего аккаунта, а не в вашем коде.

Что делать, если переехать на VPS до сезона не успеваете

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

• Закешируйте максимум статики через CDN. Если картинки, CSS и JS отдаются не с вашего shared-аккаунта, а с внешнего CDN, часть нагрузки на общий узел снимается — остаётся только динамика, которую действительно обрабатывает PHP.
• Включите кеширование страниц на уровне приложения или плагина CMS, если оно ещё не включено. Отданная из кеша страница не создаёт нового процесса PHP-FPM и не бьёт по общей базе — а значит, меньше добавляет собственной нагрузки на узел и меньше зависит от того, свободен ли CPU в моменте.
• Уточните у хостера, есть ли у вас возможность экстренного временного апгрейда тарифа на день-два вокруг пика — если да, закажите его заранее, а не в момент, когда сайт уже недоступен: в разгар распродажи очередь заявок на апгрейд у хостера тоже длиннее обычной.
• Договоритесь заранее, кто из команды следит за сайтом в эти дни и что делать при недоступности — хотя бы простой чеклист: проверить свои графики, написать в поддержку с конкретным временем просадки, зафиксировать факт для будущего решения о переезде.

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

Почему это ещё один аргумент переехать на VPS именно сейчас, а не в ноябре

Главный вывод из всего разобранного выше: проблема шумного соседа на shared-хостинге не устраняется диагностикой и не устраняется мелкими мерами — устраняется только переходом на инфраструктуру, где ресурсы не общие с чужими клиентами. На VPS с гарантированной (не burst) долей CPU и памяти ваши процессы физически не делят один и тот же PHP-FPM и одну и ту же базу данных с чужими проектами. Полностью проблема шумных соседей не исчезает и там — на уровне гипервизора есть своя, более мягкая версия того же явления, — но там у вас есть собственное ядро, cgroups-изоляция и, что важно, видимость собственных метрик, чтобы отличить свою проблему от чужой.

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

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

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

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