Продвинутый Linux: как подходить к диагностике

Перед началом

Этот курс лучше проходить после Linux: Основные инструменты. Здесь мы уже предполагаем, что ты уверенно читаешь файлы и логи, пользуешься grep, пайпами и редиректами, понимаешь права доступа, пользователей, процессы, порты, systemd, journalctl, cron, диск и переменные окружения.

Если ты не проходил Linux Core и пока не чувствуешь себя уверенно с этими темами, лучше сначала вернуться к нему. Некоторые темы могут повторяться, и это нормальный процесс обучения: сеть, логи, процессы, сервисы и shell встречаются много раз, но каждый раз в более рабочем контексте. В Linux Advanced мы меньше объясняем базовую механику команд и больше тренируем инженерный подход: симптом -> факты -> гипотеза -> проверка -> исправление.

Если такой базовый набор уже есть, можно начинать отсюда. Некоторые инструменты будут встречаться повторно, но уже в более сложных сценариях: сеть, SSH, shell startup, bash-скриптинг, ресурсы, файловые системы и troubleshooting.

Продвинутый Linux начинается не с редких команд, а с правильного порядка расследования. Если система не работает, нужно не “перебирать флаги”, а быстро отделить факты от догадок.

Удобная схема:

Что именно сломано: команда, сеть, сервис, доступ, диск?
Где граница проблемы: клиент, сервер, процесс, порт, файл?
Какие факты уже есть: код ошибки, лог, статус сервиса?
Какой минимальной командой проверить следующую гипотезу?

Например, “сайт не открывается” может означать разные вещи: DNS не резолвится, порт закрыт, сервис упал, nginx отвечает 502, приложение не ходит в базу. Для каждой причины нужны разные проверки.

Важная идея: диагностика - это не перебор команд, а последовательная проверка гипотез.

Каждая команда должна отвечать на конкретный вопрос. Если вопроса нет, команда часто добавляет шум, но не приближает к причине. Хороший инженер после каждой проверки может сказать: “теперь мы знаем вот это, значит следующий слой такой”.

Главная привычка

После каждой команды формулируй вывод. Не просто “запустил curl”, а “HTTP отвечает 200 локально, значит процесс слушает и приложение живо; проблема может быть на внешнем маршруте”.

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

Диагностика как цепочка гипотез

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

Плохой ход: “сервис не отвечает, перезапущу всё”. Хороший ход:

Проверить, жив ли процесс.
Проверить, слушает ли он порт.
Проверить локальный HTTP.
Проверить маршрут и DNS.
Только после этого менять конфиг или перезапускать сервис.

Для каждой проверки должен быть ожидаемый результат. Например:

systemctl is-active myapp
ss -lntp | grep :8080
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/health

Если systemctl показывает active, но ss не показывает порт, значит процесс запущен, но не слушает нужный адрес. Если порт есть, но curl возвращает 500, сеть уже не главная гипотеза: приложение отвечает, но падает внутри обработки запроса.

Проверка до изменения и после изменения

Перед изменением зафиксируй состояние:

systemctl status myapp --no-pager
journalctl -u myapp -n 50 --no-pager

После изменения повтори короткую проверку:

systemctl is-active myapp
curl -fsS http://127.0.0.1:8080/health

Так ты видишь не только “команда выполнилась”, но и “система стала ближе к ожидаемому состоянию”. Это особенно важно при правах, ssh-ключах, PATH, cron, systemd и mount: команда может завершиться успешно, но не дать нужного эффекта.

Что фиксировать в выводе

Когда сохраняешь результат проверки в файл, сохраняй факт, который можно сравнить:

ip route > /root/routes.before
ss -lntp > /root/ports.before

После изменения можно сделать второй снимок и сравнить:

ss -lntp > /root/ports.after
diff -u /root/ports.before /root/ports.after || true

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

Минимальный runbook

Для большинства проблем применима структура:

Шаг	Вопрос	Примеры команд
Контекст	Где я и под кем работаю?	`pwd`, `whoami`, `id`, `hostname`
Состояние	Что сейчас происходит?	`systemctl status`, `ps`, `ss`, `df`, `free`
Логи	Что говорит система?	`journalctl`, `tail`, `grep`, `dmesg`
Гипотеза	Какой минимальный факт её проверит?	`curl`, `test -f`, `stat`, `ip route`
Изменение	Что меняю и почему?	одна маленькая правка
Проверка	Изменение сработало?	повторить короткую проверку

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