Если сайт не открывается или перестал принимать заказы, первый полезный результат — понятное описание сбоя и назначенный ответственный. Оно помогает передать проблему исполнителю и согласовать действия. Попытки одновременно поменять DNS, отключить защиту и восстановить базу могут добавить новые проблемы и затруднить поиск причины.
Ниже — предлагаемая процедура для владельца сайта и его команды: дерево первичной проверки, карточка инцидента и критерии восстановления. Она не устанавливает причину по одному сообщению браузера и не обещает устранить любой сбой за фиксированное время. Примеры в статье учебные.
Сначала определите, что именно перестало работать
Сообщения «сайт упал» недостаточно. Не открываться может весь домен, отдельная страница или только действие: отправка заявки, вход, оформление заказа. Главная при этом иногда продолжает работать.
Запишите точный адрес страницы, действие перед ошибкой, её текст и время с часовым поясом. Сделайте скриншот, скрыв персональные данные. Для заказа используйте внутренний номер; платёжные реквизиты, пароли и коды подтверждения в обращение не включайте.
Затем проверьте доступность обычным открытием страницы из другой сети, например через мобильный интернет вместо офисного Wi-Fi. Если проблема повторяется у нескольких людей, зафиксируйте их условия наблюдения. Такая проверка помогает оценить масштаб, но не доказывает доступность или недоступность для всех посетителей.
Если сбой затрагивает продажи, назначьте одного координатора. Он собирает сведения, передаёт их исполнителю и сообщает команде следующий шаг. Пока технический специалист разбирается, менеджеры могут принимать обращения по заранее согласованному резервному каналу.
Сбор сведений идёт параллельно с согласованным уменьшением последствий сбоя. Не нужно ждать полного расследования причины, чтобы специалист мог восстановить обслуживание безопасным способом.
Разделите наблюдение и предположение о причине
DNS связывает доменное имя с адресом сервера. TLS отвечает за защищённое соединение. CDN или обратный прокси могут принимать запрос перед приложением. Ошибка на одном из этих участков выглядит для посетителя как недоступность сайта, но требует разных проверок.
Владельцу бизнеса не обязательно диагностировать всю цепочку самостоятельно. Его задача — сохранить точное сообщение и условия, при которых оно появляется. Дальше специалист сопоставляет их с настройками, журналами и изменениями системы.
| Что наблюдаем | Что фиксируем | Кого подключаем в первую очередь |
|---|---|---|
Браузер не находит домен | Домен, время, текст ошибки, сети, где она повторяется | Ответственного за домен и DNS |
Браузер предупреждает о сертификате | Адрес и точный текст предупреждения; ввод данных прекращаем | Ответственного за TLS, хостинг или прокси |
Страница отвечает 502 или 504 | Код, URL, время, идентификатор запроса, если он показан | Техническую поддержку, которая видит прокси и приложение |
Работает главная, но не открывается раздел | Конкретный маршрут, способ перехода, входил ли пользователь в аккаунт | Разработчика приложения |
Каталог открывается, заказ или заявка не завершаются | Шаг, сообщение, внутренний номер операции, если он создан | Ответственного за этот сценарий и его интеграции |
Код 502 означает, что шлюз или прокси получил некорректный ответ от вышестоящего сервера; 504 — что он не дождался своевременного ответа. Это определения HTTP 502 и HTTP 504 в MDN. Коды сужают область проверки, но сами по себе не доказывают DDoS, взлом или неисправность конкретного компонента.
Передайте поддержке карточку инцидента
Карточка нужна, чтобы специалист мог воспроизвести проблему и сопоставить её с событиями системы. Заполняйте известное; неизвестные поля так и помечайте. Пустое предположение «наверное, атака» менее полезно, чем точное время и адрес ошибки.
Скопируйте этот шаблон в рабочее обращение:
Что не работает: страница или действие пользователя.
Где: домен и путь без секретных параметров ссылки.
Когда заметили: дата, время, часовой пояс.
Когда последний раз работало: время или «неизвестно».
Ожидали: какой результат должен был получить пользователь.
Получили: точный текст ошибки или код ответа.
Масштаб: какие страницы, пользователи и сети проверены.
Последние изменения: что известно и когда менялось.
Что уже делали: действие, исполнитель, время и результат.
Координатор: имя и рабочий канал связи.
Следующий контакт: когда согласовано обновление статуса.
Вложения: скриншот без персональных данных, номер операции.
Сведения о последних изменениях включают выпуск версии, настройки домена, сертификат, платёжный модуль или внешний сервис. Если команда ничего не меняла, это тоже стоит записать. Совпадение по времени ещё не доказывает причину.
Отправляйте карточку по согласованному каналу поддержки. Доступы передавайте отдельно штатным защищённым способом. Не прикладывайте к обычному письму полный журнал запросов, выгрузку клиентской базы или необработанный файл сетевой сессии: там могут быть данные пользователей и токены.
Согласуйте действия, которые меняют систему
Координатор отвечает за связь и хронологию, технический исполнитель — за проверку гипотез и предлагаемые изменения, владелец процесса — за бизнес-ограничения. В небольшой компании эти роли могут совмещаться; важно, чтобы участники понимали, кто принимает решение.
Для изменения запишите: что делаем, кто выполняет, какого результата ждём и как проверяем его. Если нужен откат, заранее выясните, какие данные или операции могли появиться после выбранной точки восстановления. Подробности этой задачи разобраны в статье о резервных копиях и восстановлении.
Не меняйте несколько независимых настроек одновременно без согласования. Не отключайте защиту и проверку сертификатов ради того, чтобы страница «хотя бы открылась». Не перезапускайте вслепую оплаченные заказы после таймаута: сначала нужно установить состояние операции. Эту ситуацию отдельно объясняем в материале о надёжных интеграциях.
Порядок с координатором, понятными ролями и общей записью происходящего соответствует подходу к управлению инцидентами в Google SRE Workbook. Наш шаблон — практическая редакционная адаптация для команды сайта, а не копия внутреннего регламента Google.
Три учебных случая: как меняется маршрут проверки
Эти случаи придуманы для объяснения процедуры. Они не описывают реальные аварии клиентов DDRW и не являются результатами проведённого тестирования.
Случай 1. После выпуска версии каталог отвечает ошибкой, главная работает. В обращении фиксируют маршрут каталога, время, код и известный момент выпуска. Разработчик проверяет журналы и изменения версии. Совпадение со временем выпуска — рабочая гипотеза; решение об откате принимают после оценки совместимости и данных. Критерий восстановления — открываются каталог и карточка товара, работает нужный пользователю путь.
Случай 2. После оформления заказа посетитель видит ожидание, а затем ошибку. Команда сохраняет номер операции и время. Ответственный за интеграцию проверяет состояние заказа в связанных системах. Пользователю не предлагают заново оплачивать его, пока не выяснен результат первой попытки. Критерий восстановления включает согласованность состояний и отсутствие повторной операции.
Случай 3. Из офисной сети сайт не открывается, через мобильную — открывается. В карточке отмечают различие сетей и точные сообщения браузера. Специалист проверяет доступность, разрешение домена и настройки ограничений. Наблюдение не доказывает ни глобальную аварию, ни атаку. Результат проверяют в том числе из сети, где возникла проблема.
Как понять, что работа восстановлена
Открытая главная — только один контрольный шаг. До закрытия инцидента повторите затронутый сценарий с теми же условиями, насколько это возможно: сетью, устройством, ролью пользователя и последовательностью действий.
Для магазина это может быть переход из каталога в карточку и оформление согласованного тестового заказа. Для формы — отправка заявки и её получение ответственным сотрудником. Для кабинета — вход и нужная операция с подходящими правами. Проверки оплаты выполняют в согласованном тестовом режиме, когда он предусмотрен; реальное списание ради проверки требует отдельного согласования.
| Результат проверки | Что сохраняем в записи инцидента |
|---|---|
Затронутый сценарий снова проходит | Какой путь проверен, кем и в какое время |
Связанные системы получили нужные данные | Идентификаторы и согласованные состояния без секретов |
Наблюдаемые ошибки прекратились | Интервал наблюдения и источник данных; его выбирает техническая команда |
Работающие ограничения сохранились | Проверены вход, права и защита, которых касалось изменение |
Команда знает итог | Что восстановлено, что ещё проверяется и кто отвечает за дальнейшие действия |
Исправление симптома и установление причины могут завершаться в разное время. Если работа вернулась, а причина ещё исследуется, так и запишите. Это точнее, чем закрыть обращение формулировкой «всё исправлено» без подтверждения.
Что подготовить до следующего сбоя
Сохраните карточку в доступном команде месте и заранее впишите контакты ответственных за домен, хостинг, приложение и ключевые интеграции. Согласуйте резервный канал связи, порядок доступа и кто может разрешить изменение. Уточните, какие пользовательские сценарии команда считает критическими.
Общие регулярные работы описаны в статье о сопровождении сайта после запуска. Если появились признаки постороннего доступа, нужен отдельный процесс сохранения свидетельств и ограничения последствий — он разобран в руководстве по защите сайта.
Поводом вернуться к теме стал отчёт Cloudflare о DDoS за III квартал 2026 года. Он описывает наблюдения сети этого поставщика и не устанавливает причину сбоя конкретного сайта. Для бизнеса полезнее заранее подготовленная передача инцидента, чем поспешный вывод об атаке по одному признаку.
Если вам нужно организовать сопровождение, DDRW может обсудить критические сценарии, границы ответственности и порядок проверки восстановления в рамках поддержки сайта.
Текст и иллюстрации подготовлены с помощью ИИ. Материал содержит предлагаемую процедуру и явно обозначенные учебные примеры; измерения на сайтах клиентов в рамках статьи не проводились.
