Когда сайт перестаёт работать, первый порыв — гадать о причине. Перезапустить сервер. Откатить релиз. Позвонить хостеру. Иногда это помогает. Чаще на это уходят первые двадцать минут впустую.

Лучше начать с точного описания того, что вы видите. Симптом сужает причину до одного-двух уровней, и у каждого уровня своя первая проверка. На этой идее построено руководство. Определение простоя и его последствия см. в статье простой сайта.

Недоступен ли сайт для всех?

Прежде чем что-то менять, выясните, кого это касается.

  • Откройте сайт с телефона через мобильный интернет, а не через офисную сеть.
  • Посмотрите, что записал ваш мониторинг: когда произошёл первый сбой и какова была причина.
  • Попросите коллегу из другого места открыть сайт.
  • Проверьте, не сбоит ли только одна страница, одна страна или один тип устройств.

Если проблему видите только вы, причина, скорее всего, локальная: ваша сеть, закешированный ответ DNS, VPN или расширение браузера. Если её видят все, читайте дальше.

От симптома к первой проверке

Что вы видите Вероятный уровень Первая проверка
Страница не загружается, затем превышено время ожидания Сервер, сеть или файрвол Доступен ли адрес сервера вообще? Работает ли машина?
«Соединение отклонено» На порту никто не слушает Запущен ли процесс веб-сервера и на ожидаемом ли он порту?
«Сервер не найден» DNS или домен Разрешается ли имя? Не истёк ли домен?
Предупреждение о сертификате на весь экран TLS-сертификат Не истёк ли сертификат, не выдан ли он на другое имя?
500 Internal Server Error Приложение Журнал приложения на момент запроса
502 Bad Gateway Прокси не может работать с сервером за ним Работает ли сервер приложения и возвращает ли он корректные ответы?
503 Service Unavailable Перегрузка или обслуживание Не идёт ли развёртывание или окно обслуживания? Не исчерпаны ли ресурсы?
504 Gateway Timeout Прокси слишком долго ждал сервер за ним Не тормозит ли приложение, не завис ли оно?
200 OK, но страница сломана Логика приложения или зависимость Та часть страницы, которая не работает, и сервис за ней

Три кода шлюза определены в RFC 9110. Ответ 502 значит, что шлюз или прокси получил некорректный ответ от сервера за ним. Ответ 503 значит, что сервер сейчас не может обработать запрос, обычно из-за перегрузки или обслуживания, и в нём может быть заголовок Retry-After. Ответ 504 значит, что шлюз не дождался ответа вовремя. Во всех трёх случаях входная дверь открыта, а проблема находится глубже.

Команды для первого взгляда

С любой машины с терминалом:

curl -I https://example.com/

Команда выводит строку статуса и заголовки без тела ответа. Чтобы увидеть подробности, включая DNS-запрос, соединение и шаг проверки сертификата, добавьте -v:

curl -v https://example.com/ -o /dev/null

То, где обрывается вывод, показывает, на каком шаге случился сбой. Если вывод обрывается до «Connected», проблема в имени или в сети. Если во время проверки сертификата — смотрите сертификат. Если пришла строка статуса, сервер ответил, и статус подскажет следующий шаг.

Сервер и хостинг

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

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

Приложение и развёртывания

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

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

Прокси, балансировщики нагрузки и CDN

Многие сайты стоят за обратным прокси, балансировщиком нагрузки или сетью доставки контента (CDN). Когда прокси работает, а сервер за ним нет, посетители видят 502 или 504, часто на странице с оформлением прокси. Это оформление говорит, что передний уровень жив, а смотреть надо за ним.

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

DNS и домен

Если имя перестаёт разрешаться, сайт недоступен, каким бы исправным ни был сервер. Причины: удалённая запись, смена DNS-серверов, сбой у провайдера и истёкший домен.

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

Сертификаты

Истёкший сертификат или сертификат, выданный на другое имя, заставляет браузеры показывать предупреждение на весь экран. Сервер работает, но посетители не пройдут дальше. Проверьте даты и имена в сертификате. Причина и профилактика описаны в статье Как не допустить истечения SSL-сертификата.

Перегрузка

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

Посмотрите график нагрузки за минуты до первого сбоя. Если время ответа росло неуклонно ещё до недоступности, вероятна перегрузка.

Сторонние сервисы

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

Что может сказать монитор

Внешняя проверка, такая как у UptimeWire, запрашивает адрес и читает ответ. Для неудачной проверки она записывает причину. Среди причин, которые она различает:

  • не удалось разрешить доменное имя,
  • не удалось установить соединение,
  • нет ответа за 15 секунд,
  • недействителен TLS-сертификат или TLS-соединение,
  • сервер ответил определённым кодом ответа,
  • ожидаемый текст не найден на странице.

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

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

После восстановления

Когда сайт снова отвечает, запишите:

  • время первого сбоя и время восстановления,
  • симптом и причину,
  • что помогло починить,
  • что помогло бы заметить проблему раньше.

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

Чек-лист

  • Опишите симптом одним предложением.
  • Проверьте, у всех ли недоступен сайт.
  • Прочитайте записанную причину сбоя.
  • Выполните curl -v и посмотрите, где он обрывается.
  • Проверьте последнее развёртывание или изменение.
  • Проверьте DNS, домен и сертификат: они ломаются и без изменений с вашей стороны.
  • Запишите причину и способ исправления.