Руководства

Что делать, если сайт упал: диагностика за 15 минут

· 6 мин чтения
Что делать, если сайт упал: диагностика за 15 минут

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

Минута 0–2. Это точно сервер?

Прежде чем лезть в консоль, убедитесь, что проблема не у вас и не в DNS.

  • Откройте сайт с телефона через мобильный интернет. Если открывается — проблема в вашей сети или у вашего провайдера.
  • Проверьте домен: nslookup example.com или dig example.com. Ответ должен содержать IP вашего сервера. Если нет — истёк домен, слетели DNS-записи или их кто-то поменял. Это не падение сервера, и лечится в панели регистратора.
  • Проверьте IP напрямую: curl -I http://IP_СЕРВЕРА. Если по IP отвечает, а по домену нет — снова DNS или сертификат.

Минута 2–4. Отделить сеть от сервера

Подключитесь по SSH: ssh user@IP.

  • Подключение проходит — сервер жив, проблема в приложении, веб-сервере или базе. Переходите к следующему разделу.
  • Не проходит — либо машина не работает, либо сеть, либо вы заблокировали сами себя (fail2ban после нескольких неудачных попыток входа — классика). Проверьте состояние сервера в панели провайдера, попробуйте подключиться из другой сети или через VNC-консоль в панели. Если сервер выключен или перезагружается — дождитесь, если провайдер сообщает о работах — тоже. Если панель говорит «работает», а SSH нет — с большой вероятностью firewall или fail2ban, и VNC-консоль здесь единственный вход.

Минута 4–8. Три причины, на которые приходится большинство падений

1. Кончилось место на диске

df -h

Причина номер один. Когда раздел заполнен на 100%, база не может записать транзакцию, веб-сервер — создать временный файл, PHP — сессию. Внешне — «ошибка 500» или «не удаётся подключиться к базе». Виноваты обычно разросшиеся логи или старые бэкапы, которые никто не удалял. Найти, что съело место:

du -sh /var/log/* /var/www/* /home/* 2>/dev/null | sort -h | tail -15

Быстрое лечение — очистить или урезать самый большой лог (truncate -s 0 /var/log/nginx/access.log, а не удалять файл, иначе служба продолжит писать в удалённый). Долгое — настроить logrotate и удаление старых копий.

2. Кончилась память

free -m
dmesg | grep -i "out of memory"
journalctl -k | grep -i oom

Когда память исчерпана, ядро запускает OOM-killer и принудительно завершает самый большой процесс — почти всегда это MySQL или MariaDB. Сайт при этом открывается, но показывает «Error establishing a database connection». Записи Out of memory: Killed process в выводе выше подтверждают догадку. Лечение сейчас — systemctl start mariadb. Лечение навсегда — либо уменьшить буферы базы и число процессов PHP-FPM, либо перейти на тариф с большей памятью: как посчитать, сколько нужно, — в статье «Как выбрать тариф VPS».

3. Служба не запущена

systemctl status nginx
systemctl status php8.3-fpm
systemctl status mariadb

Веб-сервер или база могли не подняться после перезагрузки или упасть из-за ошибки в конфигурации. В выводе status видны состояние и последние строки лога — часто причина написана прямо там: опечатка в конфиге, занятый порт, недостающий файл. Проверка конфигурации до перезапуска экономит много нервов: nginx -t, php-fpm8.3 -t, apachectl configtest.

Если служба не стартует и причина неясна — journalctl -u nginx -n 50 покажет её полный журнал.

Минута 8–12. Логи

Если очевидные причины отпали, ответ в логах. Три места:

  • Веб-сервер: /var/log/nginx/error.log или /var/log/apache2/error.log.
  • Приложение: лог PHP-FPM (/var/log/php8.3-fpm.log), лог самого сайта — у WordPress это wp-content/debug.log при включённом WP_DEBUG_LOG.
  • Система: journalctl -xe или /var/log/syslog.

Приём, который экономит больше всего времени: откройте лог в реальном времени и одновременно обновите сайт в браузере.

tail -f /var/log/nginx/error.log

Тогда видно, какая именно запись появляется в момент ошибки, и не нужно гадать среди сотен старых строк. Обращайте внимание на время: сервер может жить в UTC, а вы — в московском.

Минута 12–15. Нагрузка

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

uptime
htop
ss -tn state established | wc -l

Load average в uptime выше числа ядер — процессор перегружен. В htop смотрите, кто именно: MySQL с тяжёлым запросом, PHP-FPM с сотней процессов, неизвестный процесс с чужим именем (признак взлома). Тысячи соединений в третьей команде с одного или нескольких адресов — атака или агрессивный бот. Быстрая мера — заблокировать адрес: ufw deny from IP. Долгая — ограничение частоты запросов в Nginx и защита на уровне сети, о чём мы писали в разборе границы между VPS и выделенным сервером.

Чего не делать

  • Не перезагружать сервер первым делом. Если причина — заполненный диск или OOM, она вернётся через час, а логи перезагрузка не улучшит. Перезагружайте после диагностики или когда SSH недоступен совсем.
  • Не удалять файлы логов. Урезайте их (truncate): удалённый файл, который держит открытым процесс, место не освобождает.
  • Не править конфиги без резервной копии. cp nginx.conf nginx.conf.bak занимает секунду и спасает от второй аварии поверх первой.
  • Не восстанавливать из бэкапа, не поняв причину. Если упало из-за диска или памяти, восстановление ничего не изменит, а если из-за взлома — вернёт уязвимость.

Как сократить простой в следующий раз

Разбор после падения — уже потерянное время. Три вещи, которые дают больше всего:

  • Уведомления. Узнать о падении от мониторинга в 3 ночи лучше, чем от клиента в 9 утра. Минимум — внешняя проверка доступности каждую минуту с уведомлением в Telegram.
  • Пороги по диску и памяти. Оба заканчиваются предсказуемо; предупреждение при 80% заполнения превращает аварию в плановую задачу.
  • Проверенная резервная копия. Не «настроенная», а хотя бы раз развёрнутая на другом сервере. Иначе вы не знаете ни того, работает ли копия, ни сколько займёт восстановление. Держите её в другой стране: Lite за $6 в соседней локации — самая дешёвая страховка.

Если падения повторяются из-за нехватки памяти или диска, это не невезение — это сигнал, что тариф меньше проекта. Переход на старший делается без переезда за несколько минут.

Medium в Финляндии — $20/мес   Start в Нидерландах под бэкапы — $10/мес

Шпаргалка

  1. Телефон, dig, curl -I IP — исключить себя и DNS.
  2. SSH проходит? Нет — панель провайдера, VNC, другая сеть.
  3. df -h — диск.
  4. free -m, dmesg | grep -i oom — память.
  5. systemctl status для nginx, php-fpm, mariadb — службы.
  6. tail -f error.log + обновить страницу — логи.
  7. uptime, htop, число соединений — нагрузка и атаки.

Читайте также