Что делать при недоступности сайта

Подтвердите, что именно недоступно

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

Определите бизнес-влияние: остановлены ли обращения, покупки, работа сотрудников или только второстепенный блок. Это помогает выбрать приоритет и состав участников. Технический код ошибки важен, но не заменяет понимание нарушенного сценария. Пользователь может видеть 200 и при этом не иметь возможности завершить действие.

Назначьте управление инцидентом

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

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

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

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

Выберите безопасное восстановление

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

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

Сообщайте состояние без догадок

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

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

Учебный пример сбоя после выпуска

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

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

Проведите разбор после стабилизации

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

Какие сведения собрать до перезапуска недоступного сайта

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

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