Сайт открывается через раз: хостинг виноват или код — разбор кейса

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

заявка: сайт грузится, потом падает на 502, потом снова работает

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

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

версия первая: во всём виноват хостинг

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

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

где на самом деле терялись секунды

В логах медленных запросов на сервере обнаружился один и тот же SQL-запрос, повторявшийся по 40–60 раз в минуту ровно в момент пиковой нагрузки. Фильтр каталога по бренду и наличию строил выборку без нужного индекса и на каждый клик посетителя заново пересчитывал результат по всей таблице товаров, вместо того чтобы использовать готовый индекс и отдавать ответ за доли секунды. Пока трафика было немного, это проходило незаметно — таблица небольшая, лишняя доля секунды на запрос никто не замечал.

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

что можно проверить самому, без доступа к серверу

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

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

как за 15 минут понять, кто виноват — хостинг или код

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

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

во что обошлись три недели поиска виноватого

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

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

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

Диагностика показала два независимых узких места сразу, и оба требовали исправления, а не выбора одного виновного. В коде добавили индекс на таблицу товаров и переписали фильтр каталога так, чтобы он не пересчитывал выборку с нуля на каждый клик посетителя. На стороне инфраструктуры выяснилось, что число обработчиков PHP на сервере было занижено именно под пиковую нагрузку рассылок — здесь переезд действительно был нужен, но не абы на какой тариф наугад, а на сервер с ресурсами под конкретный пиковый трафик, а не под средний трафик обычного дня. У нас аренда сервера под такую нагрузку начинается от 1 100 ₽/мес за пользователя — и такой сервер вышел дешевле того VPS, который клиент уже успел взять вслепую, ещё до диагностики.

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

зачем проверять этот стык до того, как что-то отвалилось

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

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

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

Как быстро понять своими силами, виноват хостинг или код сайта?

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

Может ли сайт тормозить одновременно и из-за хостинга, и из-за кода?

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

Хостер уверяет, что сервер работает нормально — кому верить?

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

Стоит ли сразу переезжать на выделенный сервер, если сайт тормозит через раз?

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

Сколько стоит аудит, который различает проблему хостинга и проблему кода?

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