# Сайт перестал работать: как организовать диагностику и восстановление

Источник: https://quicklanding.ru/knowledge/website-incident-response/

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

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

## Уточните, что именно не работает

![Команда работает за пультами и мониторами](/assets/images/knowledge/website-incident-response.webp)

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

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

## Назначьте координатора

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

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

| Шаг | Что зафиксировать |
| --- | --- |
| Обнаружение | Масштаб и время |
| Диагностика | Ответы и связанные события |
| Изменение | Кто, что и зачем сделал |
| Восстановление | Проверенный рабочий сценарий |
| Разбор | Причину и последующее действие |

## Проверьте ближайшие изменения

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

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

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

Возврат недавнего изменения, исправление конфигурации и восстановление копии имеют разные последствия. Проверьте совместимость кода и данных. Резервная копия может не содержать последние заказы и заявки, поэтому её возраст важен для решения.

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

## Подтвердите результат

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

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

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

## Документация и проверка сведений

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

- [MDN: коды ответов HTTP](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status)
- [WordPress: резервное копирование](https://developer.wordpress.org/advanced-administration/security/backup/)

## Материалы по соседним задачам

- [Мониторинг сайта: какие сбои стоит замечать автоматически](/knowledge/website-monitoring/)
- [Обновление сайта: тестовая копия, резервная копия и откат](/knowledge/website-update-process/)
- [Поддержка и развитие](/services/support/)

## Частые вопросы

### Нужно сразу восстанавливать вчерашнюю копию?

Сначала оцените причину и новые данные. Копия может исправить состояние, но заменить заказы и заявки, принятые после её создания.

### Главная открылась, значит работа восстановлена?

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

### После устранения ошибки разбор ещё нужен?

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

Автор: Владимир Николаев