Сайт не работает: что делать руководителю и маркетологу в первые часы

Первое действие — подтвердить, что именно не работает

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

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

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

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

Назначьте координатора и один канал связи

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

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

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

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

Какие сведения нужны технической поддержке

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

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

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

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

Что делать с рекламой, пока сайт недоступен

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

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

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

Зафиксируйте, кто и когда изменил рекламу. После восстановления сайта понадобятся обратные действия: вернуть кампании, проверить посадочные и убедиться, что временные ссылки не остались в объявлениях. Техническое исправление сайта само по себе не возобновляет остановленные источники обращений.

Как сохранить обращения и понятную связь с клиентами

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

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

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

Если на сайте размещают временное уведомление, его содержание и технический ответ согласуют с разработчиком. Для временной недоступности применяется статус 503; возможность указать ожидаемое время повторной попытки через Retry-After описана в документации MDN. Не поручайте маркетологу самостоятельно менять серверную конфигурацию в разгар сбоя.

Какие действия не стоит выполнять наугад

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

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

Не запускайте обновления «заодно», пока неизвестна причина аварии. Новая версия добавляет изменения, которые придётся отличать от первоначального сбоя. Сначала восстановите согласованный рабочий сценарий; дальнейшие улучшения оформите отдельной задачей после стабилизации.

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

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

Как убедиться, что сайт восстановлен

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

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

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

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

Что разобрать после завершения аварии

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

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

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

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

Памятка, которую стоит подготовить заранее

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

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

ШТАБ ИТ помогает организовать техническую поддержку сайта и проверку ключевых сценариев. Для обсуждения полезно принести описание последнего сбоя, перечень подключённых сервисов и имеющийся порядок обращения в поддержку. Это позволит определить, какие пробелы в подготовке действительно мешают вашему бизнесу.