Недоступность бывает на разных участках

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

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

Какие источники могут понадобиться

Обычно рассматривают журнал запросов веб-сервера, журнал ошибок, события приложения и сведения инфраструктуры. Если есть прокси, CDN, балансировщик или внешний API, их данные образуют отдельные участки цепочки. Отсутствие запроса в журнале приложения может означать, что он до приложения не дошёл.

В nginx состав записи журнала запросов определяется настройкой формата; это видно в документации модуля журналирования. Нельзя заранее обещать найти длительность обработки или идентификатор запроса, если соответствующие поля не записывались.

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

Как сохранить данные без потери смысла

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

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

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

Чек-лист фиксации сбоя

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

Условный пример: ответ 502

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

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

Какие выводы останутся ограниченными

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