Миф: техподдержка хостера починит ваш сайт

MAATRIX

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

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

Хостер продаёт вам инфраструктуру, а не разработку. Конкретно в зону его ответственности почти всегда входит:

• Физическое железо — диски, оперативная память, процессор, блоки питания, охлаждение в дата-центре. Если диск сыплется битыми секторами или процессор троттлится из-за перегрева стойки — это его забота, и обычно она закрыта SLA на аптайм оборудования.
• Сеть — канал до дата-центра, маршрутизация, базовая защита от DDoS на уровне сети (L3/L4), доступность IP-адреса. Если сервер не пингуется извне, а у вас при этом всё запущено локально — это зона хостера.
• Гипервизор и виртуализация — на VPS это слой, который нарезает физический сервер на виртуальные машины. Утечка ресурсов гипервизора, «шумные соседи», которые едят чужой CPU без изоляции, — тоже его ответственность.
• Базовый образ ОС при выдаче сервера — вам предоставляют рабочий, загружающийся образ. Дальше, что вы в нём настроите — уже другой вопрос.

Формулировка SLA вида «доступность сети 99.9% в месяц» почти всегда касается именно этого списка: железо, сеть, гипервизор. Она не говорит и не может говорить ничего про то, упадёт ли ваш Laravel-бэкенд с необработанным исключением в контроллере. Это разные слои, и путать их — источник большинства разочарований от техподдержки.

Managed vs unmanaged: где проходит граница поддержки

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

Ключевой момент, который многие упускают: даже дорогой managed-тариф почти никогда не включает поддержку кода вашего приложения. Managed снимает с вас администрирование ОС и базового ПО — патчи ядра, обновления веб-сервера, настройку файрвола. Но никто не читает ваш app/Http/Controllers/OrderController.php и не находит там логическую ошибку — это не входит ни в один SLA, который видел автор этого текста. Подробное сравнение того, что именно меняется в цене и заботах между этими двумя моделями, — в статье «Управляемый VPS против неуправляемого».

Что поддержка не чинит — и почему это не отговорка

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

• Баги в коде приложения. Необработанное исключение, неправильная обработка null, ошибка в бизнес-логике расчёта скидки — это код, который написали вы или ваш разработчик. Поддержка хостера физически не имеет доступа к репозиторию и не обязана в нём разбираться.
• Конфликты плагинов и тем CMS. Классика WordPress: обновили один плагин — упал сайт из-за конфликта с другим. Это взаимодействие двух сторонних кусков кода, которые хостер не писал и не тестировал вместе.
• Неверная конфигурация .htaccess или nginx location, сделанная вами. Если вы сами правили правила редиректов и получили петлю — это ваша правка, и разбираться в её логике будет тот, кто её написал.
• Медленные SQL-запросы и отсутствующие индексы. Поддержка подтвердит, что ресурсов сервера достаточно, но не станет проектировать индексы под вашу схему базы — это работа с прикладной логикой данных, а не с инфраструктурой.
• Уязвимости в коде сайта. Если через старую версию плагина занесли веб-шелл, поддержка может помочь с изоляцией заражённого сервера на уровне сети, но не будет чистить код и закрывать саму дыру в приложении. Похожая путаница возникает и с защитными инструментами на периметре — подробно разобрано в статье о том, почему WAF не закрывает дыры в коде сайта: фильтр снаружи не то же самое, что исправленная уязвимость внутри.
• Просроченный SSL-сертификат, если у вас не подключено автопродление. Технически хостер может подсказать, что срок истёк, но следить за продлением конкретного сертификата для конкретного домена — обычно ваша задача, если это явно не входит в managed-пакет.

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

Как читать тариф, чтобы не удивляться потом

Граница поддержки почти всегда описана в тарифе — просто её редко читают до момента, когда сайт уже упал. На что смотреть при выборе:

• Формулировка «root-доступ без администрирования». Это прямой сигнал: вы получаете полный доступ и полную ответственность за всё, что происходит внутри ОС и выше. Поддержка ответит на вопросы про сеть и железо, но не будет чинить сервисы внутри.
• Слово «managed» и явный список того, что в него входит. У добросовестного хостера это не маркетинговый ярлык, а конкретный перечень: патчи безопасности ОС, мониторинг, настройка базового firewall, иногда — базовая настройка веб-сервера при первом запуске. Чем детальнее список — тем меньше сюрпризов.
• Shared-хостинг vs VPS/выделенный сервер. На shared-хостинге поддержка обычно шире в части CMS (это стандартизированное окружение, которое хостер полностью контролирует), но там же меньше гибкости и контроля у вас. На VPS и выделенном сервере гибкости больше, но и предполагаемая экспертиза на вашей стороне — тоже.
• Отдельные платные услуги «администрирование по запросу». Многие хостеры продают часы администратора отдельно от самого сервера — это честный способ закрыть разовую задачу с кодом или конфигом руками специалиста, не переплачивая за managed-тариф целиком, если такая помощь нужна нечасто.

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

Реальные кейсы: кто чинит, а кто нет

Проще всего граница видна на конкретных ситуациях — вот типичная раскладка:

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

Как работать с поддержкой, чтобы получить максимум пользы

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

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

# Доступен ли сервер и отвечает ли веб-сервер
curl -I https://your-domain.example

# Хватает ли места на диске
df -h

# Хватает ли памяти, нет ли OOM
free -m

# Что в логах веб-сервера прямо сейчас
tail -n 100 /var/log/nginx/error.log

# Жив ли процесс приложения (пример для PHP-FPM)
systemctl status php-fpm

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

Когда вопрос всё же к поддержке — по существу инфраструктуры или на стыке (не уверены, где граница), запрос стоит формулировать конкретно:

• Точное время инцидента и часовой пояс.
• URL или endpoint, где воспроизводится проблема.
• Текст ошибки как она видна вам (код ответа, скриншот, ID запроса, если есть).
• Что вы уже проверили сами (например: «диск не полон, процесс запущен, но соединение к базе обрывается по таймауту»).
• Прямой технический вопрос: «проверьте, пожалуйста, не режется ли исходящий трафик на порт 5432 файрволом на вашей стороне» — а не «почините сайт, он не работает».

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

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