Когда сайт перестал открываться, команде важна не суета, а заранее понятный порядок действий. Сначала подтвердите сбой снаружи, зафиксируйте точный URL, время и симптом, затем назначьте одного координатора и передайте техническому специалисту одинаковый набор данных. Параллельно оцените влияние на заявки, оплату и пользователей. После восстановления проверьте не только главную страницу, но и ключевой сценарий.
Короткий план действий, если сайт упал
- Зафиксируйте сбой: точный адрес страницы, время с часовым поясом, текст ошибки и то, что видел пользователь.
- Проверьте сайт извне: откройте URL через другую сеть или используйте инструмент проверки сайта. Один браузер администратора не показывает ситуацию у всех посетителей.
- Определите масштаб: не работает весь домен или только форма, корзина, кабинет, API либо посадочная страница?
- Оцените влияние: остановлены ли заявки, продажи, оплата, вход пользователей или рекламный трафик?
- Назначьте координатора: один человек собирает факты, распределяет задачи и сообщает статус.
- Выберите маршрут: ошибка DNS, сбой после релиза и проблема сертификата требуют разных исполнителей.
- Восстанавливайте контролируемо: не меняйте одновременно код, DNS, сервер и сертификат.
- Подтвердите результат: проверьте проблемный URL, целевое действие и несколько последовательных внешних проверок.
Так тревожное сообщение «сайт упал» превращается в задачу с понятным владельцем и проверяемым результатом.
Какие данные собрать до эскалации
Эскалация — передача проблемы человеку, у которого есть полномочия и доступ для следующего действия. Она не должна быть простой пересылкой сообщения «ничего не работает». Соберите минимальную карточку инцидента:
- точный URL, а не только название домена;
- время первого наблюдения и часовой пояс;
- текст или код ошибки;
- скриншот без персональных данных и секретов;
- результат проверки из другой сети;
- перечень затронутых функций;
- сведения о недавнем релизе, изменении DNS, сертификата или настроек;
- контакт человека, который подтвердит влияние на бизнес.
Не отправляйте в общий чат пароли, ключи API, cookies и резервные коды. Доступы передают только утверждённым защищённым способом.
Если сайт не открывается на одном устройстве, исключите расширение браузера, локальный DNS-кэш, VPN и корпоративный прокси. Но обратное тоже верно: если сайт работает у администратора, это ещё не доказывает доступность для клиентов.
Как определить приоритет инцидента
Названия уровней могут отличаться. Важнее заранее договориться о критериях, основанных на влиянии.
Критический
Большинство пользователей не может открыть сайт или выполнить основное действие: отправить заявку, оплатить заказ, войти в кабинет. Координатор сразу подключает технического исполнителя и владельца бизнес-процесса. Если причина у хостинга, DNS-сервиса или внешней системы, обращение эскалируют и её владельцу.
Высокий
Сайт открывается, но сломана важная функция или коммерческий раздел. Например, главная отвечает, а форма заявки возвращает ошибку. Обычно нужен разработчик или специалист по интеграции, а владелец трафика решает, можно ли временно направить пользователей на исправную страницу.
Частичный или локальный
Проблема проявляется в отдельной сети, регионе или браузере. Сравните DNS-ответы, адрес назначения, TLS-соединение и внешний HTTP-ответ из разных точек. Затем подключайте сетевого специалиста, DNS-провайдера, CDN или хостинг.
Повышайте приоритет из-за реального влияния и расширения зоны сбоя, а не из-за громкости отдельной жалобы.
Кому передавать проблему по симптомам
Домен не находится или ведёт не туда
Проверьте DNS-записи и ответы авторитетных серверов, уточните недавние изменения у регистратора или DNS-провайдера. Подключите того, кто управляет зоной домена. Разработчик приложения не исправит неверную запись без нужного доступа.
Браузер показывает ошибку сертификата
Запишите имя хоста и точный текст ошибки. Проверьте срок действия, соответствие домена сертификату и полноту цепочки. Нужен администратор сервера или специалист, отвечающий за выпуск и установку SSL. Не предлагайте пользователям обходить предупреждение браузера.
Сервер отвечает кодом 500, 502, 503 или 504
Передайте время, URL, код ответа и информацию о последних изменениях. Для 502 и 504 проверьте связь прокси с приложением; для 500 — журналы приложения; для 503 — доступность сервиса и режим обслуживания. В зависимости от архитектуры понадобятся разработчик, администратор или хостинг.
Соединение завершается по timeout
Проверьте, возникает ли тайм-аут из нескольких сетей и на всех ли URL. Возможны перегрузка, зависший процесс, сетевой маршрут, фильтрация или недоступная зависимость. Подключите администратора сервера и при необходимости провайдера.
Код 200 есть, но функция не работает
Успешный HTTP-код не гарантирует исправность сайта. Если пропала форма, корзина или нужный текст, приложите шаги воспроизведения и ожидаемый результат, затем передайте задачу разработчику интерфейса или интеграции. Хостинг здесь не всегда первый адресат.
Как составить сообщение об инциденте
Сообщение должно позволять начать проверку без дополнительного опроса. Используйте шаблон:
Симптом: страница заявки возвращает 502. URL: точный адрес проблемной страницы. Начало: время и часовой пояс. Масштаб: воспроизводится через домашнюю и мобильную сети; главная открывается. Влияние: посетители не могут отправить заявку. Изменения: перед сбоем был релиз; других подтверждённых изменений нет. Проверено: внешний HTTP-ответ, соседняя страница, состояние сертификата. Нужно: проверить журналы приложения и связь прокси с приложением; сообщить статус координатору.
Фраза «после релиза» описывает временную связь, а не доказанную причину. Отделяйте факты от предположений.
Как работать во время сбоя
Один координатор и один канал статуса
Координатору не обязательно чинить сервер. Он следит, кто диагностирует, кто общается с провайдером, какие изменения разрешены и когда будет следующий статус. Решения фиксируются в одном канале или карточке инцидента.
Сначала безопасное восстановление
Если есть документированный и проверенный откат последнего изменения, его можно рассмотреть как способ восстановления. Нужно понимать, что возвращается, кто выполняет действие и как проверяется результат. Случайное восстановление старой копии может перезаписать актуальные данные.
Не делайте несколько изменений одновременно
Параллельный перезапуск сервисов, правка DNS и новая выкладка уничтожают часть диагностических следов и создают новые переменные. Сначала сохраните нужные журналы и состояние системы, затем выполняйте по одному согласованному действию с проверкой.
Клиентам сообщайте только подтверждённый статус: что затронуто, что команда занимается восстановлением и где появится обновление. Не называйте причину до её подтверждения.
Практические сценарии
После релиза появился 502
Внешняя проверка подтверждает 502 на нескольких URL, а статическая страница открывается. Координатор фиксирует время релиза, разработчик проверяет приложение, администратор — прокси и upstream. Если предусмотрен безопасный откат, его выполняют по инструкции. Затем проверяют код ответа и важный сценарий: авторизацию, форму или оформление заказа.
Посадочная страница отвечает, но форма не отправляется
Код страницы равен 200, поэтому простая проверка доступности не видит потерю заявок. Маркетолог фиксирует рекламный URL и шаги отправки, разработчик проверяет форму и интеграцию, владелец рекламы решает, нужно ли временно перенаправить трафик. В дальнейшем полезно контролировать наличие ключевого текста и связанный обработчик.
Сайт недоступен только части клиентов
Сотрудники видят сайт, а жалобы приходят из одной сети или региона. Команда сравнивает DNS-ответы, адрес назначения, TLS-соединение и HTTP-ответ из разных точек. После локализации инцидент получает владелец соответствующего уровня: DNS, сети, CDN или хостинга.
Как подтвердить восстановление
Один успешный ответ ещё не завершает инцидент. Проверьте, что:
- проблемный URL отдаёт ожидаемый код;
- страница содержит нужный текст, а не заглушку;
- редиректы ведут на правильный адрес;
- сертификат подходит домену и принимается браузером;
- форма, корзина, вход или другое критичное действие работает;
- внешние проверки проходят последовательно;
- мониторинг показывает восстановление без нового сигнала;
- координатор записал время и способ восстановления.
Автоматический мониторинг не исправляет сайт сам, но сокращает путь от жалобы до проверяемого инцидента. Web-Puls может регулярно проверять URL, сохранять историю и отправлять уведомления о падении и восстановлении. Подробнее — в материале как получать уведомление, если сайт упал.
Что подготовить заранее
До следующего инцидента определите:
- критичные URL и пользовательские действия;
- владельца каждого компонента и резервный контакт;
- критерии приоритета и порядок эскалации;
- безопасный способ передачи доступов;
- расположение журналов и инструкций;
- проверенный порядок отката;
- контакты хостинга, DNS-провайдера и внешних сервисов;
- канал статусов;
- проверки для подтверждения восстановления.
Настройте внешний мониторинг до сбоя и направьте уведомления тем, кто может начать реакцию. Для первого шага можно добавить сайт в Web-Puls и посмотреть историю доступности. Если проблема уже произошла и команде не хватает доступа или опыта для диагностики DNS, SSL, хостинга либо серверной ошибки, отправьте заявку через форму профессиональной поддержки или воспользуйтесь контактами. Укажите URL, симптом, время и уже выполненные проверки.
Вывод
Когда сайт упал, подтвердите сбой снаружи, соберите минимальные данные, оцените влияние, назначьте координатора, передайте проблему подходящему исполнителю и проверьте восстановление по пользовательскому сценарию. Заранее согласованный план эскалации экономит время и защищает диагностику от хаотичных изменений.