Разбор сбоев в Linux: 20 команд, которые я запускаю перед тем, как что-либо делать

Когда сбой происходит в 3 утра, самый быстрый способ потерять время — начать «пробовать что-то».

Случайные перезапуски. Случайные изменения конфигурации. Случайное масштабирование.

Они часто только усугубляют ситуацию.

После 5 лет дежурств я понял, что настоящее реагирование на инциденты — это не вопрос остроумия, а вопрос систематичности.

После каждого сбоя я изо всех сил пытаюсь ответить на три вопроса:

Что сломалось? (симптомы)
Где произошло повреждение? (радиус)
Что изменилось? (движение к первопричине)

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

⚡ Первые 3 минуты (скопируйте/вставьте этот блок)

Когда срабатывает алерт, я выполняю следующую последовательность действий:

uptime
top -o %CPU
free -h
df -h && df -i
ss -tulpn
journalctl -xe --no-pager | tail -n 80

Что вам это покажет за 60 секунд

✅ uptime → Средняя загрузка + стабильность системы
✅ top → Основные потребители CPU (CPU действительно является проблемой?) ✅ free -h → Давление на память / активное использование swap
✅ df -h / df -i → Диск заполнен ИЛИ исчерпаны inodes (оба случая могут «убить» систему)
✅ ss -tulpn → Что слушает порты + какие порты открыты (или отсутствуют) ✅ journalctl -xe → Последние критические ошибки, о которых сигнализирует система

Эти 6 команд позволяют вам получить контекст инцидента менее чем за минуту.

Теперь давайте углубимся в тему.

Раздел 1: хост выходит из строя? (CPU / Load)

uptime
top -o %CPU
ps aux --sort=-%cpu | head -n 15
mpstat -P ALL 1
pidstat 1

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

На что обратить внимание:

• Средняя загрузка процессора значительно превышает количество ядер CPU.
• Один процесс постоянно потребляет ресурсы процессора.
• Процессор работает нормально, но система тормозит → часто возникает задержка ввода-вывода (переход к разделу "Диск")

Пример из практики: средняя загрузка 47% на 8-ядерном сервере. Оказалось, что это был неконтролируемый скрипт на Python, потребляющий 780% ресурсов CPU (многопоточно). pidstat отобразил точный PID.

Раздел 2: давление на память / OOM

free -h
ps aux --sort=-%mem | head -n 15
dmesg -T | tail -n 120
journalctl -k --no-pager | tail -n 120

Используйте это в следующих случаях: сервисы перезапускаются случайно, поды/демоны падают, сервер нестабилен.

На что обратить внимание:

• Логи OOM killer: "Killed process 12345 (java) ..."
• Использование swap быстро растёт (80%+ — опасная зона)
• Один процесс раздувается в памяти

Ключевое правило: сначала фиксируйте доказательства (логи + снимок памяти), прежде чем перезапускать что-либо.

Почему? После перезапуска все улики исчезают. Вы не узнаете, что на самом деле произошло.

Раздел 3: заполнение диска или заполнение инода (оба фактора приводят к сбоям)

df -h
df -i
du -sh * 2>/dev/null | sort -h | tail -n 15

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

На что обратить внимание:

• Использование диска составляет 95–100%.
• Заполненность инодов составляет 100% (часто из-за миллионов маленьких лог-файлов).

Полезный совет: df -i команда, о которой все забывают. Я видел трехчасовые сбои, вызванные исчерпанием inode, когда диск был заполнен всего на 60%.

Раздел 4: удаленные файлы продолжают занимать место на диске (незаметный сбой)

lsof +L1

Используйте это, когда: df -h сообщает о заполнении диска, но вы "удалили 50 ГБ логов", и место не восстановилось.

Причина: удаленный файл по-прежнему остается открытым в рамках какого-либо процесса.

Как исправить: Перезапустить конкретный процесс (после сбора доказательств).

Пример из практики: однажды я потратил 2 часа на отладку дискового пространства. В логах было указано 89% заполнения. Удалил 40 ГБ. 89% всё ещё оставалось. Запустил команду lsof +L1→ обнаружил Java-процесс, удерживающий удалённый файл размером 45 ГБ. Перезапуск мгновенно исправил проблему.

Раздел 5: узкое место дискового ввода-вывода (система медленная, CPU в порядке)

iostat -xz 1
vmstat 1

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

На что обратить внимание:

• Долгое время ожидания диска (>50 мс — плохо, >100 мс — критично).
• vmstat показывает ожидания ввода-вывода / заблокированные процессы

Это самая распространенная ошибка в диагностике. Люди видят сообщение «система работает медленно» и предполагают, что проблема в процессоре. Часто же дело в дисковом вводе-выводе.

Раздел 6: что слушает? (порты + сервисы)

ss -tulpn
ss -s

Используйте это в следующих случаях: «Соединение отклонено», проверки работоспособности завершаются неудачей, трафик не доходит до сервиса.

На что обратить внимание:

• Сервисный порт не прослушивается (распространенная проблема после неудачного деплоя).
• Слишком много сокетов / давление соединений

Раздел 7: активные соединения

ss -tan state established | wc -l
ss -tan | head -n 30

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

На что обратить внимание:

• Огромное количество установленных соединений (>10 тыс. на одном хосте)
• Множество соединений находятся в странном состоянии (это может указывать на проблемы с вышестоящим сервером).

Раздел 8: основные сведения о сети (интерфейсы + маршруты)

ip a
ip r

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

На что обратить внимание:

• Отсутствует интерфейс / неправильно назначен IP-адрес
• Неверный маршрут по умолчанию
• Изменения маршрута после перезапуска или обновления конфигурации

Раздел 9: быстрая проверка доступности

ping -c 3 <target>
curl -I http://<service>
curl -vk https://<service>

Используйте это, когда нужно понять кто виноват: сеть или приложение.

Полезный совет: curl -vk бесценен для отладки TLS (цепочка сертификатов, ошибки рукопожатия, перенаправления, проблемы с SNI).

Раздел 10: состояние сервиса (systemd)

systemctl status <service>
systemctl is-active <service>
systemctl restart <service>

Используйте это, когда: подозреваете, что сервис сам упал или перезапускается в цикле.

Золотое правило: перед перезапуском сначала прочтите логи. В противном случае вы просто будете гадать.

Раздел 11: логи сервиса

journalctl -u <service> --since "30 min ago" --no-pager | tail -n 200
journalctl -u <service> -f

Используйте это, когда вам необходимо определить первопричину проблемы (ошибки конфигурации, сбои зависимостей, ошибки аутентификации).

Совет: используйте --since "30 min ago" параметр для снижения уровня шума. В большинстве случаев сигналы о сбоях в последних 30 минутах.

Раздел 12: последние системные ошибки (ядро + система)

journalctl -p err..alert --since "1 hour ago" --no-pager
dmesg -T | tail -n 120

Используйте это, когда вы подозреваете проблемы с ядром, драйвером диска или сети, либо обнаружили странное поведение хоста.

Что выявляет: ошибки нехватки памяти (OOM kill), сбои ядра, ошибки драйверов, аппаратные ошибки.

Раздел 13: что изменилось? (изменения конфигурации / временные метки)

ls -ltr /etc/<app>/
stat /etc/<app>/<config>

Используйте это, когда: сбои начался «после чего-то», но никто не помнит, после чего именно.

Почему это важно: 80% сбоев вызваны изменениями. Найдите изменение, найдите причину.

Раздел 14: Поиск сигналов в логах

grep -R "ERROR\|FATAL\|panic\|exception" -n /var/log/<app>/ 2>/dev/null | tail -n 50

Используйте это, когда логов слишком много, нужен моментальный вывод ошибок.

Альтернативный вариант journalctl -p err для сервисов, управляемых systemd.

Раздел 15: владение процессом (что это запустило?)

ps aux | grep <process_name>
pstree -ap | head -n 40

Используйте это, когда нужно увидеть parent/child связи (особенно runaway процессы).

Пример использования: зомби-процесс, который постоянно перезапускается. pstree показывает родительский процесс, который необходимо завершить.

Раздел 16: кто недавно вносил изменения в файлы?

find /etc/<app>/ -type f -mmin -120 -ls 2>/dev/null

Используйте это, когда каталог конфигурации большой, и вам нужно узнать, что изменилось за последние 2 часа?

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

Раздел 17: проверки DNS (да, часто виноват DNS)

resolvectl status 2>/dev/null || cat /etc/resolv.conf
dig +short <domain>
nslookup <domain>

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

Интересный факт: по моему опыту, 30% «загадочных сетевых проблем» — это DNS. Проверяйте его на раннем этапе.

Раздел 18: Отслеживание пути запроса (быстро)

traceroute <target> 2>/dev/null || tracepath <target>

Используйте это в следующих случаях: трафик между хостами/VPC/подсетями пропадает.

Что это показывает: где происходит потеря пакетов (правила брандмауэра, «черные дыры» маршрутизации, проблемы с пирингом VPC).

Раздел 19: Нехватка файловых дескрипторов (слишком много открытых файлов)

ulimit -n
lsof | wc -l

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

Распространенная причина: приложение не закрывает соединения/файлы должным образом. Проверьте код приложения.

Раздел 20: проверка времени (дрейф времени нарушает аутентификацию + TLS)

timedatectl status
date

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

Почему это важно: смещение времени более чем на 5 секунд может привести к поломке:

• Проверки JWT-токена
• Проверки TLS-сертификата
• Распределенного консенсуса (Raft, Paxos)
• Базы данных временных рядов

Распространенные ошибки, усугубляющие инциденты

Я совершал все эти ошибки. Учитесь на моих ошибках:

1. Перезапуск до сбора логов/доказательств → вы теряете неопровержимые улики. Всегда сначала фиксируйте данные.

2. Игнорирование df -i (инодов) → диск может быть заполнен на 60%, но система выйдет из строя, потому что иноды заполнены на 100%.

3. Предположение, что высокая загрузка CPU означает активные вычисления → Часто это задержка ввода-вывода, маскирующаяся под загрузку ЦП.

4. Отладка одного узла без проверки масштаба воздействия → Это касается одного хоста или всех хостов? Выясните это в первую минуту.

5. Устранение симптомов без выяснения причины изменения → Сбой повторится. Найдите первопричину.

✅ Краткий справочник: Схема команд при сбоях (краткое руководство на 1 минуту)

Ситуация: пользователи сталкиваются с тайм-аутами

uptime + top + ss -tulpn + journalctl -u <service>

Ситуация: всё работает медленно, но процессор, похоже, в норме.

iostat -xz 1 + vmstat 1

Ситуация: запись не выполняется / деплой не удаётся

df -h + df -i + lsof +L1

Ситуация: сервис работает, но по-прежнему недоступен.

journalctl -u <service> + grep errors + stat /etc/<service>/

Главный вывод

Реагирование на сбои — это не значит быть самым умным человеком в комнате.

Речь идёт о систематическом подходе.

Эти 20 команд — это моя система.

Скопируйте их. Вставьте. Создайте свой собственный runbook.

А когда в 3 часа ночи сработает сигнал тревоги, вы будете точно знать, с чего начать.