Сервер упал в три ночи: разбор полётов без паники

Часть 1 из 14 · Серия «Сервер в бою»

Три часа ночи. Телефон вибрирует: мониторинг сообщает, что сайт лежит. Или хуже — мониторинга нет, и вибрирует уже клиент: «У нас всё упало, срочно!». Вы открываете сайт — белый экран, 502, или браузер просто крутит колёсико в пустоту. Пульс подскакивает, руки сами тянутся к кнопке «Перезагрузить» в панели хостера.

Остановитесь. Именно в этот момент решается, чем закончится ночь: десятью минутами спокойной работы или тремя часами хаотичного тыканья по кнопкам. Эта статья — про первые минуты аварии. Не про конкретные сервисы (им посвящена вся остальная серия), а про метод: как понять, что именно сломалось, куда смотреть в первую очередь и почему перезагрузка — это не диагностика, а уничтожение улик.

Сначала выдохнуть: авария почти никогда не так страшна, как кажется

Неприятная правда: сервер, за которым никто не следит, рано или поздно падает у всех. Приятная правда: в 9 случаях из 10 причина банальна — кончился диск, кончилась память, умер один процесс, истёк сертификат. Это чинится за минуты, если вы знаете, куда смотреть.

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

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

Шаг первый: понять, что именно «упало»

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

Сайт не открывается вообще, браузер висит и отваливается по таймауту. Возможно, лежит сеть, сам сервер или nginx. А возможно — только ваш интернет. Проверьте сайт с телефона через мобильную сеть или через любой внешний чекер доступности. Смешно, но реальный процент «аварий» — это упавший Wi-Fi у самого админа.

Сайт отвечает, но ошибкой. Это уже хорошая новость: сервер жив, nginx жив, умерло что-то за ним. Код ошибки — ваша первая улика:

• 502 Bad Gateway — nginx работает, но не может достучаться до бэкенда. Классика: умер или захлебнулся PHP-FPM.
• 500 Internal Server Error — бэкенд жив, но код падает. Смотреть логи приложения.
• 503 Service Unavailable — сервис перегружен или закрыт на обслуживание.
• Ошибка сертификата — сайт, скорее всего, «жив», просто истёк SSL. Тоже чинится, и тоже не перезагрузкой.

Сайт медленный, но живой. Не авария, а деградация: кто-то ест ресурсы. Тоже разберём ниже.

Уже на этом этапе вы сузили поиск в разы — не выходя из браузера.

Шаг второй: триаж за 60 секунд

Теперь идём к серверу. Проверки — строго по порядку, от простого к сложному:

1. Пингуется ли сервер?

ping ваш-ip-адрес

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

2. Пускает ли SSH?

ssh user@ваш-ip-адрес

Если пустил — праздник: у вас есть руки внутри, и дальше всё решаемо. Если нет — не паникуем, а идём в пункт 3.

3. Что говорит панель провайдера?

Откройте личный кабинет хостера. Там два важных места: статус вашей VPS (запущена? нагрузка? график CPU не упёрся ли в потолок?) и страница статуса самого провайдера — возможно, авария у них, лежит вся стойка, и от вас вообще ничего не требуется, кроме чашки чая.

И там же — VNC/аварийная консоль. Это подключение к серверу «как будто вы воткнули монитор», в обход сети и SSH. Если сервер завис намертво или SSH недоступен, консоль часто показывает, на чём он завис: kernel panic на экране, приглашение логина (значит, жив, лежит только сеть или sshd), или бесконечные сообщения OOM killer. Про аварийную консоль забывают чаще всего — а это ваш последний и самый честный канал связи с машиной.

Шаг третий: если вы внутри — четыре команды, которые расскажут почти всё

SSH пустил. Не бросайтесь перезапускать сервисы — сначала снимите показания. Четыре команды, одна минута:

1. Нагрузка и аптайм:

uptime

 03:12:44 up 47 days,  5:03,  1 user,  load average: 0.71, 0.83, 0.79

Два вопроса к выводу. Первый: up 47 days — сервер не перезагружался, значит, проблема не в «внезапно ребутнулся». Если же аптайм — минуты, машина только что перезагрузилась сама, и это отдельная история (питание, kernel panic, действия провайдера). Второй: load average. Грубое правило — если число стабильно и заметно больше количества ядер, сервер захлёбывается. На VPS с двумя ядрами load 15 — это «мы нашли направление».

2. Диск:

df -h

Смотрите колонку Use% у корневого раздела. 100% на диске — причина доброй трети всех ночных аварий. Забитый диск ломает всё сразу и странно: база не может писать, сессии не создаются, логи молчат (им некуда писаться — да, авария, которая прячет собственные улики). Куда деваются гигабайты и как это предотвратить — тема пятой статьи серии, но ночью хватит найти и прибить самого жирного виновника.

3. Память:

free -h

Если available близко к нулю, а swap выбран под завязку — сервер в агонии, и, скорее всего, в дело уже вступил OOM killer (о нём ниже). Найти обжору:

ps aux --sort=-%mem | head -10

Та же команда с -%cpu покажет, кто выжирает процессор.

4. Живы ли сервисы:

systemctl --failed

Одна команда — и вам списком показывают всех покойников. Дальше точечно:

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

Смотрите на строку Active:. active (running) — жив. failed — вот и подозреваемый, а ниже в том же выводе — последние строки его лога с причиной смерти.

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

Почему перезагрузка — не диагностика

Теперь главный тезис статьи, ради которого она писалась.

Перезагрузка иногда возвращает сайт к жизни. И этим она коварна. Потому что она не лечит причину — она стирает симптомы. И заодно уничтожает улики: состояние процессов, содержимое памяти, список того, кто что ел, — всё это исчезает вместе с ребутом.

Разберём на самом частом ночном сценарии — OOM killer. Когда память кончается совсем, ядро Linux не падает — оно выбирает самый «дорогой» процесс и убивает его, чтобы выжили остальные. Обычно под нож идёт MySQL — он самый прожорливый. Итог: сайт в 502/500, база лежит, вы перезагружаете сервер — и всё работает! Победа?

Нет. Причина — нехватка памяти — никуда не делась. Через три дня, ровно в три ночи, OOM killer придёт снова. И снова. Вы вырастили себе хроническую болезнь и лечите её жаропонижающим. Проверить, был ли OOM, — одна команда:

dmesg -T | grep -i "out of memory"

или в журнале:

journalctl -k | grep -i "killed process"

Если там есть строки вида Out of memory: Killed process 1234 (mysqld) — поздравляю, диагноз поставлен без единого ребута. И решение будет не «перезагрузить», а «разобраться, почему MySQL столько ест» (спойлер: innodb_buffer_pool_size, статья 10 серии) или «пора добавить оперативки».

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

И ещё одно следствие: если сервер перезагрузился сам или вы всё-таки были вынуждены его ребутнуть — улики не потеряны безвозвратно. Журнал прошлой загрузки живёт здесь:

journalctl -b -1 -e

-b -1 — «предыдущая загрузка», -e — сразу в конец, к последним записям перед смертью. Часто именно там лежит вся разгадка.

Мини-шпаргалка на холодильник

Распечатайте, положите рядом. В три ночи мозг работает плохо, а бумажка — стабильно.

Что сделать утром, когда пожар потушен

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

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

Устраните причину, а не симптом. Убил OOM — разберитесь с памятью. Кончился диск — настройте ротацию логов. Умер PHP-FPM — выясните, почему (частый ответ — опять же память и pm.max_children, дойдём в девятой статье).

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

И проверьте бэкапы. Сегодня обошлось перезапуском сервиса. В следующий раз может не обойтись — а про бэкапы, которые реально спасают, мы уже подробно писали.

Падение сервера — это не катастрофа и не позор. Это плановое учение, которое жизнь устраивает без предупреждения. Разница между админом, который спокойно чинит за десять минут, и админом, который до утра жмёт «Перезагрузить», — не в опыте и не в таланте. Она в методе: посмотреть, что случилось, до того, как что-то трогать. Весь остальной цикл — про то, чтобы таких ночей у вас становилось меньше, а метода — больше.