Сайт упал. Кому звонить: разработчику или хостингу?

Разработчик говорит: «Это сервер». Хостинг отвечает: «Оборудование работает». А покупатель не может оформить заказ. Владельцу магазина нужен не победитель спора, а человек, который доведёт восстановление до проверенного результата.

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

Почему «сервер доступен» не значит «магазин работает»

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

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

Вместо «у вас всё работает?» спрашивайте: «Что именно вы проверили и в какое время?»

Что собрать самому, не меняя настройки

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

• Адрес и действие. Какую страницу открывали, что нажали, на каком шаге остановились. Если в адресе есть ключ доступа или персональные данные, полную версию передавайте только специалисту по защищённому каналу.
• Время с часовым поясом. Когда заметили сбой и когда всё точно работало. Если начало неизвестно, так и напишите: время обнаружения не обязательно совпадает с началом аварии.
• Ошибка. Текст или скриншот без данных покупателей. Если виден идентификатор запроса, сохраните его вместе со временем.
• Масштаб. Не работает весь сайт или только оформление? Постоянно или иногда? Открывается ли та же страница с мобильного интернета? Разница поможет сузить поиск, но сама по себе не докажет причину.
• Недавние изменения. Обновление сайта или модулей, импорт каталога, изменение серверных настроек, перенос, запуск рекламы. Последнее изменение — повод для проверки, а не готовое объяснение сбоя.

Посмотрите, нет ли в личном кабинете хостинга уведомления об ограничении услуги или аварии. Если уже обращались в поддержку, приложите номер заявки.

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

Как перестать пересылать ответы между подрядчиками

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

Задайте три вопроса:

1. Кто ведёт разбор и собирает общую картину?
2. Что сейчас проверяет каждая сторона?
3. Когда будет следующее обновление статуса, даже если причина ещё не найдена?

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

Начать переписку можно так:

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

Что проверяет хостинг, а что — разработчик

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

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

Для магазина на 1С-Битрикс попросите разработчика назвать, что проверено в самом сайте, а что — в обменах с 1С, оплатой и доставкой, если они используются. Ответ «Битрикс работает» без указания проверенного действия мало помогает.

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

Код ошибки — подсказка, а не назначение виновного

Код 500 означает непредвиденное условие, помешавшее серверу выполнить запрос. Код 502 — некорректный ответ, который промежуточный сервер получил от другого сервера; 504 — отсутствие своевременного ответа.

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

До перезапуска сохраните то, что поможет разобраться

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

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

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

• Что меняем и почему это должно помочь?
• Что уже сохранили для диагностики?
• Чем рискуем, в том числе заказами и оплатами, появившимися после создания копии?
• Как проверим результат и что сделаем, если это не поможет?

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

Если есть подозрение на взлом

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

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

Изоляцию затронутых компонентов и ограничение доступов поручите специалистам. Полный сбор журналов не должен задерживать сдерживание активной атаки; порядок восстановления выбирают с учётом конкретной системы и характера инцидента.

Когда можно сказать, что магазин восстановлен

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

1. Путь покупателя. Каталог и карточка открываются, товар добавляется в корзину, оформление проходит без прежней ошибки.
2. Доставка и оплата. Нужные способы работают. Создание заказов и движение денег при проверке — только по согласованному сценарию; тестовый режим не подменяет проверку боевой настройки.
3. Обработка заказа. Заказ виден сотрудникам, уведомления приходят, подключённые обмены работают. Проверены зависшие за время простоя операции и риск дублей.
4. Мониторинг. Проверяется не только доступность сервера, но и важные для покупателей действия. Назначен получатель уведомлений и проверено, что они до него доходят.

Зафиксируйте, что проверено, а что ещё нет. Если восстановлена только часть функций, так и назовите статус.

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

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

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