Linux для бэкенд-разработчика

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Инженеру

Большинство бэкендов в продакшене работают на Linux (или совместимых системах). Вам не нужно становиться администратором, но без базовой «консольной грамотности» отладка в Docker/Kubernetes превращается в угадывание.

Связанные материалы: терминал, администрирование Linux, компетенции бэкенда.

---

Минимальный набор команд

Задача	Команды
Где я, что в каталоге	pwd, ls -la, cd
Прочитать конфиг / лог	cat, less, tail -f /var/log/...
Найти файл или строку	find, grep -r
Место на диске	df -h, du -sh *
Кто слушает порт	ss -tlnp или netstat (если установлен)
Проверить HTTP с сервера	curl -v http://127.0.0.1:8080/health

Пайп | соединяет вывод одной команды со входом другой: cat app.log | grep ERROR | tail -20.

Перенаправление: > перезаписывает файл, >> дописывает, 2> — поток ошибок. Так пишут скрипты деплоя и cron-задачи.

Примеры для отладки API на сервере:

# Кто слушает порт 8080
ss -tlnp | grep 8080

# Время DNS, TCP, TTFB (удобно сравнивать с DevTools)
curl -s -o /dev/null -w \
  "dns:%{time_namelookup}s connect:%{time_connect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" \
  http://127.0.0.1:8080/health

# Хвост логов с фильтром
tail -f /var/log/myapp/app.log | grep ERROR

PID (Process ID) — номер процесса в ОС. Файловый дескриптор (FD) — «ручка» к открытому файлу или сокету; утечки соединений к БД — это часто незакрытые FD. ulimit -n — лимит FD на пользователя/сессию; при too many open files его поднимают вместе с настройкой пулов (бэкенд).

---

Процессы и сигналы

Запущенное приложение — процесс с PID. Веб-серверы часто используют модель master + worker: мастер принимает соединения, воркеры обрабатывают запросы.

Сигнал	Действие	Когда использовать
SIGTERM	Корректное завершение (graceful)	Остановка сервиса, rolling deploy
SIGKILL	Немедленное убийство	Процесс завис и не реагирует на SIGTERM
SIGHUP	Перечитать конфиг (у части демонов)	Смена nginx без полного рестарта

Команды: ps aux, top / htop, kill <pid>, kill -9 <pid>.

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

---

Дескрипторы и лимиты

Сокет, файл, pipe — в ядре это файловые дескрипторы (числа 0, 1, 2 — stdin/stdout/stderr).

Типичная авария под нагрузкой: too many open files. Причины:

• утечка соединений к БД без закрытия;
• HTTP без keep-alive и тысячи коротких TCP;
• лимит ulimit -n ниже, чем нужно приложению.

Диагностика: lsof -p <pid> — какие файлы и сокеты открыты процессом. На высоком уровне — метрики активных соединений и настройка пулов (бэкенд).

---

Память и OOM

free -h показывает RAM и swap. OOM Killer — механизм ядра: при нехватке памяти ядро завершает «жертву» (часто самый прожорливый процесс). В логах: dmesg, Out of memory: Kill process.

Для разработчика:

• задавайте лимиты контейнера осознанно;
• следите за утечками (рост RSS во времени);
• не кэшируйте без TTL всё подряд в heap.

---

Сервисы и планировщик

systemd управляет демонами: systemctl status myapp, journalctl -u myapp -f — логи сервиса.

cron — повторяющиеся задачи (очистка, отчёты). at — разовый запуск в заданное время.

Фон в текущей сессии: command &, nohup command & — процесс переживёт закрытие терминала (с оговорками для контейнеров).

---

SSH и перенос артефактов

На сервере нет браузера — отладка через SSH и curl. Копирование дампа БД или логов: scp, для больших объёмов — rsync.

Не работайте постоянно под root: лишние права = лишний риск при компрометации.

---

Типовой сценарий отладки

1. Воспроизвести на staging.
2. tail -f логов + корреляция по request_id.
3. Проверить health зависимостей (БД, Redis).
4. Сравнить метрики до и после деплоя.

---

Что изучать дальше

• Диагностика системных ошибок
• Контейнеризация
• Сеть для бэкенда

---