Упал сайт: кто отвечает — вы, разработчик или хостер

MAATRIX

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

Три зоны ответственности — и почему их путают

Когда сайт лежит, происходящее почти всегда укладывается в одну из трёх зон:

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

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

Признаки проблемы на стороне хостера

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

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

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

Признаки проблемы на стороне разработчика или кода

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

• Сервер формально отвечает, но вместо сайта показывает ошибку: «500 Internal Server Error», белый экран, стек-трейс, сообщение вроде «Fatal error» или «Application Error». Это принципиально другая картина, чем полная недоступность: сервер жив, сеть работает, а ломается уже само приложение при попытке обработать запрос.
• Панель управления хостингом при этом доступна и показывает, что сервер работает, ресурсы (диск, память, CPU) не исчерпаны критически — то есть инфраструктура снизу цела, а сбой выше, на уровне логики приложения.
• Незадолго до падения было изменение в коде — деплой новой версии, обновление плагина или CMS, правка конфигурации, миграция базы данных. Здесь помогает не память «вроде бы недавно что-то катили», а конкретика: посмотрите время последнего коммита или деплоя и сопоставьте с временем падения. Совпадение в пределах часов — сильный довод в пользу этой зоны ответственности.
• Автоматический деплой мог выкатить не то, что планировалось — ситуация встречается чаще, чем кажется, когда ночной или фоновый CI/CD подхватывает недоработанную ветку. Разбор одного такого случая — в статье «Ночной автодеплой выкатил ветку разработчика на боевой сайт».

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

Признаки проблемы на стороне владельца

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

• Прямо перед падением что-то меняли сами — заходили в панель управления хостингом и что-то там переключали, ставили новый плагин через админку CMS без участия разработчика, меняли DNS-записи у регистратора, отключали или включали какую-то интеграцию.
• Есть неоплаченный счёт. Это одна из самых частых и самых обидных причин: у многих хостеров и регистраторов доменов просрочка оплаты автоматически приостанавливает услугу, и вместо сайта показывается заглушка провайдера. Стоит проверить почту (включая спам) на письма о списании или задолженности — они обычно приходят за несколько дней до отключения.
• Истёк срок домена. Формально это тоже неоплаченный счёт, но проверяется отдельно — через сервис whois для вашего домена, а не в личном кабинете хостинга, потому что домен и хостинг нередко покупаются в разных местах и разными людьми в компании.
• Кто-то из команды недавно получал доступ и вносил изменения — новый сотрудник, временный подрядчик, стажёр, у которого был доступ к панели или CMS.

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

Практический алгоритм диагностики за 5 минут

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

1. Проверьте статус-страницу хостера, если она у него есть — обычно по адресу вида status.название-хостера или ссылке из личного кабинета. Активный инцидент там сразу закрывает вопрос: это зона хостера, писать в поддержку разработчика бессмысленно.
2. Попробуйте зайти в панель управления хостингом отдельно от самого сайта. Это самая быстрая и самая информативная проверка во всей методике. Логика простая: сайт и панель управления — это два разных сервиса, которые обычно живут на разной инфраструктуре внутри хостинг-провайдера. Если панель открывается и показывает, что сервер работает, — проблема почти наверняка не в «железе», а в приложении сверху. Если панель тоже не открывается — вероятность инфраструктурной проблемы у хостера резко растёт.
3. Вспомните, что менялось непосредственно перед падением — с обеих сторон: спросите себя (что делали сами) и спросите разработчика (что делал он или его автоматика — CI/CD, плановое обновление). Совпадение времени изменения и времени падения — самый сильный практический признак причины из всех перечисленных в этой статье.
4. Проверьте почту на счета и уведомления — от хостера, от регистратора домена, от платёжной системы, привязанной к автосписанию. Три минуты на это экономят часы взаимных выяснений, если причина оказывается именно здесь.
5. Если ни один пункт не дал однозначного ответа — пишите в обе стороны сразу, но с разными вопросами: хостеру — «сервер отвечает на пинг и доступен по SSH/панели?», разработчику — «что последнее катили и когда?». Так обе стороны получают конкретный проверяемый вопрос вместо общего «сайт не работает, помогите».

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

Почему нельзя просто писать всем «на всякий случай»

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

• Общий вопрос получает общий, а не приоритетный ответ. «Сайт не работает, срочно» без диагностики выглядит как одно из десятков похожих обращений в очереди и часто уходит в стандартный порядок рассмотрения.
• Обе стороны параллельно тратят время на проверку своей половины, которая может быть ни при чём — и это время идёт параллельно впустую, пока вы ждёте ответа от обеих сторон, не понимая, кто на самом деле разбирается в первопричине.
• Конкретный вопрос с диагностикой сразу отсекает половину причин. «Панель хостинга открывается, сервер отвечает, значит дело не у нас» — это ответ на 30 секунд, а не на 20 минут расследования с нуля.

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

Ловушка взаимных отсылок и как её избежать

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

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

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

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

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