Как думать о Linux-инструментах

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

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

Если этих навыков пока нет, сначала пройди стартовый курс. Некоторые темы и команды могут повторяться между курсами, и это нормально: в Linux навык закрепляется не одним прочтением, а повторением в разных рабочих ситуациях. Но лучше всё равно пройти предыдущий курс, потому что здесь повторение уже будет не “с нуля”, а в контексте логов, прав, процессов, сервисов и диагностики.

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

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

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

Для новичка Linux часто выглядит как набор разрозненных утилит. На практике они складываются в повторяемый сценарий:

1. Сформулировать вопрос к системе.
2. Найти источник фактов: файл, лог, процесс, порт, сервис.
3. Вывести данные минимальной командой.
4. Отфильтровать лишнее.
5. Сохранить результат или передать его следующей команде.

Например, вопрос “почему приложение отвечает 500?” превращается не в одну магическую команду, а в цепочку:

systemctl status app
journalctl -u app --since "10 minutes ago"
grep "ERROR" /var/log/app/access.log
ss -lntp

Каждая команда отвечает на маленькую часть общей картины. systemctl говорит о состоянии сервиса, journalctl показывает события, grep ищет важные строки, ss показывает сетевые сокеты.

Что важно понять перед лабораторными

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

В курсе будут часто встречаться три идеи:

Идея	Зачем нужна
“Всё можно прочитать”	логи, конфиги, /proc, вывод команд
“Вывод можно передать дальше”	пайпы позволяют собирать маленькие команды в цепочки
“Система оставляет следы”	процессы, порты, права, журналы помогают восстановить причину проблемы

Не пытайся сразу помнить все флаги. Лучше привыкай задавать вопрос: “какой факт мне нужен сейчас?”.

Где смотреть справку

Если не помнишь флаг или формат команды, это нормально. В Linux есть встроенная справка:

man ls
man grep
grep --help
sed --help

man открывает подробную страницу руководства. Внутри можно искать через /слово, переходить к следующему совпадению через n и выходить через q. --help обычно короче: команда выводит список основных опций прямо в терминал.

В справке часто встречается запись вроде grep [OPTION]... PATTERNS [FILE].... Квадратные скобки означают необязательную часть, а многоточие — что таких аргументов может быть несколько. То есть можно запустить и grep ERROR app.log, и grep -i -n ERROR app.log.

Как читать лабораторные задания

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

Например, формулировка “выведи первые 5 строк файла и сохрани результат” раскладывается так:

head -n 5 /opt/devops/lab1/app.log > /root/first5.txt

head -n 5 отвечает за действие, /opt/devops/lab1/app.log — источник, > и /root/first5.txt — сохранение результата. Если что-то не получилось, проверяй каждую часть отдельно:

ls -l /opt/devops/lab1/app.log
head -n 5 /opt/devops/lab1/app.log
cat /root/first5.txt

Такой подход важнее, чем угадывание “правильной” команды. В реальной работе ты часто не знаешь точного ответа заранее: сначала проверяешь входные данные, затем выполняешь маленькое действие, затем убеждаешься, что состояние стало ожидаемым.

Минимальная схема проверки

Перед изменениями полезно сделать короткую проверку текущего состояния. После изменений — такую же короткую проверку результата. Это особенно важно для прав, сервисов, cron-задач и конфигов.

ls -l script.sh
chmod +x script.sh
ls -l script.sh

Или для сервиса:

systemctl status myapp
systemctl start myapp
systemctl is-active myapp

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

Команды не существуют отдельно от контекста

Одна и та же команда может быть безопасной или опасной в зависимости от цели. cat безопасен для просмотра маленького файла, но неудобен для огромного лога. sed -i удобен для точечной замены, но меняет файл сразу. chmod -R быстро исправляет дерево файлов, но ошибочный путь может испортить права во всей директории.

Поэтому рабочая привычка такая:

Шаг	Что сделать
Проверить источник	ls, file, head, systemctl status, ss
Выполнить маленькую команду	сначала без длинного конвейера
Посмотреть результат	cat, tail, ls -l, systemctl is-active
Только потом усложнять	добавлять grep, awk, редиректы, циклы

Если лабораторная просит длинную цепочку, собери её постепенно. Это снижает количество ошибок и учит диагностировать собственные команды.