Если сайт перестал открываться вскоре после обновления, соберите время публикации, проблемный адрес и фактический ответ. Это позволит разработчику проверить связь между изменением и ошибкой. Само совпадение по времени ещё не доказывает, что виновата новая версия.
Сначала проверьте текущее состояние, как описано в порядке действий при недоступности. Для дальнейшего разбора важно выяснить, какая версия находится на основном домене и что одновременно меняли другие участники.
Уточните время публикации на основном сайте
Спросите разработчика: «Когда изменение стало доступно посетителям и как мы узнаем эту версию?» Время окончания разработки или загрузки файлов может отличаться от фактической публикации.
Зафиксируйте понятное обозначение, например «новое меню, опубликовано 04.10 в 09:40 МСК». Если исполнитель использует номер версии, добавьте его. Владельцу не нужно изучать весь код, но проверять разные версии под одной фразой «последнее обновление» неудобно.
Уточните параллельные действия. В тот же день могли менять настройки хостинга, адреса сайта или внешний сервис. Запишите только известные действия и их исполнителей. Если время приблизительное, отметьте интервал, а не придумывайте точную минуту.
Составьте короткую шкалу событий
Ниже пример сведений для разработчика. Он учебный; время и ответы нужно заменить вашими.
| Время, МСК | Факт | Источник |
|---|---|---|
| 09:35 | /catalog отвечает | Проверка reChecker |
| 09:40 | Опубликовано новое меню | Сообщение разработчика |
| 09:45 | /catalog не отвечает | Проверка reChecker |
| 09:48 | Каталог не открылся, главная работает | Проверка владельца |
| 10:10 | Каталог снова открывается | Проверка владельца после исправления |
По этой шкале видно, что проблему обнаружили после публикации. Не видно, когда она началась и почему. В «Контроле сайта» доступность проверяется по пятиминутному плану; между запросами состояние могло измениться.
Для технического разбора попросите проверить журнал сервера — логи — за указанный интервал. Если сервер записывает время в другом часовом поясе, исполнителю нужно учесть разницу. Время события reChecker и время из логов сохраняйте с обозначением источника.
Сравните проблемный и рабочий адрес
Проверьте главную, исходный URL и похожую страницу. Например, новый каталог не открывается, а старая карточка доступна. Это сужает вопрос: нужно исследовать конкретный раздел, а не утверждать, что весь сервер выключен.
Если ошибка возникает при действии — выборе варианта товара или отправке формы — запишите шаги и условия. Доступная страница не подтверждает работу этого действия. Сохраните точный текст ошибки и то, что должно происходить вместо неё.
Передайте разработчику шкалу, адреса и описание. Попросите назвать подтверждённую причину либо следующий способ проверки. Формулировка «Проверьте связь новой версии с этим ответом» полезнее просьбы подтвердить уже выбранного виновника. Правила проверки опубликованного сайта собраны в статье после обновления.
После возврата старой версии отделите две задачи
Решение вернуть старую версию принимает исполнитель, который знает устройство сайта. После возврата сначала проверьте восстановление: исходный адрес и действие, на котором была ошибка. Не ограничивайтесь успешной главной.
Потом уточните судьбу нового изменения. Возврат старого меню может восстановить каталог, но задача нового меню остаётся незавершённой. Запишите отдельно «сайт восстановлен» и «обновление нужно исправить и опубликовать снова».
Пример итога: «В 10:00 вернули прежнее меню, в 10:10 каталог открывается на основном домене. Связь ошибки с новым меню разработчик проверяет по логам. Перед повторной публикацией проверяем каталог и карточку с вариантами товара». Если причина не установлена, так и оставьте её открытой. Для нового выпуска используйте те адреса и условия, на которых произошёл сбой.