Получив сообщение о недоступности, откройте указанный адрес и проверьте, сохраняется ли проблема сейчас. Затем передайте техническому исполнителю время, адрес и результат проверки. Уведомление помогает начать разбор, но само по себе не объясняет причину.
Если вы прочитали сообщение через несколько часов, сайт уже мог восстановиться. Всё равно сохраните время события: оно понадобится для поиска причины повторного сбоя. Текущее состояние и прошлую ошибку записывайте отдельно.
Проверьте адрес, время и нынешний ответ
В событии найдите сайт, время проверки и показанный результат. Не путайте время сбоя, которое удалось наблюдать, со временем получения письма или открытия Telegram.
Откройте тот же адрес в браузере. Потом проверьте главную и одну важную страницу — например, каталог или запись на услугу. Если главная работает, а раздел нет, напишите об этом прямо. Выражение «весь сайт лежит» только расширит поиск без доказательства.
По возможности повторите через другое подключение, например мобильную сеть вместо офисного Wi-Fi. Запишите условия и результат; две попытки не устанавливают причину, но показывают, где проблема повторяется. Смысл отдельных результатов разобран в руководстве по мониторингу доступности.
Соберите короткое сообщение исполнителю
Для первого обращения достаточно нескольких полей. Ниже заполненный учебный пример:
Сайт и адрес: example.ru, /catalog.
Событие reChecker: ошибка ответа 04.10 в 10:05 МСК.
Проверка владельца: в 10:12 каталог не открылся через офисную и мобильную сеть.
Другие страницы: главная открывается; форму заказа не проверяли.
Последнее известное изменение: каталог опубликован в 09:40.
Просьба: проверить текущий ответ и записи сервера; сообщить следующий шаг и время ответа.Если последнее изменение неизвестно, не подставляйте догадку. Приложите точный текст ошибки или снимок без личных данных. Не нужно оформлять большой отчёт, пока пользователи сталкиваются с проблемой.
Передайте сведения назначенному техническому контакту: хостингу или разработчику, в зависимости от того, кто обслуживает сайт. Если сообщение нужно превратить в плановую задачу, используйте шаблон для разработчика.
Назначьте одного человека, который собирает ответы
Запишите, кто принял обращение и когда ожидается следующая информация. Если участвуют хостинг и разработчик, пусть один человек собирает их ответы и знает, какие изменения уже выполняются.
Не назначайте виновником хостинг по одному событию. Совпавшее обновление тоже пока только подсказка для проверки. Причину специалист должен подтвердить по состоянию сайта, коду или журналам сервера.
Не меняйте настройки наугад по нескольким советам из переписки. Одновременная замена адресов, удаление файлов и возврат старой версии могут затруднить восстановление. Если исполнитель предлагает временное решение, уточните, что оно исправляет, какие страницы затрагивает и как проверить результат.
Коллегам можно написать: «Каталог не открывается в наших проверках на 10:12 МСК. Обращение принял разработчик, следующий ответ ожидаем в 10:30». Обещать покупателям время восстановления стоит после подтверждения исполнителя.
Проверьте восстановление по исходному адресу
После ответа «исправлено» откройте тот же URL и повторите действие, на котором видели проблему. Проверьте важные страницы на основном домене. Если отказ касался формы, одного открытия главной для завершения задачи недостаточно.
Посмотрите следующие фактические результаты в кабинете контроля сайта. Успешная проверка подтверждает ответ в тот момент; она не заменяет ручную проверку заказа или получения заявки.
Запишите итог: «10:42 МСК, каталог открывается через обе сети, товар можно добавить в корзину. Отправку заказа не проверяли. Причина уточняется у разработчика». Сохраните номер обращения и выполненное изменение. Срочную проблему можно закрыть после проверки восстановления, а вопрос о причине оставить отдельной задачей, если ответа ещё нет.