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

Почему Linux критичен для разработчика в 2026 году

На сегодняшний день более 90% серверных мощностей в облачных инфраструктурах работают под управлением дистрибутивов Linux. Если раньше разработчику достаточно было уметь пользоваться командой ls и cd, то сегодня на интервью уровня Middle+ и Senior проверяют глубинные знания ядра. Это связано с тем, что современные высоконагруженные системы требуют тонкой настройки на уровне операционной системы. Например, понимание того, как работает epoll, напрямую влияет на то, как вы проектируете асинхронные приложения на Go или Node.js.

Работодатели ищут инженеров, которые могут самостоятельно диагностировать проблему «повисшего» процесса или утечки памяти в Kubernetes-поде, не дожидаясь помощи SRE-специалиста. В 2026 году стандартным требованием стало понимание механизмов cgroups v2 и namespaces, так как именно на них строится вся контейнеризация. Если вы не знаете, чем отличается виртуальная память от резидентной, вы вряд ли сможете эффективно оптимизировать потребление ресурсов вашего микросервиса.

Кому полезен этот материал

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

Управление процессами и жизненный цикл

Процесс в Linux — это не просто выполняющийся код, а абстракция ядра, владеющая ресурсами: памятью, дескрипторами файлов и правами доступа. На собеседованиях часто просят объяснить разницу между процессом и потоком (thread). В Linux, благодаря модели NPTL (Native POSIX Thread Library), потоки технически являются процессами, которые делят общее адресное пространство. Команда ps -efL позволяет увидеть эти потоки (LWP — Light Weight Processes).

Важно понимать состояния процесса. Типичный вопрос: «Что такое Zombie-процесс и как его убить?». Ответ «использовать kill -9» неверный. Зомби — это запись в таблице процессов, которая остается после завершения дочернего процесса, пока родитель не прочитает его код возврата через системный вызов wait(). Чтобы убрать зомби, нужно отправить сигнал SIGCHLD родителю или перезагрузить родительский процесс.

Сигналы и межпроцессное взаимодействие

Сигналы — это программные прерывания. Разработчик должен знать базу: SIGTERM (15) для мягкого завершения и SIGKILL (9) для немедленного убийства процесса ядром. В 2026 году при работе с Docker и Kubernetes критично уметь обрабатывать SIGTERM в коде приложения, чтобы реализовать Graceful Shutdown — корректное закрытие соединений с БД и завершение текущих запросов перед остановкой контейнера.

# Поиск процесса, потребляющего больше всего CPU, и просмотр его потоков
ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -n 5
# Дерево процессов для понимания иерархии
pstree -p [PID]

Приоритеты и планировщик

Linux использует планировщик CFS (Completely Fair Scheduler), а в новых ядрах (6.x+) активно внедряется EEVDF. На интервью могут спросить про nice и ionice. Значение nice варьируется от -20 (высший приоритет) до 19 (низший). По умолчанию процесс получает 0. Важно помнить: только root может устанавливать отрицательные значения (повышать приоритет).

Файловая система и дескрипторы

«Всё в Linux есть файл» — эта фраза звучит на каждом втором интервью. Но что это значит на практике? Это значит, что сокеты, пайпы (pipes), устройства и обычные файлы представлены в системе через файловые дескрипторы (FD). Лимит дескрипторов — одна из самых частых причин падения высоконагруженных приложений. Ошибка Too many open files означает, что процесс исчерпал свой лимит ulimit -n.

Каждый процесс имеет три стандартных дескриптора: 0 (stdin), 1 (stdout), 2 (stderr). На собеседовании могут попросить перенаправить вывод ошибок в основной поток и в файл одновременно. Знание конструкции 2>&1 | tee output.txt показывает, что вы понимаете механику потоков данных.

Индексные дескрипторы (inodes)

Частая задача на интервью: «Место на диске есть (df -h показывает свободные гигабайты), но создать файл нельзя. Почему?». Правильный ответ: закончились inodes (индексные дескрипторы). Каждый файл занимает одну inode, и их количество фиксируется при создании файловой системы. Проверить можно через df -i. Это часто случается в системах с миллионами мелких файлов, например, в кэшах сессий или временных файлах.

• Soft Links: содержат путь к файлу. Если оригинал удалить, ссылка «сломается».
• Hard Links: указывают на тот же номер inode. Файл удалится только когда количество ссылок (link count) станет равным нулю.

Виртуальные файловые системы /proc и /sys

Разработчик должен уметь получать информацию о системе без сторонних утилит. Директория /proc — это окно в ядро. Например, cat /proc/[PID]/status покажет детальную информацию о потреблении памяти процессом, а /proc/cpuinfo — параметры процессора. В 2026 году это знание помогает писать скрипты мониторинга, которые не зависят от наличия установленного htop или top.

Оперативная память: RSS, VSS и Swap

Понимание работы памяти отделяет Middle от Senior. На вопрос «Сколько памяти ест ваш процесс?» нельзя отвечать цифрой из колонки VSZ (Virtual Size). VSZ включает в себя все выделенные адреса, включая общие библиотеки и память, которая еще не была фактически использована. Реальное потребление — это RSS (Resident Set Size). Однако и RSS может вводить в заблуждение, так как учитывает разделяемые библиотеки (shared libraries) несколько раз для разных процессов.

В современных системах для точного измерения используют PSS (Proportional Set Size) — это RSS, где общие библиотеки делятся на количество процессов, их использующих. Это самый честный показатель того, сколько физической памяти занимает приложение.

OOM Killer и баллы «плохости»

Out of Memory Killer — это механизм ядра, который выбирает и убивает процесс, когда свободная память заканчивается. Как он выбирает жертву? На основе oom_score. Чем больше памяти потребляет процесс и чем меньше он живет, тем выше его оценка. На интервью могут спросить, как защитить критически важный процесс (например, БД) от OOM Killer. Ответ: настроить oom_score_adj в сторону уменьшения.

Свопинг (Swap) и Swappiness

Существует миф, что Swap нужно отключать. В 2026 году это считается плохой практикой для большинства систем. Swap позволяет ядру вытеснять неиспользуемые страницы памяти, освобождая место под дисковый кэш (Page Cache), что ускоряет систему. Параметр vm.swappiness (от 0 до 200 в новых ядрах) определяет агрессивность этого процесса. Значение 10-60 обычно является оптимальным для серверных приложений.

Сетевой стек и диагностика

Разработчик бэкенда обязан знать, как проходит пакет от сетевой карты до приложения. На собеседовании часто просят описать 3-way handshake TCP и состояния сокетов. Особое внимание уделяется состоянию TIME_WAIT. Если сервер открывает и закрывает тысячи соединений в секунду, он может столкнуться с нехваткой портов из-за того, что сокеты «висят» в TIME_WAIT в течение 60 секунд (по умолчанию).

Для диагностики в 2026 году стандартом является использование ss вместо устаревшего netstat. Команда ss -ntlp покажет все слушающие TCP-порты и процессы, которые ими владеют. Для анализа задержек и потерь пакетов на пути к серверу полезно знать mtr (My Traceroute), который объединяет ping и traceroute.

Анализ трафика: tcpdump и Wireshark

Умение «снять дамп» — обязательный навык. На интервью могут дать кейс: «Приложение не может достучаться до БД, хотя пинги идут. Что делать?». С помощью tcpdump -i eth0 port 5432 можно увидеть, доходят ли пакеты до порта базы данных и отвечает ли она SYN-ACK или RST. Это позволяет быстро понять, проблема в коде, в фаерволе (iptables/nftables) или в самой базе.

Современные технологии: eBPF и XDP

В 2026 году на позициях Senior часто спрашивают про eBPF (Extended Berkeley Packet Filter). Это технология, позволяющая запускать безопасный код внутри ядра без изменения его исходников. eBPF используется для глубокого мониторинга сети (проект Cilium), безопасности и профилирования производительности. Знание того, что eBPF может перехватывать системные вызовы или фильтровать пакеты на уровне драйвера (XDP), даст вам огромное преимущество.

Производительность ввода-вывода (I/O)

Диск — самое медленное звено системы. На собеседовании любят спрашивать про iowait. Если top показывает высокий %wa, значит процессор простаивает, ожидая данных от дисковой подсистемы. Причиной может быть как медленное «железо», так и неэффективные паттерны записи в приложении.

Для детального анализа используется iostat -xz 1. Здесь важно смотреть на колонку %util (нагрузка на диск) и await (среднее время обслуживания запроса). Если await растет выше 10-20 мс, пользователи начнут замечать задержки в работе приложения.

Синхронный vs Асинхронный I/O

Разработчик должен понимать разницу между блокирующим и неблокирующим вводом-выводом. В Linux долгое время стандартом был epoll, который позволяет эффективно отслеживать тысячи соединений. Однако в 2026 году всё чаще говорят о io_uring — новом интерфейсе ядра, который радикально снижает накладные расходы на системные вызовы при работе с диском и сетью. Использование io_uring в высоконагруженных серверах (например, ScyllaDB или новые версии Nginx) позволяет добиться прироста производительности в 20-30%.

Файловый кэш (Page Cache)

Linux старается использовать всю свободную память под кэширование файлов. На вопрос «Почему у меня осталось всего 100 МБ свободной памяти?» нужно уметь ответить, что память занята под buff/cache и будет мгновенно освобождена ядром, если приложению она понадобится. Это штатное поведение, повышающее скорость работы с файлами.

Безопасность и права доступа

Классика интервью — вопрос про права chmod 755. Но Senior должен знать больше. Например, что такое SUID-бит. Если на исполняемом файле стоит SUID (например, -rwsr-xr-x), то он запускается с правами владельца файла (часто root), а не того, кто его запустил. Это потенциальная дыра в безопасности, если файл уязвим.

Также важно понимать механизмы ACL (Access Control Lists), которые позволяют задавать более гибкие права, чем стандартные owner/group/others. Команды getfacl и setfacl — ваши инструменты здесь.

Capabilities вместо Root

В 2026 году запуск приложений от root в контейнерах считается грубой ошибкой. Linux Capabilities позволяют разбить привилегии суперпользователя на мелкие части. Например, если вашему приложению нужно только слушать 80-й порт, ему можно дать CAP_NET_BIND_SERVICE вместо полных прав root. Это значительно снижает риск при взломе приложения.

Пространства имен (Namespaces)

Namespaces — это фундамент Docker. Существует несколько типов: mnt (файловая система), pid (дерево процессов), net (сеть), uts (имя хоста). На интервью могут спросить: «Как изолировать сеть процесса так, чтобы он не видел внешний мир?». Ответ: запустить его в отдельном network namespace без настроенных интерфейсов.

Системные вызовы и инструменты отладки

Программа общается с ядром через системные вызовы (syscalls). Самый мощный инструмент отладки для разработчика — strace. Он позволяет увидеть, какие файлы программа пытается открыть, какие сетевые запросы делает и на чем «зависает».

# Отладка процесса: смотрим только системные вызовы работы с сетью
strace -e trace=network -p [PID]
# Подсчет времени, затраченного на каждый вызов
strace -c -p [PID]

Если strace слишком сильно замедляет приложение (а он это делает, так как перехватывает каждый вызов), на помощь приходит ltrace (отслеживание вызовов библиотек) или современные инструменты на базе eBPF, такие как bpftrace.

Анализ открытых файлов с помощью lsof

Команда lsof (List Open Files) незаменима, когда нужно понять, какой процесс занял порт или какой файл не дает размонтировать диск. На собеседовании могут спросить: «Как найти все файлы, открытые конкретным пользователем?». Ответ: lsof -u username. Или «Какой процесс слушает 8080 порт?»: lsof -i :8080.

Контейнеризация и cgroups

В 2026 году Linux на интервью — это почти всегда Linux в контексте Kubernetes. Нужно понимать, как работают лимиты (Limits) и запросы (Requests) ресурсов. Это реализуется через cgroups (Control Groups). Cgroups ограничивают потребление CPU, RAM и I/O для группы процессов.

Важный нюанс: если вы ограничиваете CPU в Kubernetes (например, до 0.5 ядра), ядро использует механизм CFS Quota. Если приложение пытается потребить больше, оно будет «задушено» (throttling). Это можно увидеть в /sys/fs/cgroup/cpu.stat. Понимание этого механизма помогает исправлять проблемы с внезапным ростом задержек (p99 latency) в микросервисах.

Разница между cgroups v1 и v2

В современных дистрибутивах (Ubuntu 22.04+, RHEL 9+) по умолчанию используется cgroups v2. Она имеет единую иерархию ресурсов и более предсказуемое поведение. На интервью могут спросить, как проверить версию или как v2 улучшила управление памятью (например, через Memory Quality of Service).

Автоматизация и Bash-скриптинг

Даже если вы пишете на Rust или Go, умение быстро набросать bash-скрипт для обработки логов — мастхэв. На интервью часто дают задачу на обработку текста: «Из файла логов вытащить все уникальные IP-адреса, с которых было больше 100 запросов с кодом 404». Решение через awk, sort и uniq показывает вашу эффективность.

# Пример решения задачи
awk '$9 == 404 {print $1}' access.log | sort | uniq -c | awk '$1 > 100 {print $2}'

Знание базовых конструкций bash (циклы, условия, переменные окружения) и разницы между sh и bash (например, поддержка массивов и [[ ]]) — это стандартный чек-лист для любого разработчика.

Заключение: План подготовки к интервью

Подготовка к вопросам по Linux требует не только заучивания команд, но и понимания архитектуры системы. В 2026 году фокус сместился с администрирования «железа» на понимание того, как код взаимодействует с ядром в виртуализированной среде.

Чек-лист ключевых тем:

• Процессы: состояния, сигналы, зомби, потоки.
• Память: RSS/PSS, OOM Killer, Page Cache, Swap.
• Сеть: TCP handshake, сокеты, TIME_WAIT, ss, tcpdump.
• I/O: дескрипторы, inodes, epoll vs io_uring.
• Безопасность: chmod, SUID, Capabilities, Namespaces.

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